If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Big .EXE Startup behaviour "locked ad loaded"

Hi,

Since Windows Vista Windows seems to load the full exe file and lock it before it runs it.

Is there a way of changing both behaviours?

For example:
I'd like to provide a single .exe file with everything compiled in statically including resources so it is easy to download and requires no installation / uninstallation routine. The user can just download it and run it.
Second thing:
Integrated updater. As far as I know Windows locks the .exe file when started. But I'd like to provide a simple updater which automatically updates the program. I know there are workaround, but I just want to know if i can unlock the file and change it in place (like download to temp and if checksum is ok, copy it over the old exe and restart it).

Re: Big .EXE Startup behaviour "locked ad loaded"

Oh and I should say: I'l like to change loading behaviour like that only the executable code is loaded and the resources on demand. I thought there might be a way like some properties in the manifest or something.

Re: Big .EXE Startup behaviour "locked ad loaded"

Yea I know :-)

It's the way I do it now: having a "Loader" which does licensing, updating, etc... and the main stuff is in a DLL file. Everything is installed / uninstalled using NSIS.

My Post is more an enquiry if my ideas can be realized, having only 1 file for easyness doing everything and telling windows how to use the exe file. If it's not possible it's still okay, I'm just askin.

Re: Big .EXE Startup behaviour "locked ad loaded"

Since Windows Vista Windows seems to load the full exe file and lock it before it runs it.
Is there a way of changing both behaviours?

The first is just blatantly incorrect.
And the second is a direct result of how the first really works.

When you start an exe, windows will memoryMAP (not load) the exe image into the address space of your exe. Parts of the exe are then paged into actual memory as needed.

This means windows needs to assure that the exe image does not get changed while this is happening, and as a result this is achieved by opening the file in exclusive mode.

The above is also why "exe compressors" are so terribly bad. They force the entire exe image to be considered as data, negating any effect of the inate windows optimisations.

I'd like to provide a single .exe file with everything compiled in statically including resources so it is easy to download and requires no installation / uninstallation routine. The user can just download it and run it.

Actively downloading code over the internet and executing said code is just asking for serious security issues. While there certainly are methods for achieving this, the blanket statement here is:
"it's a bad idea". There is a reason why software needs to be installed, and why it needs to be installed in the security of an administrator.
Also, with DEP enforced (as is growing in popularity). The "bad idea" just became a "really really bad idea".

[quote]
Integrated updater. As far as I know Windows locks the .exe file when started. But I'd like to provide a simple updater which automatically updates the program. I know there are workaround, but I just want to know if i can unlock the file and change it in place (like download to temp and if checksum is ok, copy it over the old exe and restart it).[/quote
see above for why this is.
You cannot change this behaviour.

One obvious solution: start a 2nd exe, end the 1st, have the 2nd exe replace the 1st, have the 2nd exe restart the now replaced 1st.

Re: Big .EXE Startup behaviour "locked ad loaded"

Hi.

I see why this brings up security thoughts about this and if our projects would be "serious software" I would not ask such things ^^

Most projects are simple tools (small, with and without installation) and smaller games and demos with heavy media load (the reason why I am asking).
Those "huge-file" demos aren't meant to be installed especially in an enterprise environment.

They're some fun for 2-3 runs, then they normally will be deleted or "backed up" or given away by the viewer. They should be simple to run.

The target group should be able to handle it without installation/uninstallation, administrative help, etc. Download / recieve -> run -> be impressed / have fun -> (tell / give it away to potentially interested people) -> remove by pressing "del". Thats the life cycle and because of this simplicity I / we do not really care if DEP prevents execution or the App is sandboxed.

I just want to get rid of everything that makes it more complicated than necessary. So I try to avoid all unpacking / installation routines and like to update in place if the projects stays longer and needs to recieve updates.

Thank you very much for your detailed description.
I think Microsoft have those information you provided somewhere in the MSDN, but I was unable to find them (or maybe I'm just blind, I come from a linux background and am not that familiar with windows development). Maybe you could help me out with some links? I'd like to take care about everything that could cause trouble enjoying our projects as far as possible and as far it does not collide with our "as simple as possible"-way too much.

Re: Big .EXE Startup behaviour "locked ad loaded"

Since Windows Vista Windows seems to load the full exe file and lock it before it runs it.

The behavior (memory-mapping) was since the very early Windows NT versions. BTW, the behavior is applicable to any executable, driver, DLL, whatever. You have to explicitly unload the module from all processes to be able to overwrite its file.

I just want to get rid of everything that makes it more complicated than necessary.

Then get rid of your "modify-exe-code-bytes-on-the-fly" idea first of all.

The first important thing to know about PE files is that the executable file on disk is very similar to what the module will look like after Windows has loaded it. The Windows loader doesn't need to work extremely hard to create a process from the disk file. The loader uses the memory-mapped file mechanism to map the appropriate pieces of the file into the virtual address space. To use a construction analogy, a PE file is like a prefabricated home. It's essentially brought into place in one piece, followed by a small amount of work to wire it up to the rest of the world (that is, to connect it to its DLLs and so on). This same ease of loading applies to PE-format DLLs as well. Once the module has been loaded, Windows can effectively treat it like any other memory-mapped file.