Windows vs Linux: Architecture, part I

[ Wednesday, 5 September 2007, Keyto ]


Linux is not a free version of Windows. The two systems differ not only visually, in the graphical user interface the user sees, but also functionally, as is frequently discussed, and legally to boot, which is constantly emphasized by the Free software community. The differences between them are so fundamental that drawing a comparison between them is nearly impossible. There are so many moot points that they could make up a very long list.

This part of my article concerns the architectures of Windows systems. The systems themselves are baffling ones, to put it mildly, but to know them is more than a necessity. (And a forced necessity sometimes…) When I say Windows, I mean the whole family of operating systems – NT/2k/XP/Vista – but mainly XP Professional. Many a time I’ve read anti-Microsoft rants, where the authors complained about lack of command line functionality (poor in Windows and very advanced in Linux), or installation processes, which create some problems and erratic application upgrades (just at the point the comparisons to Linux programs like apt-get, emerge and rpm show up). A lot of grumbles pertaining to wrongly set-up default user and root accounts could be found there. And so on.

These inconveniences are grievous ones in my opinion, more, they should be branded as top-level ones. But the fact remains that something can be done with them – more or less. For example, any Windows system I’m talking about here allows to create a user account after all. Linux as well makes it possible to unlock root account to work with. No problem. I must emphasize one thing — it can be done. Regardless whether someone will do it or not. I can’t contradict as well the sentence that Windows’ default configuration is “politically incorrect”. But this very text concerns architectural solutions which cannot be changed one iota, mainly due to project’s “derailed” design philosophy.

I admit to a certain simplifications in comments, even drastic ones, with premeditation. I want the article to be understood by everyone who has a basic knowledge of operating systems, so I ask those who know the subject well to remember this and do not show the signs of the ROTFL syndrome :)
This is a collection of random thoughts rather than a scientific article about Windows architecture so keep this in mind when reading and commenting.

Ground Zero or Collective Governing

As we all know, operating systems make use of a “user” notion. We can log in to the user account and then run amok within the “computer space” the account is defined by. With the exception of a group of system functions which are restricted for a unique user called the “system administrator”. This fact is common knowledge. It can be a Unix’s “root”, a NetWare’s “supervisor”, or another “admin”. The distinctive feature of this peculiarity is the fact that the user is a real Master of his system as Zeus was for the ancient Greeks.

Provided that we do not talk about Microsoft Windows systems, otherwise the matter would become more complex. Namely, the Microsoft’s flagship product has at least two distinct administrators, as some of you know (and some of you don’t). One of them is called ADMINISTRATOR user, the other is named SYSTEM user. The standard SYSTEM account is like an “agent” from the Wachowski brothers’ Matrix trilogy. If we look at the process list in Task Manager we’ll see that most of them belong to SYSTEM user. It is also the owner of the technical files like the System Volume Information (SVI) directory and its files. Our electronic friend, the SYSTEM user, is the only default owner of the file, so if we want to check the space it takes we will have to add the ADMINISTRATOR user to the list of permissible users. (Other users can be added too, but I do not recommend this option.)

I will try to explain in the next chapters why I think that “Though this be madness, yet there is method in it”, and that the SYSTEM user is indispensable for the Windows system’s functionality. But now, a short afterthought on its existence taken as a whole. It is common knowledge that every problem in the IT world can be resolved in many ways. Are all of them equally simple? Decidedly no. But the Kiss, “Keep It Simple, Stupid”, rule has proved to work in real life. As I have written above, all operating systems have only one administrator in principle, and that’s a simple solution. That’s for sure, that the existence of another administrator would automatically create certain complications, to put it mildly. A trivial example: nearly all common Windows users do not know how to get into SVI directory (so they don’t need the “advanced users” at all).

If I wanted to write a dirty trick which gathers a Windows user’s passwords, projects and everyday agenda, I’d put the data just there. First of all, the SVI directory is not visited at all. What’s more, most of the users do not know about its existence. Secondly, the directory evinces a magic feature of changing size in flushes by up to several hundreds of MB – both up and down. (Failover information is stored there). The ideal place. What is important, a computer virus is more efficient if it is able to infect executable files with the highest permissions. Once more, the SYSTEM user is the best for these types of tasks. For sure, the SYSTEM user will not make a hue and cry, as it isn’t Artificially Intelligent.

Making an analysis of a Windows architecture, it might appear that the implementation of the “agent” was vital to the system… Really? I’ll answer in a while.

And the Life is an Illusion

…or system start.

Let’s vote, which system – Windows or Linux – starts faster. Most IT users would vote for the Windows systems. It is a solid proof for a thesis that one should deal with a democracy with utmost care. I suggest to run a test. Let’s measure the starting times of the two systems with the help of a stopwatch. Let’s start with Windows first. We switch on the computer, we observe POST messages or a BIOS manufacturer’s logo, and at last we face a boot manager (GRUB, LILO, etc.) or we see a system’s loading process. Here we turn on the stopwatch. Boring moments pass. Boredom filling our limbs… The system crunches and minces some data, but we are still lazily yawning… One more time and the login window appears. Most of the users would stop the stopwatch now. Unrecoverable error! The system loading is still going on! We type in a password and we see how the graphical environment emerges. Beg your pardon. The graphical environment and the system. Windows system finishes loading – depending on configuration – after several dozens of seconds after user actually logs in!

Bootchart, Linux loading
Picture 1. Linux loading (sources: Bootchart.org)

To examine the reasons that the system booting process was solved in a particular way, we must start from the ground up, or see to the notion of the system’s kernel. It’s funny – but everyone uses Operating Systems’ names, but only a few know what it really is. If a precise definition cannot be delivered, it is advisable to create a list of features which will describe the idea. However, even the operating systems’ specialist cannot agree how to define operating systems. Nearly all features are the same, but there is always a small “but”. Even the operating system’s bible – Silberschatz’s book (A. Silberschatz, P. Galvin “Operating System Concepts”) names two definitions. Generally, it is considered that the operating system is a program, which runs incessantly in the computer from the beginning (when the operating system has been started, not the computer!) until the computer is turned off (or restarted). All other programs are called “applications”.

As Silberschatz writes:

An operating system resembles a government. It provides means to proper usage of computer resources. And similar to the government it doesn’t make use of any useful functions. It simply creates an environment in which other programs might facilitate the useful functions.

In this view the operating system’s definition is tantamount to a kernel definition. In other words, one could place an equality sign between the word “kernel” and the technical concept of an operating system. Generally, the phrase “operating system” is used to denote all those programs which are provided by a manufacturer to satisfy the demand for such a working environment. That’s why the Linux name is often used to define the whole system, although the name denotes the kernel only. Let’s assume that when I write about kernel I will use a full name – operating system. However, I say “system” when I want to describe all the programs as a whole, together with the kernel.

Now, the difficulties appear. The kernel tasks are defined very loosely. No one knows if management refers to blocking access to system resources or to allowing them to be accessible (e.g. a network card), or it has to deliver a handler (even if a partial one). In practice, the solution is not a simple one, as to master the resources, their specifications must be known. In other words, the problem boils down to one question: whether the kernel should be a program containing complete solutions, however basic, or the program should be focused on only one thing – administration, leaving all the works to do to “external” (to kernel) applications?

With the first example we get a really big program called a monolithic kernel. The second example defines a small and fast microkernel, which looks like an “underdeveloped” version of fully fledged kernel. Monolithic kernels are used by Linux systems (sometimes called Linux distros). Microkernels, for example the Mach microkernel, are foundations to Mac OS X operating systems (attached to Apple computers) and GNU/Hurd operating system which is still in its infancy (which is the case for almost two decades).

And another important matter. An operating system, or every operating system, is build like a cake (or gâteau). As we know the bottom part consists of a layer of biscuit, then it’s covered with sweet fudge, then another biscuit disk, let it be a coffee-flavored one, and once more a fudge layer covered with jelly. As far as programming is concerned, such a layered structure is also used but it’s called abstraction layers. And so as we have the first biscuit level (layer) in a cake which “lies on a hardware” (on a table), so we have a kernel in operating systems which manage the hardware (all operations depend on the layer). Next levels are then build on top of the kernel. For example – first we have X Window System, then on top of it a graphical environment (e.g. KDE), then window manager (e.g. kWin), and only then, on top of all the “layers”, a Firefox web browser. It does matter that every layer sends messages only to its direct neighbors. When a jelly dribbles down onto a table it is high time to lay off the cook.

Operating System Architecture
Picture 2. Operating System Architecture (sources: Wikimedia Commons)

Keeping in mind the layered model we will come back to Windows systems’ booting. First of all we have to emphasize that the Windows system’s kernel is similar to a microkernel. (To be more precise, the kernel is called a hybrid kernel – it can be placed between monolithic and microkernels. None the less, it needs many “helpers”).

After starting the computer, the first thing which is loaded is a kernel indeed (ntoskrnl.exe). Next comes its best “friend”, namely HAL module – Hardware Abstraction Layer which manages drivers needed for system loading. When the environment is ready, a Session Manager is put into motion (smss.exe – Session Manager Subsystem) which starts identification and authentication programs – or using simple terms – which shows the login screen. A user satisfied that his Windows “is ready” to use, may enter a password, which makes the system load system permission data (Group Policy) and then have up and running the tasks defined in Runonce and Run keys placed in Windows Registry (e.g. HKLM\SOFTWARE\Microsoft\CurrentVersion\Runonce). At the end, Autostart (from Start Menu) applications are loaded.

Linux systems present a different approach towards this problem. After the monolithic kernel has been loaded, the init process is started, which in turn invokes other processes (I suggest to issue a pstree command in a console while this happens). Practically, all the necessary system processes are started during the system start. So when a user sees login window (or screen) the only thing left to do is to attend to the KDE or GNOME graphical environments. Anything beyond that is ready to use. (Ubuntu team works at present to replace the init script with an upstartscript. But it doesn’t affect our reasoning.)

The question – which solution is better – must be left without an answer. However, a short digression must be added to the end. Microsoft uses the trick notoriously. As psychology teaches, the most frustrating is a man’s inability to act and his lack of influence on any processes, so moving the login phase into the middle of starting sequence of events, will give the user psychological comfort and it will be received better. And even though the monitor has displayed the famous task bar and icons, no one will be able to load an advanced spreadsheet application or a game. Most of the users are aware they must wait a while yet. Such solution is a better one than previous ones in terms of marketing but it backlashes in lesser stability or the system’s safety and leads sometimes to the frustration of inexperienced users.

Taking into consideration the whole start sequence – Linux doesn’t load slower than Windows systems. The foundation of operating systems, that is, all what is hidden behind the name is known for years. There’s no wizardry in this world.

II Where the Hell is the Security?

Operating System as a cake.
Picture 3. Operating System as a cake.
(sources: Wikimedia Commons)

Why the opinion that Linux systems are safer than the Windows systems is so prevalent? Perhaps due to the fact that it is true. But why? Let’s go back to the previous point. As I wrote, an operating system resembles a cake. You’ll find its kernel at the bottom, and its applications placed on top. According to the cake, picture the kernel together with associated programs creating a so called kernel layer. The rest of the running tasks make up a user layer. In other words – the kernel layer creates an environment in which the user layer is ran. The system is divided into two – upper and lower parts.

We can simplify the matter if we are to write about the Linux, Mach (Mac OS X kernel), Solaris or BSD systems. Safety tasks are run within the kernel layer. Basically, in the kernel alone. The Mach microkernel has additional safety modules which run in the kernel layer as auxiliary programs. Protection in Unix systems is always on, moreover, it is simple in terms of design and due to that statistically tougher to crack.

The same cannot be said about Windows systems. The protection subsystems are more complex and they run within the user layer. The logic lying behind is screwed up. The operating system is deaf and blind. It creates an environment. The programs which can “talk” to the environment are started in the user layer, so the protection which works on the same level should be efficient. Read from a paper, it is true, but life is not so rosy. First of all, any program running in the user layer (protection is implemented as another program) is more vulnerable or prone to “disarmament” than protection implemented in the kernel layer. For second, one of the most popular computer protection systems, not playing with details, is a firewall. As it works in the user layer, it must be designed in such a way that it shouldn’t find itself not starting in the system’s loading process. At last, it is a program, and contrary to the kernel itself, it doesn’t have to work.

A small digression. I have written earlier about the “SYSTEM user”. This SYSTEM is needed by the Windows systems to start programs in the user layer, among others. After all, we mustn’t wait to launch a firewall until John Smith is logged-in (after several hours in which his computer has been up and running). So the SYSTEM user is used. But it suffices, like in the Mach example, to place the protection subsystem in lower layer and have the problem off of a head.

“Keep it simple”, old Rabbi used to say. Well, Windows’ architects seemed deaf for this thoughtful advice…

III Mapping problems

Let’s assume something like this. I have logged in to a Windows system as a common user. Let’s check what disks have been attached to my system or speaking precisely – what disks have been mapped to my system. I have found, as a “normal” user, a few network disks from two servers. My computer runs several programs. You’ll find among them local ones, one from the first server, and another one from the second server. All the applications make use of several dozen files at once, some of them placed on the two servers.

Let’s assume now that at one time I have decided to read the data from a file owned by a server administrator (and it has just happened to be me). Oh, Lord! How I did yearn to work with any Unix system in such conditions! Any attempt to attach admin resources will end up with the message: “Multiple links to server or to shared resources by the same user, making use of the user’s name more than once, is not allowed. Disconnect all previous server connections and try to reconnect.” Marvelous!

If I was working under Linux or OS X I’d be able to mount the needed device and to make use of a file, using a nice and simple program called smbmount. The program treats every connection as a unique one and “pays no attention” to such conditions where another copy of itself has just made a connection to the same device under the name of another user. This is the direct result of conceptually complex design of the user layer, which I described earlier in this article. It can be commented only one way: another proof for superiority of simplicity over complexity.

if there is interest in the subject… it will be continued… in a due time…

What the author has in mind?

It is not the author’s intention to rekindle another flame war between Windows and Linux users. The author asks both sides interested in this topic to refrain from darting names onto each other. If one feels necessity to comment the article, please write “it is bad or not”, or point where it should be rewritten in a broader perspective – what doesn’t mean it should show superiority of one of the systems over the other. Such a statement would be highly subjective. And when I reckon Windows’ architecture inferior to Linux one, it doesn’t mean it is inferior. They differ. Writing operating system is a complex matter and too many times the chosen solution is so called “a solution of lesser evil”. One is able to write a similar “list” of architectural items pertaining to Linux systems, but it would have nothing to do with Photoshop running or not on every of the two systems.


Translated by P2O2

Proof-read by trashcat, chaddy, michuk

About the Author

Keyto

Keyto is a computer engineer living in Poland. In free time he likes to write longish stories about GNU, Linux and its users :)

New AdTaily ads!

Are you a film buff?

film buffs community, movie recommendations and reviews

RSS: Comments

You can follow the comments to this article through a special channel RSS 2.0 .

Related articles: Linux

 more »

PolishLinux Top Content


Become our fan on Facebook!

PolishLinux.org on Facebook

Follow PolishLinux on Twitter!

Follow polishlinux on Twitter

Google Ads