Windows 7

[neliz]

Yeah, I keep wishing MS would go back to the DOS ways of program installations, where everything was stored in the directory of the program itself.

Unfortunately, we're still stuck with a system that came into existence due to a desire to conserve (at the time) limited HD space in the face of increasingly large programs. Such that "common" files are stored in one location. Unfortunately, that also makes program uninstallation more complicated as you have to know whether another program requires that file before removing it.

HD's are so large now that I wish they'd go back to the old ways of program installation. But, then MS would probably get blasted by everyone for wasting HD space if they were to do so. Damned if you do, damned if you don't.

At least program devs don't rely on storing information in the registry as much as they did with XP, thank god... Although some still use the registry when they don't need to.

Speaking of pet peeves, I also wish MS would have implemented a 3rd party Program Files directory that didn't require admin privaleges to modify.

Regards,
SB

They're basically attacking that problem on the user-interface side only, with your shortcuts now being in central locations, I used to go to c:\games, now I got to Start->Games. but for us, the "power user" it is inconvenient.

 

[Mize]

Have you seen the unbelievably massive amount of regkeys created by Norton Antivirus? It must be hundreds, if not thousands of entries.

That's because it's malware (IMHO). Hardest program to remove completely, EVER.

 

[Arwin]

The App-wrapper method (originally from NeXT then transfered to Apple in OS X) beats all others. It takes more drive space, but a single directory with .app extension holds all the libraries, etc. for each app. Uninstall is simple "rm ./*.app"

Sure wish MS would take this route with windows 8...

.NET applications are basically the same way. All the applications I write will generally not use the registry. The only exception is when I want to advertise the location of my configuration file (xml) to other programs. For security only in rare cases do we need to roll out a policy to .NET security, but that generally works fine and dandy too. Means that almost everything I write just needs to be copied to a folder somewhere, and presto. That can even be a network folder, though in this case sometimes a security policy chance is needed (network locations need to be explicitly trusted).

 

[Silent_Buddha]

Have you seen the unbelievably massive amount of regkeys created by Norton Antivirus? It must be hundreds, if not thousands of entries.

The registry is a completely useless invention anyway, why would separate programs need to put their own private stuff all in one central repository? I see no genuine advantage anywhere, I'd really like to know how MS was thinking internally at the time...

There's a lot of reasons for it. So that the OS is aware of the program and it's locations, especially when you use custom directories. Also so the program, the programs updates, and possibly other programs will know where it's located. As well persistence of user information if a program is uninstalled and later reinstalled.

Related to above, the fact that the INF folder that used to contain much of this information was getting to a size that it was slowing down the OS and file operations. Especially when a rogue application would write 10's of thousands of INF files into the directory which would virtually cripple Win9x.

But what devs started to do, was to then keep program settings and other unnecessary information in the registry. It's one thing to have the information there for install/uninstall purposes and for updating and location awareness across programs... But program settings and what not really have no place in there. And it's nice to see with the advent of Windows Vista that devs have been encouraged to move that information out of the registry and back into regular files.

Progress is being made, just not fast enough for me. I'm also afraid that relaxing on the UAC default prompts will inadvertently encourage devs to go back to the practice of putting information in the registry.

Regards,
SB

 

[pcchen]

.NET applications are basically the same way. All the applications I write will generally not use the registry. The only exception is when I want to advertise the location of my configuration file (xml) to other programs. For security only in rare cases do we need to roll out a policy to .NET security, but that generally works fine and dandy too. Means that almost everything I write just needs to be copied to a folder somewhere, and presto. That can even be a network folder, though in this case sometimes a security policy chance is needed (network locations need to be explicitly trusted).

We put all DLL or related libraries in the program's directory too. We used to install some important DLL in the system directory, but there are just too many possible problems. Unfortunately, there were some bugs in Windows XP which prevents some types of DLL being NOT in the system directory.

Another problem in Windows is about user data. Microsoft does implement shadowing for Program Files directory, but it's basically just a hack. Now we put most configuration files in AppData directory, and avoid using registry. It'd be better if Microsoft has a consistent system for programs to store their per user data (e.g. a special directory for each user in the application's directory which is only writable by the user, and when the user removes the problem, it's can be decided whether or not to remove these data).

 

[Grall]

There's a lot of reasons for it.

I don't see why pretty much any of the reasons you mention require this information to all be collected in the same gigantic file. The more eggs you put in the same basket the more fragile it becomes, the greater the cost should anything go wrong.

Looking through the registry on a clean install of windows shows a simply incomprehensibly staggering amount of registry keys. There's also like four separate locations in the registry from which programs/services may autostart, is that strictly neccessary? I can't see any other reason for it than simply bad design. What other duplication of the same basic feature is there in the registry? I'm sure it's not the only case of it.

But what devs started to do, was to then keep program settings and other unnecessary information in the registry.

Well, what do you expect, when windows itself does the exact same thing? The registry is a general dumping ground for all kinds of crap by now.

I'm also afraid that relaxing on the UAC default prompts will inadvertently encourage devs to go back to the practice of putting information in the registry.

Hm... I actually never disabled the UAC in Win7, it was typically pretty much the first thing I did in WinVista. I haven't seen a single UAC prompt in weeks now... I can't say I miss them.

 

[Silent_Buddha]

Hm... I actually never disabled the UAC in Win7, it was typically pretty much the first thing I did in WinVista. I haven't seen a single UAC prompt in weeks now... I can't say I miss them.

Yeah, at default settings the UAC is no longer triggered when changes are made to the registry from what I remember. I turned my system to highest UAC level in Win7 once I noticed this. I don't like not knowing if a program wants to make changes to my registry or not.

Regards,
SB

 

[Arwin]

Another problem in Windows is about user data. Microsoft does implement shadowing for Program Files directory, but it's basically just a hack. Now we put most configuration files in AppData directory, and avoid using registry. It'd be better if Microsoft has a consistent system for programs to store their per user data (e.g. a special directory for each user in the application's directory which is only writable by the user, and when the user removes the problem, it's can be decided whether or not to remove these data).

Definitely. These days it's probably best to think about what would actually work in a Citrix environment. That seems like a good basis and useful because it's becoming a very common configuration to deal with in companies.

 

[Grall]

Why does it matter to you if a program changes the registry or not? It's not as if you know exactly what it's doing anyway, or have any real choice in the matter. If you deny the change, you'll likely just fuck up the normal operation of the program.

 

[Mize]

Why does it matter to you if a program changes the registry or not? It's not as if you know exactly what it's doing anyway, or have any real choice in the matter. If you deny the change, you'll likely just fuck up the normal operation of the program.

The problem is one, central, easily-corrupted, multiple-access with poor cleaning upon removal database and the dropping of dlls wherever.

For user-based proggy data, why not the equivalent of a Un*x-style .username invisible directory owned only by that user and located in a subdir of the app dir?

 

[Bouncing Zabaglione Bros.]

Why does it matter to you if a program changes the registry or not? It's not as if you know exactly what it's doing anyway, or have any real choice in the matter. If you deny the change, you'll likely just fuck up the normal operation of the program.

The whole design is stupid. Devs can put all sorts of crap in there. You can install something that causes crashes or system problem, and when you uninstall it, the drivers are still present. Even stuff that does uninstall still leaves entries in the registry, leaving it to get bigger and more cluttered as time goes by. Then you have to start hacking in the registry or using cleanup utils, which in themselves can cause more problems. If you break the registry, you can pretty much destroy your whole OS.

Just upgrading recently showed me that devs are putting savegames or config files in about a billion different places in the filesystem, or scattered about in the registry. It's a big fat mess.

 

[Davros]

remember the recent street fighter demo, when you uninstalled it, it left behind a 400mb file in a hidden folder no less, without any mention of it, I only discovered it by accident

If youve played the demo you should take a look
(substitute your username)


Users/username/AppData/Local in Windows 7.

 

[Frank]

Yeah, I keep wishing MS would go back to the DOS ways of program installations, where everything was stored in the directory of the program itself.

That has been the M$ recommended way since W2000.

They made things a lot more difficult by using (automatically backed up and very hard to flush) dll caches, which at first (up to XP) only allowed a single version of a DLL to be active at any one time.


Their ultimate sulution seems to be to simply run everything in their own VM, if required (WOW and their likes).

 

[Frank]

The registry is a completely useless invention anyway, why would separate programs need to put their own private stuff all in one central repository? I see no genuine advantage anywhere, I'd really like to know how MS was thinking internally at the time...

M$ loves to take charge.

 

[Frank]

There's a lot of reasons for it. So that the OS is aware of the program and it's locations, especially when you use custom directories. Also so the program, the programs updates, and possibly other programs will know where it's located. As well persistence of user information if a program is uninstalled and later reinstalled.

Related to above, the fact that the INF folder that used to contain much of this information was getting to a size that it was slowing down the OS and file operations. Especially when a rogue application would write 10's of thousands of INF files into the directory which would virtually cripple Win9x.

But what devs started to do, was to then keep program settings and other unnecessary information in the registry. It's one thing to have the information there for install/uninstall purposes and for updating and location awareness across programs... But program settings and what not really have no place in there. And it's nice to see with the advent of Windows Vista that devs have been encouraged to move that information out of the registry and back into regular files.

Progress is being made, just not fast enough for me. I'm also afraid that relaxing on the UAC default prompts will inadvertently encourage devs to go back to the practice of putting information in the registry.

Regards,
SB

As a programmer, I like to put all my configuration information in a single, human-readable .ini file, with lots of comments and explanations. It's much more convenient and easier for everyone.

I don't see why it would be progress to make that into an XML file, or dump it somewhere in the registry. Would you fancy an RSA encrypted binary that is totally unalterable as the next best step?

 

[Frank]

Btw, I'm quite happy that nobody has told me that I'm a moron because I don't totally dig what Microsoft has to offer and wasn't first in line to buy it, just because of that. And it being shiny and new.

Then again, as I said before, I have a really hard time of coming up with M$ apostles who proclaim everything Microsoft creates as the next best thing to sliced bread, who actually buy any of it themselves for their own use. That's what companies and usenet are for...

 

[Arwin]

As a programmer, I like to put all my configuration information in a single, human-readable .ini file, with lots of comments and explanations. It's much more convenient and easier for everyone.

I don't see why it would be progress to make that into an XML file

An XML file is basically a better version of a .ini file, making it more easily readable by both humans and machine, with good support for comments/explanations included to boot. I can load an xml version of an ini file into an object that parses it automatically and run queries on it, give it stylesheets to display it nicely, etc. You should really look into it, it's very useful - have moved from .ini files to xml files 10 years ago and now use it for almost anything at almost any level too.

 

[Mize]

An XML file is basically a better version of a .ini file, making it more easily readable by both humans and machine, with good support for comments/explanations included to boot. I can load an xml version of an ini file into an object that parses it automatically and run queries on it, give it stylesheets to display it nicely, etc. You should really look into it, it's very useful - have moved from .ini files to xml files 10 years ago and now use it for almost anything at almost any level too.

yeah, but .ini is better when you're stuck with vi on a VT100 emulator

 

[Silent_Buddha]

Why does it matter to you if a program changes the registry or not? It's not as if you know exactly what it's doing anyway, or have any real choice in the matter. If you deny the change, you'll likely just fuck up the normal operation of the program.

If a program doesn't need to access the registry I am damn sure going to deny access and not run the program. Especially if I'm using a program for the first time or just downloaded it from a website. And I'm not talking about questionable programs here. It's certainly not uncommon for hackers to infect legit files with malware.

Think of it as an extra layer of protection from potential malware. If I don't think something should have access that requires admin level priveleges I'm not going to grant it.

And there are ways to track changes to the registry if I'm so inclined and I decide that I'm going to give the program a chance.

For my personal systems, I'm not going to take any unnecessary risks.

Regards,
SB

 

[ban25]

An XML file is basically a better version of a .ini file, making it more easily readable by both humans and machine, with good support for comments/explanations included to boot. I can load an xml version of an ini file into an object that parses it automatically and run queries on it, give it stylesheets to display it nicely, etc. You should really look into it, it's very useful - have moved from .ini files to xml files 10 years ago and now use it for almost anything at almost any level too.

XML is frankly a terrible format for most forms of data. It's tremendously expensive both in terms of size and parsing speed. It's not human readable and should not be modified outside of a dedicated XML parser. The ability to store hierarchies of nested data gets people into hot water faster than you can imagine.

XML worked its way into games a few years back and finally people are coming to terms with all the drawbacks. On my current project, we are using .ini / key-value-pair for tuning values and a binary serialization library for large nested data.