Windows vs Linux: Architecture, part II
[ Sunday, 30 September 2007, Keyto ]
…continued
After a boring and dry customary introduction in the previous part of the article, Windows vs Linux: Architecture, part I, I went on to describe problems with Windows system accounts, kernel architectures, system security, and both kernel and user modes. Welcome to the second part of the article. If I’m counting correctly, it is time for the fifth chapter, namely:
Documentation or Vendor Lock-In for the First Time
All advocates of free software praise open source benefits - that it can be modified, analyzed, and whatever else may come to their minds. But to me what is best in the Open Systems is their openness of documentation. Linux alone happens to be irritating. Hey, stop pretend it is not true! It fails - as any other advanced program. Sometimes it goes wild, contrary to our expectations. Errors and failures occur in Linux equally as often as in the Windows systems. Why? Because the least reliable feature is the man himself. A lot depends on the administrator. He can crash the most reliable Unix system and operate Windows Server 2003 without a glitch.
So, we have failed, made the system unsafe and someone stopped it - now we have to make it operable. We reach out for documentation. There is no problem with this when it comes to such systems as Linux, FreeBSD, Mac OS X (Darwin), or other Unices. After a while, we end up with a proper doc page, and after many attempts and consultations with gurus, we remove the error. When dealing with Windows, we behave differently. Documentation exists, but all in all, it cannot be found. Microsoft Customer Service exists, but it seems to be non-existent. Other Windows users shrug when asked. What remains is the Microsoft web pages…
I don’t mean to test your patience, but I’d be pleased to hear/read about others’ experiences with finding something helpful there. Looking at the subject from the perspective of time, all that remains for us to do is to use the good old method - reinstalling the system.
A reinstalled system needs to be configured once again. The problem comes back like a boomerang. There are zillions of Windows configuration possibilities. Having a knowledge of specialized Registry settings, one can work wonders. The only snag is that one has to have the knowledge. We will not read the know-how from the Windows help. Even the right books about the subjects are scarce, as most books dealing with Windows systems tend to bring up such important topics as “how to change the Windows background/wallpaper or/and system sounds”. The same could be written about accessibility to information for programmers, but these are not the worst questions.
Let’s assume we bought an OEM version of the Word text processor and we have written a book in .DOC format (e.g. “Harry Potter and the Magic of Colin Craven”). Now we buy a new computer without Word, because we want to install OpenOffice. Surprise! Our precious file we worked on for several hundred hours is unavailable! The file was conjured up through our hard work, but is practically useless because (By Jove! We even do not know why! Due to our ignorance) it can be opened only with Microsoft Word, and Microsoft does not make public specification of the file’s format. (I’ve given you a life example, alas. A friend of mine wrote non-fiction texts and in order to read them he was forced to drive 70 km at 2:00 AM in the night, as the matter was urgent.)
Most people contend that OpenOffice needs to be used because it is open source, free of charge, and sufficient for most of the office’s needs. Nonsense. It should be used because even after a hundred years, we will be able to read its format and recreate its algorithms. I refer prospective opponents to a recently published article on the future of closed file formats: British National Archives Report.
Of course, documentation is not a part of the system’s architecture in the strict sense of the word. However, it constitutes an integral part of the product called the operating system and it cannot be omitted when operating systems are compared. I will take a chance and say it is better to have a functionally lame program, but a documented one, than an elaborate solution without a page of description. And good documentation for Windows would come in handy sometimes. For example, let’s see into the…
System Registry… (and the world was once so beautiful…)
Hell, it makes one’s hair stand up on ends! I do not know who got the idea to put all the Windows system configuration data and those of the Windows applications into one database file. It would be recommendable to look through patent motions - it’s probable that the same person patented the squared circle or powdered water. The most preposterous idea. We put all the data in one place, system failure occurs and we are in shit. One error within the database file and we have to reinstall the system. Sometimes it could be recovered if there was reliable documentation and the file was a little less complex. Good Lord! Less complex…
Let’s have a closer look into the “invention”. The Windows Registry in 2000/XP/Vista systems is placed in C:\Windows\System32\Config directory. (If C:\Windows is Windows directory.) It is comprised of the following files:
- Sam - HKEY_LOCAL_MACHINE\SAM
- Security - HKEY_LOCAL_MACHINE\SECURITY
- Software - HKEY_LOCAL_MACHINE\SOFTWARE
- System - HKEY_LOCAL_MACHINE\SYSTEM
- Default - HKEY_USERS\.DEFAULT
- Userdiff
Additionally, there are files in the HOME directory:
- Ntuser.dat - HKEY_USERS\ (HKEY_CURRENT_USER)
- Local settings\Application Data\Microsoft\Windows\Usrclass.dat - HKEY_USERS\_Classes (HKEY_CURRENT_USER\Software\Classes)
System configuration data and its entries can be found in the first five files. They constitute the system configuration database. After a login, the data from the user’s home directory is also added to the database. I’d like to draw your attention to the fact that it is not a relational database, as what may come to mind, but is instead called a hierarchical database. The database’s main branches:
- HKEY_CLASSES_ROOT
- HKEY_CURRENT_USER
- HKEY_LOCAL_MACHINE
- HKEY_USERS
- HKEY_CURRENT_CONFIG
Let’s notice, please, that some branches and registry keys possess their own permission rights. The worst thing in this picture is that Registry is not enough to have the system configured. There are application configuration files and system configuration data stored in INI files, sometimes XML files, and in other formats. (E.g. system.ini, win.ini…). All in all, it’s simple - isn’t it?
Let’s make it clear - I do not claim the Windows systems are bad. I mentioned that in the comments put in the first part of the article. But I judge the Registry decidedly negatively. I am not able to find even one reason justifying its existence. On the contrary, there are a dozen arguments against.
But before I name a few, it is worth it to see how the system configuration was solved in the Unix family. All configuration files were put together in one place - the /etc directory. We’ve gotten an order and the possibility to manage permissions. Because, as a rule, all the files are in text format, they are well documented both through their inner structure, and through the possibility to put readable comments inside them. Failure of any one of them will not result in “the end of the world”. Even if the system does not want to start, we are able to get to the /etc directory in some way, make corrections, and come out victorious from the precarious position. Sometimes even without having a backup copy of the corrupted file.
Generally speaking, the whole picture isn’t so rosy, but dealing with the Unix config files is easier than with Windows files, because:
-
Just for the beginning. As I said before - failure of one of the Registry files spoils the whole system configuration.
- We can make a backup copy of the database (who makes them regularly?), but pay attention to the fact that when the system is crashed we are left with only one possibility for recovery - we have to rebuild the whole Registry. It’s extremely difficult to extract a branch, or a key from a Registry’s copy and place them in lieu of faulty ones in the original Windows Registry. (it isn’t impossible to do that, but it requires the skilled management of a few tools, among others to run Registry Editor in the command line environment. Without the specialized editor, nothing can be done as we are facing a binary file.)
-
I have written about Windows documentation in the previous chapter, but I want to draw your attention here too. A Nobel Prize for anyone who understands Windows Registry config entries. And anyone able to freely add default entries in empty places within the Registry, may be addressed from now on “The Mother of All Gurus” (well, Father too
).
- System crash entails failures of all applications. If their configuration files were kept alone, there would not be so much work to do with reinstalling Windows.
- At first, such a uniform, consistent, and binary database should appear to be rather fast. But in reality, the Windows Registry I work with is over 50 MB, whereas a Linux /etc directory takes 30 MB and gives me, what I want to emphasize here, the same functionality. OK, ok, it’s hard to compare the values, any consideration about the superiority of searching a file-tree over a database would fill in a whole article. But I am gravitating toward the conclusion that there are no wonders. For sure, searching the Windows Registry isn’t faster, but it certainly doesn’t spare system resources, either. I’ve been observing the trend for years.
Curiously, in the beginnings of Windows, it didn’t have the Registry. The system was configured through ini files placed in the main directory. Well, today they run faster and better…
Applications or Vendor Lock-In for the Second Time
My high school physics teacher (I get goose pimples…) used to say that “when it comes to (please put here any subject, at random), everybody has a knowledge but no one ‘feels it’”. In order to “feel it”, as my expert teacher said, one should live through it. (Why, then, didn’t we make experiments instead of cramming knowledge?) I suggest, then, the following trivial experiment. We need one computer with Windows XP Professional on board (or with Windows 2000, but not with Vista!) and Internet Explorer v.6 (it’d be the best to have only one web browser), access to the Administrator account and about 10 minutes. To the work, then. Ouch! I forgot: The Author cannot be blamed for any results following the experiment. Everyone does it at his/her own risk.
First: Log in as Administrator,
Second: Create a user account, let it be Bill (in honor of William Henry the III). Such an account is called a “limited account”,
Third: Log out from the Administrator account and log in to the Bill account. At this time, the user’s home subdirectory with corresponding configuration files is being created in the Documents and Settings directory (except if it was defined otherwise). It would be wise to set the “classic folders” option, in “Folder Options” within “Control Panel”.
Fourth: Log out from the Bill account and log in as Administrator. Find the “Program Files” directory and “Internet Explorer” subdirectory on the system disk (usually C:). The iexplore.exe program is placed there, with the famous “Blue E” icon.
Fifth: Click the object with right mouse button and choose “safeguards”. You’ll find there, at the top, the “Group and User Names” option. With the help of the “Add” button, add the user Bill. Click the Bill object, and in the lower part of the tab, mark all the flags in “Deny” column. It suffices to tick off “Deny” in the “Full Control” flag to have the rest of the flags marked automatically. The Windows system will show the message: “You set the Deny option. Denies are prior to Allow options. It means that if a user is a member of two groups - Deny and Allow - a given right will be denied to the user. Do you want to continue?” Choose yes. Attention - do not play with the user rights belonging to administration groups, particularly to the ADMINISTRATOR user and the SYSTEM user. It can result in a system freeze. Well, sometimes - it’s not 100% and not straight off.
Sixth: Log in as Bill. Double clicking “Blue E”, you’ll get the message: “Deny” in return. What this means is that Internet Explorer is blocked for the Bill account.
Seventh:
Double click “My Computer”. A window will appear with an address bar (where “My Computer” is written). Remove the current text and enter “http://jakilinux.org/”. Press Enter. If everything goes OK, you will be able to read latest IT news. (Some computers may require additional configuration.)
Eighth:
Now for the most interesting thing. Every Windows application has a Help option in its Menu. The Help window contains the “About” or “Information” buttons at the bottom. Pressing it, you will be shown a message telling about Microsoft Internet Explorer. Version: 6, etc. etc. So, do we have the permissions to run the application or not? It’s interesting that the “Open in New Window” option does not work. On the one hand, we cannot run IE, and on the other we have “de facto” just used it.
The first insight pertains to the fact that the notion of a web browser is losing its meaning. However, it should not be forgotten that every advanced program doesn’t represent a monolith, but is comprised of numerous program modules. I wrote about software abstract levels in the first part of the article. What has referred to operating systems is also true in reference to any well written application. Every web browser, be it Microsoft Internet Explorer, Mozilla Firefox, Apple Safari or the multiplatform Opera, all are built using the aforementioned levels - logical layers. We all know that a rendering engine is responsible for displaying the Web page. In respect to the above browsers’ list, they are as follows: Trident, Gecko, Apple WebCore (see KHTML) and Presto.
To display an HTML page, one doesn’t have to use the full IE browser - it suffices to run a few IE modules (among them, the rendering engine). If one was able to block access to the mshtml.dll library, the HTML page wouldn’t be displayed (don’t try to do this!). The problem with IE stems from the fact that the application is not limited to browsing the “Internet”. It creates conditions crucial to the functionality of the whole Windows graphical interface. Here are the next three insights resulting from the “experiment”:
Firstly - leave alone the IE for a while and let’s think about a commonly uttered sentence - “free software is really slow” (a wordplay - in Polish both meanings, “free” and “slow”, use the same word “wolny”). What that usually means is that it runs slowly. Boiling it down to simplicity, we could say that Microsoft applications (or “closed software”) starts faster, because in the time we click the application icons they are “already running” to some degree. Both the above mentioned web browser, MS Office, and Outlook Express already have at the beginning an advantage over non-Microsoft applications. It doesn’t mean they are loaded without user’s consent. This “actuation” before “a real actuation” is to some degree a metaphor. It can be that all the programs make use of shared components, dynamic libraries, or the same rendering engine. Because…
Secondly - when designing software, one has to answer a very serious question: are we to write a single platform program (e.g. for Windows), or do we want it to run on many IT platforms? It is not a clear-cut issue. In the first case we gain on software consistency, faster starting and/or running, but at the expense of platform portability. The designing of the project and its implementation are straightforward too, at least in theory, as we can make use of ready solutions. But if the software is more attached to one platform, then moving it to another platform means that most of its code will have to be rewritten. (We can cite, as an example, Internet Explorer for Mac OS X. Instead of the Trident rendering engine it uses the Tasman equivalent.)
In the second case, we often have to reinvent the wheel, namely to code some software functions anew, i.e. x found in Windows. Why? Because they are not implemented in Linux and we want to have our product to be a universal one. The algorithms alone differ a little in such cases because their behavior cannot be set a priori in terms of system states.
Thirdly - as it can be inferred from our experiment, in case of too strong an attachment to a hardware platform, a problem can arise. The problem of software transparency. Well, well, ladies and gentlemen, in the time when Windows 2000 hit the market and the information about it was scarce, I experienced a small nightmare related to system “security” connected with such “inventions” as Internet Explorer. The ways which should work within reason, wouldn’t. And I have always ended up with a new security hole, and please believe me, it concerned issues more complex than this one described above amounting to a simple blocking of an executable file.
What conclusion can an ordinary mortal who doesn’t write software come to? I would say this one: nothing is certain in our life. For example, using OpenOffice.org may expose us to a little discomfort related to a loading time of an application, but we gain the possibility to move painlessly to other operating systems like Solaris, Linux, or any of the BSD family and at any time. I find here another meaning of the term “free software” - we obtain a free choice. In the case of Microsoft products, which are strongly bound to one hardware platform, any change would be a very difficult one. They won’t be ported to other system platforms, and even if they were, ease of use would not deviate from that found in other applications. And even though it may have been true at one time, free software is not so slow anymore. A method will prevail.
It is indicative of the proven marketing behavior, which makes prospective customer to act in such a way, whether they like it or not, that they always choose a given software only because they used its older version before. The strategy is called a Vendor Lock-In.
What did the Author have in mind?
With my last words, I’d like the readers to keep in mind that the article was written to entertain them above all. Secondly, I must recall, the goal of the article (apart from entertainment) is not to prove the superiority of Linux over Windows. When dealing with systems, I evaluate them paralell and with attention to details. However, poor performance in one place doesn’t have to impinge on the system as a whole (and vice versa). If someone got the impression that I favor Linux systems, they were right, but I spent nearly the same amount of time with Windows and I’m still alive.
And that’s all folks. For the time being…
Translated by P2O2, Proof-read by trashcat, Jake Conroy
Subscribe to RSS feed for this article!
5 Comments
- A hyperlink: <a href="polishlinux.org">GNU/Linux for everyone!</a>,
- Strong text: <strong>Strong text</strong>,
- Italic text: <em>italic text</em>,
- Strike: <strike>
strike</strike>, - Code: <code>
printf("hello world");</code>, - Block quote: <blockquote>Block quote</blockquote>
















Wonderful article! I enjoyed it very much. Interesting, thorough and well-written!
I found this to be both entertaining and most informative. A very good, well thought discussion. Bravo!
I don’t whether the author was asking a rhetorical question, but the inspiration for the Windows registry was derived from VAX/VMS, since the same person -Jim Alchin- was pretty much the architect and father of both OSs.
That was the same Jim Alchin who sent an e-mail to Gates and Ballmer in which he said: “If I wasn’t a Microsoft employee, I would buy a Macintosh”. Look it up…
-Ramon
After reading this text
you must come to the conclusion that
Windows could be wonderful if not the Registry
The author forgot the comparison of:
1-(Linux kernel scalabilty and portability)
and (Windows OS/2 kernel)
2-NTFS and (ext3 + swap) file systems
permisions
3-Client/Server architechture
and single application
(what makes Linux really
multitask and multiuser?)
4-The enormous, tremendous flexibility
of the configuration of the UNIX-like OS.
5-The quality of the Open Source applications
is verifiable and is bound to the authors.
There are pros and cons to both approaches of storing configuration data. It would be unfair to say all Windows’ configuration data is stored in the registry and all Linux’s configuraion data is stored in flat-files on disk. Something like the registry on windows isn’t exclusive to windows - We see implementations of ‘registries’ on the Unices too. sysctl for changing kernel options and gconf for maintaining gnome configuration data are just two of many examples.
Storing information in flat-files has some benefits too.
- Not everyone’s a C[++|#|.Net] programmer - It’s easier to engineer tools in [place you fav. programming/scripting language here] to mainpulate configuration information without having to interface with APIs.
- It’s easier to make changes to another user’s configuration data which is quite an inconvenience with how the various users’ registry sections are stored.
- Some down-sides to using flat-files are
– maintainability - the more flat-files you have, the more you have to remember in terms of filenames, sections within file names, data-types within sections, etc. It’s not to say that registries solve all problems of maintainability, but they sure help.
– scalability - flat-files are quick and easy for a very limited set of data, but they quickly become huge, slow and ugly once you start to store anything-and-everything about your complex, customisable application.
– speed - disk access speeds are relatively slow and top-to-bottom scans of unfixed-length-records in files don’t help when things are already slow.
Registries provide solutions to problems faced with using flat-files but they have their own sets of problems too.
- A collection of configuration information under one roof and providing a consistent API allows for a multitude of tools to be able to search, query, add, modify and delete options with relative ease. Incidentally, backing up and restoring all this information is convenient. A Potential down side is data-loss due to memory or disk corruption on a huge scale (all these eggs exist in one basket).
- Logically gouping options by relavance into hives could allow for easy batch operations - e.g. installing/uninstalling software, services, devices, etc. Backing up and restoring a subset of all your configuration data is also convenient.
- Confgiuring security descriptors on registry objects allows one to control what subsets of access users on the system have in relation to configuration data. Rather than grant a user write-access to a file, you can grant write-access to a set of particular records while still protecting others.
- Generally indexed registries provides better perormance over flat-files in terms of looking up and manipulating data.
- Support for object types allow for effecient storage, organisation and retrieval internally. This to some degree provides filtering of data but is dependant on implementation - e.g. you couldn’t mistakenly store a string in a binary container.