What's up with M$ ?

It certainly makes it harder to transfer software from one machine to another or even to back it up without cloning your whole C: drive.

>
Reply to
gfretwell
Loading thread data ...

...

One of the largest utilities in the US is, to the best of my knowledge, still using OS/2 on some plant-monitoring systems--although I moved the application to NT and it's it which they've "rolled out" on systems when they have died, it was never any cost-benefit to make the change on every unit until it became/becomes necessary. These are 24/7 background, "slow" real-time plant performance monitoring systems that are the backbone of the plant heat-rate monitoring which is the key statistic for reporting when the plant is operating most efficiently (or conversely, let's operations know when it is markedly off-target).

They do their job...

Reply to
dpb

I see you drank the Kool Ade but I still don't know why an INI for one particular program should not be with that program. If you have a suite of interactive programs like Office, all of the INI info should be in the directory with that suite of programs. Microshaft simply did not want that to be too easy to copy over to another machine so they joined it to a particular OS that was hardware tied to one particular hardware profile. Probably a good BUSINESS move but not good for the user.

Reply to
gfretwell

Sure I read what I wrote. Terry clearly wasn't asking for MSFT to create and write new updates. He was asking for the updates to XP that were issued in the past, which are still available, as they always have been, even though support has ended. Proof of that is that he found them, downloaded them and is now installing them. Go back to sleep.

Reply to
trader_4

My Mama is dead , bitch . And like I said , if you don't like what I say , don't read it .

Reply to
Terry Coombs

I always thought the registry was a bad idea. Programs should keep what they need in their own directories.

Reply to
Mark Lloyd

As has been stated here, it was Bill Gates' way of making it harder to copy software from one machine to another. The machine signature engine is buried in Windows and the software is tied to that particular version of the OS via the registry. I suppose if someone was interested enough to track down every registry entry and move them all when they copied the software it would work but there are probably 100 entries for something like Office and they are scattered across almost as many separate paths in the registry.

Reply to
gfretwell

Because programs are immutable objects. I should be able to run those programs off a CD and *still* be able to make changes to the "settings" (i.e., the "settings" need to be stored in someplace that can be written.

In the UN*X world, that's typically /etc -- despite the fact that the "programs" may reside in /bin, /sbin, /usr/bin, /opt, /usr/local/bin, etc.

The "user specific" settings are typically in an ad hoc "rc" file stored under each user's $HOME.

So, for a machine with 10 users, there should be 10 *sets* of INI files? Or, perhaps a folder for each user thereunder?

The registry is actually *simpler* for the user.

I've seen all sorts of malformed INI files -- because the developers didn't understand the concept of "sections". And, the layout of the files are inherently sequential: if I find an entry called "colordepth=32", I have to scan BACKWARDS to see if it is in the "[resolution 640x480]" section or the "[resolution 1600x1200]" section.

And, if one application wants to represent this as a hexadecimal number while another uses decimal...

And, one application says "background=red" while another equivalently says "background=FF0000" or even "background=255:0:0".

When I query my RDBMS for a "color" value, I know the result will be in exactly the same form regardless of WHAT the color pertains to or "who" set that value. Likewise for an IP address, netmask, filename, date, time, etc. I know that NOTHING can ever set an IP address of "257.3.4.5" or "192.X.0.45" or "18".

From the developer;s point of view, it means all value checks are consistent -- regardless of the application involved. It also means you don't have to check values that you retrieve (from

*my* RDBMS) for "sanity" -- the RDBMS *guarantees* that a "color" is always a "color"... even for the user that would LIKE to open a text editor to manually manipulate an "INI file". "background=aardvark" "time=blue"

Dig through your registry (INI files) and see how many different representations for times you encounter! (time of last update, installation time, license expiration time, etc.) Quick, what "time" is "1001"? Is it 10:01AM (on some indeterminate day)? Is it October 1st? Is it 1001 seconds after the MS epoch? Or, 1001 seconds after the UNIX epoch? Or, an elapsed time (since some particular event)?

Reply to
Don Y

Why not, disk space is cheap. Then each package can be managed separately. Things parked in the registry tend to stay there forever, long after the software that put therm there was removed or updated. That is one of the things that makes old copies of Windoze slow to a crawl and explains a lot of weird bugs. Some little kitch left over from discontinued software starts stepping on newer software. Shared DLLs do the same thing.

Reply to
gfretwell

Sammsoft's Advanced Registry Optimizer will clean up a lot of the crap .

Reply to
Terry Coombs

How did you handle ACL's when the filesystem didn't support them? Everyoe can do to any INI file?

Then that's the problem with the application's installer! (uninstaller)

The size or contents of the registry are a problem only if windows opts to cache the entire registry (because it was poorly implemented).

I *want* to make sure anything that changes the netmask of an interface in the registry (because they have been ENABLED to do so) automatically causes the correct "handler" to be invoked to actually update the hardware in the network interface chip; so the "anything" that made the change doesn't need to know how to talk to that hardware.

Likewise, I want an object that is no longer referenced to be automatically deleted (regardless of where it happens to reside in the filesystem) because the RDBMS *knows* that no one else has an active reference to it (so, if no one can reference someTHING, then why should that THING persist?)

Would you want every application to keep track of who is using the DLLs that they happen to be using? So, when they are uninstalled, they know to remove the DLL as well? Without fear that something else is still referencing it?

Or, do you want everything staticly linked -- so the executables are bigger and the footprints of applications (in RAM) are larger? And, so bugs in those libraries can't be "live updated" but, instead, must result in every application that uses them being updated?

You can't do these sorts of things without centralized knowledge.

Reply to
Don Y

The problem is that the registry is far more complex than INI files. In large part, because it *does* more than INI files could ever do.

How do you associate a particular "handler" with a particular file type/extension? Have the OS dig through every INI file to see who *claims* a particular extension? What if two INI files each want to make the same claim?

What about the handlers for *events* -- things that the user never directly sees (e.g., when this particular USB device is plugged in, run this piece of code to initialize the device interface and make the following things available automagically to the user)?

The reason there are "Registry Optimizers" and "Registry Cleaners" is because there is a lot of information embedded in the registry keys -- things that Joe ABOVEAVERAGE User could never *reliably* sort out with his bit of meatware.

Reply to
Don Y

No time to read the whole thread so maybe someone said this already.

You can fake them out by calling your computer a Point of Purchase computer and it will still let you do updates for another year or two. Let me know if this helps you. Let me know if you need help finding the details.

P&M

Reply to
Micky

The point has been rendered moot , I got some of the updates from WSUS.com , the rest from wupdate . I believe now that the original problem was because IE8 wasn't up to date . Can't get the updates until you've updated ... can you say Catch-22 ?

Reply to
Terry Coombs

BTW, I had no plans to change either, but something started destroying** files on my XP computer, and a friend had given me a Vista computer he'd used at his company for a few years. It was all up and running.

When I have time I may go back to XP, but like one of you said, changing OSes, changing computers, is a lot of time and work.

**Maybe it was a virus, but i'm not convinced. It seemed to erase all the Windows files and nothing else when I turned it off. Yet I copied my email and newsgroup data from that very harddrive, in a drive caddy, iirc.
Reply to
Micky

HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.