The vaguely and helplessly expressed "reasons" like "cause I use many shortcuts" can no way server as a justification for any attempts to break some very fundamental computer paradigms. The solution with configuration and/or state file is perfectly feasible and regular way to solve any problems like that. Before considering any "esoteric" approaches, try to get the essence of programming using dominating paradigms, and at least don't waste you time on endeavour aimed to abuse the working paradigms of the OS you're using.
As a short note about feasibility of file creation of approach of the approach of cloning data in the file, let me explain one simple thing. In Windows systems, you cannot remove or modify any executable files currently loaded in memory. Surprise? Even though one can relatively easily work around this "limitation" (which is in fact not limitation but an important safety feature), I don't even want to discuss it. I prefer to explain how wrong and fruitless this approach is.
Have you ever head of the concepts of "universal Turing machine"? "Von Neumann architecture"? "Harvard architecture"? You are using a computer based on Intel or AMD CPU with
instruction-set architecture designed with Harward architecture in mind. Nearly all modern
operating systems follow this architecture which first of all means the architecture with stored program, and separate memory for storing a program and data; program memory is not modified during execution. These basic principles are translated onto all the basic conceptions related to programming, such as compiling/linking/loading of programs, executable files and everything on top of it.
Please see
http://en.wikipedia.org/wiki/Stored-program_computer[
^].
As soon as you work with languages and programming systems based on compilation (interpretive languages is a different story), and the compilation into the native CPU instruction-set codes, all the mainstream programming is based on the same principles. Development of CPU architectures led to possibilities for absolutely strict hardware protection of loaded program code and executable files from modification. You should embrace all the basic principles instead of fighting against them. At least, don't try to find against the fundamentals for such miserable goals like preserved "check boxes".
Speaking of the "many check boxes": at least get familiar with the concept of
finite state machine and think about its representation in data and operation.
Disclaimer. The above answer is written in response to v.2 of the question. I think it's good to know anyway.
—SA