Including a file in a program + Saving settings TO a program

[rcmaehl]

Okay first off, currently my script I'm working on uses a file in the directory it's running in as the background. However, I was wondering if there's a way to include the background file INSIDE the compiled script so I can use GUICtrlCreateIcon(@ScriptFullPath, Icon, 0, 0, @DesktopWidth, @DesktopHeight) or something of the sort. The background is 1280x1024 if that will help at all.

Secondly, is it possible to write settings to the program itself. As in saving the settings to hex at the end of the compiled script or a seperate file (non-plain text). If so how would I do so, as it would be EXTREMELY helpful in abuse prevention of the settings file, because currently what I'm using for a settings file is a settings.ini with FileSetAttrib(".\settings.ini", "+RSH") and that's not really portable and really just plain annoying. EDIT: Basically I need a way to write to a file that isn't encrypted/hashed that can't be edited without a hex-editor or such, while still being portable. EDIT: Going to use binarytostring and vice versa to convert the settings.ini file, read/write what's needed, and convert it back.

Problems solved, thanks everyone!

Thanks -RC

Edited November 2, 2011 by rcmaehl

[nitekram]

For the first one - FileInstall()

For the second one - maybe an INI file?

edit - nevermind - it looks like you are using an INI file - maybe writing the registry?

Edited November 2, 2011 by nitekram

[guinness]

Your first question is search Resources.au3 by Zedna. The other one is a little tricky to do & not for the novice user, plus it's more work required. I would say stick to the INI file which is Portable if used correctly. I have no idea why you have to hide it?

edit - nevermind - it looks like you are using an INI file - maybe writing the registry?

This isn't considered portable by the portable freeware community. Edited November 2, 2011 by guinness

[BrewManNH]

Secondly, is it possible to write settings to the program itself. As in saving the settings to hex at the end of the compiled script or a seperate file. If so how would I do so, as it would be EXTREMELY helpful in abuse prevention of the settings file, because currently what I'm using for a settings file is a settings.ini with FileSetAttrib(".\settings.ini", "+RSH") and that's not really portable and really just plain annoying.

Thanks -RC

You can still use an .ini file for the settings, if you encrypt the ini file they will have a harder time changing the settings in it.

Use something like this

$OutFile = @TempDir & "\temp.txt"
 _Crypt_EncryptFile($IniFile, $OutFile, "Au+01+R0ck$", $CALG_AES_256)
FileMove($OutFile, $IniFile, 1) ; move the temp file to the ini file overwriting it

[rcmaehl]

This is considered Portable by the portable freeware community.

Writing to the registry is considered portable? O_o I thought it wasn't.

You can still use an .ini file for the settings, if you encrypt the ini file they will have a harder time changing the settings in it.

Use something like this

$OutFile = @TempDir & "\temp.txt"
_Crypt_EncryptFile($IniFile, $OutFile, "Au+01+R0ck$", $CALG_AES_256)
FileMove($OutFile, $IniFile, 1) ; move the temp file to the ini file overwriting it

I had edited my first post because I don't want to encrypt the file if I can directly write the settings to the Hex of the compiled script. EDIT: Also the script will be opensource so they won't have a hard time because they'll have the encryption key.

In general, I'm trying to cut down the number of files that would be inside the directory of the script while still having everything with it.

Edited November 2, 2011 by rcmaehl

[guinness]

I made a mistake in my previous post, plus if you're interested then search for _WinAPI_UpdateResource, but this blows your whole less files problem out the water (I would be happy to explain why.)

Edited November 2, 2011 by guinness

[nitekram]

This isn't considered portable by the portable freeware community.

Not sure how it would be portable in any sence then? As if I were to use the program on one computer, I would have to then bring the INI file or whatever with me to the next computer - although - that would be a lot easier then trying to export the registry and importing it into the next computer.

[guinness]

If you have the application on a USB drive in a folder with the INI file next to the exe then it's not difficult to transport and messing with the registry without/limited knowledge is just asking for problems.

Edited November 2, 2011 by guinness

[nitekram]

If that is the case, USB drive, then I would not inflate the compiled EXE with installing the files needed into it, I would just put them in the same directory as the EXE and the INI file?

[rcmaehl]

If that is the case, USB drive, then I would not inflate the compiled EXE with installing the files needed into it, I would just put them in the same directory as the EXE and the INI file?

That is what is generally done, however, if I could merge any of the files together into one file and decrease the file count it would be less files to move. Basically, some other people (and myself) have a huge folder full of files that go with portable programs and searching through those can take time. Also, is it possible to merge the settings and background image into a dll or something, then again I don't know how to make a dll so you'd have to teach me...

[nitekram]

I do not think that will work, as once the application is compiled the FileInstall() function will include them with your EXE but then it needs to be able to extract/place those files within a directory of your choice - in this case a USB drive, and then you are back to square one with the big list of files that you wanted to stay away from.

But the Resources.au3 by Zedna - might be different, have not looked at the code.

edit spelling mistake

edit ps - if you are looking to just make it easier to move all the files at one time, not having to look for them and then transport them - then FileInstall() could be helpful.

Edited November 2, 2011 by nitekram

[guinness]

If that is the case, USB drive, then I would not inflate the compiled EXE with installing the files needed into it, I would just put them in the same directory as the EXE and the INI file?

From experience users like to delete files regardless of their function, so if a settings file is deleted no problem re-create it. If an image file is deleted then of course it's a different matter. My suggestion still stands, look at Resources.au3, a 23KB file isn't going to be a noticeable difference in file size , unless they're using a floppy drive!

Which looks easier to 'transport'? An exe, settings file and a folder labeled 'bin' with 100 jpgs? Or an exe and settings file?

Edited November 2, 2011 by guinness

[BrewManNH]

Your edit to your second question makes no sense at all. You don't want it encrypted, but you don't want it editable unless you have a hex editor. I don't understand why encrypting the file wouldn't make harder to alter it? In light of this statement "as it would be EXTREMELY helpful in abuse prevention of the settings file", encrypting the file to prevent abuse of the setting file just makes it a tiny bit harder to do so unless they have the key to decrypt it.

Also, if you FileInstall all of your needed files into the exe when you compile it, you can designate where to put the files when you run the program, and if you wanted to delete them after they're no longer needed, your script can do that for you too. There's no searching for files needed if you clean up after yourself in your script.

[rcmaehl]

From experience users like to delete files regardless of their function, so if a settings file is deleted no problem re-create it. If an image file is deleted then of course it's a different matter. My suggestion still stands, look at Resources.au3, a 23KB file isn't going to be a noticeable difference in file size , unless they're using a floppy drive!

Which looks easier to 'transport'? An exe, settings file and a folder labeled 'bin' with 100 jpgs? Or an exe and settings file?

I'm trying to make it so that all the files are inside the EXE. So it's easier to transport an EXE than an EXE and a settings file, however I WILL look into resources.au3. Thanks!

encrypting the file to prevent abuse of the setting file just makes it a tiny bit harder to do so unless they have the key to decrypt it.

Notice in one of my posts I say that they DO have the key.

Edited November 2, 2011 by rcmaehl

[guinness]

He changed the initial post again BrewManNH. BinaryToString/StringToBinary vs Encryption...interesting.

The code is Open Source, but this doesn't mean you have to include the encryption key, just create a random key when you upload.

Edited November 2, 2011 by guinness

[nitekram]

Which looks easier to 'transport'? An exe, settings file and a folder labeled 'bin' with 100 jpgs? Or an exe and settings file?

Agreed, two files are better then 102 files for portablility - i edited my previous post.

[rcmaehl]

He changed the initial post again BrewManNH BinaryToString vs Encryption...interesting.

The's a grayish area between speed and time accessing and easy of edibility (by both the program and users).

I need a file that can be quickly accessed/modified by the program while being protected from the semi-above average computer user for abuse reasons.

[guinness]

Nothing is 100% protected, but if your problem is about the encryption key being in the source code, then simply don't upload the correct encryption key. And I didn't understand your last message, what's wrong with BrewManNH's solution?

[czardas]

I asked a similar question recently and got some good answers. You might find something useful:

[rcmaehl]

I asked a similar question recently and got some good answers. You might find something useful:

Thanks! Also resources.au3 is what I'm looking for, I just have to figure out how to use it. Basically I'm trying to idiot proof the normal settings values while smart & malicious proofing the important stuff while keeping it simple, because I'm not taking ANYTHING out of my source code, because then it's not opensource, it's just source and some jerk will complain to google code.

Edited November 2, 2011 by rcmaehl