Windows Programming/Windows System Architecture
From Wikibooks, the open-content textbooks collection
Contents |
[edit] History
Windows was originally a 16-bit graphical layer for MS-DOS that was written by Microsoft. As it grew, it gained the ability to handle 32-bit programs and eventually became totally 32-bit when Windows NT and 2000 came out. After Windows 95, Microsoft began to remove dependencies on DOS and finally fully implemented the separation in Windows 2000. Windows has many advanced features as well as many platform specific problems. It possesses an Application Programming Interface that consists of thousands of mostly undocumented GUI functions as well as having varying degrees of MS-DOS compatibility. Additionally, with the advent of NT (New Technology), Windows relies completely on the NT kernel instead of its MS-DOS subsystem, the NT kernel is capable of emulating the necessary DOS functionality. In addition to the NT kernel, Microsoft has also introduced many API wrappers, such as the MFCs (Microsoft Foundation Classes), COM (Component Object Model), and .NET technologies.
The most popular languages for use on Windows include Visual Basic/VB6 and C/C++, although C++ is quickly being replaced by the .NET platform, specifically C# (C Sharp).
[edit] Windows Kernels
Windows 1.0, 2.0, and 3.11 are considered to be an older generation of Windows systems that were built as simply a graphical layer over the MS-DOS operating system. Windows 95, Windows 98, and Windows ME were designed to bypass MS-DOS (although DOS was still present), and were all based off the same code structure known as the "9x Kernel". Windows NT 4.0, Windows 2000, Windows XP, and Windows Server are all based off a bunch of code known as the "NT Kernel".
[edit] System Architecture
The Windows NT Kernel is divided up into several sections, here we will briefly discuss how the Windows operating system is put together. At the most basic level is the file NTOSKRNL.EXE, the kernel of the Windows operating system, and the most important file on your computer. If you are interested in seeing this for yourself, you can find it in the C:\Windows\System32 folder (this can also be found using the following path %systemroot%\system32 ) on your own Windows NT machines.
NTOSKRNL.EXE provides some of the basic functionality of Windows, but one file alone cannot make the whole system work. NTOSKRNL relies heavily on a Dynamic Link Library (DLL) known as HAL.DLL. HAL stands for "Hardware Abstraction Layer", and is the portion of code that allows the Kernel (NTOSKRNL.EXE) to communicate with the computer hardware (ports, monitors, keyboards, etc.).
If we consider that Windows architecture is a layered architecture, with NTOSKRNL.EXE and HAL.DLL on the bottom layer, the next layer up contains 2 important files, NTDLL.DLL, and WIN32K.SYS. NTDLL contains a number of kernel-mode functions that implement much of the functionality of the Windows API, but NTDLL does not handle any of the graphical components. NTDLL is instead responsible for things like File I/O functions, threading and synchronization, timing, messages, etc... WIN32K.SYS is similar to NTDLL.DLL, in that it contains a lot of primitive kernel-mode code that performs most of the low-level tasks in Windows. However, WIN32K.SYS is primarily concerned with graphics and user interface tasks, while NTDLL.DLL is mostly concerned with system tasks. The Functions in NTDLL.DLL are undocumented by Microsoft, and are known popularly as the "Native Windows API".
The next layer up from our kernel-mode functions contains a number of libraries that will be of primary interest to us. This layer comprises what is called the Win32 API, and contains (almost) all the functions that a user will need to program in Windows. The Win32 API is divided into 3 component parts, each one a .DLL:
- kernel32.DLL
- This is the user-mode equivalent of the NTDLL.DLL code we discussed already. Kernel32 contains a number of high-level functions for performing a variety of system tasks. Most of the Kernel32 functions simply call into NTDLL.DLL, which has caused many people to believe that programs could be made faster by using the NTDLL.DLL functions directly, and not going through Kernel32.DLL at all. However, NTDLL functions are very complex, undocumented, and Microsoft may change them in future versions.
- gdi32.DLL
- This contains a number of basic functions for drawing. These functions are all relatively simple, and allow the user to draw shapes (circles, rectangles, etc.) on the screen, to display and manipulate bitmaps, etc.
- user32.DLL
- This contains a number of functions that implement the familiar user-interface of Windows. Programs, message boxes, prompts, etc are all implemented using the User32 functions. User32 performs its tasks by calling on gdi32.DLL and WIN32K.SYS functions to do the "dirty work".
In addition to the 3 primary libraries in the Win32 API, there are a number of other important libraries that a Windows programmer should become familiar with:
- MSVCRT.DLL
- MSVCRT.DLL is the dynamic link library that contains the implementations of the C standard library (stdlib) functions that C programmers should be familiar with. These are the functions defined in the common header files stdio.h, string.h, stdlib.h, etc.
- WS2_32.DLL
- This is the Winsock2 library, that contains the standard Berkeley socket API for communicating on the internet. We will talk about winsock programming later in this book.
[edit] Windows Does It
The Windows system, it might be surprising for some people to learn, is a very hands-on system. This is not a familiar concept for people who are just beginning C programming using the standard library. In a normal software project, there is typically a main function, and the main function in turn calls other functions that are defined in your project. In a Windows function, typically the programmer provides function pointers to the system, and Windows will make calls into your program. Also, in a Windows program, your code will sit idle when there is nothing to be done. Using the message loop architecture, Windows will send messages to your program when an event needs to be handled, and the program responds to the messages. If the program doesn't respond, the message is ignored.
For each program, Windows sets up a message queue structure to handle the message transmission process. Windows will maintain a listing of all the objects and system resources in use by a program, and will assign each one a handle. These handles are useless by themselves, but they can be passed to the system to reference particular objects and resources.
