it can be done but not easily, but not with one app, you will need two at least on windows. the windows loader prevents direct modification of the image...
here's an outline of the loader process
0) create virtual address space for new process
1) map executable module into process's address space
2) parse executables import section
3) load and map required dll-files into address space
4) repeat 3 for each dll-file
5) start process
from this you would assume the following:
at step 0, space is allocated in the paging/swap file
at step 1, the PE is copied into this space
etc.
if you think about this, you will realize that app start times would be even worse than they are now... the work-around is that the system uses the actual image of the exe-file as the program's region of reserved space! this means that the file is locked to everyone except the kernel! translation: you cannot modify a running app's disk image.
the most obvious workaround to this is the use of a program to create a virtual drive, copy the image from the physical drive to the virtual one, delete the physical copy, start the copied app, &c.
another approach would be to compile "on-the-fly"...
at this point, I must stop helping you *unless* you can describe a legitimate use of this technique -- it's only real use is an attempt to defeat security measures on a system...
here's an outline of the loader process
0) create virtual address space for new process
1) map executable module into process's address space
2) parse executables import section
3) load and map required dll-files into address space
4) repeat 3 for each dll-file
5) start process
from this you would assume the following:
at step 0, space is allocated in the paging/swap file
at step 1, the PE is copied into this space
etc.
if you think about this, you will realize that app start times would be even worse than they are now... the work-around is that the system uses the actual image of the exe-file as the program's region of reserved space! this means that the file is locked to everyone except the kernel! translation: you cannot modify a running app's disk image.
the most obvious workaround to this is the use of a program to create a virtual drive, copy the image from the physical drive to the virtual one, delete the physical copy, start the copied app, &c.
another approach would be to compile "on-the-fly"...
at this point, I must stop helping you *unless* you can describe a legitimate use of this technique -- it's only real use is an attempt to defeat security measures on a system...