We help IT Professionals succeed at work.

Windows OS structure

Koepsell asked
Medium Priority
Last Modified: 2013-12-04
I'm trying to gather information on the Windows operating system structure.  What I need is a dataflow diagram and names of some of the more important functions and ques that the OS uses to communicate between DOS and programs.  I need a good grasp of how the Windows Operating System works.
Watch Question


Edited text of question
Please clarify what Windows are you interesting in: 3.1, 95 or NT?
You seem to be asking several different things here.Do you want to know how the entire Windows OS works? It is a huge and complex beast with hundreds of API's and thousands of structures (eg file system, multi-media, graphics, messaging, networking, mail etc etc) - there is no way all that can be covered in a posting here.I guess the main functions and queues you may be interseted in are the MSG structure (for message/events) and the functions used to send/post and receive messages.Here are the details:MSG structure============= 
typedef struct tagMSG {     // msg  
    HWND   hwnd;// the window to receive the message    UINT   message;// the message number.
    WPARAM wParam;// additional info for the message
    LPARAM lParam;// additional info for the message
    DWORD  time;// the time the message was posted
    POINT  pt;// cursor pos on screen when posted
} MSG;
The functions to post/send messages are:The SendMessage function sends the specified message to a window or windows. The function calls the window procedure for the specified window and does not return until the window procedure has processed the message.
LRESULT SendMessage(
    HWND hWnd,      // handle of destination window
    UINT Msg,      // message to send
    WPARAM wParam,      // first message parameter
    LPARAM lParam       // second message parameter
The PostMessage function places (posts) a message in the message queue associated with the thread that created the specified window and then returns without waiting for the thread to process the message. Messages in a message queue are retrieved by calls to the GetMessage or PeekMessage function.
BOOL PostMessage(
    HWND hWnd,      // handle of destination window
    UINT Msg,      // message to post
    WPARAM wParam,      // first message parameter
    LPARAM lParam       // second message parameter
   );The API functions to process messages are:The GetMessage function retrieves a message from the calling thread's message queue and places it in the specified structure. This function can retrieve both messages associated with a specified window and thread messages posted via the PostThreadMessage function. The function retrieves messages that lie within a specified range of message values. GetMessage does not retrieve messages for windows that belong to other threads or applications.
BOOL GetMessage(
    LPMSG lpMsg,      // address of structure with message
    HWND hWnd,      // handle of window
    UINT wMsgFilterMin,      // first message
    UINT wMsgFilterMax       // last message
   );The TranslateMessage function translates virtual-key messages into character messages. The character messages are posted to the calling thread's message queue, to be read the next time the thread calls the GetMessage or PeekMessage function.
BOOL TranslateMessage(
    CONST MSG *lpMsg       // address of structure with message
The DispatchMessage function dispatches a message to a window procedure. It is typically used to dispatch a message retrieved by the GetMessage function.
LONG DispatchMessage(
    CONST MSG *lpmsg       // pointer to structure with message
A loop calling GetMessage,TranslateMessage,DispatchMessage is usually called a message pump.Every window can have a windows procedure (winproc) that includes a message pump.When a message is posted, it is placed in an internal queue (usually one per application or thread) and are made available to the destination windows message pump.That is basically how windows application communicate.However, you now ask about communicating between DOS and programs - I don't undertand what it is you really want to know.  Under Win95/WinNT there is no DOS (well, that's not QUITE true) - just the Windows OS, so the question doesn't make sense.  In Win3.1 both Windows and the program communicate with DOS just as they do in DOS itself - through DOS api calls and interrupts.If you want a more general overview of the major components that make up Windows95, here is an extract from MSDN...Windows 95 Architecture=======================The operating environment for Windows 95 consists of a computer's hardware devices and the following software components:
7      Virtual machine manager (VMM).
7      Virtual devices (VxDs).
7      Device drivers.
7      16- and 32-bit Windows dynamic-link libraries (DLLs).
7      MS-DOS - based applications.
7      16- and 32-bit Windows-based applications.
The Virtual Machine===================The virtual machine manager (VMM) is the 32-bit protected-mode operating system at the core of Windows 95. Its primary responsibility is to create, run, monitor, and terminate virtual machines. The VMM provides services that manage memory, processes, interrupts, and exceptions such as general protection faults. The VMM works with virtual devices, 32-bit protected-mode modules, to allow the virtual devices to intercept interrupts and faults to control the access that an application has to hardware devices and installed software.
Both the VMM and virtual devices run in a single, 32-bit, flat model address space at privilege level 0 (also called ring 0). The system creates two global descriptor table (GDT) selectors, one for code and the other for data, and uses the selectors in the CS, DS, SS, and ES segment registers. Both selectors have a base address of zero and a limit of 4 gigabytes (GBs), so all the segment registers point to the same range of addresses. The VMM and virtual devices never change these registers.
The VMM provides multiple-threaded, preemptive multitasking. It runs multiple applications simultaneously by sharing CPU (central processing unit) time between the virtual machines in which the applications run. The VMM is also nonreentrant. This means that virtual devices must synchronize access to the VMM services. The VMM provides services, such as semaphores and events, to help virtual devices prevent reentering the VMM.
For more information about the VMM, including descriptions of the services that it provides to virtual devices, see the documentation included in the Microsoft Windows 95 Device Driver Kit (DDK).
Virtual Devices===============Virtual devices (VxDs) are 32-bit programs that support the device-independent VMM by managing the computer's hardware devices and supporting software. VxDs support all hardware devices for a typical computer, including the programmable interrupt controller (PIC), timer, direct memory access (DMA) device, disk controller, serial ports, parallel ports, keyboard, and display adapter. A VxD is required for any hardware device that has settable operating modes or retains data over any period of time. In other words, if the state of the hardware device can be disrupted by switching between multiple virtual machines or applications, the device must have a corresponding VxD.
Some VxDs support software, but no corresponding hardware device. In general, a VxD can provide any kind of services for the VMM and other virtual devices. Windows 95 allows the user to install new virtual device drivers to support an add-on hardware device or provide some system-wide software service.
A VxD can also provide application programming interface (API) functions for applications running in virtual 8086 mode or protected mode. These functions can give applications direct access to the features of the VxD.
Windows 95 includes a device input and output control (IOCTL) interface that allows Microsoft. Win32. - based applications to communicate directly with VxDs. Applications typically use this interface to carry out selected MS-DOS system functions, to obtain information about a device, or to carry out input and output (I/O) operations that are not available through standard Win32 functions. For more information about the device IOCTL interface, see Device I/O Control.
For more information about virtual devices, see the documentation included in the Windows 95 DDK.
Device Drivers==============A Windows device driver is a DLL that Windows uses to interact with a hardware device, such as a display or keyboard. Rather than access devices directly, Windows loads device drivers and calls functions in the drivers to carry out actions on the device. Each device driver exports a set of functions; Windows calls these functions to complete an action, such as drawing a circle or translating a keyboard scan code. The driver functions also contain the device-specific code needed to carry out actions on the device.
Windows requires device drivers for the display, keyboard, and communication ports. Other drivers may also be required if the user adds optional devices to the system.
The Windows 95 DDK provides independent hardware and software vendors (IHVs and ISVs) with the resources to build device drivers and VxDs that are compatible with the Windows 95 operating system. The resources include a configurable development environment, documentation, tools, and header files and libraries for several device types. The Windows 95 DDK contains the following components:
7      Header files and libraries for building device drivers and VxDs.
7      Sample source code for device drivers and VxDs.
7      16- and 32-bit versions of the driver development tools.
Dynamic Link Libraries======================Dynamic linking provides a mechanism for linking applications to libraries of functions at run time. The libraries reside in their own executable files and are not copied into an application's executable file as with static linking. These libraries are "dynamically linked" because they are linked to an application when it is loaded and executed rather than when it is linked. When an application uses a DLL, the operating system loads the DLL into memory, resolves references to functions in the DLL so that they can be called by the application, and unloads the DLL when it is no longer needed. Dynamic linking can be performed explicitly by applications or implicitly by the operating system.
DLLs are designed to provide resources to applications. Many applications can use the code in a DLL, meaning that only one copy of the code is resident in the system. Also, it is possible to update a DLL without changing applications that use the DLL, as long as the interface to the functions in the DLL does not change.
Software developers can extend the Windows environment by creating a DLL that contains routines for performing operations and then making the DLL available to other Windows-based applications (in addition to internal Windows routines). DLLs most often appear as files with a .DLL filename extension; however, they may also have an .EXE or other filename extension.
For more information about dynamic-link libraries, see Dynamic-Link Libraries.
Windows 95 supports 32-bit DLLs as well as 16-bit DLLs that were written for Windows version 3.x. For a discussion of the issues involved in mixing 16- and 32-bit components in the Windows 95 environment, see Thunk Compiler.
MS-DOS - Based Applications
===========================Windows 95 supports applications written for MS-DOS. Each MS-DOS - based application can run as a full-screen application, or it can run in a window on the Windows 95 desktop.
The system can run multiple MS-DOS - based applications at the same time. To do so, it creates a separate virtual machine (VM) for each MS-DOS - based application and shares the microprocessor among the MS-DOS VMs and the system VM (which contains all Windows-based applications). A VM can run an MS-DOS - based application in either the virtual 8086 mode or protected mode of the microprocessor.
Although most MS-DOS - based applications run fine in a window or as a full-screen application, some may not. To ensure absolute backward compatibility for all MS-DOS - based applications, Windows 95 provides a separate operating mode called "single MS-DOS application mode." When in this mode, Windows 95 runs only one MS-DOS - based application at a time. No Windows-based applications run in that mode; in fact, none of the graphical user interface (GUI) components of the system are even loaded.
Windows 95 supports the complete set of MS-DOS system functions and interrupts and provides extensions that permit MS-DOS - based applications to take advantage of features such as long filenames, and exclusive volume locking. For more information, see MS-DOS Extensions, Long Filenames, and Exclusive Volume Locking.
Disk utilities and other applications that directly modify file system structures, such as directory entries, must request exclusive use of the volume before making modifications to the structures. Windows 95 provides a set of input and output control (IOCTL) functions to manage exclusive volume use. Exclusive use prevents applications from inadvertently changing the file system while a disk utility is trying modify it.
Virtual machine services let Microsoft MS-DOS - based applications take advantage of features provided by Windows 95 when the applications run in a window. MS-DOS - based applications can retrieve and, optionally, set the title of the window in which they run. Virtual machine services also allow MS-DOS - based applications to periodically check the state of an internal close flag and terminate if the flag is set. Windows 95 sets this flag when the user chooses the Close command from the system menu of the window in which the MS-DOS - based application runs. Close-aware applications enable the Close command, which gives the user an alternate way to exit the application and close the window. For more information, see Virtual Machine Services.
Windows-Based Applications
==========================Windows 95 supports 16-bit applications written for Windows version 3.x as well as 32-bit applications that use the Win32 or Microsoft. Win32s. API. For 16-bit applications, Windows 95 preserves the cooperative multitasking model used in Windows version 3.x; that is, all 16-bit applications share the same virtual address space, the same message queue, and the same thread of execution. By contrast, each 32-bit Windows-based application has its own address space, a private message queue, and one or more threads of execution. In addition, each 32-bit thread is preemptively multitasked.
All new applications should be 32-bit applications developed using the Win32 API. For information about porting a 16-bit application to Win32, see Version Differences.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.