control of memory usage within an application, including incremental
   dumping of heap usage as an application runs.  ICSDEBUG knows about
   both debug memory management and DirectToSOM C++ objects.  The
   DataBuilder and VisualBuilder tools bundled with the compiler assist in
   the construction of databases and graphical user interfaces to
   applications.  LPEX, a programmable syntax colouring programmers'
   editor (yet another in the "E family" of editors from IBM) is also
   bundled.

                                == CON ==

   The price has gone up.  IBM VisualAge C++ is now the second most
   expensive of the C++ compilers listed here.  Demands enormous amounts
   of memory (16Mb of RAM is a working machine for a C++ compilation.  The
   side of the box recommends 32Mb!  VisualBuilder and the C++ compiler
   aren't happy side by side on the same box in less than 40Mb!).  The
   memory resident feature will impact the swapfile heavily on low-memory
   machines, and is thus rendered virtually useless for them.  Requires a
   device driver in CONFIG.SYS for the execution profiler.  No
   cross-platform compatibility (CSet for AS/400 and PowerPC are "coming",
   but are due late 1995).  POSIX.1 is poorly and badly supported.  There
   is no runtime library support for 16-bit development (so device drivers
   are out here too).  Those used to compilers with command lines
   influenced by UNIX (such as all of the others listed here), will find
   the compiler command line options counter-intuitive; they certainly
   aren't mnemonic at all.  Library files now use a proprietary format
   rather than the Intel OMF library format used by all of the other
   commercial compilers listed here, meaning that they cannot be used with
   either other compilers or previous versions of IBM CSet++.  Many bugs
   in the frozen code for version 3.00 mean that obtaining the 3.01 CSD is
   recommended (the new headers supplied with IBM VisualAge C++ 3.00
   generate several compiler warnings that weren't in IBM CSet++ 2.xx, for
   example, and there are still problems with precompiled headers).  The
   runtime library DLL is certainly *not* upwardsly compatible with IBM
   CSet++ 2.xx, as some function names have changed.  There are several
   errors in the DirectToSOM C++ facility, such as incorrectly declaring
   acessor methods as "virtual", and no facility to automatically call
   "XNewClass" in dynamically located DLLs. DTS C++ does not support
   Distributed SOM.  Combining DTS C++ with the object browser or
   precompiled headers causes the compiler to crash.


    Z=================4 EMX C++ 0.9a for Intel OS/2 C================?
    3                                                                3[
    3  [ ] OS/2 Developer's Toolkit (*NOTE*) [ ] IDE         (*NOTE*)3[
    3  [ ] PM Class libraries                [ ] Workframe   (*NOTE*)3[
    3  [-] Ships on CD-ROM          (*NOTE*) [ ] SOM support         3[
    3  [ ] DirectToSOM C++                                           3[
    3  [ ] Intel 586 FDIV workaround                                 3[
    3                                                                3[
    3 No FIDONET address.                                            3[
    3 Try mattes{at}azu.informatik.uni-stuttgart.de .                   3[
    3                                                                3[
    3 EMX C++ is distributed as "free" software.                     3[
    {at}================================================================Y[
     __________________________________________________________________

                               == NOTES ==

   EMX C++ is not a commercial compiler, being distributed as "freeware"
   under terms similar to those of the Free Software Foundation.  It's
   "ethos" is completely different to commercial compilers.  You have to
   hunt for EMX.  Most file sites are not always up to date, or carry the
   complete distribution.  One of the CD-ROMs of the Hobbes OS/2 FTP site
   comes with EMX pre-installed (the other does not).  Unfortunately,
   there is no author-supported site from which EMX can be File Requested
   or downloaded.  The author only distributes via FTP from
   ftp.uni-stuttgart.de.  Buying the OS/2 Developers' Toolkit is highly
   recommended for PM work, since it includes PM documentation, which EMX
   C++ lacks.  The lack of an IDE or Workframe support are deliberate
   omissions on the part of the author.  The EMX ethos is to use the
   command line, or the author's port of the emacs text editor.

                                == PRO ==

   Free (it's essentially the GNU compiler "rebadged").  Will develop OS/2
   and extended DOS applications from the same source.  The compiler
   itself is a port of GCC ("EMX" derives from the name of the DOS
   extender).  Because of its roots, it has exceptional support for
   POSIX.1, even including stuff that doesn't actually fit the OS/2 model,
   such as fork() and .  Lots of UNIX libraries should be easily
   portable to OS/2 using EMX C++, and many have been.  Fair optimiser.
   Can call 16-bit code.  Full source to all libraries is available.  Full
   source for the compiler itself is available.  The run-time library DLL
   is (upwardly) compatible between applications written with different
   versions of the compiler.

                                == CON ==

   Free (you get what you pay for, including the support).  The FSF and
   the EMX author's "Copyleft" have some minor impact on commercial code.
   Installation of the whole compiler is not a trivial task, since it
   comes in lots of little bits and pieces.  You are expected to be able
   to obtain and install all of the necessary tools which EMX C++ relies
   upon (such as TeX and emacs), for which you also have to hunt (they
   aren't distributed with it).  No 586 support.  No support for
   generating 16-bit callable code (which rules out device drivers).
   Calling 16-bit code requires "hand thunking" using a set of supplied
   macros.  Development tools are as horrible as the UNIX originals, and
   are strictly command-line based.  Tools frequently default to UNIX, not
   Intel/PC, standards and conventions, especially filename, object
   module, executable file, and command-line conventions (working from
   OS/2 programming reference books with EMX C++ is a challenge not
   recommended to the novice).  "Native" EMX programs (i.e. those where
   you don't specifically request Intel/PC compatibility in the
   compile/link stages) all contain a stub to load the embedded UNIX
   translation layer at run-time, which makes application loading
   noticably slower.  No PM or OS/2 support tools (help compiler, dialogue
   editor, message file generator, pack generator, et al.) are supplied.
   The supplied OS/2 header files generate spurious compiler warnings for
   legal code due to incorrectly defined constants, and use the wrong
   definitions (char/unsigned char mismatch) for some types.  The DOS
   extender supplied (EMX.EXE) doesn't work under OS/2 because it uses
   VCPI (another "EMX compatible" DOS extender using DPMI is available,
   but it is yet another extra thing not bundled with the compiler that
   you have to go hunting for, and you then have to adjust everything to
   use it).  No printed manuals at all.  Some manuals are available in INF
   format, but this doesn't include the all-important compiler manuals.
   All of the GCC documentation is in TeX format, and not plain ASCII,
   requiring that you have TeX (or yet another non-bundled conversion
   tool) in order to make it legible.  No OS/2 API documentation at all.


   / JdeBP .          / (c) Copyright 1993-1996 All Rights Reserved. .
   / FIDONET 2:440/4.0                      JdeBP{at}donor2.demon.co.uk .

... Another excellent OS/2 day goes by.

--- Blue Wave/OS2 v2.20 [NR]