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)
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.
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. WinMain() is windows
equivalent of main()
from DOS or UNIX. It is entry point of windows based application. This is
where program starts execution. 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. HINSTANCE hPrevInstance: Handle to
the previous instance of the application. Always NULL
for Win32 programs, so we ignore this parameter. 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.int nCmdShow: An integer value
which may be passed to ShowWindow().
It specifies how the window is to be displayed.- 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.