The future of IBM VisualAge C++ for OS/2
What is going on with IBM VisualAge C++ for OS/2? Does OS/2 really need an "official" C/C++ compiler and developer's environment from IBM? Or could it even be desirable to switch to "open source" entirely in this area??
Looking at certain IBM statements with the following discussions in different forums this question really is an issue right now. This contribution is going to explain and discuss a number of aspects of the problem; all expressed views are just mine of course and no "official statements" by whoever!
Current status
On 18-7-2000 the following article was posted to several IBM newsgroups under the title "Reminder of End of Service Dates for Compiler Products" (e.g. to ibm.software.vacpp.misc, available through news.software.ibm.com):================================
Please be reminded that the Program Services end date is January 31st,2001 for the following compiler products for OS/2 and Windows NT:- IBM VisualAge C++ for OS/2, Version 3.0
- IBM VisualAge C++ for Windows, Version 3.5
- IBM VisualAge C++ Professional for OS/2 and for Windows NT, Version 4.0
Refer to announcement letter 298-239 at this URL for the VisualAge C++ for OS/2, Version 3.0 and VisualAge C++ for Windows, Version 3.5 products.
Refer to announcement letter 298-473 at this URL for the IBM VisualAge C++ Professional for OS/2 and for Windows NT,Version 4.0 product.
Dwayne Moore VisualAge C++ Service & Support
================================ The last version (4.0) for both mentioned platforms is from 1998 and no new one is announced yet. At the same time a new version (5.0) for AIX appeared - the third supported platform -, just a couple of months ago. Also the NT version seems to be one step "further" than the OS/2 version, because it's at fixpak #2 level already (while OS/2 is at fixpak #1), but the reason is probably just Windows2000, where the old version didn't run correctly.
IBM has thus *not* officially said that VAC++ for OS/2 and NT are *not* being further developed. But neither did they issue any positive statement in that respect: It's thus allowed to go on and hope the best! Anyway, to me it seems more realistic to take an end of this product into account.
Would that mean we couldn't write any OS/2 programs any more, starting with next January? Of course not - and still the end of VAC++ would be a *real* loss for OS/2! Admittedly there are other compilers, e.g. GNU C/C"" (EMX), which is even open source! But VAC++ is more than just a compiler.In order to understand the situation, the most important parts of VAC++ have to be looked at one by one: This is the intention of the current editorial.Since not all readers here are also programmers,I am also going to characterize the different parts with a few words.
The Compiler
VAC++ brings a well optimizing, fast compiler with it. It was completely rewritten for version 4 and now supports the full ANSI-C++ standard and some "revolutionary" VAC++ specific extras: "header files" and "object files" are mostly superflous because the translated code is stored in a database called "codestore". This means that after a small change really just the affected code has to be recompiled, resulting in an enormous increase in turnaround time.
It's a pity that version 4.01 (i.e. version 4.0 with fixpak #1) with all these features isn't yet as "ripe" as the old version 3.08 (version 3.0 with fixpak #8), so many developers still prefer the old version: A fast and solid C/C++ compiler, but in turn not yet supporting all new language constructs of the ANSI-C++ standard. This is mainly a nuisance if existing code from whatever source is being recompiled for (ported to) OS/2.
So would the further development of VAC++ be stopped, we would be stuck with the choice: either "current features" (version 4.01) or "solid craftwork" (version 3.08); we couldn't expect a version that brings the two together!
In the pure compiler area there are alternatives to VAC++. The two probably most important ones are:- - GNU C/C++, with EMX by Eberhard Matthes as the best OS/2 version: For Open Source adherents sure a good choice. (The runtime library emx.dll that belongs to it is probably almost standard on most OS/2 systems.)
- Watcom C/C++, being released as Open Source also in the new future and which also brings an IDE with it (see below).
Both are (or will be) good and useable alternatives which are already used a lot.
IDE - the Developer's Environment
There is an enormous difference between version 3.0 and 4.0 in this area: They are rather two different products than just two versions. Both are quite powerful in their way, but need some "getting used to", which means they both have their strong adherents and opponents. They are both much different from other IDE's (like MS Visual-Studio or Delphi). A highlight of version 3.0 is the consequent "object orientedness", which means that it integrates nicely into the WPS and has a modular design: New tools can be integrated like the original ones can be replaced by others (You could principally go and use the EMX compiler...). The strenghts of version 4.0 are rather in the almost incredible ways to "browse" in the code of a project even if it is very complex, thanks to the "codestore" database.
Looking for alternatives to these tools is much more difficult already than finding another compiler. Those who are familiar with and like the way of working with either version 3.0 or 4.0 will see almost everything else as a "descent". Most easily "power editors" can be found in this area, even as freeware or open source, allowing besides syntax highlighting and other "goodies" also to start the compiler, debugger etc. directly. (But you will probably have to go far for a debugger like the one that comes with VAC++...).
OCL - the class library
Almost nobody writes C++ programs without making his life a lot easier by using at least one class library. This is specially true for programming graphic user interfaces like the Presentation Manager. VAC++ includes the OCL or "Open Class Library", which is rather well designed and powerful and coverss general data structures (strings, complex numbers, "containers" etc.) and all aspects of the graphical user interface. There are also uncovered areas, like e.g. internet functionality, that have to be handled with other libraries.
There are plenty of alternative class libraries, mainly in areas that are not dependent on the operating system and thus easy to port (data structures etc.). For PM programming the situation is already somewhat more difficult. The OCL is probably the class library that reflects the PM architecture in the most "natural" way, i.e. without forcing it into a Windows or Unix style paradigm. Still it offers good portability to Windows or AIX - but sorry to say not to Linux.
Another good conceptual element of the OCL is the separation of display and "event" handling (i.e. mouse clicks) of the controls in their own classes. This turns out to be much more elegant and powerful than other solutions (like the "Microsoft Foundation Classes" with their excessive use of macros). The "notification framework" (which allows that different C++ objects can send each other "messages") does not even exist in most other libraries.
So an immediate replacement of the OCL is unavailable: Porting code that uses the OCL to some other class library(s) means more or less rewriting the code from scratch. Therefor some participants of the mentioned IBM forums are asking about the possibility that IBM would release the OCL to the "open source". Even the possibility to write an own OCL clone for Linux is already being discussed. The one like the other would indeed be great things and would allow to easily write portable code for OS/2, Windows and Linux. Sorry to say that both are not more than wishes or good ideas right now...
"Visual Builder"
The "Visual Builder" (VB) is an absolutely unique tool for visual programming for which there are not even from far any alternatives. Would it be better based in the market, it would actually start the "visual age" of programming. Microsoft marketing knew very well why they gave their own IDE a name as similar as possible ("Visual C/C++" instead of "VisualAge C/C++"), but this is just a false label: The MS product contains no tool that is even in the faintest way comparable to the "Visual Builder" - but who except a few programmers will see that?
The VB doesn't only allow to place controls "visually" in dialogs, but it allows also to "draw" the logic that connects them. Also non-visual elements (e.g. lists, variables, "factories", i.e. "data producers") can be used. The diagram like sketches are then used by the VB to create C++ code which can also be completed with own code. Selfwritten and graphically generated code can interact in all possible ways, and it can also be switched between the two ways of working. The "parts" that are created that way can then be embedded in other "parts" and it is also possible to derive other "parts" from them (i.e., the concept is "object oriented").
In spite of all these highlights and it's "simplicity" many VAC++ programmers do not seem to use the VB. One important reason is probably the fact that it requires still a lot of training in order to become really productive. Specially switching back and forth between "hand coding" and "graphic coding" is not very well documented; many things you only find out by trial and error - which deters potential users, of course...
Result
If the further development of VAC++ was stopped this would actually hurt the OS/2 "community" painfully, even if there are alternatives for important parts of it (compiler, class libraries). Those seeing the future of OS/2 mainly in the "open source" area (like me for example), could even tend to welcome this loss, but this seems to me somewhat shortsighted: EMX C/C++ is sure a great compiler, but still by far no VAC++!
If now VAC++ would be stopped anyway, my greatest wish would be the release of the OCL with an "open source" license - while not having any illusions in that respect. But looking around at all the things that are being released that way recently!?!...
Of course the existing program versions can also still be used, given the fact that the user interface and the APIs have remained compatible to a high degree since OS/2 2.0 and probably will remain. Only the prospect is painful that version 4.0 would never reach the stability and relative "bug freeness" of version 3.08, which is most disturbing for a developer's tool: The developer has normally enough with tracking down the bugs and crashes the crashes in his own half- ready products ;-)
Until now a OS/2 developer could say: Even if the choice of OS/2 applications is somewhat thinned in certain areas, we still have one of the best developer's tools, if not the very best indeed! This always with one little restriction: *if* IBM would one day finish version 4.0 and get it really stable...
So the situation for VAC++ is a bit similar to the situation of OS/2 itself: No illusions, but let's hope the best!
Cornelis Bockemühl, 2000-10-01
Comments: 5
|
![[Forum]](../../../images.os2.org/en/forum.gif){kind=small}
![[Forum]](../../../images.os2.org/en/forum2.gif){kind=small}
