|
| Foocha! is a non-profit Web site. We do it for kicks, not for cash. If you're interested in writing for the site, click here |
|
 |
| Nerd Up! 2,
2. Reboot again? Now?! |
|
 |
 |
|
 |  |
 |  |
 |
Anyone who has ever tried to do something more complex to their Windows 9x Operating System (OS), would sooner or later have asked the question – "Is it really necessary to reboot the machine all the time?" Personally, I have my doubts about whether it really is necessary to shut everything down and restart just because I want to change the resolution of my screen (I know this has been improved), but apparently Microsoft has another opinion. I will not try to explain all these frustrating reboots, but some of them can be understood with a little knowledge of the OS underlying structures.
Layers of an OS In the perfect world, an OS is structured into layers.
-
Figure 1- Layers of an OS
Applications This layer is not part of the OS, but rather drawn to show how the applications interact with the OS.
System Libraries In all common OS, there are a bunch of standard libraries. Functionality Application Programming Interfaces (APIs – see below) used to program applications.
Device Drivers The drivers are the interpreters that translate the hardware device’s language into system library language. The term "Device driver" is often shortened to "driver", and is what a computer might ask for when you have installed a new piece of hardware.
Hardware The actual gadgets. Sound card, mouse, network devices etc
Not part of the OS.
System Libraries When creating applications, most programmers use system libraries to accomplish the task. System libraries contain "high-level functionality" which programmers can access using APIs. A system library can use the device drivers or other system libraries to perform its tasks. High-level functionality means in this case that the functionality provided by the system library in fact is often translated into a wide range of device driver calls. For example, in most operating systems we have system libraries used for creating graphical user interfaces. The library might contain a function that can be used for creating a button of a specific size, colour and placement on the screen. From the programmer’s point of view, he tells the computer to create a button of this or that size, using this or that colour, at this or that place. This is a typical high-level task, since actually drawing the button requires a quite complex sequence of libraries and a device driver. Full example:
Programmer tells the computer, using a system library, to draw a button of a certain size, color and position. The system library draws the button onto an invisible canvas, e.g. coloring pixels according to the programmer’s instructions onto a fictitious canvas in the computers memory. The canvas is most often a window, and before drawing the button on the actual monitor screen, the OS must ask the window manager (another system library) if the particular window right now is shown or not (it could be fully or partially covered by another window). The exact contents of the current visible screen are determined (checking all buttons and widgets in all visible parts of windows). The result is a grid of coloured pixels that are to be shown on the monitor using the device driver for the video card.
Who creates Libraries? Anyone can create their own libraries. For instance, if I need some strange mathematical calculations, I could create a generic package for this that I can reuse in all my applications. Almost all applications developed tend to have their own system libraries.
On the fly loading of libraries Most operating systems are able to load system libraries when up and running. In Windows these libraries are called DLL (Dynamic Linked Library) and one equivalent in UNIX are the ".so" (Shared Object) files. The libraries resides on the hard drive as files until requested, and then loaded up into the memory and used by the applications. In UNIX implementations this tends to be handled quite elegantly. The OS knows what program that uses which "so" file and when no application uses them anymore, it can remove the library from the memory. In Windows, especially 9x variants (NT seems a bit better), this seems to be more troublesome though. When all applications are terminated, it is still possible to find DLL files not currently in use in the memory. In fact Microsoft also chooses to load some DLL into memory upon OS startup in order to enable "quick launches" of their own applications.
Why do I have to restart? A part to the answer of why you have to restart Windows is because of this problem with DLL in memory. If you are to update a DLL, you overwrite the file on the hard drive. This does not ensure you that there isn’t one in use in the memory. This could result in crashes, and the easiest way to solve it is of course wiping all the memory contents by rebooting.
Device Drivers The device drivers are the interpreters between the system libraries and the actual hardware. Most often all communication with the device drivers are done through the system libraries. One example is the use of the mouse. All programs that require mouse input, would ask a system library for that input rather than go directly to the device driver. The reason is that the program itself is not responsible for determining whether the program’s window is activated, visible etc. The OS decides which window (application) will have the input. Though in most operating systems, it is possible to obtain direct access to the device drivers. Using the devices directly gives the possibility for faster, more direct response, which could be useful in time critical applications. In a game for instance, a direct communication could be necessary for doing fast operations. Not too long ago, when the 3D games where the latest thing and the hardware was quite slow, the game had to have direct communication with the graphics card in order to do the screen updates fast enough. And many of us remembers that when 3D accelerators where all new, the game itself had to know how to use the accelerating features (using the device directly). The games were marked "3dfx" or "Voodoo" enabled. In Windows this is now solved using the system library Direct X, which among other things gives the programmer a standardized way of using the acceleration features of the hardware.
Who creates device drivers? So who creates device drivers? Most often the manufacturers of the hardware also programs the device drivers. Not always though, an example is the VGA driver for the screen. Almost all 2D graphic cards can show VGA graphics using a driver not developed by the hardware vendor. But to obtain optimal performance, the "real" graphics driver is needed. Most often the manufacturer does not support all OS either. In Linux for example, there is a very long list of device drivers developed by others than the hardware vendor.
On the fly loading of device drivers Is very possible. In Linux for instance, it is possible to compile most device drivers as "modules" that can loaded and removed when the OS is up and running.
Next time Next time I will try to explain the kernel, memory protection and multitasking and so on
Top Home |
|
 |
|
|