Idea born of boredom... Successor to the registry?

[RyanLucier]

So... Sitting in my office right now with very little motivation to work Taking a 30 minute break and I'm thinking to myself, why do we not have something better than the registry. Here's what I was thinking, why doesn't windows scan all root folders in "c:/program files" looking for a specific registry file that it loads.

This would allow you to quite literally drag-and-drop programs into program files and they'd be installed automatically & quickly. Dependencies could be indicated in the registry file of the root folder of each individual program as well, and if the dependencies were not installed they could be installed/downloaded.

Is it just me or does this not sound like a far superior system? You could literally bring your PC back to a "fresh install status" by just removing every folder in program files.

I highly doubt the bootup scan process would add much time to bootup either, as it would just scan the root folder of each folder in c:\program files and look for a specific file (similar to autorun.inf on CD/DVD's). I bet 500 folders could be scanned practically instantly, and I doubt many users have over 500 programs installed. But even if they did, the additional bootup time would probably be negligible.

This would also eliminate programs nuking operating systems.. Say you installed something which prevented the OS from starting, just bootup on a USB thumb drive or something and delete the offending folder. Problem solved?

Thoughts/opinions?

 

[XOR != OR]

I wouldn't even do the start up scan. When an application starts up, it would look in it's current directory for the registry settings ( an "INI" file, if you will ), then check in other directories defined by an environmental variable.

The real bitch with installs isn't the registry though. It's the dlls which the install process setup.

 

[DeaconFrost]

You haven't ever used OSX, have you? For the record, I'm not a Mac guy, nor do I want to be. I feel Windows 7 is far superior as a whole, but OSX does have the right idea with contained app installs.

 

[XOR != OR]

You haven't ever used OSX, have you? For the record, I'm not a Mac guy, nor do I want to be. I feel Windows 7 is far superior as a whole, but OSX does have the right idea with contained app installs.

I've always felt Macs did it the right way.

 

[Elledan]

Yeah, it's basically how OS X does it. Installing/deleting an app is as easy as dragging an app folder to/from the programs folder. Very intuitive and leaves behind very little junk.

Linux is almost as bad as Windows with its use of /etc as the dumping grounds for most app settings, not to mention the inconsistent installation locations of apps, anywhere from /bin, /opt, to god-knows-where-else. It's a shame OS X's GUI doesn't appeal to me, and it hasn't caught up with Windows in a number of places, else I might have switched

 

[XOR != OR]

Yeah, it's basically how OS X does it. Installing/deleting an app is as easy as dragging an app folder to/from the programs folder. Very intuitive and leaves behind very little junk.

Linux is almost as bad as Windows with its use of /etc as the dumping grounds for most app settings, not to mention the inconsistent installation locations of apps, anywhere from /bin, /opt, to god-knows-where-else. It's a shame OS X's GUI doesn't appeal to me, and it hasn't caught up with Windows in a number of places, else I might have switched

Again, i can only agree. What makes the linux situation worse is that many tar balls don't have an uninstall target. So once you install it, you're done ( unless you want to reverse engineering the makefile...*shudder* ).

 

[GushpinBob]

Again, i can only agree. What makes the linux situation worse is that many tar balls don't have an uninstall target. So once you install it, you're done ( unless you want to reverse engineering the makefile...*shudder* ).

Back when I was using Slackware, there were many times when I had no other choice but to install software from source. Yes, there were quite a few programs that lacked a "Make Uninstall" option but reverse-engineering the makefile was something I never even heard of. Instead, it was a recommended practice to re-install the application over itself but with a tool that logged the locations of the items installed (I think it was called "checkinstall", but I'm not 100% sure). Still a pain in the ass, though.

Didn't Windows originally rely on INI files prior to the registry? Wasn't the registry created to solve their setbacks including but not limited to speed and strongly-typed data. Your proposal of Windows scanning the program files directory over a centralized database file(s) sounds like an expensive operation. Also, what if the user decides to install an application in an arbitrary folder or drive?

 

[MrGuvernment]

But the bad part about OSX was when people would walk into a store, plug in a USB drive and steal all of the apps they wanted.

with the program having no tie to anything copy and paste and everyone has a copy, i know OSX is now using serials and activation methods, so can you still do drag and drop with OSX?

 

[Elledan]

Didn't Windows originally rely on INI files prior to the registry? Wasn't the registry created to solve their setbacks including but not limited to speed and strongly-typed data.

AFAIK Win3.x used only INI files for storing settings. Today there are still some apps which use INI files to store their settings instead of using the registry. I must say that I appreciate it when an app does this

But the bad part about OSX was when people would walk into a store, plug in a USB drive and steal all of the apps they wanted.

with the program having no tie to anything copy and paste and everyone has a copy, i know OSX is now using serials and activation methods, so can you still do drag and drop with OSX?

Yes, you can. And there is a tie with the OS/hardware using hashes and other methods. It's not like you can't copy/paste an app on Windows if you know the registry keys to replicate on the target system either. It just takes a bit more effort

 

[XOR != OR]

Didn't Windows originally rely on INI files prior to the registry? Wasn't the registry created to solve their setbacks including but not limited to speed and strongly-typed data. Your proposal of Windows scanning the program files directory over a centralized database file(s) sounds like an expensive operation. Also, what if the user decides to install an application in an arbitrary folder or drive?

I wasn't recommending that. I was recommending that the application look for it's settings in common locations ( so if foo.exe was started, it would look for foo.ini in the current directory first, then check the environment if it didn't find it ). Functionally, that would only be moderately slower than the registry, but probably not enough for anyone to notice. In fact, windows does something very similar with dlls and no one notices the performance hit.

Like I said, however, it's not the registry that's the problem. Rather, it's the shared libs that the installation usually registers with the system that usually present the problem.

 

[Arainach]

Didn't Windows originally rely on INI files prior to the registry? Wasn't the registry created to solve their setbacks including but not limited to speed and strongly-typed data. Your proposal of Windows scanning the program files directory over a centralized database file(s) sounds like an expensive operation. Also, what if the user decides to install an application in an arbitrary folder or drive?

Yes and yes. I'm not sure what people hate about the Registry. It wasn't some random hack, it was designed to address specific problems with text-based configuration files and the setup, administration, and upgrading of software and operating systems. It's an excellent, and highly performant solution that other operating systems should take as inspiration.