If you port a Windows-based application to the Windows NT or Windows 95 operating system and do not need to maintain compatibility with Windows, you can change your DB-Library code to remove redundant or unnecessary Windows functions.
The dbwinexit function is Windows-specific and unnecessary in DB-Library for the Win32 API.
The following changes apply to the registration of error and message handlers for the Win32 API:
For Windows
// Define variables static FARPROC lpdbMsgHandler; static FARPROC lpdbErrHandler; // Get Procedure Instances lpdbMsgHandler = MakeProcInstance((FARPROC)dbMsgHandler, hInst); lpdbErrHandler = MakeProcInstance((FARPROC)dbErrHandler, hInst); // Install the instances into dblib dbmsghandle(lpdbMessageHandler); dberrhandle(lpdbErrorHandler);
For the Win32 API
// Install the instances into dblib dbmsghandle(dbMsgHandler); dberrhandle(dbErrHandler);
To support asynchronous processing in the cooperative multitasking environment in Windows, each application must behave well and yield to the CPU at regular intervals. Therefore, when you process SQL Server queries in Windows, you need to use Windows timers or the PeekMessage function in combination with the DB-Library function calls for asynchronous processing (dbsqlsend, dbdataready, and dbsqlok).
Support for preemptive multitasking in the Win32 API simplifies the implementation of asynchronous query processing. The preemptive multitasking nature of the Windows NT and Windows 95 operating systems ensures that other processes always obtain CPU cycles regardless of any processing that another application is doing. Within a single process, asynchronous processing can be implemented using Win32 threads or by using the DB-Library functions that support asynchronous processing in conjunction with the PostMessage Windows function. For more information about asynchronous processing, see Taking Advantage of Win32 API Features in DB-Library Applications.