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