BCS wrote:
> Walter Bright wrote:
>> Dave wrote:
>>
>>> In article <e0io88$22jc$2@digitaldaemon.com>, Walter Bright says...
>>>
>>>> Walter Bright wrote:
>>>>
>>>>> At this point, it was apparent that tech support had no idea why this was happening, and I was beginning to worry there was either a rootkit installed, or there was just creeping corruption going on. I gave up on Microsoft tech support, and decided to reinstall Windows.
>>>>
>>>> Turns out, I did have a trojan rootkit on my system. arrgh!
>>>
> 
> How did you pick up on this?

Microsoft tech support eventually suggested it, as apparently other people had the same symptoms.

Wang Zhen wrote:
> I don't know how Walter detected the rootkit on his machine, but I would recommend SysInternals' excellent freeware RootKitRevealer, available at http://www.sysinternals.com/utilities/rootkitrevealer.html

Rootkitrevealer crashes on my system. :-(

Maybe I have yet another rootkit installed.

In article <e0ks5g$1h7j$2@digitaldaemon.com>, S. Chancellor says...
> 
>On 2006-03-29 09:19:27 -0800, Jari-Matti Mäkelä <jmjmak@utu.fi.invalid> said:
> 
>> pragma wrote:
>>> In article <e0dtb1$2mld$1@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