Unclear how to use NT and OS2 macros to differ betwen OS/2 build and Windows build

[jmalak]

I am trying to improve OpenWatcom support in Kermit source code for OS/2 and Windows.
Somewhere is used OS2 macro definition test and next NT macro definition test.
If looks like it is current to define both macros NT and OS2.
I supposed that only NT or only OS2 macro should be defined in dependency on required target platform.
It is unclear for me what these two macros means and how it is related to target build?

[davidrg]

Kermit 95 started out as OS/2 C-Kermit, so originally #ifdef OS2 really did just mean building for OS/2 rather than Unix or some other OS. In 1995, Columbia decided to do a Windows version and used OS/2 C-Kermit as the basis for that as it had terminal emulation, etc. So the meaning of OS2 changed:

• #ifdef OS2 - this now means either OS/2 or Windows, rather than OpenVMS or some other platform
• #ifdef NT - this means Win32 (Windows NT 3.1+ or Windows 9x/ME). Usually this is found inside an #ifdef OS2 though it doesn't strictly need to be as OS2 will always be defined when NT is.
• #ifdef OS2ONLY - this means OS/2 (2.0+) specifically. There isn't a whole lot of these - usually just if some entire feature is OS/2-specific (like REXX scripting until recently), or there is some special thing that needs to be done on OS/2 but not on Windows. Otherwise OS/2-specific code is often in the else branch of an #ifdef NT. There are some other #ifdefs around for dealing with 16bit vs 32bit OS/2 as well, but K95/C-Kermit hasn't been built for 16bit OS/2 in 30+ years now.

So when targeting Windows, both NT and OS2 will be defined (via -DNT and -DOS2 command line arguments to the compiler), while when targeting OS/2 only -DOS2 will be supplied and somewhere (probably ckcdeb.h), OS2ONLY will end up being defined because NT isn't.

This also extends to filenames - cko* and ckn* (and all of kui/) are specific to Kermit 95. ckn.* are Windows only (no #ifdef NT required there), while cko*.* may either be OS/2-only (mostly just some TCP/IP code), or both OS/2 and Windows.

A bunch of other files (cku*.* , ckc*.* and some others) are shared with C-Kermit for Unix, OpenVMS and other much more obscure platforms (I upstream changes semi-regularly, and mostly around release time merge in the latest C-Kermit versions of these files). So in these files any code there intending to only apply to OS/2 or Windows must be guarded with at least #ifdef OS2 and because of the many obscure and quirky (even pre-ANSI/K&R) C compilers which those files still need to be compatible with there are bunch of other portability guidelines that apply to them even inside an #ifdef OS2. Because of this you may see things like #if _MSC_VER < 1900 in cko* and ckn*, but not in ckc* and cku*.

[jmalak]

Many Thanks for all your info. Now it has more sense for me.
It looks like compilers options are for original WATCOM version, because OpenWatcom version has some change in defaults setup that some options are useless.
The K&R C syntax is little archaic, but probably necessary for OpenVMS or similar systems that I will hold it.
I tried to compile it with OpenWatcom 2.0 (it is more strict then OW 1.9) and there are many pointer mismatches for HANDLE type because on OS/2 it is long type but on Windows it is pointer that mostly NULL value is mismatch. Need to use 0 value on OS/2.
Also _beginthread/_endthread has similar issue with type of parameters.
OW supports TCP/IP on OS/2 (32-bit only) that it can be used without need of IBM TCP/IP stuff but it will require some changes in code.
Main issue is status_func function because there is calling convention and parameters mismatch masked by declaration as no parameters function. OW use special calling conventions which use registers and stack that calling depend on number and type of parameters. Probably best will be to use some structure for passing parameters to fix number of parameters.
I will try to fix most of these discrepancies and rework status_func to be more portable.

[davidrg]

When Kermit 95 was originally open-sourced, the only compiler it could be built with was, IIRC, Visual C++ 2002 or 2003 on Windows, and some version of IBM VisualAge C++ on OS/2. So there has been quite a bit of work to add in all the other 32bit Visual C++ versions, the RISC compilers, 64bit port, plus of course OpenWatcom and GCC (this page covers all the compilers I test with for targeting windows).

I'm not an OS/2 developer at all though, and I know nothing about the IBM compiler, so I just found some documentation somewhere for what the various ICC parameters mean and tried to find OpenWatcom 1.9 equivalents, though without success in most cases. I've never had any confidence they were correct at all, but it was enough to get at least something to build and run.

There are still a whole bunch of issues with targeting OS/2 with OpenWatcom though (see #8) - I assume VisualAge C++ still works (I've tried not to break it), but I don't think anyone has actually tested it since 2002. MichalN has been looking into this a bit recently - he has apparently got TCP/IP working (my makefile changes to build cko32i20.dll are hopelessly wrong which doesn't surprise me at all), and has determined why the NetBIOS code crashes ("Arguably the compiler [OpenWatcom] isn't doing things quite right"), so there might be some fixes for that stuff coming along eventually.

Separate from the OS/2 stuff, I had a go at building Kermit 95 for Windows NT on DEC Alpha with OpenWatcom 2.0 I think last year with some limited success - I think I got it to the point where the build was falling over at the link step so possibly not so far from working. IIRC I asked some questions about cross-compiling for Alpha around that time as the regular OW2.0 builds didn't include the Alpha compiler and libs.

[jmalak]

I don't think that it is necessary follow options used for IBM VisualAge C++ tools, rather need to use OW correct options to create DLL or executable and link them together. The 16-bit code (segmented code) is more specific, but you doesn't compile it anymore if I understand correctly. Take into account that OS/2 code use specific calling convention for system API it doesn't require to use it for user code that may be you can abandoned _System calling convention and use Compiler default calling convention or some to ensure binary compatibility by example cdecl. Only OS/2 API callback functions must use _System calling convention. Anyway OpenWatcom tools for Alpha, MIPS or PPC are work in progress and nobody work on them now. That it can generate wrong code or can crash. Only Intel processors are supported.

[jmalak]

@davidrg Please are there any standard for source code formatting?
It looks like original code used only spaces but now it is mixture of TABs and spaces.

[davidrg]

yeah, its a bit of a mix. I use spaces for any new code, and will sometimes convert any blocks of code I'm modifying to spaces as well if it isn't indented correctly

[davidrg]

@jmalak The changes over in #340 might be of interest if you're looking at OS/2 stuff. I'll probably merge it all in a day or three depending on what MichalN comes back with - the NetBIOS code is presenting some challenges for Open Watcom, but the TCP/IP bits seem to be working properly on OS/2 Warp 4 fix-pack 15 and newer at least. Turns out Open Watcom only includes libraries and headers for IBM TCP/IP 4.1 (MPTS 5.3+) , but the headers and libraries for IBM TCP/IP 4.0 are on the Warp 4 CD and work OK with Open Watcom. The resulting binaries don't work on Warp 4 Advanced Server but that might just be a bug in OS/2 rather than some issue with how cko32i20.dll is being built or used.