Porting Issues from WIN16 to WIN32 in Discuss for Windows

By Arjun Sanyal (Sanyal@cris.com)

Code Compatibility

"You can easily port projects from the Intel x86 platform to the Alpha AXP platform, but some changes are required. You can use the same project (.MAK) and source files, but not intermediate files, which have to be rebuilt."

This multiplies the re-coding task. This was the case with Discuss which depened on a enchanced editor contol DLL (MAGMAED.DLL), a Kerberos verison 4 DLL (KRBV4WIN.DLL), and LIBDS.LIB and UPS.LIB. The Kerberos DLL in turn depended on the WSHELPER.DLL which had to be ported. These backend libraries containing low-level, non-MFC code were the most dificult to port.

The LIBDS.LIB contained the lowest level code in the project, the RPC interface to the Discuss servers. Mainly this code gave the most trouble for two reasons. One, much of the code is a mix of Discuss meeting functions, home-brew RPC, Windows sockets calls, and the Unified Stream Protocol. The complexity slowed down the process of quickly finding and fixing a porting error. Second, some illogical bugs popped up in this code: see memcpy.

A Note on Kerberos DLL Naming Conventions

WINDOWSX.H

       "WINDOWSX.H"
	...
	#define far
	#define pascal
	...
	#define _fmemcpy memcpy
	...

Use WINDOWSX.H to speed up a port, but it may be a better idea to re-write the code to the WIN32 API standard becuse of the phase out of the WIN16 API and for clarity.

WIN32_LEAN_AND_MEAN

If there is trouble with the more esoteric header files that the mandatory WIN32 WINDOWS.H file includes (some OLE stuff and other strange things), try the WIN32_LEAN_AND_MEAN preprocessor definition. This excludes these headers from the build and reduces compile time.

#ifndef WIN32_LEAN_AND_MEAN
#include <cderr.h>
#include <dde.h>
#include <ddeml.h>
#include <dlgs.h>
#include <lzexpand.h>
#include <mmsystem.h>
#include <nb30.h>
#include <rpc.h>
#include <shellapi.h>
#include <winperf.h>
#include <winsock.h>
...
#endif /* WIN32_LEAN_AND_MEAN */

Multiuser Concerns

#ifdef WIN32
	m_pConferenceList = new CConferenceList(getenv("USERNAME"));   
#else 
	m_pConferenceList = new CConferenceList(getenv("NAME"));
#endif

ERRNO.H Compatibility

The errno values in NT are a subset of the values for errno in XENIX systems. Thus, the errno value is not necessarily the same as the actual error code returned by a Windows NT system call. To access the actual operating system error code, use the _doserrno variable, which contains this value.

Structured Exception Handling

EXCEPTION ACCESS VIOLATION Occurs if a thread attempts to load or store data to or from an address that is not accessible to the current process. This is the most common exception: reading or writing through a bad or NULL pointer will cause it. But with a 4GB address space, what address could be considered bad? Well, if you read Jeff Richter’s 'An Introduction to Win32 Heap and Virtual Memory Management Routines,' MSJ, March 1993, then you know that only 2GB is available to a process and that some virtual addresses within that 2GB can be marked as PAGE READONLY or PAGE NOACCESS.

When the code is stopped is the _real_ access violation. In the port another message

First-Chance Exception in WDforNT.exe: 0xC0000005: Access Violation.

was seen several times. Ignore this one. The MSDN explanation:

Under Windows NT, the default top level handler detects writes to resources and will make the resource writable. If you are running outside of a debugger and you have no exception handler, your resource writes will silently work. If you are running under the debugger, your resource write will look like an access violation:

First-Chance Exception in msin32.exe: 0xC0000005: Access Violation

This allows you to "fix" your resource writes. If you have the debugger pass on the exception to your application and you have no handler, the default handler will make your resource writable.

The disadvantage of setting the attribute of the resource section to read/write is that Windows NT will use a separate copy of the resource section for each process that uses this section, instead of one copy for all processes.

Not-So-Universal Thunk

The "Generic Thunk", 16-bit code calling 32-bit code, is avalible in Windows NT but it is irreversible.

The Simple Portability Features of the MFC from WIN16 to WIN32

Most notably, the widening of the WPARAM type from 16 to 32 bits usually necessiitites the repacking of the wParam and lParam message parameters. The library handles most of the changes internally. Also, "un-natural" structure member alignment is automatically corrected, with a signifigant performance penalty, especially on RISC processors. See the article "Port Your 16-bit Applications to Windows NT Without Ripping Your hair Out" for information on natural structure member alignment.

Intrinsic Functions - Alpha Specific

Intrinsic functions (also called "intrinsics") are function calls that the compiler resolves directly, by generating code, rather than by calling an external function. The Alpha AXP version of the compiler supports a number of new intrinsics. With all new intrinsics, you must explicitly enable the intrinsic before calling it, by using it with the /Oi compiler option or the intrinsic pragma. The general syntax for using this pragma is:

#pragma intrinsic(intrinsic-name)

For example, to enable the use of the _InterlockIncrement intrinsic, include a pragma as shown, along with the declaration of the function:

long _ _stdcall _InterlockedIncrement(long *); #pragma intrinsic(_InterlockedIncrement)

It's importaint to know what functions are intrinsic so that if there is an error in that call, you are aware of both compilation options. Of course, intrinsics can be activated or deactivated using the compiler optimization options.

Memcpy Bug - Alpha Specific

	 memcpy((LPSTR) &address.sin_addr, hp->h_addr, hp->h_length);
	
	// Note: memcpy returns the value of dest (&address.sin_addr)