The information in this article applies to:
- Microsoft SNA Server version 2.0, 2.1, 2.11, 2.11 (all service packs),
3.0 (all service packs)
SUMMARY
A 16-bit Windows application which uses the APPC, CPIC, or LUA interfaces
may hang when running over the SNA Server Windows 3.x client TCP/IP
sockets interface. This problem can occur on either WFW/Windows 3.x or
Windows 95. This problem may only occur when the client is configured
for TCP/IP sockets. The application may work correctly when the SNA Server
Windows 3.x client is configured to use named pipes or Netware ipx/spx.
There are two main scenarios where this has been observed:
- If the 16-bit application isn't "peeking" on messages to all windows
handles.
2. If the Windows SNA startup call is made from a different windows
process than the SNA API calls are made from.
These scenarios are described in more detail below.
NOTE: When running on Windows NT, a 16-bit Windows application that uses
the APPC, CPIC, or LUA interfaces can run over the SNA Server Windows NT
client software, through the 16-to-32-bit SNA "thunking" DLL's. By using
these thunking DLL's on the SNA Server Windows NT client software, the
problems described in this article do not occur.
MORE INFORMATION
Normally, a 16-bit Windows application which uses the SNA Server
Windows 3.x SNA API's should function properly regardless of the LAN
interface used by the underlying SNA Windows 3.x client software.
However, the application may encounter problems when running over the
SNA client when configured for TCP/IP sockets because the underlying
architecture of the socket interface has special requirements for the
16-bit Windows calling application.
If a 16-bit Windows application fails to work on top of the SNA Windows
client TCP/IP sockets interface, here are the possible causes.
- 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 LoadLibrary.
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.
- 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.
|