Win16 SNA App May Hang Over SNA Win 3.x TCP/IP Sockets Interface

MORE INFORMATION

1. If the 16-bit application isn't "peeking" on messages to all Window handles.
   
   Unlike named pipes and Netware IPX/SPX, the Windows 3.x TCP/IP socket interface runs within the non-preemptive Windows architecture, underneath the calling application. When the SNA Windows 3.x client makes calls to named pipes or Netware IPX/SPX, which run outside of Windows, the network i/o is accomplished with no requirements of the 16-bit Windows application.
   
   However, when the SNA Windows 3.x client is configured for TCP/IP sockets, the 16-bit Windows application must "peek" on messages intended for any Windows handle, in order for the underlying SNA client software to receive data from the TCP/IP sockets interface.
   
   So, in order for the Windows application to work over TCP/IP sockets, the application's Windows message loop should be architected as follows:

         /*  get the next message if any */ 
         if ( PeekMessage ( &msg, NULL, 0, 0, PM_NOREMOVE) ) {
            if ( msg.message = WM_QUIT )
               return FALSE;   // let app process WM_QUIT
            PeekMessage ( &msg, NULL, 0, 0, PM_REMOVE) ;
            TranslateMessage (&msg) ;
            DispatchMessage (&msg) ;
        }

   The second parameter passed to PeekMessage(), the Window handle (hWnd), must be NULL in order for the underlying TCP/IP sockets interface to receive messages on behalf of the application. NOTE: If an API communication layer is being developed (for example, an ODBC/DRDA driver), the developer may not have control over the architecture of the calling application. If this is occurring, then the following strategy can be used to function over TCP/IP sockets:
   
   
   • When SNA client is running over Winsock it makes a hidden window with class name "SNA Winsock". For the other transports, it's "SNA Server".
   • During initialization of the API communication layer, call EnumWindows and find one whose class starts with "SNA ".
   • Establish an SNA blocking hook which dispatches messages only for this window.
   • Call OpenFile (IF_EXIST) on WINSOCK.DLL. If it exists, call
     
     If not, do not call LoadLibrary since this will put a dialog on the screen if it can't find the DLL.
   • Call GetProcAddress for WSAStartup and WSASetBlockingHook, and set a Winsock blocking hook that doesn't dispatch any messages.
2. If the Windows SNA startup call is made from a different windows process than the SNA API calls are made from.
   
   If a Windows application calls the APPC, CPIC or LUA interface, the application should first call WinAPPCStartup, WinCPICStartup, or WinRUIStartup/WinSLIStartup respectively. This startup call should be performed when the Windows process first initializes, before initiating a session over the SNA interface.
   
   A hang has been observed if a Windows 3.x application calls WinAPPCStartup from one Windows process, and then calls the APPC interface from another Windows process. Later versions of the SNA Windows 3.x client software (3.0 and later) now allow a Windows 3.x application to invoke an APPC conversation without first calling WinAPPCStartup. However, the application should still call WinAPPCStartup. If an application calls WinAPPCStartup from one process, and then calls APPC functions from another process, the application may hang if TCP/IP sockets is being used.
   
   To correct this problem, the WinAPPCStartup call should be moved to the process which is actually using the APPC interface, or the WinAPPCStartup and WinAPPCCleanup calls should be removed from the Windows application.