What's up with M$ ?

Page 4 of 4  
wrote:

My wife is getting away from PCs completely. She has a W/7 machine by her chair but it is seldom turned on. She uses an Android tablet and a smart phone. That is where this all may be going, hence the W/10 "tablet" release from Microshaft. They have a tall hill to climb to cut into Android's market share. I am still running several DOS apps because windoze has never even come close to matching their features. If you are just dealing with text and numbers, DOS is king. The best MP3 player MPXPLAY runs on DOS too although Atilla has rewritten it so it will run natively on W/XP and, I suppose the follow on OS. If you are just playing MP3s it is fine if you just load DOS. The advantage of my DOS based database and accounting programs is they can just be booted on any machine from a thumb drive and they run without installing anything.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

YEP this entire concept of INSTALLING software in a registry is an issue. Individual SW with indiviual .ini files is less prone to big problems.
Thats what the windows registry is, a gigantic .ini file for everything I think they did it to make it harder for software piracy.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/12/2016 12:43 PM, snipped-for-privacy@yahoo.com wrote:

Ah, you completely miss the point of a "registry"!
First, it keeps all of the settings in one place. So, you don't have gobs of little INI files scattered throughout the file system (in "real" OS's, you would like to be able to treat portions of the filesystem as read-only; perhaps even residing on immutable media!).
Second, by gathering all of the settings in one place, you can more easily support multiple users -- just swap out the "settings file" (instead of having an INI file for each user for each application!)
Third, it provides a common SERVICE (OS's are all about "services") so each developer doesn't have to invent his own INI file format/syntax and write a parser for it (to be able to "read" the INI file).
Fourth, it provides a way to protect those settings (with an INI file per user per application, you'd have to wade through <wherever> the application decided to store its INI files and note that ...\ApplicationName\Don.ini is the INI file for "ApplicationName" while ...\ApplicationName\Administrator.ini is the INI file for the Administrator when he opts to use said ApplicationName. *And*, that Don shouldn't be able to access (read or write) the contents of ...\ApplicationName\Administrator.ini but that Administrator AND Don should be able to access ...\ApplicationName\Don.ini (but, no one else).
Fifth, it has the potential to allow other applications to "see" information maintained or controlling particular applications instead of each application having to invent a mechanism to peek into an INI maintained by some "foreign" app.
I use a full blown relational database in my current project for these reasons. It lets me create lots of little "databases" (tables/relations), saves the "user" (program) from having to know how to parse the data ("This is a number, this is a date, this is an IP address, etc." -- all defined by the table itself... no possibility of a date being entered where an IP address is expected!), lets me control who (applications) can see and/or alter individual entries and lets me share those entries without worrying about duplication costs/errors.
E.g., I can have a table called "network interfaces": interface_name IP_address IP_netmask FDX/HDX NIC_type friendly_name I can write an application that examines this table and uses the information it contains to create yet another table called "network statistics": interface_name octets_in octets_out packets_in packets_out dropped And, yet another application that uses these two to determine when an interface appears to have "died" -- to alert the user ("cable unplugged?")
Otherwise, you have to lump all of these things together which means you make a more complex program AND have to update it for each "new idea" (instead of AUGMENTING something that already "works perfectly")
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Thu, 12 May 2016 13:28:15 -0700, Don Y

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/12/2016 1:49 PM, snipped-for-privacy@aol.com wrote:

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 "colordepth2", 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 "background0000" or even "background%5: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". "backgroundrdvark" "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)?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Thu, 12 May 2016 15:47:45 -0700, 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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@aol.com wrote:

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



Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/12/2016 4:49 PM, Terry Coombs wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/12/2016 4:43 PM, snipped-for-privacy@aol.com wrote:

How did you handle ACL's when the filesystem didn't support them? Everyoe can do <whatever> 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.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Thu, 12 May 2016 12:43:36 -0700 (PDT), snipped-for-privacy@yahoo.com wrote:

another or even to back it up without cloning your whole C: drive.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 05/12/2016 02:43 PM, snipped-for-privacy@yahoo.com wrote:

I always thought the registry was a bad idea. Programs should keep what they need in their own directories.
--
Mark Lloyd
http://notstupid.us/
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 05/12/2016 10:01 AM, Terry Coombs wrote:
[snip]

I seldom if ever flay fancy games, but I do like the Spider Solitaire that came with XP. That runs fine on WINE on Linux. However, lately I prefer the Linux version.
--
Mark Lloyd
http://notstupid.us/
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Micky wrote:

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 ?
--
Snag



Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Related Threads

    HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It 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.