The XCOMP/2 (WIN32 port) home page

XCOMP/2 on WIN32

As far as I can tell, XComp/2 for WIN32 should behave the same between OS/2 and WIN32, though due to the different APIs there, there might be incompatibilities I'm certainly interested in hearing about.

I did the port under NT4 SP5, and though I was using the oldest version of the APIs that should be available under WIN9x too, there is no guarantee that XComp/2 will really work there. As always, Microsoft's inflation of APIs for different versions of Windows is a hell, and shows that due to their monopoly they can force what they want, and whatever they do looks shortsighted!

Porting to WIN32

Because I was in a masochisitic mood, I started to port the OS/2 code to the WIN32 platform (done under NT4, but I would not know why the port shouldn't work under the gaming OS's WIN95 and above too). After about 12 hours or so (without having done anything specific for the WIN32 API before) the horror was over and the port seems to be working.

As I almost expected, it really was some kind of horror adventure even though I also used IBM's VisualAge C++ compiler so that at least the non-OS/2 C++ stuff shouldn't cause headaches. Anyway, after that experience I am reconfirmed that it is a pleasure to develop under OS/2 compared to WIN32, because:

• The MS SDK (admittedly the one included in IBM's compiler is definitely dated now, the documentation you can download from MS directly is much better, though I don't know how well it is usable with IBM's compiler) is horrible compared to the OS/2 Warp toolkit:
  • The contents of the single 20 MB sized Windows Helpfile are a bad joke, it is incomplete, messed up, a mentally-ill hierachical structure, usually non-helpful and a plague to read.
  • Searching the help is a bad joke at best, unless you exactly know what you're looking for.
  • Even if you found something, you have to wonder what parameters are used as input and output.
  • Many help hyperlinks just point into the woods.
  • The C include files seem to have been written in a non-consistent style, searching there instead of the help file is also troublesome.
  • I may not have figured out it correctly, but just using #include <windows.h> instead of including only the header files needed by using #define INCL_* as under OS/2, slows down compilition enormously as the C-preprocessor has to look through myriads of headerfiles.
• The debugger included with VisualAge C++ looks similar to OS/2's IPMD, ICSDEBUG and IDEBUG but:
  • Does not work unter W2K, for W2K one can download freely from IBM the IDEBUG debugger (thanks), which is a remote debugger (thus allowing you to debug not just locally, but also remotely over a TCP/IP network), but has a relatively slow (on a 866 MHz PIII) JAVA frontend that admittedly looks quite magnificent, but clearly lacks the flexibility of the older native debugger (e.g. to freely position and overlap all windows) thus once you need to look at more than 4 things you'll get crazy.
  • The IDEBUG debugger comes as a 60MB bloatware download, sucking up to 240MB (!) on your disk.
  • I'm not sure if it is related to Windows or just to the Debugger, but when using the default settings it won't catch access violations and just ends the failing application. By requesting it to watch for access violations, it stops at various points even in a working program. I could explain that by Windows demand-loading pages that way, but even if it's not that silly as it looks like, it's damned useless for debugging.
  • I have to admit though, that it did not crash (as the OS/2 version sometimes does) and even if it did, it easily can be closed from Task Manager.
  • Also, but that's a consequence that NT has multiple input queues in contrast to OS/2's single input queue, it does not lock up the desktop even when debugging GUI programs.
• The WIN32 API:
  • Similar to the header files, it's non-consistent. For some APIs one can rely that the value returned tells if the call was ok or has failed, more often one has to explicitely ask for the error code by GetLastError(), which returns the last error even if it was set by a call long before (thus, one has to use SetLastError() to avoid that and bloat the code). Unless you get used of that you hunt down phantom errors excessively.
  • The APIs themselfes are difficult to oversee, as there is no hint where they come from. In contrast under OS/2 where e.g. the base API is prefixed by Dos or the GUI API by Win, which makes is much more logical to read and understand.
  • Of course, it's heavily non-consistent that some APIs return the result in the result code while others return it via a (pointer to the passed) parameter.
• The IBM VisualAge C++ 3.6 FP2 compiler:
  • The main advantage is that it is quite compatible with the OS/2 version, so you can concentrate on the program not the environment itself.
  • The debugger is still the best I've seen under Windows, unfortunately IBM messed that up too, because their latest Windows debugger (using a JAVA frontend) is a real Microsoft look-alike application, a much nicer GUI but having an idiotic when it comes to a real productive use.
  • I can't be installed on anything later than NT (while using an installed setup will still work except the debugger as I said above). Unfortunately, IBM gave up in the C/C++ compiler market (ok, not completely, AIX is the last platform supported, probably because they don't get kicked out by the MS marketing machine there, but as IBM no longer likes OS/2 and they saw they don't have a chance on MS's homeland they left the Intel platform completely).
• Finally, the editor:
  • Under OS/2 I use EPM and I haven't yet seen anything better on any platform, using WRITE or WORDPAD can only be a temporary solution as without linenumber information one is lost when programming.

Well, meanwhile I had the chance to play a little with MS VisualStudio C++ 6, and of course some observations:

• It's a IDE (Integrated Development Environment) in the deepest sense of it's word, I yet have to see if there is a way to run the compiler from a commandline.
• While I admit this environment seems powerful enough to do all programming project one might think of in the IDE, it has a bad habit to write lots of proprietary files and lots of directories. E.g. even for a simple "Hello World!" you get multiple files beside the main C file, be it one for precompiled headers, be it for a class browser, be it what only the devil knows. And it also creates multiple directories for building a debug and an optimized version.
• The GUI looks nice, but it's always the same with such Mickey Soft applications, real productive use is hard. Take e.g. the debugger (which is similar to IBM's latest JAVA based incarnation of its debugger), it is simply uncapable of displaying lots of variable monitor, be it because that window can't be detached from the integrated environment to be sized to any size more usuable, be it that the nice layout takes so much space on the screen that there is not much space left to display the variable monitor.

Results

Once again, it's clearly to demonstrate that OS/2 is the superior platform and one gets only even more disappointed that IBM lost interest to compete with that inferior monopolistic evil empire (it won't bring back OS/2, but one can at least hope that switching to Windows makes things much more expensive, unreliable and insecure, so we got at least something to laugh about).

I haven't really looked into LINUX programming, but have bought the book Linux Application Development because it was heavily recommended everywhere. After reading it I really was very disappointed (or maybe I did not understand what this book was written for), because it did spent a lot of time talking about terminals and so, but not or just on the surface talking about queues, semaphores, multithreading, ... all the stuff needed to make good programs :-(.

The SYS executable

During XComp/2 porting on WIN32 I had to struggle with API return codes as many APIs provide the same as OS/2 (even the macro reads the same) while others provide different (it seems to me that OS/2 has a finer resolution when providing error codes) return codes. As translating the return codes into something one can find out its cause, I have written Sys.c which returns the text corresponding to the return code (as the MS SDK help proved helpless and the header files are too incomplete again).

By the way, this utility can also be helpful when XComp/2 does complain and show error codes during comparison to find out the cause (e.g. XComp/2 will just tell SYS32 when you try to compare PAGEFILE.SYS, because the Windows swapper is locked by the system as SYS 32 will tell you).

Accessing XComp/2 for WIN32

The port XComp/2 to windows is part of the XComp/2 source code archive, both for the modified source code and the exectuable itself.

Note: You have to have access to an OS/2 PC to decrypt the encrypted source code archive, because I provide the decryption executable only for OS/2. These tools are for OS/2 users who are forced to used Windows sometimes, but not for users that uncritically help to extend the power of the evil's empire monopoly!