Important Data Types Compared The following table shows the most important simple data types of Win16 and Win32 in direct comparison. The first column shows the type name, the second its definition and length (in bytes) under Win16, and the third the same under Win32. The last column (called Rem.) contains pointers to further remarks and explanations that are found in the mar­ gin. Please note that some portable and Unicode-compatible data types have been introduced with Win32 (TCHAR, and the like), which as of today have no equivalent in Win16. These have not been included in the table. Data type Win16 definition and Win32 definition and Rem. Table A1.1; The most size size important Windows data int/INT int (2) int, INT (4) [1] types in direct comparison char/CHAR char (1) char, CHAR (1) short/SHORT short (2) short, SHORT (2) BOOL int (2) int (4) [1] [1 J The size of the type has BYTE unsigned char (1) unsigned char (1) changed. WORD unsigned short (2) unsigned short (2) DWORD unsigned long (4) unsigned long (4) [2J Win32 pointers are not UINT unsigned int (2) unsigned int (4) [1] built from segment and LONG signed long (4) signed long (4) offset, but just contain a WPARAM UINT (2) UINT (4) [1] (widened) offset; therefore LPARAM LONG (4) LONG (4) segment arithmetics are LRESULT LONG (4) LONG (4) impossible. There's no PSTR char NEAR * (2) char * (4) [1] distinction between NEAR NPSTR char NEAR * (2) char * (4) [1] and FAR pointers. LPSTR char FAR * (4) char * (4) [2] LPCSTR const char FAR * (4) const char * (4) [2] PBYTE BYTE NEAR * (2) BYTE * (4) [1] LPBYTE BYTE FAR * (4) BYTE * (4) [2] 355 Appendix 1: Important Data Types Compared Data type Win16 definition and Win32 definition and Rem. [1 J The size of the type has size size changed. PINT int NEAR * (2) INT * (4) [1] LPINT int FAR * (4) INT * (4) [2] [2J Win32 pointers are not PWORD WORD NEAR * (2) WORD * (4) [1] built from segment and LPWORD WORD FAR * (4) WORD * (4) [2] offset, but just contain a (widened) offset; therefore PLONG long NEAR * (2) long * (4) [1] segment arithmetics are LPLONG long FAR * (4) 10nK * (4) [2] impossible. There's no PDWORD DWORD NEAR * (2) DWORD*(4) [1] distinction between NEAR LPDWORD DWORD FAR * (4) DWORD* (4) [2] and FAR pointers. LPVOID void FAR * (4) void * (4) [2] HANDLE const void NEAR * (2) void * (4) [1] [3J ... similar to the other (STRICT) handle types defined with HANDLE UINT (2) void * (4) [1] DECLARE_HANDLE (HOC, (normal) HMENU, HGDIOBJ, etc.). HWND const struct HWND- const struct HWND- [1,3] [4J One of those pointer (STRICT) NEAR * (2) * (4) types that under Win16 were HWND UINT HANDLE [1,3] dependent on the memory (normal) model (small, medium, etc.). PHANDLE HANDLE * (2) HANDLE * (4) [1,4] SPHANDLE HANDLE NEAR * (2) HANDLE * (4) [1] [5J This is one of the rare LPHANDLE HANDLE FAR * (4) HANDLE * (4) [2] exceptions: a Win16 UlNT ATOM UINT (2) WORD (2) [5] changes to a Win32 WORD HFILE int (2) int (4) [1] (i. e.,the size doesn't FARPROC void (CALLBACK *) int (WIN API *)0 (4) [2,6] change). (void) (4) [6J One of the rare cases WNDPROC LRESULT LRESULT [2,7] where the two header files (CALLBACK *) (CALLBACK *) are not consistent. (HWND, UlNT, (HWND, UlNT, WPARAM, WPARAM, {7] Apart from the parameter LPARAM) (4) LPARAM) (4) list also valid for other CALLBACK functions (like Over and above these standard Windows data types, the Win32 API DLGPROC, etc.). predefines a lot of other simple types, which for the better part stem from the time when Windows NT was still called OS/2 NT. Therefore it should not exactly be astonishing that these type definitions look quite familiar to OS/2 developers. The following small table shows the most 356 I Appendix 1 important of those new, "old" types, which easily can be used in parallel I to the well-known Windows types: Win32 datatyp_e Win32 definition Win16 equivalent(s) Table A1.2: OS/2 compatible UCHAR unsigned char BYTE Win32 data types. USHORT unsigned short WORD,OINT PYOID void * LPVOID PUSHORT USHORT* LPWORD ULONG unsigned long DWORD PULONG ULONG* LPDWORD PSZ char * LPSTR 357 Appendix 2 PORT.INI: Enhanced and Clarified Appendix 2 shows an enhanced and clarified version of the PORTIOOL initialization file PORT.IN!. Of course, a copy of the file is also found on the accompanying disk - possibly even in a somewhat more current version than is printed here (see the subdirectory \PORTIOOL). Using the file is simplicity itself: just rename the original PORT.lNI found in X:\MSTOOLS\BIN (e.g., to PORT.OLD) and copy the enhanced version from the disk to X:\MSTOOLS\BIN. If you start PORTTOOL as usual, the program directly accesses the new file. (Another possibility would be to copy the file with another name, e.g., PORTENH.lNI, and to use the PORTTOOL open command to read in an INI file.) The entries in Divided in seven classes PORT.INI are divided into seven classes: the section [APIS] is responsi­ ble for all Windows functions; [MESSAGES] deals with messages; [STRUCTURES] with struct definitions; [TYPES] handles the simple data types; I assume [CONSTANTS] and [MACROS] are self-explaining. Fi­ nally, [CUSTOM] is a dumping spot for all those items that are not easily assigned to one of the other categories. In a specific group the entries are sorted alphabetically, so the following listing can be used either as a ref­ erence or, if you have a specific question in mind, as an enhancement to the index. Of course, you can easily modify and enhance the file on your own (caution: don't use special characters above the standard 7-bit ASCII set, best regards of strtokO!). If you have to report an improvement or error, please inform me of the change or addition so that this information can be put into subsequent editions. The directory \PORTIOOL also sports a simple application called PORTVIEW.EXE (including source code). This program can be used for PORTVIEW.EXE brOWSing and investigating PORT.INI (or any other file in the proper format). The program also allows you to search the whole file for a spe­ cific item and links to the API WinHelp files. The executable file is a standard portable executable (PE) and can be executed under Windows NT, Windows 95, and Windows 3.1 (with the help of Win32s, see subdi­ rectory \ WIN32S on the disk). Have fun! 359 Appendix 2: PORT.lNI Enhanced and Clarified [PORTroJL] To get help for the various items from within PORTTOOL, specify the path ; where WinHelp can find the API help file. But be forewarned: PORTroJL is ; (not only in this respect) scmewhat "obstinate" (if not to say buggy) •.. WinHelp=z:\hlp\api32wh.hlp Viewing l6-bit help is unfortunately not supported by PORTroJL. This line is read and interpreted by my PORTVIEW program only; it should-contain the location of the Win16 help files (if any) . WinHelpl6=d:\bc\bin\tcwhelp.hlp [APIS] The fonnat for the follwing entries (which can be easily enhanced or changed) is defined as follows (alas, no special characters such as umlauts are allowed in the text) : SearchKey=Win32APIHelpTerm; Reason for the change; Proposed action; There are the following optional variants: SearchKey=APIHelpTerm;Reason for the change; SearchKey=APIHelpTerm; ;Proposed action; SearchKey=APIHelpTerm; ; ; SearchKey= ;Reason for the change;Proposed action; SearchKey= ;Reason for the change; ; SearchKey= ; ;Proposed action; Trailing semicolons are optional. By the way, more about the sections can be found in the book in appendix 2; there also a complete listing of this file is shown! The first line has to appear twice to be read once ... AccessResource=AccessResource;No 32-bit equivalent;Not required, just delete; AccessResource=AccessResource;No 32-bit equivalent;Not required, just delete; AddFontResource=AddFontResource;Only use file names (strings), no handles;; AllocDSToCSAlias=AllocDSToCSAlias;No 32-bit equivalent;; AllocResource=AllocResource;no direct 32-bit equivalent;Replace with Load/Find/LockResource; AllocSelector=AllocSelector;No 32-bit equivalent;; AnsiLower=AnsiLower;Macro around CharLower;; AnsiLowerBuff=AnsiLowerBuff; Macro around CharLowerBuff; ; AnsiNext=AnsiNext;Macro around CharNext; ; AnsiPrev=AnsiPrev;Macro around CharPrev;; AnsiTcDem=AnsiTcQ:m;Macro around CharTcQ:m;; AnsiTcQ:mBuff=AnsiTcQ:mBuff;Macro around CharTcQ:mBuff;; AnsiUpper=AnsiUpper;Macro around CharUpper;; AnsiUpperBuff=AnsiUpperBuff;Macro around CharUpperBuff;; Catch=Catch;No 32-bit equivalent;Replace with structured exception handling (SEH); ChangeMenu=ChangeMenu;New functions available;Replace with portable functions; ChangeSelector=ChangeSelector;No 32-bit equivalent;; CloseCamm=CloseComm;OOMM functions mapped to file I/O;Replace with CloseHandle; CloseSound=CloseSound;No 32-bit equivalent;Replace with multimedia sound support or PlaySo- und/Beep; 360 Appendix 2 CountVoieeNotes=CountVoieeNotes;No 32-bit equivalent;Replace with multimedia sound support or PlaySound/Beep; DefHookProc=DefHookProe;Old hook API, creates only thread-local hooks;Use new CallNextHookEx; DefineHandleTable=DefineHandleTable;No 32-bit equivalent;Not required, just delete; DeviceCapabilities=DeviceCapabilities;No 32-bit equivalent;Replaee with portable DeviceCapa- bilitiesEx; DeviceM:xie=DeviCEM:xie;No 32-bit equivalent;Replace with portable DeviCEM:xieEx; DialogProc=DialogProc;Dialog proes should be defined portable;EOOL CALLBACK WhdProc(HWND hWhd, UINT uMsg, WPARAM wParam, LPARAM lParam); DirectedYield=DirectedYield;No 32-bit equivalent;; DlgDirSelect=DlgDirSelect;No 32-bit equivalent;Replace with portable DlgDirSelectEx; DlgDirSelectComboBox=DlgDirSelectCcmboBox;No 32-bit equivalent;Replaee