Not my question, but actually quite an interesting problem:
Not my question, but actually quite an interesting problem:
How do I add file data to my EXE file at RunTime in delphi
Or to phrase it better:
How do I store and manipulate data inside the executable?
David Heffernan already has posted an answer and rightly suggests not to do it that way.
Of course this would also wreak havoc with virus scanners.
http://stackoverflow.com/q/36257250/49925?sgp=2
How do I add file data to my EXE file at RunTime in delphi
Or to phrase it better:
How do I store and manipulate data inside the executable?
David Heffernan already has posted an answer and rightly suggests not to do it that way.
Of course this would also wreak havoc with virus scanners.
http://stackoverflow.com/q/36257250/49925?sgp=2
windows allows a running executable to be renamed.
ReplyDeleteSo you rename yourself, copy yourself as original name, modify as much as needed and when terminated (by user or by other means) you are guaranteed to have the updates to your original exe (then you just remove the copy at startup).
A bit simpler than what David suggested and doesn't require you starting another instance, which may require to take into consideration the parameters and pass them along and maybe other issues like mutexes which don't allow multiple instances, making things a bit more complicated by involving a 3rd process.
David is correct. This won't work, ever. The first time the application crashes or hangs (forcing the user to kill it) the resources inside the EXE won't be in their latest state. Sometimes we have to explain our users that they are just trying to shoot themselves on the foot...
ReplyDeleteAlexandre Machado but isn't that also the case when you store data in a separate file?
ReplyDeleteHi Thomas, no not the same thing. You (at least should) have transactions, correct? Your DB file is always in consistent state, even if you kill the process. On the other hand, If you store the database inside the EXE, extract, modify and store it again, you don't have any guarantee that your process is atomic. How can you guarantee that in a single logical "transaction" you can store the modified file inside the EXE again and delete the old file? Lets say your application starts storing the file inside the EXE and Windows hangs... is your EXE still a valid x86/x64 Win applicaiton? I don't know... If your application starts and find a DB file left behind... what does it mean? The application failed to remove it (after storing it again), or the whole process failed? IMHO, this is a nightmare :-)
ReplyDeleteAlexandre Machado you're assuming that the program uses a database that supports transactions. Yes, that could be the case, and if implemented correctly it should prevent data corruption. But you could get the same level of data consistency by making the changes to a copy of your executable first and then move it to the original location, which is also an atomic operation on a modern file system.
ReplyDeleteThis whole question is driven by a customer with no clue stating requirements that are insane. It takes a degree of nerve to tell the customer that, and obviously it would need to be sugar coated!
ReplyDeleteDavid Heffernan it depends on the data and the situation in which the program is to be used. I could definitely think of a few use cases for this in my line of work. But none of them is currently worth the effort.
ReplyDelete