.ini files are awesome. Users should be able to break games if they want - not making a backup is their problem. I'm all for things that are immediately somewhat intuitive for users, and the registry just isn't one of those things.

What problems do you have with the page file to say that it's ass-backwards?

Although, Mac OS does have a registry of sorts, the system-wide, and user-specific library folders. Sure it's split up into hundreds of files instead of half a dozen, but they're equally left where they are when the user removes the program.
Of course, the user in that case don't need admin privileges to edit his own branch of the application and system settings repository, and if a non-admin does a mistake the worst they can do is fuck up their own account. That is, I feel, really the worst design flaw of the registry so far, you need admin rights just to open the app, even if the only settings you're about to edit are ones specific to your own account.
Ditto Linux and other Unix-likes. System-wide settings in /etc/ and user-specific in your home folder (most often hidden by starting the file/folder name with a dot)

The Linux kernel has a pseudo registry as well. All the system hardware information is in /proc
All a program needs to do is open something like /proc/cpuinfo to figure out what the CPU is and different things about it.
Finding shared libraries (like .dlls in Windows) in Linux isn't handled by the program anyway. There is an environment variable that stores the location of where all the shared libraries would be; i.e /lib and /usr/lib.
So when a program is compiled, it just tells the compiler to link to something to a certain file; for example libGL.so, and then when it's executed it looks for libGL.so in the paths supplied by the environment variable I mentioned earlier. That's all handled by the really low-level stuff, not the program itself.

Yeah, instead that devolved into Windows Search.

I must say I had hopes of WinFS making it into Win7 but apparently it's not. Oh well, win 8 can have it as well as 64bit only operation, things have to progress sometime
Yeah but thats hardly the fault of the people who made windows, thats sloppy 3rd party coding.

Pah, it was supposed to get into Win95, there's no rush, it can wait another few versions.

I suppose you've never run into the "out of virtual memory" error that happens even if you allow Windows to manage the file and make it as large as it needs to? Or even had an app or game grind to a halt at a critical time as Windows has to waste processing cycles trying to re-size the page file to accommodate whatever you are doing? Or tried to defrag a drive with a page file using Windows own defrag tools? Why can third party tools do it but Windows cannot? Or better yet, in a system with multiple hard drives, Windows automatically uses the most inefficient set up possible (the only set up it ever uses), placing the page file on the same drive as the operating system and programs. That forces the system to work that hard drive extra hard as it seeks back and forth between programs and the page file, leading to shortened drive life and terrible page file speed.
The sad part is, this is the way it has been with Windows page file management since the beginning. They have never done anything that outwardly appears to improve on the system since the days of Win 95/98. Better to set the page file to a fixed size that is a minimum of 1.5 - 2 times the amount of RAM you have (never runs our of virtual memory, never re-sizes) and configure it on a secondary hard drive (far more efficient, better for the life of both hard drives and does not interfere with defragging the system) than let Windows page file management do what those "experienced engineers" at Microsoft set it up to do.