VOICE Home Page: http://www.os2voice.org
|
VOICE Home Page: http://www.os2voice.org |
September 2003 |
| By Christian Langanke © September 2003 |
It has been about twelve years since I started programming for OS/2. Meanwhile my homepage is populated with some quite nifty helper programs and more are yet to come, as there are still more I haven't released. Furthermore, netlabs.org is meanwhile hosting CVS source trees of three larger projects; two of which I invented and one I co-invented. netlabs.org is able to run in nearly automated fashion, all the hosted source archives with the aid of my Netlabs Open Source Archive Administrator package. It hHides the complexity of CVS behind a set of easy to use REXX scripts, among other features allowing easy setup of new archives, easy maintenance of archives as well as automated backup. The Internet Assistant for OS/2 an eComStation, currently my largest project, is included in the current eComStation V1.1.
I can say that I have coded a lot for OS/2 and organized a lot for the development of free OS/2 software. But what remains for me after a decade of programming in the spare-time? What were the reasons for me to start and stick with programming OS/2 and now eComStation?
Very similar questions have quite often been posed to end-users, but what about the developer's perspective? Where can I - as an example of an OS/2 and eComStation freeware developer - head for today? Do I have everything available to keep on programming and debugging my projects? And why could such questions be of interest for end users anyway?
These are the questions to which this article will try to give some answers, many of course only from my very subjective standpoint. Now you may ask why I intend to publish that via a medium in which one would expect to be read by end-users for the most part. The answer is that I recently got the impression that end users could well use an insight into the developer's sphere, learning about how things go or don't go well there. And this will possibly also make obvious that this concerns the end-user as well, if not for programming techniques and questions, then at least for the kind, the quality, and the amount of applications which are produced by programmers for their platform. Indeed there are, of course, specific reasons for the existing number of freeware/shareware applications for a given platform, and this writing may reveal some of them to you. At the same time this article may also give some things to think about for programmers or those, who want to become programmers.
Of course I intend to speak not too much from a technical point of view, but rather from an abstract one, so there is enough to read on for everybody, not only for programmers. Usage of some abbreviations are a must though to stay precise, if you don't understand some of it, you are very welcome to ask via email. I'd be glad to explain further.
Once OS/2 attracted me with a beautiful API and magnificent programming concepts, and that is still the case. But what is left of the perspective of recent years? And where could I head to for new challenges and progamming fun?
So what do I need for kind of serious programming? To make obvious what I mean: it is about C/C++ and possibly also Pascal programming, although in the following only C/C++ compilers are covered. There are some compilers for other languages as well, but they are seldom used and thus not discussed here. Also I certainly don't count REXX and other script languages within this category, although I am a great lover of REXX. But script languages like REXX are intended for creating extensions for "real" applications, where these extensions could even be created by experienced end-users. If you still cannot imagine of what I mean: you will never see an Apache web server or a Mozilla web browser in REXX, for obvious reasons...
Well, for just doing some nice OS/2 programs in our days, you do not need much, just a compiler and the Developers Toolkit for OS/2. Gone are the days of the very first OS/2 release, where Microsoft wanted to sell the Developers Toolkit for OS/2 for around $2,500. Today it is available freely. Concerning compilers, there are good alternatives to the still existing IBM compilers. The alternatives become even more and more important, as the IBM compilers are not available any longer (for several years now) and no longer maintained or supported. Nevertheless some OS/2 related projects still use them, as some features of them are still unmatched by the alternatives.
As an important alternative though, first of all, the OS/2 port of the free GNU compiler has existed for a long time. It is especially important when it comes to create OS/2 ports of Linux programs. But unfortunately, the GNU compiler is missing some important features, for example and first among them is a real good debugger, which limits the usefulness of this compiler to some extent, especially for larger projects. Second, the Open Watcom compiler is certainly to be mentioned, which still could use some facelifting, but after all, together with the GNU compiler is a C/C++ compiler for OS/2 that is still somewhat under development. Let's hope that both compilers do evolve very well for the OS/2 and eComStation platform in the future, as we will see below that this point becomes more and more important.
As an end-user you may ask yourself why this is interesting for you. Well, the compiler is as important for programmers as the Office Suite for an end user. Concerning companies using OS/2, I have seen more than one company going away from OS/2, not because there were too little end-user applications, but because there were little or no suitable compilers, project management utilities, problem tracker software and so forth for their inhouse development.
The very same applies to the freeware and shareware developers community. To bring it to the point for everybody: if there is no compiler for OS/2 available anymore, which is capable of compiling source code of large projects with up-to-date language constructs, there will be no more versions of OS/2 programs, even of those that you may have already gotten used to.
Let me name just two examples. The very last OS/2 version of StarOffice was V5.1, after that the OS/2 line was ended. The first reason given was because of problems/bugs with the IBM Visual Age Compiler V4, being said to be badly supported at that time. The second reason was that a switch to the free GNU compiler was impossible because of the missing debugger, which is indeed necessary when trying to find bugs in such a huge application.
In the end the only choice left for the end-user is to either stick to the old V5.1 for OS/2 (what I do) or to use OpenOffice V6.0 under Virtual PC. The fact that printing is currently not possible under Odin, excludes this very obvious option.
Another good example is Mozilla. No, don't panic, the OS/2 port is not ended, but according to Mike Kaply, the owner of the OS/2 port, newer versions of Mozilla for OS/2 are not longer compiled with the IBM Visual Age Compiler (you remember this has been unsupported for several years!). They intend to switch to the GNU compiler instead.
But isn't that a bit surprising? I would be greatly interested to learn how the developers of Mozilla for OS/2 solved the debugger problem, as I expect that also for the maintainance of the Mozilla port a working debugger is mandatory. I remember I heard some rumours that somebody once had a solution to debug programs compiled with the GNU compiler with the still quite good debugger of the Visual Age compiler, although this normally is not possible due to incompatibilities between the compilers. And that already at a time when development of StarOffice for OS/2 was stopped because there would be no available option to debug programs compiled by the GNU compiler...
Conclusion: A big current threat to the OS/2 and eComStation platform is indeed that at some point in the (near?) future it won't be that much of a problem that software vendors and freeware/shareware developers may just leave the OS/2 and eComStation platform, but rather that those who are even willing to stay cannot any longer, just because of missing basic (!) development tools, which just work. Already now, or better already for some time now, developers and maintainers of large software projects for OS/2 and eComStation have been facing massive problems, which can hardly be solved.
Having nice technologies and concepts available is not the only source of motivation for programmers, especially for those who code programs for free, but it still an important one. Such coding must be fun or it will likely not take place. And even though a concept and a tool is only as good as the person using it, nevertheless good concepts are really the base for creation of good and easy-to-use user interfaces. If a concept or tool is not good enough, the task of creating a well-designed user interface likely costs much more in effort and will less likely be brought to a good end. So even programming interfaces are a topic which indirectly is also important for the end-user, as the better the offered programming concepts are, the more likely there will be applications available with a consistent user interface across all applications, as well as the desktop itself.
A good example, where a consistent user interface with same look and feel is not present across all applications, is Linux. As just one example, an application written in Tcl and using the TclTk script engine looks and behaves significantly different in usage compared to an application for example using the QtLib. If you compare that situation with dozens of user interfaces with a different look-and-feel under Linux with the situation under OS/2 and eComStation, where such differences only very rarely exist, it becomes clear what safe places OS/2 and eComStation are in terms of a consistent user interface.
But let me come back to where I started with OS/2 programming and learned to like the programming interfaces of OS/2. I well remember myself coding my very first programs for the OS/2 Presentation Manager. Soon afterwards this annoying "OS/2 is dead" discussion started, which gave me reason to have an insight into the chaos of the several Win32 APIs (Were there four or five different APIs?). This made me shiver...
I was so glad that there was a clearly structured OS/2 API that I could stick to - you would peek into an applications source code of somebody else and could tell in a second, even as a newbie without deep knowledge of all operating system function names, which function calls were handled by the operating system or graphic subsystem, and which were obviously part of the application itself. All that is simply possible because function names of the OS/2 API are always prepended by a three letter prefix. When at the contrary I had a look into Win32 source code, where the API does not follow such rules, I needed either to explicity know that a given function is one of the operating system, or I would have to search within the online help first - in one word: nightmare. In fact the only part of the Windows API that had been well-structured was the 16-bit API from OS/2, that Microsoft kept until and including Windows NT for their OS/2 fullscreen textmode Lan-Manager applications...
But the milestone for operating systems and the big winning point on the side of OS/2 was and is the Workplace Shell, being introduced first with OS/2 V2.0. This outstanding piece of software won an award for the best software (Was it in '92 or '93?) and is still claimed by many to be the most innovative and intuitive user interface available in the operating system market. Two years later I started trying to code some Workplace Shell classes, which resulted in my release of the quite well-known Workplace Shell extension in 1997, the "Animated Mouse Pointer for OS/2".
This package was somewhat special, as for the end-user this was just more fun with OS/2, but for me as a programmer it was of much more interest. Many end-users do not know that the Workplace Shell also has a brilliant programming interface, as under its covers it is a true object oriented class library. No, I won't go into t much detail what that means, only this: thanks to that wonderful programming interface I was able to simply replace the mouse pointers page in the mouse object with my own page, providing the animation as a completely new feature to the end-user, without requiring to recode the whole mouse object or requiring to modify original source code (which would not have been possible anyway...).
But beyond the new functionality, what was the benefit for the end-user? It was and still is that the revamped mouse object can be used just like the old one to the very last extent, so there would be no confusion with a modified user interface at all. The new pointer page even looks very much like the old one, with the exception of one literal within the dialog. Nevertheless it offers completely new functionality at the same time, not only animation, but also drag'n'drop and context menus for the mouse pointer container on that page.
The nicest comment on that package, on which IMHO every programmer of a Workplace Shell extension can be proud of, was: "If I didn't now it was an extra package, I would have thought it was part of OS/2 Warp itself". I'd say no integration can be much better and while I owe a big part of the compliment to the beautiful programming interface of the Workplace Shell itself, and this ability for elegant and seamless integration of new functionality certainly is what I like most.
Beside being a fun program, this package was also a proof of concept for me, and I hoped it was the same for the whole OS/2 developers' freeware and shareware community, as I had reason enough to feel like a pioneer in Workplace Shell programming in these days. After all, in 1997 my Mouse Pointer extension was the first larger, but yet non-commercial Workplace Shell Extension package available, at the same time with the tightest integration of new functionality into the existing desktop interface, full-blown online help and configuration via settings strings. I hoped very much that more programmers would jump on the bandwagon and code directly for the Workplace Shell.
Soon others followed, and some time later the XFolder package from Ulrich Möller appeared, meanwhile having grown to the outstanding and well-known XWorpklace package, including countless great features. This package truly defines a new level, if not a new standard of usability for the Workplace Shell under OS/2 and eComStation, making itself one of the most important pieces of software for this platform. As a logical consequence a simplified version, called eWorkplace, is an integral part of eComStation V1.1, (but it can be replaced by the full XWorkplace version without a problem).
So you may understand the enthusiasm I had in those days. And I think the reasons for being enthusiastic about the Workplace Shell as a user interface as well as its programming interface have not decreased in importance at all. But as always there is more than one side of the coin.
One could say now: "The Workplace Shell is looking rather old now, compared to newest user interfaces of other platforms." Not true, I would respond, as there is a theme support available under eComStation as well, so that you could just as well make it multi- if not overcolored, just like the other desktops around.
Fine. An end-user will buy that or not, depending on his/her own taste and other reasons. But again, what about the programmer? The Workplace Shell is yet another part of OS/2 that is no longer worked on or even the bugs fixed by the vendor. And there is more than one glitch in the implementation that an end-user never will notice, but Workplace Shell programmers will have to work around again and again. But while all that is true, I am pretty sure that the potential of the Workplace Shell and directly programming for it has not been fully exploited yet by far, despite any limitation that may arise out of some nasty unfixed bugs and partly strange design.
The reason for my opinion is that while the Workplace Shell is not perfect, I can still create extensions for it. While it is not further developed, I can still create extensions for it. While it is no longer bug-fixed, I can still create extensions for it. While XWorkplace may have reached some limits of implementation, arising out of the unfortunately partly strange, if not buggy design of the Workplace Shell behind its programming interface, XWorkplace still can be used with the features that it offers today, and there is no reason why new features could not be added at all. Yes, there may be limits, but I doubt they will affect us very much, if programmers concentrate more on the things that still are possible, and that still seems to be a lot.
But is that the only question that we need to ask? Remember, coding must be fun for the programmer, being an important source of motivation. So it is a decision of every programmer if he or she is willing to stick with Workplace Shell programming despite of its limitations. All I can say is that it is really fun experiencing the beauty of the concept, and meanwhile there is enough expertise available in the developers' community to work around some problems that may arise.
So I personally will stick with the Workplace Shell, both as an end-user and as a programmer, and would certainly miss its concepts and interfaces under any other platform. But the Workplace Shell is not the only technology to think about. What about the other technologies that we find in OS/2 and now eComStation? How do they fit into the puzzle? These and more questions will be covered in the second part of this article.
References:
|
[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org