Windows woes
Jari-Matti Mäkelä
Jari-Matti_member at pathlink.com
Sat Apr 1 06:23:35 PST 2006
In article <e0ks5g$1h7j$2 at digitaldaemon.com>, S. Chancellor says...
>
>On 2006-03-29 09:19:27 -0800, Jari-Matti Mäkelä <jmjmak at utu.fi.invalid> said:
>
>> pragma wrote:
>>> In article <e0dtb1$2mld$1 at digitaldaemon.com>, Juan Jose Comellas says...
>>>> At some point in the past, the only way to be able to be certified
>>>> "Windows-logo compatible" was if you used the registry to save your
>>>> program's settings. I guess they wanted to make it really difficult to
>>>> switch computers without reinstalling. The registry is probably the worst
>>>> abomination to come from Redmond and it's the cause of most of the
problems
>>>> Windows has.
>>>
>>> Here's how I look at it. The registry works fantastic for a few things:
>>>
>>> 1) Making explorer do file type magic
>>> 2) OLE/Drag-and-Drop interoperability (more file type registration and
>>> metadata)
>>> 3) COM registry
>>> 4) Application initalization
>>>
>>> .. but design wise it has the following drawbacks:
>>>
>>> 1) Behaves as its own entity in memory (can you say "cache-thrashing"?)
>>> 2) Has its own LRU algorithm and behavior
>>> 3) Is prone to bloat, as applications abuse it in various ways
>>
>> IMO the worst thing is that you really can't separate all the per-user
>> settings from the system-wide configuration. That makes it impossible to
>> backup your personal data without 3rd party programs. In *nixes it's
>> damn easy to backup your home directory without any problems and restore
>> all data to another system in a breeze. Even a newbie can do that.
>
>Much of the registry is stored in data files in your documents and
>settings folder.
>
>>
>>> Why they didn't just come up with a universal configuraiton file tree
( /etc
>>> anyone? ), with filesystem drivers that feature superior or tree-specific
>>> caching, I'll never know. In every possible way, it would have provided a
more
>>> stable configuration, for about half as much engineering.
>>
>> FAT-file systems used to have bad space efficiency. Currently a complex
>> registry would require you to have at least reiserfs4 to work fast enough.
>
>That is absolutely not true. Not to mention that they use NTFS now.
>If you're talking about storing a file for each variable, you missed
>the point of the original comment. Switching to everything used
>per-app XML files would simply require changing the behavior of the
>Registry function calls.
Hmm, I think I said "they _used to_ have bad space efficiency". For example
the block size was ~64 kB on a "large" hard disk back then (1991-1995).
Another solution was to use smaller blocks, but a huge FAT-block. Win-3.1
programs didn't have cool installshield wizards and stuff like that. They
stored per-application data in separate .ini-files to c:\windows and never
removed any .ini-files of removed programs. Having thousands of separate small
files in the same directory was and is a pain in a FAT-system. Back then hard
drives were quite small and 2000 files * 64 kB/file was 128 MB!
XML is very cool and per-app xml files in user home directory is a working
solution on modern *nix systems, but certainly you realize that XML 1.0 was
introduced in 1998 and registry was already widely used in Windows 95. It's
hard to change that with some backwards compatibility in mind. NTFS may be
somewhat better than FAT, but it's still slower than reiserfs4. Many friends
of mine use FAT32 because it's faster than NTFS in some cases. The problem
with per-app configuration files is that they should be in a strict directory
hierarchy to work well on non-reiser4-systems. One big file or many small
files in a same directory are both bad options on traditional file systems.
--
Jari-Matti
More information about the Digitalmars-d
mailing list