Experiment No.

1
Aim: -Study Windows API and their relationship with MFC classes and how are they
useful in finding complexity of the windows programming.
Basic for Windows Programming: API is an acronym for Application Programming Interface. Its simply a set of functions
that are part of Windows OS. Programs can be created, by calling the functions present in
the API. Programmer doesnt have to bother about internal working of functions. By just
knowing the functions prototype and return value he can invoke the API function.
Its two varieties are:a) API for 16-bit Windows (Win 16 API)
b) API for 32-bit Windows (Win 32- API)
Their descriptions are:Win 16API
User.exe

Win 32 API
User32.exe

Gdi.exe

Gdi32.exe

Kernel386.exe

Kernel32.exe.dll

Description
User component is responsible for
window
management,
including
messages, cursor, timers, etc.
This is graphical device interface. It
takes care of user-interface and graphics
including windows bitmap, context and
fonts.
Kernel component handles the low level
functions of memory, task and resources
management that are heart of windows.

Win API was created for 16-bit processors (current generations) and it relies on 16-bit
values. Although, Win16 versions of these components cant run on their own. Win32 is
future.
Dynamic Link Library (DLL) is a binary file that provides a library of functions, objects
and resources. All API functions are contains in DLL. The functions present in DLL can
be linked during execution. These functions can also be shared between several
applications running in windows. Since linking is done dynamically, functions dont
become a part of executable file. As a result size of exe files dont go out of hand.
Advantages: Sharing common code between different executable file.
Breaking an application into component parts to provide a way to easily upgrade
application component.
Keeping resources data out of application executable but still readily accessible to
an application
Queued and NON-Queued messages: - In event driven programming model, Windows
sent numerous messages to the application. Some messages are sent to message Queue.

These are queued messages. These messages are got using Got Message () and dispatches
to Window procedure by calling Dispatch Message () function.
Some messages are sent to application straight way calling the window procedure
instead of following message loop routine. Those messages sent to application by
directly calling its windows procedures are called Non-Queued messages.
WinMain: The WinMain function is called by the system as the initial entry point for a Win-32
based application.
Int WINAPI WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdline,
Int nCmdShow
);

//handle to current instance instance

//handle to previous instance
//pointer to command line
//show state of window

Parameters: hInstance
Handle to the current instance of the application.
hPrevInstance
Handle whether another instance already exists, create a uniquely named mutex
using to the previous instance of the application. For a Win32 based app, this
parameter is always NULL. To detect the CreateMutex() function. This will
succeed even if the mutex already exists, but the GetLastError() function will
return ERROR_ALREDY_EXISTS. This indicates another instance of the
applicant exists, coz it created the mutex first.
lpCmdLine
Pointer to a null-terminated string specifying the command line for the app,
excluding the program name. To retrieve the entire command line, use the
GetCommandLine() function.
nCmdShow
Specifies how the window is to be shown. This parameter can be one of the
Following values:
Values
Meaning
SW_HIDE
Hides the window and activates another
window.
SW_MINIMIZE
Minimizes the specified window and
activates the top-level window in the
systems list.
SW_RESTORE
Activates and displays a window. If the
window is minimized or maximized, the
system restores it to its original size and

SW_SHOW
SW_SHOWMAXIMIZED
SW_SHOWMINIMIZED
SW_SHOWNNOACTIVE
SW_SHOWNA
SW_SHOWNOACTIVATE
SW_SHOWNORMAL

position(same as SW_SHOWNORMAL)
Activates a window and display it in its
current size and position.
Activates a window and displays it as a
maximized window
Activates a window and displays it as a
icon
Displays a window as a icon. The active
window remains active.
Displays a window in its current state. The
active window remains active.
Displays window in its most recent size &
position. The active window remains
active.
Activates & display a window. If the
window is minimized or maximized, the
system restores it to its original size &
position (same as SE-RESTORE)

Return Values: If the function succeeds, terminating when it receives a WM_QUIT message, it should
return the exit value contained in that message wParam parameter. If the function
terminates before entering the message loop, it should return zero.
Remarks: WinMain should initialize the app, displays its main window, and enter a msg retrieval
and dispatch loop that is the top level control structure for the remainder of the apps
execution. Terminate the msg loop when it receives the WM_QUIT msg. At the point
WinMain should exit the app, returning the value passed in the WM_QUIT msgs
wParam parameter. If WM_QUIT was received as a result of calling PostQuitMessage,
the value of wParam is the value of the PostQuitMessage functions nExitCode
parameter.
ANSI app can use the lpCmdLine parameter of the WinMain function to access the
command line string, excluding the program name. The reason that WinMain cannot
return Unicode string that lpCmdLine uses the LPSTR data type, not the LPSTR data
type. The GetCommandLine function can be used to access Unicode strings in the
command line, coz it uses the LPSTR data type.
ContainedWindow::WindowProc
Static LPESULT CALLBACKM WindowProc (HWND hWnd, UINT uMsg, WPARAM
wParam, LPARAM lParam);
Return Value

The result of the msg processing.

Parameters
hWnd
[in]The handle to the window.
wMsg
[in]The msg sent to the window.
wParam
[in]Additional msg-specific information.
lParam
[in]Additional msg-specific information.
Remarks
This static method implements the window procedure. WindowProc directsmsgs to the
msg map identified by m_dwMsgMapID. If necessary, WindowProc calls
DefWindowProc for additional msg processing.
Accessing the Microsoft Windows API: You can access to the Windows API (or other outside DLLs) by declaring the external
procedures within your Visual Basic application. After you declare a procedure, you can
use it like any other language feature in the product.
The most commonly used set of external procedures are those that make up Microsoft
Window itself. The Window API contains thousands of functions, subs, types, and
constants that you can declare and use in your project. These procedures are written in the
C language, however, so they must be declared before you can use them with the Visual
Basic. The declaration for DLL procedures can become fairly complex. While you can
translate these yourself, the easiest way to access the windows API is by using the
predefined declares included with Visual Basic.
The file Win32api txt, located in the \Winapi subdirectory of the main Visual Basic
directory, contains declarations for many of the Windows API procedures commonly used
in Visual Basic. To use a function, Type, or other feature from this file, simply copy it to
your Visual Basic module. You can view and copy procedures from Win32api.txt by
using the API Viewer application, or by loading the file in any text editor.
Note: The Windows API contains a vast amount of code. To find reference information
on the procedures and other details included in this API set, refer to the Win 32
SDK, included on the Microsoft Developer Network Library CD.
Using the API Viewer Application: The API Viewer application enables you to browse through the declares, constants, and
types included in any text file or Microsoft Jet database. After you find the procedure you

want, you can copy the code to the Clipboard and paste it into your Visual Basic
application. You can add as many procedures as you want to your application.
The API Viewer application
To view an API file: 1. From the Add-Ins menu, open the Add-In Manager and load API Viewer.
2. Click API Viewer from the Add-Ins menu.
3. Open the text or database file you want to view.
To load a text file into the viewer, click File \ Load Text File and choose
the file you want to view.
To load a database file, click File \ Load Database File.
4. Select the type of item you want to view from the API types list.
Note: You can have the API Viewer automatically display the last file you viewed in it,
When it is opened, by selecting View \ Load Last File.
To add procedures to your Visual Basic code: 1. Click the procedure you want to copy in the available Items list.
2. Click Add. The item appears in the selected Item list.
3. Indicate the scope of the item by clicking Public or Private in the Declare Scope
group.
4. To remove an entry from the selected Items list box, click the item and click
Remove.
5. To remove all the entries from the Selected Items list box, click Clear.

MFC: Overview: The Microsoft Foundation Class Library (MFC) is an application framework for
programming in the Microsoft Windows. Written in C++, MFC provides much of the
code necessary for managing windows, menus, and dialog boxes; performing basic
input/output; storing collections of data objects; and so on. All you need is to do is add
your application-specific code into this framework, and given the nature of C++ class
programming, its easy to extend or override the basic functionality the MFC framework
supplies.
The MFC framework is a powerful approach that lets you build upon the work of expert
programmers for windows. MFC shortens development time; makes code more portable;
provides tremendous support without reducing programming freedom and flexibility; and
gives easy access to hard to program user-interface elements and technologies, like
Active technology, OLE, and Internet programming. Furthermore, MFC simplifies
database programming through Data Access Objects (DAO) and Open Database
Connectivity (ODBC), and network programming through Windows Sockets. MFC
makes it easy to program features like property sheets (tab dialogs), print preview, and
floating, customizable toolbars.

The Framework: Your work with the Microsoft foundation Class Library (MFC) framework is based
largely on a few major classes and several visual C++ tools. Some of the classes
encapsulate a large portion of the Win32 application programming interface (API).
Other classes encapsulate application concepts such as documents, views, and the
application itself. Still others encapsulate Ole features and ODBC and DAO data-access
functionality.
For example, Win32s concept of window is encapsulated by MFC class CWnd. That is, a
C++ class called CWnd encapsulates or wraps the HWND handle that represent a
Windows window. Likewise, class CDialog encapsulates Win32 dialog boxes.
Encapsulation means that the C++ class CWnd, for example, contains a member variable
of type HWND, and the classs member functions encapsulate calls to Win32 functions
that take an HWND as a parameter. The class member functions typically have the same
name as the Win32 function they encapsulate.
The Assumptions of MFC: Among the important assumptions made by the MFC documentation are that:
You already know a little about programming for windows.
You know basics of programming in C++.
You understand the fundamentals of object-oriented programming.
MFC Application Architecture Classes: Classes in this category contribute to the architecture of a framework application. They
supply functionality common to most applications. You fill in the framework to add
application-specific functionality. Typically, you do so by deriving new classes from the
architecture classes, then adding new members and/or overriding member functions.
AppWizard generates several types of applications, all of which use the application
framework in differing ways. SDI(single document interface) and MDI (multiple
document interface) applications make full use of a part of the framework called
document/view architecture. Other types of applications, such as dialog-based
applications, form-based applications, and DLLs, use only some of document/view
architecture features.
Document/view applications contain one or more sets of documents, views, and frame
windows. A document-template object associates the classes for each
document/view/frame set.
Although you do not have to use document/view architecture in your MFC application,
there are a number of advantages to doing so. MFCs OLE container and server support is
based on document/view architecture, as is support for printing and print preview. All
MFC applications have at least two objects: an application object derived from
CWinApp, and some sort of main window object, derived (often indirectly) from CWnd.
(Most often, the main window is derived from CFrameWnd, CMdIFrameWnd, or
CDialog, all of which are derived from CWnd.)
Applications that use document/view architecture contain additional objects. The
principal objects are as follows:
An application object derived from the class CWinApp, as mentioned before.

 One or more document class objects derived from class CDocument. Document
class objects are responsible for the internal representation of the data
manipulated in the views. They may be associated with a data file.
One or more view objects derived from class CView. Each view is a window that
is attached to a document and associated with a frame window. Views display and
manipulate the data contained in a document class object.
Document/view applications also contain frame windows (derived from CFrameWnd)
and document templates (derived from CDocTemplate).