Saving data on the Exe itself..
BlitzMax Forums/BlitzMax Programming/Saving data on the Exe itself..
| ||
| Hi. lets say i have an app called Noter.exe and i want to save some preset data inside the exe itself. like Page size, color, etc.. First, Is it possible? Second, Is so, how do you exactly do that? maybe its a basic question.. but Ive never done that. I guess its something about defining some allocated memory or something. Cheers and TY |
| ||
| A running .exe can't write to itself since the OS will have an exclusive lock on the file while it is running. Realistically, you really should use the Microsoft guidelines on data storage locations to ensure it will work, and *continue* to work across future windows versions. https://blogs.msdn.microsoft.com/patricka/2010/03/18/where-should-i-store-my-data-and-configuration-files-if-i-target-multiple-os-versions/ But even if you could: 1) Modern Windows doesn't allow programs to write anything under the "c:\program files" folder structure post-install time 2) Pretty much all antivirus programs that use heuristics would/should prevent this from happening as well |
| ||
| If it's "default" or built-in data, you can Incbin files, and load them at runtime. If it's user-modifiable data, store it in the registry or the OS's official application storage area. |
| ||
| Well, you can. But it requires some trickery, and the caveats that xlsior mentioned still apply. You have to use a second application that writes to the first one, and to make it work you have to set it up to run right before the first one exits. The second application then has to wait for the first one to finish, then it can write to it. And optionally the second application can then restart the first one. Its pretty safe to append data to the end of an executable too, the EXE headers determine what is actually loaded into memory so the payload is never read by the OS loader. To find the payload, either use some magic number before it and do a search. Or better, write the size of the payload after it and seek to the right offset. If the payload size never changes, you could IncBin it and using the same method as above and overwrite the IncBined data instead. Ive only tested this on Windows btw... But honestly, id just use a config file or even the registry if i expected to land in Program Files. |
| ||
| the reason i asked that is because i tried to save some info on C: with windows 10 by using WriteStream.. command and it wouldnt allow me.. I guess due to windows restrictions.. |
| ||
| BaH.Volumes lets you get at the OS-specific folders with functions such as GetUserAppDir(). You'd normally create a subfolder in there for your app, and read/write whatever stuff you want. |
| ||
| Then you probably should have asked about that ;) Windows 10 does not allow writing to the root of C: and a bunch of other places unless the process has Admin rights. Though any other dir you create yourself is fair game. |
| ||
| Thats a great idea brucey tnx :) And yea grable good point :) I just thought its a good idea to keep some data on the exe itself. This way it never gets deleted. |
| ||
| I just thought its a good idea to keep some data on the exe itself. This way it never gets deleted. Well, but if you (for any reason) delete the .exe, you lose even the data: not a very good move! |
| ||
| yea... sure.. Degac, its not good for anything. in my case it is a simple settings data of a Text Editor. |
| ||
| Following Microsoft's advisory seems a better idea than trying to hack your way around the limitations, because they are bound to break again down the road. |
| ||
| @Hardcoal: Just use a config file, it's a lot less hassle and you'll get your application finished quicker. ;) |
| ||
| If your only going to run this from NTFS and dont need to transmit over a network, you could also use Alternate Data Streams. Windows itself uses it for Meta-Data attached to files/dirs, like that annoying "this file was downloaded and is insecure" popup. But you can use them yourself and stick anything in there, the data will follow the file so long as it stays on an NTFS volume. And you dont have to do anything special either, as its supported by most file level APIs, unless you want to enumerate them that is. Const TESTFILE:String = "c:\dump\ads.txt" Const TESTMETA:String = TESTFILE + ":myspecialmetadata" SaveString "test file for ads", TESTFILE SaveString "test ads meta-data", TESTMETA Print "contents of file -> " + LoadString(TESTFILE) Print "contents of meta-data -> " + LoadString(TESTMETA) |
| ||
| BaH.Volumes lets you get at the OS-specific folders with functions such as GetUserAppDir(). system folders love it.:) Don`t delete there C:/ drive. |
| ||
| Im going to exploit this post and ask this unrelated question. how come there is this stupid message from microsoft "this action cant be completed because the folder or a file in it is open in another program" how come windows cant tell you which program is using the file instead of sending you to search by your self? |
| ||
| Earlier Windows doesnt, but Windows 10 usually figures it out for you. But it will print the program name instead of the EXE if the application has the right metadata. As to why.. My guess is that MS is lazy, why fix something that doesnt count towards the new shiny, which is what they think sells their OS. Though a lot of this changed with Windows 10 imo. |
| ||
| In Windows 7 I use LockHunter to determine what process is holding the file. If the program can do it, there's nothing to stop MS from doing it, except for the reasons above. -Henri |
| ||
| Ya Henri, Agree... I can list you stupid things that microsoft is doing wrong but i will mention one more thing that bothers me. they wont allow you to chose the User files location they force you to have it in C. and thats dumb. when you format your computer you loose all your stuff their. |
| ||
| Hardcoal: in a corporate environment using domain controllers you can use roaming profiles where the info get stored/synced to the network. Home users have less options. |
| ||
| Don't know if this was answered to your satisfaction. You can certainly write to an EXE that is not being executed. For instance, if you want to create your own mini-compiler that builds single EXE w all the data you need. This has been considered and done already, it's not that difficult. |
| ||
| I'm all for the ini / xml solution. Static data via incbin. Please never ever use the Windows registry! |
   |