Gcc 32 bits portability

With the support of Gcc 32 bits, we have to take some good reflex to create a source file available for compiler which use integer ('int') with a size of 16 bits such as Pure C and Sozobon or compiler which use integer with a size of 32 bits. The first problem comes from GEM. GEM are coded with 16 bits integer and function binding use short integer. For that raison all GEM library for Gcc work with short integer (GemLib for example) or INT16 integer (MGemLib for example). INT16 is an 'int' for Pure C and a 'short' for Gcc. WinDom Functions addressed are mainly WindGet() and FrameGet().

So the first rule is :

use INT16 (defined by WinDom or MGemLib) when you use AES, VDI and WinDom functions. Look at the new WinDom specifications.

The second problem comes with the way which parameters are transmitted to a function : in 32-bit mode, each parameter - even short integer - use a size of 32 bits. When you use functions, such as ApplWrite() and WindSet(), it is not possible to deal directly with pointer type due to the previous reason. Such as parameter should be encapsuled by a ADR() macro function (defined in WINDOM.H). In order to prevent these problems during compilation, prototype of WindSet() and ApplWrite() have changed for respectively 4 and 5 integer instead of variable arguments prototype if you use gcc with long integer. For other case, the old variable argument prototype has been kept.

So the second rule is :

With ApplWrite(), use ADR() macros function which pointer parameter. With WindSet() use WindSetStr() or WindSetPtr() macros for modes addressing pointer parameters (e.g. WF_TITLE, WF_MENU, ...).