Windows Considerations

This topic summarizes information about developing TPs for the Microsoft® Windows® version 3.x system.

Blocking routines

Do not use blocking functions if your application runs in Windows version 3.x. Instead, use WinAsyncAPPC in conjunction with a WinAsyncAPPC Windows message.

Limits

For APPC limits, see your product documentation. For the Windows version 3.x system, the number of simultaneous CSVs allowed per computer is 64. Only one of these verbs per process can be synchronous.

Load-time linking

For a TP to be dynamically linked to APPC at load time, you must do one of the following at link time:

• Insert the following IMPORTS statements in the definition (.DEF) file used to link the TP:

  IMPORTS WINAPPC.APPC
  IMPORTS WINAPPC WinAsyncAPPC.APPC
   

• Link the TP to WINAPPC.LIB, which contains the entry point linkage information for APPC. If you intend to use CSVs, you must also link to WINCSV.LIB, which contains the entry point information for CSVs.

Packing

VCBs are not packed. As a result, DWORDs and WORDs are on WORD boundaries, and BYTEs are on BYTE boundaries. This means, for example, that there is not a 2-byte gap between the primary and secondary return codes. VCBs should be accessed using the structures provided, and compiler options that change this packing method should be avoided.

RECEIVE_AND_POST and MC_RECEIVE_AND_POST

These verbs have been replaced for Windows version 3.x by calling RECEIVE_AND_WAIT or MC_RECEIVE_AND_WAIT using WinAsyncAPPC.

Registering and deregistering applications

All Windows APPC applications must call WinAPPCStartup at the beginning of the session to register the application and WinAPPCCleanup at the end of the session to deregister the application.

All Windows CSV applications must call the Windows SNA extension WinCSVStartup at the beginning of the session to register the application and WinCSVCleanup to deregister the application when the session is finished.

Run-time linking

For a TP to be dynamically linked to APPC at run time, the TP must issue the following calls:

• LoadLibrary to load WINAPPC.DLL, the dynamic-link library for APPC.
• GetProcAddress to specify APPC on all the desired entry points to the DLL such as APPC, WinAsyncAPPC, WinAPPCStartup, and WinAPPCCleanup.

The TP must issue the FreeLibrary call when the APPC library is no longer required.

Simultaneous conversations

A TP can participate in as many as 64 conversations simultaneously within the Windows environment. However, if more than one TP is active at once, the total number of conversations cannot exceed 64.

Translating service TP names to ASCII for WIN.INI

For service TPs on SNA Server clients running Windows version 3.x, a line must be added to the WIN.INI file, specifying the TP name in ASCII. For more information, see Translating SNA Service TP Names to ASCII for WIN.INI.

Yielding to other components

Because Windows version 3.x is single-threaded, there is only one thread of execution. In the case where a function must wait before completing a task, the only thread of execution could block to allow other tasks to proceed.

This means that while in a blocking call, the calling application's Window procedure can be called. To test if this is the case, the extension WinAPPCIsBlocking is provided. Any attempt to make a second blocking call with one already outstanding will cause the call to fail with the return code ap_thread_blocking.

Windows APPC and CSV contain a default yield procedure for Windows version 3.x that can yield to other functions while waiting for the first function to complete. The default is:

BOOL DefaultBlockingHook (void)  {
    MSG msg:
    /* get the next message if any */
    if ( PeekMessage (&msg,0,0,PM_NOREMOVE)  )   {
if  ( msg.message = = WM_QUIT  )
    return FALSE;   / /  let app process WM_QUIT
PeekMessage  ( &msg,0,0,PM_REMOVE)  ;
TranslateMessage  (&msg)  ;
DispatchMessage  (&msg)  ;
    }
    /*TRUE if no WM_QUIT received */
    return TRUE;
}
 

Besides the default yield procedure, Windows APPC provides WinAPPCSetBlockingHook to support applications that require more complex message processing. This call allows a Windows APPC implementation to block APPC function calls by means of a new function. It is used by Windows version 3.x applications to make blocking calls without blocking the rest of the system. To call WinAPPCSetBlockingHook:

FARPROC WINAPI WinAPPCSetBlockingHook (FARPROC 1pBlockFunc)
 

WinAPPCUnhookBlockingHook removes any previous blocking hook that has been installed and reinstalls the default blocking mechanism. To call WinAPPCUnhookBlockingHook:

BOOL WINAPI WinAPPCUnhookBlockingHook (void)