"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.
"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.
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.
This defnintion was nessary to port on both platforms.
#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 */
Also remember that in Windows NT and Windows 95 much of the system and user information that was previously stored in the WIN.INI and SYSTEM.INI files is now in the Registry. WIN16 applications should be changed to access the Registry instead of the INI files.
#ifdef WIN32 m_pConferenceList = new CConferenceList(getenv("USERNAME")); #else m_pConferenceList = new CConferenceList(getenv("NAME")); #endif
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.
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.
The "Generic Thunk", 16-bit code calling 32-bit code, is avalible in Windows NT but it is irreversible.
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 (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:
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((LPSTR) &address.sin_addr, hp->h_addr, hp->h_length); // Note: memcpy returns the value of dest (&address.sin_addr)
Similar code in the Winsock test application ran without fail. This error is still being investigated.
For further information:Discuss: An Electronic Conferencing System for a Distributed Computing Enviromnent. Raeburn et al.
Visual C++ 2.0 Development System for DEC Alpha AXP, Alpha AXP Programmer's Guide
Port Your 16-bit Applications to Windows NT Without Ripping Your hair Out. MSJ. Vol. 8. Aug. 1993.
Slay the Porting Beasties: Dave's Top Ten Tips for Migrating to Windows NT. MSJ Vol. 8. Sept. 1993.
Clearer, More Comprehensive Error Processing with Win32 Structured Exception Handling. MSJ Vol. 9. Jan. 1994
Programming With MFC and WIN32. Vol. 2 of 6. MIcrosoft Press. 1994.