Main Area and Open Discussion > General Software Discussion

Why the Windows Registry Exists

<< < (2/4) > >>

app103:
There is a 32kb limit?

Whoops! Someone forgot to tell Opera, AOL, Maxthon, Spybot, Flashget, Sierra, etc.

Why the Windows Registry Exists

That 97kb one is from Opera, which seems to work just fine with an INI file that is 3x the 'limit'.  :huh:

Ralf Maximus:
That 97kb one is from Opera, which seems to work just fine with an INI file that is 3x the 'limit'.  :huh:
-app103 (November 26, 2007, 12:30 PM)
--- End quote ---

Heh.  That's because those programs have stepped outside the Windows API for manipulating .INI files and have rolled their own mechanism.  Exactly what I do.

Armando:
Yes, I was also asking the question because so many ini files on my system seem to exceed the 32kb limit (farr being one of them...)

Lashiec:
I remember that back on the 9x days, Notepad couldn't handle text files bigger than 64 KB, and CDPLAYER.INI couldn't store many CDs in there :)

Excellent post, at least we can finally understand why they choose a registry system instead of .INI files. I wonder if this was some kind of answer to Jeff Atwood's post about the same thing...

Can we move to .XML or custom .CFG files now?

Gothi[c]:
Can we move to .XML or custom .CFG files now?

--- End quote ---
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.

--- End quote ---
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.

--- End quote ---
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

--- End quote ---
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.

--- End quote ---
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.

--- End quote ---
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.

--- End quote ---
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.

--- End quote ---
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.

--- End quote ---
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."

--- End quote ---
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?

Navigation

[0] Message Index

[#] Next page

[*] Previous page