Hi,

Just wondering, when an app is started, is it possible for it to open and write to it's own *.exe file? I was thinking this would be a way to 'permanently' update user options without using an *.ini or similar extraneous file.

Many thanks for any input

mori

discussed already
look for self-overwriting exe or so
maybe it could go to interesting threads

It is wrong way, because some antiviruses will be locking your program, when you will try to write in a exe-file.

just use the registry in this case

OK, thx all for the replies

mori

There was a self-deleting file example somewhere around these forums - if you find it - you may aswell find a way to change it.

The problem (or the difference from deleting) is that when you change that file, you need to mess with the PE headers again meaning you should have the source and FASM packed with your executable so you can reassemble it. Changing one byte might not harm a PE file, like changing the first instructino to INT3 to debug it , but by settings you mean at least 10 bytes... I think you need to change the dates and checksums and other stuff lying around the PE header.

You can change bytes inside the exe but don't add or remove them. Also you can add as much as you want to the end.

id go for having separate section for doing it and then CreateRemoteThread to modify those settings which does wait until app is closed and then change them to your exe... look for comrade's selfsave example(masm)...

Madis731: In fact it isn't such difficult. You don;t have to have a copy of FASM and your sources to reassemble everything. It can all be calculated. Like every PE packer/protector do. They get all values to be written in PE header during runtime.

Plue: and how do you do this in a way that works from win95 to XP SP2?

IMHO people seem to over complicate the task of self modifying an exe file at runtime. Especially if the information you wish to store is of a static size or a size that is no greater than a set limit.

I'll elaborate further,
While an EXE file is running you still have...
- Readonly access to the EXE file
- Ability to rename the file

So all your exe file has to do to edit itself is...
1- Rename itself to (ie: deleteme.exe)
2- Make a copy of itself with the correct EXE name
3- Edit the copy using the file io APIs
4- Run the copy and shutdown the old instance
5- The copy should have a short procedure at the beginning to deletefile "deleteme.exe".

People talking about adding sections and using PE analyses seems excessive


Now in step three you only need a simple loop going through the mapped view of the file searching for your unique string and changing the bytes after it to your new saved record data.

Not on win9x...

Besides, the rename-modify-relaunch will make your application "flicker in and out of existance" if you have any open windows (obviously), this looks pretty ugly.

Or you could just use environment variables to change default behavior. Much cleaner than worrying about rewriting .EXEs, IMO.

rugxulo, using the registry is obviously the correct solution, but it's out of the scope of this particular thread.

f0dder, you could have the new instance close the old one, so the it would be more of an overlap then a flicker.
But for serious use the only case where my method would be aesthetically viable would be if the data only needed to be saved at the shutdown of the program. (Because then no restart/flicker would be necessary)

AND how much longer do we have to make our code coddle win9x. It's newest iteration is 8yrs old. Not that it's a bad OS or anything, it's just antique

Do you mean time reduces the quality of software? I think that, for example, a game that we play today will be the same after 8 years (if it isn't lost in that period, of course ). It will still be the same. Just think a bit.

Okay, I'm no Microsoft old-product-lover, and I certainly don't say Win9x has higher quality than Win2K, but it was only an example. Take your time and analyze those things, and then say what most people say, that products are being poorer (sorry, can't find better word) by age. This is nonsense. Those who say that are usually spoilt people...

Personally, if I was in charge of the world, I would let people appreciate all things, and only give them the "cooler toys" after they appreciated the "old toys". This way will they understand everything and not be blinded by "toys will suck in time, cooler is magic, etc.." and then they'll see the truth about it.


About your method: I see it as kinda brute-force one.. I simply don't like it (of course no offense)...

And Registry sucks!! Imagine what kind of trash is in there!! If all programs had only .ini we wouldn't even need to install them -- we could just copy them (if we had information, of course). The only thing that has to be modified this way will be the application path, but that's not a big deal, since it can be obtained with APIs, so why write it in Registry.

From my point of view, Registry was one of the bad designs of Windows -- it grew so popularily that we simply have to live with it

The registry has pretty fast data access, though - you don't need to parse text files, and it has binary search to look up keys. The downside is that many people forget to defrag their drives...

Why not make .ini binary then, and a .ini editor like regedit?

you can make small registry for each program

Yes I know, but it still adds up in the Registry after you "apply it". That's why you need Registry cleaners and no Ini cleaners.

The only real advantage of registry cleaners is to clean up COM components and filetype associations, stuff like that. They don't speed up your system because entries are removed, really, but because of the type of entries they clean up...