Can we move to .XML or custom .CFG files now?
Or just read/write your own ini's without the windows api, as mentioned before...
This article is funny.
So basically, Microsoft implemented something in a very horrible way (ini api), then came up with a very horrible alternative (registry), while the rest of the world implemented their own way of dealing with ini files, which is actually not broken like the original api, microsoft is now still pushing their broken registry.
INI files don't support Unicode.
Not in the windows api perhaps, but it's trivial to implement an unicode-compatible ini-reader/writer as many have done before.
INI file security is not granular enough. Since it's just a file, any permissions you set are at the file level, not the key level. You can't say, "Anybody can modify this section, but that section can be modified only by administrators.
Oh, so you're saying that file permissions at the file level are not secure? Bad news for Vista I guess. It's not like registry keys are secure... I'm assuming he's referring to ancient single-user windows. These days it's easy enough to set file permissions so a file can be accessed by only one user, or administrator, just as with registry settings.
Multiple writers to an INI file can result in data loss. Consider two threads that are trying to update an INI file. If they are running simultaneously
I guess they don't use mutexes over at microsoft. No wonder their OS crashes all the time
INI files contain only strings. If you wanted to store binary data, you had to encode it somehow as a string.
As addressed before, it's easy enough to store binary data in an ini...
Parsing an INI file is comparatively slow. Each time you read or write a value in an INI file, the file has to be loaded into memory and parsed.
Again, this is windows API ineffectiveness. Most programs using ini files will read the file, parse ALL strings they need, or if they need to write multiple values, it's easy enough to do so in one write operation.
What's more, many programs that parsed INI files were buggy, so in practice you couldn't store a string longer than about 70 characters in an INI file or you'd cause some other program to crash.
Wait... programs using ini files buggy? Didn't you just say you guys created an API with only a 32KB buffer? Oh yeah, and 640K memory is all you'll ever need, right? Maybe look at your own code first,...
The default location for INI files was the Windows directory! This definitely was bad for Windows NT since only administrators have write permission there.
I haven't seen an app that writes ini files into the windows directory in years,... Most of them are stored in the application's folder or one of it's sub-folders... Which is actually pretty cool. Copy your application folder to an usb-key, and you can use it anywhere with the same settings. Lets see you do that with the registry...
INI files contain only two levels of structure. An INI file consists of sections, and each section consists of strings. You can't put sections inside other sections.
I guess technically you could make an ini with more hierarchy, but it would make more sense to use XML here.
[Added 9am] Central administration of INI files is difficult. Since they can be anywhere in the system, a network administrator can't write a script that asks, "Is everybody using the latest version of Firefox?" They also can't deploy scripts that say "Set everybody's Firefox settings to XYZ and deny write access so they can't change them."
You can do that with the registry? Wow! Isn't firefox always going to be firefox.exe in the same friggin' folder regardless of version? But i guess that's not the point he was making. 100 different apps might use 100 different registry key names for where they store the location to firefox... I guess you could search on the actual filename, and get lots of false positives... but wait, isn't that the same as doing a file search for *.ini containing firefox.exe?
Recent Posts
