There are some programming practices that work well for standard C or assembly-language applications, but will not work in the Windows environment.
In general, when writing Windows applications, remember the following rules:
Do not take exclusive control of the CPU—it is a shared resource. Although Windows is a multitasking system, it is nonpreemptive. This means it cannot take control back from an application until the application releases it. A cooperative application carefully manages access to the CPU and gives other applications ample opportunity to execute.
Do not attempt to directly access memory or hardware devices such as the keyboard, mouse, timer, display, and serial and parallel ports. Windows requires absolute control of these resources to ensure equal, uninterrupted access for all applications that are running.
Within your application, all functions that Windows can call must be defined with the PASCAL keyword; this ensures that the function accesses arguments correctly. Functions that Windows can call are the WinMain function, callback functions, and window functions.
Every application must have a WinMain function. This function is the entry point, or starting point, for the application. It contains statements and Windows function calls that create windows and read and dispatch input intended for the application. The function definition has the following form:
int PASCAL WinMain( hInst,hPrevInst,lpCmdLine,nCmdShow )
HANDLE hInst;
HANDLE hPrevInst;
LPSTR lpCmdLine;
int nCmdShow;
{
.
.
.
}
The WinMain function must be declared with the PASCAL keyword. Although Windows calls the function directly, WinMain must not be defined with the FAR keyword, since it is called from linked-in start-up code.
NOTE:
By convention, certain C keywords in Windows programs are written in all capital letters rather than lowercase as the ANSI standard has them. WINDOWS.H defines two equivalent versions of these keywords. They are: FAR (__far), PASCAL (__pascal), NEAR (__near), LONG (long), and VOID (void).
When using Windows functions, be sure to check the return values. It's not a good idea to ignore these return values, since unusual conditions sometimes occur when a function fails.
Do not use C run-time console input and output functions, such as getchar, putchar, scanf, and printf.
Do not use C run-time file input and output functions to access serial and parallel ports. Instead, use the communications functions, which are described in detail in the Windows Programming Reference.
You can use the C run-time file input and output functions to access disk files. In particular, use the Windows OpenFile function and the low-level, C run-time input and output functions. Although you can use the C run-time stream input and output functions, you do not get the advantages that OpenFile provides.
You can use the C run-time memory-management functions malloc, calloc, realloc, and free, but be aware that Windows translates these functions to its own local-heap functions, LocalAlloc, LocalReAlloc, and LocalFree. Since local-heap functions don't always operate exactly like C run-time memory-management functions, you may get unexpected results.