Windows NT and Windows 95 Considerations

This topic summarizes information about developing TPs for the Microsoft® Windows NT® and Windows® 95 systems.

Byte ordering

The values of constants defined in WINAPPC.H and WINCSV.H are dependent on the byte ordering of the hardware used. Macros are used to set the constants to the correct value.

By default, Intel little-endian byte ordering is used, with the low byte of a 16-bit value followed by the high byte. However, for inline environment defining, the NON_INTEL_BYTE_ORDER macro used in WINAPPC.H and WINCSV.H will not reverse (flip) the byte order for constants. Nonconstant input parameters in VCBs (such as lengths, pointers, and so on) are always in the native format.

For example, the primary return code of ap_parameter_check is defined to have a value of 0x0001. Depending on the environment (byte ordering), the constant AP_PARAMETER_CHECK may or may not be 0x0001. Some formats define the value as it appears in memory; others define it as a 2-byte variable. Because you cannot assume that the application will always use provided constants rather than hardwired values, you can define a macro to swap the bytes. The following is an example of using the macro:

/* when NON_INTEL_BYTE_ORDER is specified, the APPC_FLIPI macro defined in WINAPPC.H macro becomes */
#define APPC_FLIPI(x)    (x)

/* otherwise this macro flips bytes by defining */
#define APPC_FLIPI(X) APPC_MAKUS(APPC_HI_UC(X),APPC_LO_UC(X))

/* the AP_PARAMETER_CHECK macro is now defined using the APPC_FLIPI macro */
#define AP_PARAMETER_CHECK APPC_FLIPI (0X0001)      /* X '0001' */

Events

To receive data asynchronously, an event handle is passed in the semaphore field of the VCB. This event must be in the nonsignaled state when passed to APPC, and the handle must have EVENT_MODIFY_STATE access to the event.

Library names

In preparation for the coexistence of Win16 and Win32® API libraries on the same computer, the Win32 DLL names have been changed.

Old DLL names	New DLL names
WINAPPC.DLL	WAPPC32.DLL
WINCSV.DLL	WINCSV32.DLL

The old DLL names should be used for Win32-based applications that are required to run on SNA Server version 2.0. The new DLL names should be used for Win32-based applications that are intended to run only on SNA Server version 2.1 or later.

If you intend your Win32-based application to be used with SNA Server version 2.0, you should link with the libraries included with SNA Server version 2.0. Otherwise, use the new libraries provided with SNA Server versions 2.1 and 3.0.

Limits

For Windows NT and Windows 95, the number of simultaneous CSVs allowed per process is 64. Only one of these verbs per thread can be synchronous (blocking).

Multiple threads

A TP can have multiple threads that issue verbs. Windows APPC makes provisions for multithreaded Windows-based processes. A process contains one or more threads of execution. All references to threads refer to actual threads in the multithreaded Windows NT and Windows 95 environments.

With the exception of RECEIVE_AND_POST. MC_RECEIVE_AND_POST, RECEIVE_AND_WAIT, and MC_RECEIVE_AND_WAIT, only one conversation verb can be outstanding at a time on any conversation; however, other verbs can be issued for other conversations. This guideline also applies to TP verbs and TPs. Although multiple TP verbs can be issued, only one TP verb can be outstanding at a time on a TP. This applies to both multithreaded applications and single-threaded applications that use asynchronous calls.

Packing

For performance considerations, VCBs are not packed. As a result, DWORDs are on DWORD boundaries, WORDs on WORDs, and BYTEs on BYTEs. This means, for example, that there is a 2-byte gap between the primary and secondary return codes. VCBs should be accessed using the structures provided.

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 the dynamic-link libraries WINAPPC.DLL or WAPPC32.DLL.
GetProcAddress to specify APPC on all the desired entry points to the DLL such as APPC, WinAsyncAPPC, WinAPPCStartup, and WinAPPCCleanup.

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

LoadLibrary to load WINCSV.DLL or WINCSV32.DLL, the dynamic-link libraries for Windows CSV.
GetProcAddress to specify CSV on all the desired entry points to the DLL such as ACSSVC, WinAsyncCSV, WinCSVStartup, and WinCSVCleanup.

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

Yielding to other components

By default, and because the Windows NT and Windows 95 environments are multithreaded, there is no need to yield to other components. However, if an application is single-threaded and is intended for both Windows NT or Windows 95 and Windows version 3.x, use the Windows extensions WinAPPCSetBlockingHook and WinAPPCUnhookBlockingHook. These extensions must be explicitly called to accomplish the yield procedure.