1   Introduction to Windows Concepts

1.1 The Windows Operating System

-          Microsoft Windows is an operating system with the graphical user interface

-          Windows version before 3.1 ran on Intel 8088 and at least of 640KB of conventional memory and as little as 2MB of total memory

-          Windows 3.1 requires at least 80286 processor and 4MB of total memory

-          Windows 95 requires at least an 80386 processor with at least of 4MB memory

-          Windows 3.x and earlier versions run on DOS 3.1 or later

-          Windows 95 contains its own underlying support and will not run on any other version of DOS

-          Windows NT is a complete operating system without any underlying DOS (but it emulates DOS although it is not present in it)

-          Windows 95 and  Windows NT represent a new and significant improvement over the older versions of the Windows and support programs that use native 32 bit instructions set of the processor

-          Windows supports multitasking in graphical environment

-          Window is a rectangular area where the outputs are displayed

-          For users it provides multitasking in graphical environment

-          For Programmers it provides a rich programming environment that supplies libraries of functions for User Interface such as menus, dialog boxes, list boxes etc

-          Because windows provides device independent graphics, programmers should be aware of the hardware connected in the computer


1.2 Win32 Facts

-          It is a family of Windows programming interfaces

-          It is common to Windows 95 & Windows NT

-          The Win32 Application Programmers Interface (API) is specified in terms of 32 bit values

-          In Win32 specification programmers work in 32 bit flat address space instead of 16 bit segmented address space

-          Win32 API has many new functions than Win16 API

-          Windows NT API supports all of the Windows 95 API as well as more powerful graphics capabilities

-          Win32 also supports OCX controls. OCX controls are implemented using OLE automation


1.3 History of User Interface

-          In previous days people had to input data to a computer using toggle switch

-          With the invention of punched card system the system became little easier

-          Still with the punched card system the use of computer was often difficult

-          The introduction of CRT(Cathode Ray Tube) enabled the user to directly interact with the computer

-          Initially display terminals were treated as nothing more than printing terminals at which we could see only last 24 lines (DOS uses display in this fashion)

-          The first IBM PC used 25 line by 80 columns display

-          With the effort to make better user interface there should be a provision for randomly displaying in the display rather than displaying sequentially in the line by line fashion

-          Since Windows uses graphical environment the line by line text display is use less

-          As a continuing effort in developing devices for graphical support displays such as Color Graphics Adapter (CGA), Enhanced Graphics Adapter (EGA), Video Graphics Array (VGA) super VGA were developed, which can still be used for text display

-          The graphical display card of the past were not compatible with the programs

-          Microsoft Windows was announced in November 1983 as a solution to make device independent system

-          Windows 2.0 was released in November 1987, this version switched the windows application from the tiled concept to overlapped concept which was sill used in later versions of windows

-          The graphics interface Windows 2.0 was improved form of the previous windows version

-          Windows 3.0 was introduced in May 1990

ü  Improvement in desktop appearance

ü  Many Icons and buttons had a three dimensional look

ü  Not limited to 640 KB memory could use extended memory

ü  Multiple applications could run side by side

-          Windows 3.1 was introduced in April 1992

*  It was easy for user to install and configure

*  A tutorial was added

*  Common Dialog Control was added

*  There was a file manager to manage files in the disks

*  True type scalable fonts were added

-          Windows for workgroup version 3.1 was introduced in November 1992

*  It had the networking feature

*  It was revised as Windows for Workgroup 3.11 in December 1993

-          Windows NT 3.1 was introduced in 1993

*  It was a complete operating system written from the ground up

*  Supported preemptive multitasking

*  Other windows use cooperative multitasking

*  Application for Windows NT run in separate address area, so the illegal operation performed by one application doesn’t affect the performance of the windows

*  Powerful graphics capabilities were added

*  It can run on multiprocessor system

*  It was portable and written for MIPS, Alpha & PowerPC

-          Windows NT Advanced Server was released in July 1993

*  It was optimized to be a file server

*  Support SQL server to enable client/server database

-          Windows NT Server 3.5 was released in September 1994

-          Windows NT Workstation 3.5 was released in October 1994

-          Windows NT had a drawback, it was resource hungry, Windows NT 3.1 required 16MB of minimum memory and Windows NT 3.5 required 12MB of minimum memory, but the development environment running on it may require as much as 20MB minimum memory

-          Windows 95 was released in August 1995

*  Great improvement in graphical interface

*  File manager was removed

*  It was a hybrid of 32-bit environment running on a largely 16-bit substrate

*  It implements the subset of Win32 API

*  It was network aware

*  Windows 95 is not actually a subset of Win32 interface of Windows NT 3.x it is a subset of Level 4 Win32 Interface available in Windows NT 4.x

-          Windows NT is recommended to use where security is a major concern in networking environment

-          Windows NT Workstation 4.0 and Windows NT Server 4.0 were introduced in August 1996

*  It implemented the API level 4.x

*  Windows 95 API is the subset of Windows NT 4.0 API


1.4 Windows Compared with DOS/Unix

-          Resource Sharing

*  Windows applications are designed to share resource, like memory, the processor, the display, the keyboard, hard disks etc. So for this programmers should interact with the resources through the Application Programmers Interface (API)

*  Conventional DOS system allows all the resources of the system to the application and all the memory is allocated to the application without the concern of the other applications

*  Unix programmers will see nothing new, like Unix the Win32 environment provides private address for the applications

-          Graphical User Interface

*  Windows applications typically run with a graphical user interface (GUI)

*  Windows provides a rich set of input controls as part of GUI such as dialog boxes, combo boxes, button controls, menus, scrollbars etc.

*  GUI is not in DOS or Unix

*  However Unix has XWindows GUI environment

-          Input System

*  Windows applications takes input through the controls

*  Windows applications cannot take input on demand like DOS or Unix shell applications

*  Windows applications take input whenever it is produced

-          Notification event handling

*  Windows application respond to some event or action to take some action

*  DOS does not have this feature

*  Unix however have the signal trapping process

-          Memory Management

*  Unlike DOS windows application uses the required memory at a time and frees it as soon as it is not longer needed

-          Device Independent Graphics

*  To draw graphics in windows, programmer should not be aware with the hardware in it; this is because of the device independent graphics

*  The device independence is not only for the graphics system it is also applicable to other hardware of the system

*  This is not the case in DOS


1.5 Windows Programming Model

-          Difficult to learn because of rich set of programming component


1.5.1 The Conceptual model

-          Windows program requires conceptual model of the problem than is used by traditional DOS or Unix shell programs

-          Windows applications use the different windows components such as button controls, edit controls, menus, dialog boxes etc. and they react to different user actions

-          Windows uses objects like Pens, Brushes, Menus and dialog boxes 

-          The main Object is the main Window and controls (also called child windows) in it


1.5.2 Windows and Their Associated Window Functions

-          All windows have an associated function, called the window function, that determines how the window reacts to the notification of the event

-          The notification is called a message

-          Controls contained within a window are also windows and they to have an associated window function that controls how the control react; eg a scroll bar window reacts to a mouse click by visually changing the appearance of the window and sending a message to its parent window of the request to scroll

-          Messages originates from different sources and the window function handles them

-          Some messages originates from the hardware and some originate from the windows operating system itself


1.5.3 Windows Queues and the Message Loop

-          Many messages in Windows originate from devices

-          Pressing and releasing a key on the keyboard generates interrupts that are handled by the keyboard device driver

-          Similarly moving the mouse and clicking the mouse buttons generate interrupts that are handled by the mouse device driver

-          The device drivers call Windows to translate the hardware events into messages

-          The resulting message is then placed into the Windows system queue

-          There are two types of queues in Windows

*  System queue

*  Thread queue

-          There is only one system queue in Windows

-          Hardware events are converted into messages and placed into the system queue

-          Messages stay in the system queue for very small time

-          Each running Windows application has its own unique message queue called thread queue however in Win32 there can be multiple threads

-          Windows transfers the message in the system queue to the appropriate thread queue

-          Windows implements the sharing of the resources by the system queue

-          When event occurs a message is placed in the system queue and window decides which thread should receive the message

-          Keyboard messages are moved from the system queue into the tread queue for the thread with a window that has the input focus, so there will not be the possibility of using the same resource by two programs at the same time

-          Mouse messages are sent to the window that is under the mouse pointer but if there are overlapped windows the window at the top will receive the message

-          A program calls the windows GetMessage function to retrieve a message from its thread queue

-          To send the message to the appropriate window it is done by calling the windows DispatchMessage function


1.6 Windows Operating Modes

-          Windows 95 and Windows NT run on 80386 and newer processors

-          The 80386 and above processors can run in protected mode which is required by Windows 95 and Windows NT to use all the features of the processor

-          However Windows NT also runs on a variety of non-Intel platforms

-          Win32 environment uses a uniform 32-bit flat memory addressing


1.7 __cdecl and __stdcall Calling Sequence

-          When calling C functions the parameters are passed through the stack normally right to left and expects the caller to remove the parameters from the stack

-          The no of parameters for the C function is not fixed e.g., printf function have variable no of arguments

-          A called C function cannot clean up the parameters passed to it on the stack because the no of parameters might vary and is unknown until runtime

-          This type of calling with variable no of arguments is __cdecl calling sequence

-          There is another calling sequence __stdcall calling sequence where the no of calling parameters is fixed, so the compiler can then generate the code to remove the parameters from the stack at the end of the called function rather than after every call to the function

-          By default, the Microsoft C compiler generates call to functions using the __cdecl calling sequence

-          However Windows functions take a fixed number of parameters, so this functions use the __stdcall calling sequence to gain the additional efficiency


1.8 Static and Dynamic Linking

-          The linking processes links one or more object module together to form an executable program and the linker matches calls within the object modules to functions within either the sae or another object module

-          After this process the linker if the unresolved call remains the linker searches the library files for the missing functions, fi the linker find the function, its object code is copied from the library and inserted into the executable file

-          This process of linking is called static linking where the object code of the function is actually copied to the executable file

-          The dynamic linking is the process of linking during the runtime

-          In dynamic linking the linker defers full resolution of a function call until the program is executed. At the link time, the linker inserts additional information into the executable program, informing Windows of the unresolved functions

-          When the program is loaded, the deferred calls are dynamically resolved to the proper function within Windows

-          Because of dynamic linking the same copy of Windows functions can be shared among concurrently running programs

-          In Windows the dynamic libraries are distributed in the form of the dynamic link libraries (DLLs)


Dynamic Link Libraries

-          There are several import libraries used for linking Windows programs

-          The most important are

*  user32.dll: It manages the Windows environment in addition to managing all the application’s windows, menus, built-in controls, and the like are managed here

*  kernel32.dll: It provides the system services of the Windows. The services include multitasking, multithreading memory management and resource management. It also provides the console subsystem for the character-based applications

*  gdi32.dll: It provides the Graphic Device Interface for drawing lines, texts etc

-          The linker can produce either program module or dynamic link libraries (DLLs)

-          The dynamic libraries are also executables but they should be called by some other programs, so they are the program extensions

-          Programs run as task under Windows and they receive messages independently

-          A task is an independent executing entity

-          We can run two copies of the notepad program concurrently. Windows creates two tasks one running each copy of the notepad program, but there is only one copy of the notepad program in the memory but each task has its own private data

-          DLLs are simply collections of routines that can be used by programs or by other DLLs.

-          A DLL never runs as a task under Windows, it must be called directly or indirectly from a running program that is a task under Windows


1.9 Windows Memory Management

-          Windows programs can consist of one or more code segments and one or more data segments

-          DLLs may have one or more code segments and one or more data segments

-          In Windows environment multiple windows programs can be running concurrently and multiple instances of the same program also may run concurrently

-          In Win32, some number of these data segments can be shared with all programs that are using the DLL

-          In Win16 the segmented memory model (memory with segment address and offset address) is used but in windows the flat memory model is used with memory address of 32 bits.


1.10 The windows.h Header File

-          A significant percentage of the Windows API is defined by the windows.h file

-          In windows header file there are a lot of API definitions, symbolic constants associated with those calls and the structures and typedefs

-          The windows header file is becoming larger and larger with the subsequent releases of Windows

-          Again there can be a problem that the new symbols can conflict with the existing symbols

-          The file size become a significant factor in compilation time because if its large size, the usable lines in the header files can be only a dozen for a typical program

-          To eliminate this problem Microsoft started the concept of precompiled headers

-          Precompiled header files are saved in a semidigested form and only those pieces required are read in binary form by the compiler

-          The problem of potential symbol incompatibility were addressed by adopting more complex naming convention and by putting new features in new header files

-          Features such as shell extensions, tool extensions, 3-D controls and OLE were added as separate header files and we have to explicitly included

-          Conditional compilation is another features which can be used to exclude some portion of the windows.h header file, e.g. by using #define NOCOMM before including windows.h header file to exclude communication component


Symbols used to exclude portion of windows.h


What it Excludes


Atom function prototypes


Clipboard function prototypes and related


Communication function prototypes and related


Dialog and control functions and related


Color constants and function prototypes


Defer window functions prototypes and related


Desktop symbols and methods


DrawText and constants


Extended API functions unique to Win32


Font signature structure


GDI function prototypes and symbol definitions


Symbols related to capabilities


Help function prototypes


Standard Icon definitions


Input method manager symbols


Input method manager-IMM symbols


Kanji support


WinMain: All kernel defines and function prototypes


Key state mask for mouse messages symbols


Language support


MessageBox, MessageBeep and constants


Modern interface structures and calls


Memory manager constants and function prototypes


Menu structures, constants and function prototypes


Constants, structures and function prototypes for metafile


Macros min and max


Message handling function prototypes and constants


Nonclient message constants


National language support defines and routines


OpenFile structures, constants and temp file function prototypes


Profiler function prototypes


Raster operation codes


Resource constants


Scroll bar function prototypes and constants


All security options


All servide controller routines, and constants


ShowWindow parameters and constants


Sound functions prototypes and symbols


System commands constants


GetSystemMetrics and symbols


System parameter information


Text matrix functions prototypes and define symbols


All user defines and function prototypes


Virtual Key code symbols


The hook function prototypes and symbols


Window station support


Window messages symbols


Window and class extra area access function prototypes and constants


Window styles constants


-          The windows.h header file is split-up into following header files

Components of windows.h header file

File Name



Structured exception handler API


ANSI variable-argument list




Base API: file, security, exception symbols, COM port symbols, most other constants


GDI symbols: ROP codes, metafile codes, printer escapes, GDI API


USER symbols: resource symbols and macros, wsprintf, control symbols, virtual key codes, hook symbols, keyboard layout, desktop, message API


National Language Support constants and API


CONSOLE interface




Registry interface API


Network API, WNet API calls, and symbols.

The following will be excluded if the symbol WIN32_LEAN_AND_MEAN                  


Common dialog error codes


DDE interface, WM_DDE messages


DDEML interface


Symbols for controls in common dialogs


Data compression DLL API


Multimedia system


Portable NetBIOS 3.0 interface


Remote Procedure Call interface. Includes rpcdce.h, rpcnsi.h, rpcnterr.h


Shell API: drag-and-drop, ShellExecute, ExtractIcon, etc


Performance monitor API including registry interface


Network sockets API

The following will be excluded if NOGDI is defined


Common dialog API


Printer API

The following will be included if symbol inc_ole1 is defined


Object linking and embedding

The following will be included if symbol inc_ole2 is defined


Object linking and embedding 2.x (OLE) API; includes oleidl.h

The following will be excluded if the symbol NOSERVICE is defined


Service control manager (SCM) API

The following will be excluded if the symbol NOMCX is defined               


MCX (Modem Control Extension) API

The following will be excluded if the symbol NOIME is defined


IMM (Input Method Manager) API


-          Most #define statements in windows.h are used to provide symbolic names for numeric values. For example, a windows frequently receive a WM_COMMAND message, it is defined as

#define WM_COMMAND   0x0111

-          windows.h header file also contains #define statements for the non standard C keywords used for portable programming


Platform-independent keywords




#define FAR


Obsolete, empty

#define NEAR


Obsolete, empty

#define LONG



#define VOID



#define CDECL



#define PASCAL



#define WINAPI

_far __pascal



No keyword


#define WINAPIV

No keyword


#define CALLBACK

_far __pascal



-          These keywords is to be used if it is planned to port the 32-bit application to MIPS, Alpha, PowerPC, or future 32-bit Windows NT platforms


windows.h typedef Declarations

-          windows.h also uses many typedef declarations to permit a windows program to be more independent of the actual architecture of the computer on which it is running

-          It is best to use the typedefs declared by windows.h whenever possible


Basic data types defined by windows.h

Desired Data Type

Type to Use

Windows.h typedef

constant pointer to a Unicode string


const wchar_t *

pointer to a Unicode string


wchar_t *

constant pointer to an 8-bit string


const char *

pointer to an 8-bit string


char *

constant pointer to string



pointer to a string



pointer to a byte



pointer to an integer


int *

pointer to a 16-bit unsigned integer



pointer to a 32-bit signed integer


long *

pointer to a 32-bit unsigned integer



generic pointer


void *


-          The pointers are defined with LP prefix, it is because Win16 used LP for long pointer type, but Win32 do not have the long concept. To be consistent with the previous versions LP is used in definitions

-          Apart from LP as prefix there are also typedefs which uses P as the prefix in the definition as follows


PINT for int *


PLONG for long *


PVOID for void *


1.11 Getting Handle on Handles

-          One important data type defined by windows.h is a handle

-          A handle is like a pointer used to reference the datum

-          Unlike a pointer handle cannot be dereferenced

-          When CreateWindow function is called it returns a handle to a window and this handle can be used to ask Windows to perform some action on behalf of that window

-          Handles provide a way to reference items that are managed by the operating system

-          Most Windows objects are identified by a handle such as handle to windows; handle to resources such as strings, icons, menus and cursors; handle to instances of a program; handle to graphical objects such as pens, fonts, brushes and bitmaps; handle to device contexts; handle to regions; handle to color palettes; handle to dynamically allocated memory


Types of handles defined by windows.h

windows.h typedef

Handle Type




Bitmap (GDI)


Brush (GDI)




Device context


Device driver


Deferred window position


Enhanced metafile


Font (GDI)


General GDI object


Global memory



windows.h typedef

Handle Type




Program Instance


Region key






Palette (GDI)


Pen (GDI)


Region (GDI)




String for OLE/DDE






1.12 Some more points on Windows programming

-          When both Windows header file and standard header files have to be included in the program the Windows header file is to be included first to be sure that certain symbols such as NULL are defined correctly

-          We can take advantage of stricter type checking by defining the symbol STRICT before including windows.h header file

#define STRICT

-          When the symbol STRICT is defined , the windows.h header file defined many data types in more precise way

-          Microsoft suggests us to write Windows applications with its suggested naming conventions

-          Using the naming condition make the program easy to debug and understand

-          According to the convention Windows function names are named according to a verb-noun model that identifies what the function does (verb) and what the function operates on (noun)

-          Function names begin with an uppercase letter, each word in a function name is individually capitalized and all words are concatenated (no spaces or underscores separate the words)




-          Variable names are given a lowercase prefix that indicates the general type of the variable followed by one or more words describing the variable’s contents

-          Multiple words in a variable name are individually capitalized and concatenated as in function names

-          When no lowercase prefix is used a variable normally is a short integer whose name is descriptive


Standard prefix for Windows variables


Data Type




8-bit unsigned integer



Character (an 8-bit signed value)



Double-precision floating-point



32-bit unsigned integer



Boolean , f stands for flag



Bit flags packed into a 16-bit integer



Handle to global storage from GlobalAlloc



32-bit unsigned integer handle to an object



Window handle



32-bit signed integer



32-bit far (long) pointer



16-bit signed integer (number)


* (pointer)

32-bit pointer (inconsistently used)



32-bit x and y coordinates packed in a struct



RGB color value packed in a DWORD


CHAR array

NULL-terminated character array (string)



16-bit unsigned integer (except WPARAM)



Function name



Signed integer data



Used with x or y coordinates



Used as x or y coordinate length, c stands for count


1.13 Language Options

-          Using C and the native APIs is not the only way to write programs for Windows 98

-          This approach offers you the best performance, the most power, and the greatest versatility in exploiting the features of Windows

-          Executables are relatively small and don't require external libraries to run (except for the Windows DLLs themselves, of course)

-          Becoming familiar with the API provides you with a deeper understanding of Windows internals, regardless of how you eventually write applications for Windows

-          Some recreational programmers or in-house corporate programmers prefer to use development environments such as Microsoft Visual Basic or Borland Delphi

-          These environments allow a programmer to focus on the user interface of an application and associate code with user interface objects

-          For professional programmers, who write commercial applications, Microsoft Visual C++ with the Microsoft Foundation Class Library (MFC) has been a popular alternative in recent years

-          Most recently, the popularity of the Internet and the World Wide Web has given a big boost to Sun Microsystems' Java

-          MFC is particularly problematic. While it simplifies some jobs immensely (such as OLE)

-          MFC has not been the Windows programming panacea that many hoped for, and few people would characterize it as a model of good object-oriented design

-         MFC programmers benefit greatly from understanding what's going on in class definitions they use, and find themselves frequently consulting MFC source code and understanding the source code is the benefit of Windows API


1.14 First Windows Program

Consider a short character-mode program

#include <stdio.h>

int main ()

        printf ("hello world") ;
        return 0 ;

1.14.1 The Windows Equivalent

The Windows equivalent to the "hello, world" program has exactly the same components as the character-mode version. It has an include statement, a program entry point, a function call, and a return statement.

/*first windows program*/
#include <windows.h>
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
                    LPSTR lpszCmdLine, int nCmdShow)
     MessageBox (NULL, TEXT ("Hello world"), TEXT ("HelloMsg"), MB_OK);
     return 0 ;


Let’s see the structure of the WinMain function

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
                    LPSTR lpszCmdLine, int nCmdShow)
  1. Every windows program written in C begins with   #include <windows.h>. It is master include file that includes other Windows header files such as

·         WINDEF.H   Basic type definitions.

·         WINNT.H   Type definitions for Unicode support.

·         WINBASE.H   Kernel functions.

·         WINUSER.H  User interface functions.

·         WINGDI.H  Graphics device interface functions.

  1. WINAPI specifies the calling convention. It indicates the order (left to right or right to left) in which the arguments are passed to a function when a function called is made. In __pascal calling convention the parameters used to get passed to a function from left to right. WINAPI is defined as __stdcall where values are passed from right to left.                                                                            
  2. WinMain() is windows equivalent of main() from DOS or UNIX. It is entry point of windows based application. This is where program starts execution.                                                 
  3. HINSTANCE hInstance : Handle to the current instance of the application. Handle is a number  that an application uses to identify something. The handle uniquely identifies the program. It is required as an argument to some other windows function calls.                                                                                      
  4. HINSTANCE hPrevInstance:  Handle to the previous instance of the application. Always NULL for Win32 programs, so we ignore this parameter.                                                                                  
  5. LPSTR szCmdLine:  Pointer to character strings is a data type. We can also use PSTR, LP stands for Long Pointer. Pointer to a null-terminated string specifying the command line for the application, excluding the program name.
  6. int nCmdShow: An integer value which may be passed to ShowWindow(). It specifies how the window is to be displayed.
  7. MessageBox function is designed to display short messages. It is also called as dialog box. The first argument to MessageBox is normally a window handle. The second argument is the text string that appears in the body of the message box, the third argument is the text string that appears in the caption bar of the message box. These text strings is enclosed in a TEXT macro, it ensures text to be in Unicode format if defined. The fourth argument to MessageBox can be a combination of constants beginning with the prefix MB_ that are defined in WINUSER.H.  MB_OK will display a single OK button.