View Full Version : OT - Windows Registry Size

Ian B
07-13-2006, 05:30 AM
Just received this email from our IT department:

"Dear Colleague,

The Microsoft Windows 2000 Professional Operating System (OS) uses a registry to start and operate a laptop/desktop. The optimum registry size is below 7MB. Any size above the optimum level will put the machines at a potential risk of 'crashing' and recovery would require re-imaging of these machines."

Has anyone experienced such crashing, or is this just more IT department mumbo-jumbo?



07-13-2006, 06:24 AM
I think somebody in IT is smoking something, never heard of that. It does use the Registry extensively. And as far as a "system database" goes, it's a terrible design with no facility for compaction, defragmentation or other seemingly common sense features. Over time the system will grow more and more sluggish as the registry degrades. This is why a system that is otherwise unchanged will seem MUCH faster when you reinstall everything as compared to how it runs after even 6 months to a year of installing, upgrading, and using applications which all tromp through the registry.

It’s also true that some registry issues can cause a system crash in various flavors and that the only real way to fix a fragmented, obese, or corrupted registry is to reinstall/reimage the system. But I have never heard of some arbitrary size beyond which the registry is going to start brining down the system consistently.

07-13-2006, 08:58 AM
The windoze registry is a terribly bad idea, brought to you by the folks who patented bad ideas. It's the product of a committee flying high on the best stuff money can buy.

07-13-2006, 10:11 AM
Yep. Agree with above. In many cases when something is uninstalled it leaves many entries in the registry that become useless garbage. They are usually ignored by the OS since they are no longer referenced but just add to the size. Not only is it a bad design it is completely unnecessary. There is no reason or sensible justification for allowing an application to change any file that belongs to the operating system. It simply isn't good practice. Proper operating system design requires that applications be restricted to a "sandbox" with no write access to system files.

As for the size of the registry causing crashing, no. Windows does that just fine regardless of the size of the registry.

07-13-2006, 10:43 AM
if 7 mb is the limit, then my main pc would not operate, it is at 43mb! Yes, it needs to be wiped and Windows 2000 reloaded, but.....

It is silly that MS allows programmers to use the registry as their own ini file. My opinion is that many new programmers start doing it that way because it is a neat trick that they just learned and then keep it up as a bad habit.

07-13-2006, 07:11 PM
There is a limit for older os'es but it is much more than 7mb usualy 150mb see


for more info. There is also garbage from people who want to sell you a program to "clean" your registry. If you are worried get a free reg cleaner.

But unless you are getting warnings, which you wont in XP, don't worry about it. Sometimes cleaning causes more problems than it solves so it is safer to leave it alone.

07-13-2006, 09:28 PM
Just to clarify things, I would like to know what the registry IS good for-- what was its purpose? If it's of no value to me, can I eliminate it, say during a fresh instal of the OS? (win 98se) I'm almost certain the answer is no, but --

07-13-2006, 09:49 PM
It stores settings, like which programs you have, how you like the menus to look which colors, which document spreadsheet you had open last, which program to use to play a mp3 file etc etc.

When setting up a new computer you can trash it, but it will then remember NOTHING about what you had before. A new registry will be created. And you can not get rid of it and keep on running.

Oh and for geeks - It is a replacement for those old ini files that win3.11 and the like used.

Clear as mud? If not ask another question.

The Doctor
07-13-2006, 09:54 PM
darryl, about the only thing that the registry is truly good for is causing trouble if it gets corrupt, if it does not get corrupt it works just fine. An operating system can be designed which does not require a registry, in which case you will not have one. All versions of Windows except for 3.1 has used this monstrosity, on these OSes it is a required thing. Although it may eventually cause you some trouble, you cannot install the OS without it, and the computer will probably not even boot up if you try to remove it.

On the plus side, the registries on Windows 2000 and XP systems do not seem to get corrupt to very easily. I will also note, for those Windows bashers amongst us, that I have quite a bit of experience with Windows 2000 and a little bit with XP, and the systems are almost always rock solid. The only exceptions to this I have seen our computers with defective hardware. Things like hard drives which have developed bad sectors, or memory with a few bad locations tend to make the system a bit unstable, and usually get it to the point will eventually it not boot. Please note, the same problems will prevent any operating systems and working correctly.

As to registry size, all the claims that it needs to be small are just pure BS. My current notebook is running Windows 2000, with a whole bunch of software installed on it. The registry size is currently 40 MB, the computer is very responsive and typically goes more than a month between reboots. One of my computers had a registry size of 57 MB, and was also quite fast and stable.

As to registry cleaners, just say no! The bad ones will screw in a hurry, the better ones may take a few tries before you're truly F%&#ed. but believe me, they will get you there. Microsoft just have their own registry cleaner called regclean, but even they realize that cleaning and compacting the registry was a hopeless task. All the cleaners on the market are just a method to extract money from your pocket for a product which does nothing at its best, and can really trash or installation at its worst. They are in the exact same class as these" memory optimizer" programs. Avoid at all costs!


07-13-2006, 09:58 PM
Yeah, a history lesson on the registry might be useful.

First there was INI files. These were just text files containing configuration and default initialization settings used by programs. Most programs as well as what served as systems services used them. They were everywhere.

Then OLE came along (now called COM along with other names not suitable for a public forum) which used something called "the registry" to store it's setting and hook up services among process and the like. This is what enabled Word docs to contain Excel spread sheets.

Then some bright bastage in the MS OS group decided, "Hey, we can use the Registry as a system wide place to store all sorts of program and system related data!" And so began the decent into darkness...

Microsoft actively pushed "the Registry" as the sectioned place to store most everything except user data (and in some cases even user data!) for several years. They even baked it into the default settings for development tools like Visual C++ and MFC with it's wizards and the like to encourage you to follow the gospel.

Now years have passed and the evils of the registry have been accepted as fact by all but the most ignorant of savages. So Microsoft came up with a fantastic NEW technology called config files which allow each program and system service to store it’s configuration and default startup settings as a text file on the file system... :D

Am I the only one getting dizzy? ;)

07-13-2006, 10:21 PM
I would like to know what the registry IS good for-- what was its purpose?
Hi Darryl,

The original purpose was very simple... to keep track of which programs used common files. The idea being that if you uninstalled all of the referencing programs, the last one out could safely delete the common files since nobody else was using them.

The falacy arose when programs used common files without notifying the registry of that fact. Once this practice became commonplace, it was no longer safe to uninstall common files just because the registry said they were no longer used by any program.

But the registry becaue the dumping ground for all sorts of things. You'll find icons stored there, and actual executable code, and a million other things that don't belong there.

As I said before, a horribly bad idea from the folks who perfected the technology of bad ideas.

07-13-2006, 10:23 PM
You can also go to the registry editor and export a "good" registry to your hard drive for future use. I have done that along the time my OS has been up incase I either screw up the registry or it gets screwed by no fault of my own. JRouche

P.S. mine is about 52meg and never had a prob...

07-13-2006, 10:29 PM
Of course that isn't the only stupidity in Windblows. I'm not sure which is worse, the registry or allowing applications access to the system directories. Ever since Windows 3.0 the problems caused by applications adding and changing files in the system directories has cause uncountable lost hours of productivity and headaches for IT people.

Of course, it is in large part the fault of the developers. It isn't necessary to use the registry or write files in the system directories. None of the software that I use on my servers does this. I run Mercury Mail Transport, Xitami Web and FTP server, F-Prot Antivirus, Netstat Live, Icalendar server, AnalogX Atomic Time Sync, Vallen Jpegger, a shutdown scheduler and a log file analyser and publisher. None of them touch the registry or write anything outside of thier own directories. Not coincidentally, these are all freeware and most are open source.

Most developers take advantage of the ability to write the registry and the system directories through plain laziness (or incompetence) and to make their software hard to copy.

07-13-2006, 10:32 PM
As a deveolper, I try to keep stuff away, but have you ever tried to use a dll without it being in one of the "system" directories?

07-13-2006, 11:27 PM
but have you ever tried to use a dll without it being in one of the "system" directories?

No problem. If it's a system dll it's already there. If it isn't you need to discover the install path to your application where you keep your custom dll. Then you run it from there. That's where the laziness part tends to come in.

J Tiers
07-14-2006, 12:03 AM
My theory on the registry, is that it was primarily for security..... but "sold" on teh basis of efficiency.

It allows the install programs to spray program pieces so widely over the disk as to render a "copy" from a working machine impossible. You have to have the original disks, unlike DOS or earlier windows where the program resided in one place.

Sure, it is supposed to use one copy of any dll. But, let that be the WRONG dll version (with the same freaking name, of course!), and lots of programs may stop working.........

Kind of a "safety paid for with slavery" approach... where the overseers can't add up your hours right....

07-14-2006, 12:58 AM
As I said earlier, it originally surfaced in Win16 and was used only to handle OLE binding information. NT 3.51 started using it for some system stuff. Then with Win95 and NT4.0 all hell broke loose and it became the "system database of choice" for any sort of application settings. The "common file tracking" (which was a disaster for reasons stated) came in with the Win95 era as well as a whole host of other things like Security hive and Local Machine (system services setting primarily). The Classes Root hive contains all the COM stuff that had it’s roots in the original registry supporting OLE.

Exporting a “good registry” and later importing it can absolutely cause your system to become unstable. Any program you’ve installed since the export could have installed it’s own services, applied system patches, DirectX updates, and many other things that depend on settings that will no longer be there. If they “degrade” or recover gracefully with reasonable defaults then all is fine, but many programs are never tested with that scenario and are not prepared to deal with it since that is absolutely NOT a supported or expected action to be taken by the user. It’s akin to going through System32 and randomly deleting files because you don’t recognize the file name. It’s not supported and the results are “not defined”.

Loading a DLL from anywhere is easy via. the LoadLibrary API, using COM binding, or the PATH (both explicit and implicit) as well as a few other options dependent on the technology (e.g. Fusion for DotNet). The problem comes in when depending on default Win32 loader binding by simple name (what you get with imp lib links). In that case, the loader just recurses the PATH until if finds a matching name based on COFF import tables. It has no way to know if it found the right binary and bad things can happen. This is one of the things that COM addressed by avoiding default Win32 loader binding.

07-14-2006, 01:50 AM
Exporting a “good registry” and later importing it can absolutely cause your system to become unstable. Any program you’ve installed since the export could have installed it’s own services, applied system patches,.

Yep, I didnt mean to imply it could or should be used for a "rescue disk" type repair. I don’t throw programs on and off my compute much now that it is set with what I use.

What having a "good" reg can do for you is to get you clear of a viciously embedded trojan or similar spy type ware. Lemme just say, I have been in contact with some malicious ware which is so intertwined through the reg that it took some long manual, discrete combing to clear it out. JRouche

Ian B
07-14-2006, 02:04 AM
...so it looks like the sky won't fall in if my registry expands to a massive 7.1Mb!

Thanks guys,


07-14-2006, 02:08 AM
Ever since Windows 3.0 the problems caused by applications adding and changing files in the system directories has cause uncountable lost hours of productivity and headaches for IT people.
Hi Evan,

Sorry to disagree, but there's a fundamental flaw in your argument, to wit: Windoze is not an operating system, therefore it can't have "reserved structures" such as system directories and system files.

The operating system is DOS, which is a single-user single-tasking OS with interrupt handlers. Windoze is a pseudo-multi-tasking applique which runs on top of DOS. Since DOS is not a multi-user environment in the first place, the concept of system security is meaningless.

07-14-2006, 02:35 AM
Sorry to disagree back at you. ;)

What you say is true of Win9x and it’s variants as well as Win16. But anything based on the NT kernel (NT, 2k, 2003, XP, etc.) is a fully functional multi-threaded, multi-user, OS in it’s own right with no DOS underpinnings of any kind.

Something else the slashdot crowd will always harp on is security issues, but it also has fully integrated security top to bottom. With a few exceptions which exist in any complex software to varying degrees, very nearly ALL the Windows security flaws are a result of catering to lowest common denominator users where ease of use wins over security. These two goals are always in direct diametric opposition such that getting more of one almost always costs in terms of the other. With only a few relatively minor changes to the default config, my system has been running 24/7 since late last year with NO anti-virus, NO software fire wall (though I do have a router fire wall), and no other protective measures not built directly into windows. These are things that anyone could do having the same relative depth of Windows/Computer knowledge that the typical xNix operator MUST HAVE to get things running and keep them that way. The main point is not running as Admin, though there are others. In all that time, and sitting on a 5MB connection 24/7 for about 8 months now, I’ve not had a single successful attack, virus or otherwise...

07-14-2006, 02:55 AM
Sorry to disagree back at you. ;)

In all that time, and sitting on a 5MB connection 24/7 for about 8 months now, I’ve not had a single successful attack, virus or otherwise...

Ahhh, thats my slow up speed, usually 15M down :D JRouche

07-14-2006, 03:01 AM
Welcome to registry 101. Take a seat.

I learned something about the computer tonite, right on. And the owner of this thread got his answers too. Forum life is good.

07-14-2006, 03:22 AM
very nearly ALL the Windows security flaws are a result of catering to lowest common denominator users where ease of use wins over security.

Uh, no. The vast majority of security vulnerabilities in Windows and associated Microsoft applications are the result of brain dead programmers and a fatally flawed system architecture. The largest category of hacks take advantage of simple buffer overflows. These dump data into ram where it is then executed as an executable.

Not only should strict buffer checking be done but it wasn't until XP service pack 2 that anything was done about data execution prevention. This isn't catering to the lowest common denominator. These are programming errors that even a rookie shouldn't be making and on a system that allows such errors to utterly compromise it.

Windows has more holes in it than a screen door. It has more patches on it than a raggedy ann doll. In the first year after Win XP release to manufacturing 305 serious problems were found. Five of those problems had the possibility of instantly on the next reboot scrambling the file system beyond recovery. Dozens of those problems were critical security vulnerabilities. The total number of critical security vulnerabilities that have been found in Windows of various versions numbers in the thousands.

As a point of comparison, in the first eight years after the OpenBSD operating system was released (a UNIX variant) only one significant security vulnerability was found. Just one (1).

07-14-2006, 03:35 AM
And do you realize that the vast majority of those exploits (which exist in all complex systems, even xNix, though generally found and fixed quicker and less severe since EVERYONE in that camp knows you don't run as root day in and out) are not viable without access to an admin token? If the security hole exists in an application using limited credentials, then the damage is also limited. WinNT Kernel security is quite robust in spite of the common opinion so many are so quick to trumpet. But when you do have a buffer overflow on the stack such that you can replace (typically) the return address and cause your code to execute, and that thread happens to be running with admin credentials, then you are OWNED. I've worked on these systems for years on both sides of the fence from DOS to mainframes and including xNix systems as well, wearing both black and white hats, and I can tell you flat out that 99% of the common vulnerabilities associated with modern windows system RELY on having access to an elevated token, and that is a direct result of users conditioned to think running as admin is acceptable.

As I said, I was challenged to put my “money where my mouth is” by a colleague over half a year ago. Due to lame programs from both MS and (mostly) third parties, running as non-admin, and particularly doing dev work as non-admin was quite painful in the beginning, but once I got a few things ironed out and some procedures in place, it’s not that bad. In that time, and I am on this machine CONSTANTLY with no protective software what so ever, I have had not one single issue with virus, Trojan, or spy/mal-ware associated problems. And that includes intentional exposures at the direction of some of my Linux head buddies who were predisposed to want to see this experiment fail. They are strangely silent on the matter now and I am actually quite surprised at how much better the system runs (stability and perf wise) without the anti-everything garbage and bloat-ware on the system. Frankly, I’ve come to realize that the low level hooks used by anti-whatever were what caused the marginal instabilities I had before my last repave and experiment. Since then, my system has BSOD twice in over 6 months of running, and both were due to an ATI video driver that was fixed with a update from ATI...

07-14-2006, 03:41 AM
Oh, and don't take that to mean I'm drinking the MS coolaid. I know they have flaws and have been far too slow to respond to issues like this (such as data page execution locking), you have no argument out of me there. My problem is with the endless legions of slashdot parrots overstating and skewing/exaggerating the problem and its causes simply from hear-say. You and anyone else are very welcome to your opinions, but I have quite another opinion based on my 20 odd years in all facets of the industry.

07-14-2006, 10:40 AM
Bad dog,

The most commonly used operating system for the home user at this time is XP Home. It doesn't have an option to run as anything other than admin. Yes, it has a "guest" account but that account is so restricted it is unusable and the permissions cannot be changed.

So, with XP Home you must run as admin, you have no choice. This automatically exposes all possible vulnerabilities. This is Microsoft's choice. It was an extraordinarily bad choice. It is consistent with their incredible lack of concern with security and reflects their long term inability to secure the system.

The experience with Open BSD does not depend on running at reduced privlege level. It is secure and security is the priority of the Open BSD community. You can safely run as root on an Open BSD system.

Having said that it is possible to secure a Windows system, at least an old one. I run my servers on Win 98. I have completely customized the system and don't even have file sharing enabled. I run them in the DMZ with only a software firewall. In four years they have never been compromised. The applications I run have no known vulnerabilities. Of course, none of the applications are from Microsoft.

07-14-2006, 02:50 PM
I am running XP Pro, and the window I'm using at this moment is running as a custom user account with very specific limited privileges that pretty much guarantee that I could click a link direct to a virus or trojan and it wouldn't be able to do a thing. There is another window running right now (at the same time) in the same "Windows Station" (which is the thing that has the Explorer desktop for it's UI) running with full admin privs.

I can’t speak for XP Home as I’ve had little cause to fool with it other than limited application defect reproduction and debugging (usually via network connection), but I’m pretty sure that while there may or may not be a user manager UI on the start menus, the config msc is still there for use should I choose to seek it out. Again, assuming I’m right (I lack motivation to load an image to see) the key to securing it would be a level of knowledge and skill comparable to the “average” Linux user.

But I whole heartedly agree that the default install, which is all most people will ever even think to use, is completely brain dead. That’s what I said earlier about the focus on making it as easy as possible, even at the expense of security. That’s not a flawed design or stupid programmers at MS, it’s the technological impact of a marketing decision. A rather successful one in spite of the consequences I might add. Whether it was the “right” decision is a debatable one and we won’t settle that here, but it’s not an inherent flaw or limitation in the system, but rather an artifact of default/typical config, which itself is a result of marketing pressures/requirements.

Funny that you feel a Win9x system can be secured, but not an NT Kernel system. On 9x, where there is no security sub system at all and no resources are protected in any way, ANY compromised process/thread can do anything in the system. And whether there are “known vulnerabilities” or not, I can pretty much feel confident in saying that if I were sufficiently motivated I (or anyone with knowledge and motivation, I’m by no means special) could “own” your W98 system without much difficulty even without social engineering (which I would assume you are to savvy to fall for easily, making a tech attack simpler in that case).

Finally, unbiased studies (plural, not just one) by security interested third parties (one of which was biased to find against MS and who I have worked for, though not on those studies) have shown that on the average, MS applications are no more generally susceptible to tech attacks than industry mean, and in some notable cases were actually MORE “secure” (various definitions) than other applications that were much more highly regarded in groups with strong anti-MS sentiments like the quintessential slashdot. The noted difference was that, because of the prevalence of the MS application’s (and OS) installed base, the motivation for identifying and sharing exploits of MS among the generally anti-MS hacker community is much, MUCH higher than for any other segment. And since the majority of the hacker community IS anti-MS and generally holding MS application security in low regard (rightly or wrongly, as we are discussing), they far more often target MS applications for their spelunking expeditions and internal rivalries. So, larger installed base and a perception of lack of security provides the impression of MUCH higher return on their investment to discover vulnerabilities. The only significant balancing force is the typically higher regard of their peers for finding exploits against those applications that are considered “more secure” in the community.

Your the first Nix proponent I’ve ever spoken to who feels consistently running as root would be ok. But then I’ve not been involved more than cursorily in that community for many years. But in any case, the statement that “is the priority of the Open BSD community” has absolutely nothing to do with the wisdom of running as root all the time. There is no way, none at all, that any complex system can be *known* to be 100% secure. Security” is ALWAYS a matter of degrees in an attempt to push “cost of success” to a level high enough to over balance the “perceived value” of conquering. Understanding this and determining this balance point is a big part of a process known as “risk assessment”. Claiming otherwise is to be wearing an enormous set of blinders and is best left for politicians and marketing directors. Assuming we can agree on that point (and if we can’t there is no point in this discussion), then running as “root” is just dangling that ripe fruit of full privs and eliminates the most difficult aspect of “hacking” a system, which is the effort to find a way to elevate your privileges to “root” once you’ve gained the ability to execute your arbitrary code. Generally, finding a way to execute your code on an arbitrary remote system (regardless of OS or software producer!) is not that hard to accomplish (modulo firewall restrictions and such). It’s finding a way to elevate your privs sufficiently to accomplish your goals that is FAR more difficult, and running as “root” eliminates that larger hurdle. Which brings us back to my initial assertion AND the reason anyone serious about security would/should never consider running as root/admin unless the process in question MUST have those privs.

It’s obviously far more complicated than either of us likely understand, or would care to take the time to express on a public forum even if we were convinced we had a full understanding, but making sweeping statements about the inherent inferiority of Windows security as was done on this thread is far to broad and absolutely incorrect.

On a positive note, the next MS OS uses a reduced priv “limited admin” account for the default operation of the computer, only elevating to “full admin” privs for applications where it is required. This seems to be a significant step in the “right direction” but it remains to be seen how the general consumer community will react to this as it does require a bit more interaction and awareness of security. Discussing it further would risk violation of NDAs so I’ll stop there...

07-14-2006, 03:53 PM
There is no user manager or config.msc in XP Home. It is possible to control the registry remotely and the system can be somewhat more secured that way but that isn't possible at the normal home user level. This isn't just a matter of default configuration, the entire permissions and control substructure in XP Home has been kneecapped.

The problems in Windows are most certainly programming problems. The continuous parade of security vulnerabilities are based in sloppy programming. These mistakes run throughout the OS, everywhere from the TCP/IP stack to the graphics display subsytem. There was even one found last year nicknamed the "JPEG of Death" that allowed a complete compromise of nearly all windows versions by the user merely viewing a jpeg image, regardless of the source of the image and regardless of the Microsoft application used to view the image.

I don't advocate running as root on 'nix. Not all versions are as secure as Open BSD. Open BSD is an exception and has been developed from the start as a secure OS. Not a single vulnerability was found in the first six years. I'm talking about vulnerabilities to outside attack over a network connection, not from the console. A person at the console automatically owns the machine and nothing can be done to stop that.

As for securing Win 98, it isn't hard to do. The only ports that are open lead to the secure applications I run. Furthermore, those applications have been configured for maximum security. For instance, there is no admin account on the FTP server and no public anon account. Passwords are minimum 10 characters. Same goes for the web server and I do not run PHP or Pearl and no web admin. Nothing runs at default settings. All admin is done from the console or via FTP which is limited to file transfer. Access to the FTP server is IP masked.

People certainly have tried to break in but none have succeeded. I have considerable experience breaking systems and a lot of tools that will shortly be illegal in this country when they sign an international treaty this fall. I keep them under triple DES for security reasons.

07-14-2006, 06:09 PM
I can't imagine why you think 98 is easy to secure but XP is hard, but oh well. I would rather be beaten that ever run 98 again. I'll also concede the point on XP Home user manager and trust to your accuracy since I have no handy image and no inclination to apply the effort to either confirm or deny. ;) I don't do any sort of IT work so it's not in my main sphere of knowledge.

Well, sounds like we are both professionals with strong backgrounds in the area but differing conclusions. Much like 2 experience auto professionals, one is a die hard GM fan, the other considers only Ford worth owning. Seems we agree on the important points, we just disagree on some of the OS specific applications of those points, so should probably just agree to disagree and let it go... :D One of my old colleagues used to say that “this is a point upon which reasonable people may disagree”. It IS good to see that you have knowledge on which to base your opinions rather than just parroting the anti-MS line like so many I run across.

It’s been a pleasure discussing this, but I use hands on machine work and fabrication to get a break from the virtual world of my professional career. :D Take care.

Rich Carlstedt
07-15-2006, 02:07 AM
" Proper operating system design requires that applications be restricted to a "sandbox" with no write access to system files."

I am no expert , or even near one, but Evan makes the point exactly.
As a mechanical Engineer, I am appalled at computer guys.
If you have a machine with cams that cannot/should not be revised, you put a locked box around it. If you don't want the motors and controls screwed with, you put a lock on the electric box. This is done every day in the real world
If you build an electronic organ and tune it with whatever, you lock the box.
You do not put a tone adjusting pot above each key !
(that is unless the oscillators you use are so unstable that you need to tune when ever you use the organ)
But then the organ is only good for trained organ tuners ...right?

That is why we have problems and he addressed it !
Go Evan !


07-15-2006, 08:42 AM
There's only one secure OS... Secure Linux


07-15-2006, 10:09 AM
Digital Equipment Corp. had security figured out back in the late '60s with their timesharing systems.

07-15-2006, 11:04 AM
There's only one secure OS... Secure Linux

Uh huh. I trust the NSA to not put in a back door. Millions wouldn't but I do. Uh huh.

J Tiers
07-15-2006, 10:56 PM
All I know about it is I run 98 at home, and rarely have any problem. Like once in a couple years.

Just got XP at work, due to using "Agile"...........

Xp has tripped an fallen repeatedly....... on its face, splat........

Here I thought it was better than 98....

07-15-2006, 11:03 PM
The problem is one of complexity. XP has around 25 million lines of code. I don't recall how many lines are in 98 but based on the size of the install it must be around 5 to 10 times less.

I am interested to see how Vista will turn out. I have a copy of the beta but need to upgrade one of my machines with a better video card and some more ram before I can try it. To run the full graphical interface requires a separate video card with 256mb ram and at least 1 gig of system ram.

There is an old saying in the computer business. "Intel giveth and Microsoft taketh away".

J Tiers
07-16-2006, 12:17 AM
If Microsoft can't handle it, maybe they should do something else instead...... They are supposed to be good at this stuff...... and it does work a lot of the time.

But little stuff is so annoying, like toolbars that appear sometimes, and other times refuse to come back, a taskbar that is set to auto hide, but only auto hides when I want to see it........

And then the unannounced lockups...... pull the plug time..... And XP seems to be less tolerant of abnormal shutdowns. It has had to be wiped and re-installed on a bare disk once already.....

As for Vista, isn't that the version that will call home and decide if you have privileges to see your own data and documents? With encoded and encrypted everything, and no way to recover dayta if it forgets you are allowed, or teh disk craps?

Thank you, Adm. Poindexter..... I know you got in there somehow...... bless you with a brick...

07-16-2006, 02:03 AM
Uh huh. I trust the NSA to not put in a back door. Millions wouldn't but I do. Uh huh.
It's open source.

07-16-2006, 02:28 AM
It's open source.

That isn't sufficient protection in such a complex operating system.

A few years ago a problem was noticed in a module in the build tree for one of the popular versions of Linux. A checksum was off. The code was examined numerous times and nothing unusual was found.

Finally, by pure luck somebody stumbled on the problem. A single line of code had "==" instead of "=" in a statement. Changing the comparison to assignment didn't change the functioning of the code at all. It did however set a flag that allowed the process to be invoked at any privilege level at all and provided a back door to root privileges.

No one is sure if this was simply a coding mistake or an attempt to insert a back door in the code base. If it was a hack it was a brilliant one and almost made it into the distro. Checksums are never 100 percent reliable since that is mathematically impossible.

Something similar could easily be included in the NSA distro and even an army of hackers wouldn't be likely to find it. The NSA has some smart people working for them.