Hello
I am tryng to read data from an ini file, I use GetPrivateProfileString and I was wondering if it will be able to read encrpted text, I mean instead of text data there will be hex values, will that be read correctly by this function ?
If not, then is there an alternative ?
Looking at the win32 api the GetPrivateProfileString looks like it will copy the contents of the defined key to your return buffer. If the buffer is large enough there wont be any errors. However it will probably terminate the 'string' with a null character. If the contents of the key is of a defined size you could probably ignore the null character - you dont want extra data that is not needed to be fed into your decryption routine. So its possible it may work.
Looking at WritePrivateProfileString for writing data out to the ini file, it wont work, as it copies a null terminated string out to the ini file. So if your encrypted code contains any 0's this will be seen as the null terminator and the 'string' of data will be truncated = bad
I would probably favour using the ReadFile & WriteFile functions for passing the data to and from the encryption/decryption routines and the local file.
you just have to use an encryptor that doesn't generate any nulls
in fact, there are several other characters that shouldn't be used in a .ini file parameter
http://www.cloanto.com/specs/ini.html
i stick to alphaumerics - lol
but, it isn't hard to write an encryptor that only uses 0-9, A-Z, a-z
in fact, it can allow you to use any other characters in the string when decrypted
that list gives you 62 characters - if you add a couple more, like (-) and (+), that gives you 64
then you can write a simple base-64 encryptor, which can handle all characters
as fearless said, though, still good to avoid null - lol
thankyou for the reply.
I have taken steps to ensure that none of the encrypted charters will be 'null'.
Apart from that, the section name and the key name will be alphanumeric charters, only the value data part will be encrypted.
Is it then safe to use ?
Will it get all the encypted value data to the buffer ?
And yes, the value will be maximum of 50chars.
Quote
If not, then is there an alternative ?
An alternative is to use the .ini as a text file,and use some intructions (scasb,..) or functions to read or modify it.
There is a function in the masmlib (it's new) who load a file into memory.it's enough to start.
Some notes about GetPrivateProfileString:
http://www.masm32.com/board/index.php?topic=1073.0
another alternative to using an INI file is to use the system registry
Quote from: dedndave on July 07, 2009, 06:21:37 PM
another alternative to using an INI file is to use the system registry
Only if its a small amount of non-changing data (or rarely-changing). Registry is cluttered enough :)
Quote"There is, shall I say, an etiquette issue when dealing with the Registry. Feel free to store what you need there, but if it's a "lot" of buffered data, store that data to a file. In other words, don't pollute the Registry with a lot of data that might be better kept in a file somewhere. Instead, use the Registry for storing persistent state information. The larger the Registry grows the longer Windows takes to boot. And remember there is an upper Registry size boundary (what that is and how you set it is operating system dependent)."
QuoteOnly if its a small amount of non-changing data (or rarely-changing). Registry is cluttered enough
programs like yahoo messenger change registry values all the time
there is no limit to how often the information changes
Quotebut if it's a "lot" of buffered data, store that data to a file
i agree totally - if it is more than 1 kb, put it in a file
this depends a bit on the application, of course
if it's a major app that gets used often, a little more space should be allowed
if it's a small-simple program that gets used once in a while, it should use even less than 1 kb
but, i hate some programs that pile stuff into the registry that should be in a file
it's like the idiot programmer doesn't know that thing has to load every time you boot - lol
it also bothers me a bit that 80% of the registry is 0's
.02
Using an ini file in the exe folder rather than the registry, along with any files associated with the program, makes it much easier for the user to move a program from one computer to another, or to set up multiple instances of a program with different settings. As a user, which way would you want it?
that is true
however, the entire idea behind windows registry is to centralize all the "ini" files of previous os's
i think i would use the registry whenever another program is to have access to the information (read or modify)
(sometimes, it is hard to predict the future use of information, of course)
i would use an ini file if the information was "private" to the program and intended for possible user-allowed modification
i would use some other type of data file if the information was "private" to the program and not intended for user modification
that would minimize the use of the registry and maintain flexibility
it also keeps the user from mucking things up
most of the stuff that goes in an ini file might just as well be menus/options/preferences modifiable
EDIT - see the frist 3 posts - lol - right on topic, here
http://www.masm32.com/board/index.php?topic=11795.0
Though personally I use the registry for saving application data, for those who prefer INI files once again I will mention the value of the Get/SetPrivateProfileStruct (http://msdn.microsoft.com/en-us/library/ms724356%28VS.85%29.aspx) API. NULLs are perfectly fine as it does not expect characters for input. So encrypt away and store any results at all in your INI file..
Also, efficient but questionable, create an additional R/W .data section in the main executable, and extract and run a worker app to save settings to the main program upon termination. The cheaper anti-virus kits out there might throw a fit, but no .ini file necessary, nor registry. Such would be a true single-file distribution.
Quote from: dedndave on July 07, 2009, 10:52:25 PM
QuoteOnly if its a small amount of non-changing data (or rarely-changing). Registry is cluttered enough
programs like yahoo messenger change registry values all the time
there is no limit to how often the information changes
Quotebut if it's a "lot" of buffered data, store that data to a file
i agree totally - if it is more than 1 kb, put it in a file
this depends a bit on the application, of course
if it's a major app that gets used often, a little more space should be allowed
if it's a small-simple program that gets used once in a while, it should use even less than 1 kb
but, i hate some programs that pile stuff into the registry that should be in a file
it's like the idiot programmer doesn't know that thing has to load every time you boot - lol
it also bothers me a bit that 80% of the registry is 0's
Sorry, I didn't mean that it's not allowed. I just mean it's supposed to be "good practice" :P
Also, people use yahoo messenger?
</sarcasm>
lol - no prob disintx
we like to analyze the simple things to death - lol
as for messenger - oh heavens yes
i play in leagues in yahoo games
we always use yah messy to organize tournies and such
Quote from: Mark Jones on July 08, 2009, 09:44:27 PM
... but no .ini file necessary, nor registry. Such would be a true single-file distribution.
Just wondering if you could embed your config settings as a resource (string or raw) and use UpdateResource to write the changes, and FindResource and LoadResource as the read part. Could be handy to create a couple of wrapper functions to provide the read/write, and name them something like LocalIniReadString, LocalIniWriteString or whatever.
Hello
I was trying GetPrivateProfileStruct but I dont seem to be getting along.
I have renamed my ini file to xuz.abc, but format is ini
invoke GetPrivateProfileStruct,chr$("1"),chr$("MyApp"),addr buffer,sizeof buffer,addr hpath
This seems to giveme a NULL answer.
contents of inifile:
[1]
MyApp=test
When I use GetPrivateProfileString, I get the answer but GetPrivateProfileStruct fails.
Please help.
Because it must have been written with WritePrivateProfileStruct because GetPrivateProfileStruct calculates a checksum, msdn is here:
http://msdn.microsoft.com/en-us/library/ms724356(VS.85).aspx