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

Symbol

What it Excludes

NOATOM

Atom function prototypes

NOCLIPBOARD

Clipboard function prototypes and related

NOCOMM

Communication function prototypes and related

NOCTLMGR

Dialog and control functions and related

NOCOLOR

Color constants and function prototypes

NODEFERWINDOWPOS

Defer window functions prototypes and related

NODESKTOP

Desktop symbols and methods

NODRAWTEXT

DrawText and constants

NOEXTAPI

Extended API functions unique to Win32

NOFONTSIG

Font signature structure

NOGDI

GDI function prototypes and symbol definitions

NOGDICAPMASKS

Symbols related to capabilities

NOHELP

Help function prototypes

NOICONS

Standard Icon definitions

NOIME

Input method manager symbols

NOIMM

Input method manager-IMM symbols

NOKANJI

Kanji support

NOKERNEL

WinMain: All kernel defines and function prototypes

NOKEYSTATES

Key state mask for mouse messages symbols

NOLANGUAGE

Language support

NOMB

MessageBox, MessageBeep and constants

NOMCX

Modern interface structures and calls

NOMEMMGR

Memory manager constants and function prototypes

NOMENUS

Menu structures, constants and function prototypes

NOMETAFILE

Constants, structures and function prototypes for metafile

NOMINMAX

Macros min and max

NOMSG

Message handling function prototypes and constants

NONCMESSAGES

Nonclient message constants

NONLS

National language support defines and routines

NOPENFILE

OpenFile structures, constants and temp file function prototypes

NOPROFILER

Profiler function prototypes

NORASTEROPS

Raster operation codes

NORESOURCE

Resource constants

NOSCROLL

Scroll bar function prototypes and constants

NOSECURITY

All security options

NOSERVICE

All servide controller routines, and constants

NOSHOWWINDOW

ShowWindow parameters and constants

NOSOUND

Sound functions prototypes and symbols

NOSYSCOMMANDS

System commands constants

NOSYSMETRICS

GetSystemMetrics and symbols

NOSYSPARAMS

System parameter information

NOTEXTMETRIC

Text matrix functions prototypes and define symbols

NOUSER

All user defines and function prototypes

NOVIRTUALKEYCODES

Virtual Key code symbols

NOWH

The hook function prototypes and symbols

NOWINDOWSTATION

Window station support

NOWINMESSAGES

Window messages symbols

NOWINOFFSETS

Window and class extra area access function prototypes and constants

NOWINSTYLES

Window styles constants

 

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

Components of windows.h header file

File Name

Definition

excpt.h

Structured exception handler API

stdarg.h

ANSI variable-argument list

windef.h

Base types: ULONG, NULL, TRUE, FALSE, BOOL, DWORD, RECT, POINT, etc

winbase.h

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

wingdi.h

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

winuser.h

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

winnls.h

National Language Support constants and API

wincon.h

CONSOLE interface

winver.h

VERSIONINFO resource API

winreg.h

Registry interface API

winnetwk.h

Network API, WNet API calls, and symbols.

The following will be excluded if the symbol WIN32_LEAN_AND_MEAN                  

ecerr.h

Common dialog error codes

dde.h

DDE interface, WM_DDE messages

ddeml.h

DDEML interface

dlgs.h

Symbols for controls in common dialogs

lzexpand.h

Data compression DLL API

mmsystem.h

Multimedia system

nb30.h

Portable NetBIOS 3.0 interface

rpc.h

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

shellapi.h

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

winperf.h

Performance monitor API including registry interface

winsock.h

Network sockets API

The following will be excluded if NOGDI is defined

commdlg.h

Common dialog API

winspool.h

Printer API

The following will be included if symbol inc_ole1 is defined

ole.h

Object linking and embedding

The following will be included if symbol inc_ole2 is defined

ole2.h

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

The following will be excluded if the symbol NOSERVICE is defined

winsvc.h

Service control manager (SCM) API

The following will be excluded if the symbol NOMCX is defined               

mcx.h

MCX (Modem Control Extension) API

The following will be excluded if the symbol NOIME is defined

imm.h

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

Declaration

Win16

Win32

#define FAR

far

Obsolete, empty

#define NEAR

near

Obsolete, empty

#define LONG

long

long

#define VOID

void

void

#define CDECL

__cdecl

__cdecl

#define PASCAL

__pascal

__stdcall

#define WINAPI

_far __pascal

__stdcall

#define APIPRIVATE

No keyword

__stdcall

#define WINAPIV

No keyword

__cdecl

#define CALLBACK

_far __pascal

__stdcall

 

-          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

LPCWSTR

const wchar_t *

pointer to a Unicode string

LPWSTR

wchar_t *

constant pointer to an 8-bit string

LPCSTR

const char *

pointer to an 8-bit string

LPSTR

char *

constant pointer to string

LPCTSRT

LPCWSTR or LPCSTR

pointer to a string

LPTSTR

LPWSTR or LPSTR

pointer to a byte

LPBYTE

BYTE *

pointer to an integer

LPINT

int *

pointer to a 16-bit unsigned integer

LPWORD

WORD *

pointer to a 32-bit signed integer

LPLONG

long *

pointer to a 32-bit unsigned integer

LPDWORD

DWORD *

generic pointer

LPVOID

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

PBYTE for BYTE *

PINT for int *

PWORD for WORD *

PLONG for long *

PDWORD for DWORD

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

HACCEL

Accelerator

HBITMAP

Bitmap (GDI)

HBRUSH

Brush (GDI)

HCURSOR

Cursor

HDC

Device context

HDRVR

Device driver

HDWP

Deferred window position

HENHMETAFILE

Enhanced metafile

HFONT

Font (GDI)

HGDIOBJ

General GDI object

HGLOBAL

Global memory

HHOOK

Hook

windows.h typedef

Handle Type

HICON

Icon

HINSTANCE

Program Instance

HKEY

Region key

HMENU

Menu

HMODULE

Module

HPALETTE

Palette (GDI)

HPEN

Pen (GDI)

HRGN

Region (GDI)

HRSRC

Resource

HSTR

String for OLE/DDE

HTASK

Task

HWND

Window

 

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)

RegisterClass

CreateWindow

PostMessage

-          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

Prefix

Data Type

Meaning

b

BYTE

8-bit unsigned integer

ch

CHAR

Character (an 8-bit signed value)

d

double

Double-precision floating-point

dw

DWORD

32-bit unsigned integer

f

BOOL

Boolean , f stands for flag

f

WORD

Bit flags packed into a 16-bit integer

gh

GLOBALHANDLE

Handle to global storage from GlobalAlloc

h

HANDLE

32-bit unsigned integer handle to an object

hwnd

HWND

Window handle

l

LONG

32-bit signed integer

lp

FAR *

32-bit far (long) pointer

n

short

16-bit signed integer (number)

p

* (pointer)

32-bit pointer (inconsistently used)

pt

POINT

32-bit x and y coordinates packed in a struct

rgb

RGB

RGB color value packed in a DWORD

sz

CHAR array

NULL-terminated character array (string)

w

WORD

16-bit unsigned integer (except WPARAM)

fn

function

Function name

i,n

int

Signed integer data

x,y

int

Used with x or y coordinates

cx,cy

int

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.

 


Comments