Products and Resources for VisualAge (click here)Remote control any PC from any platform in the world!
Tools First - by Chris Wenham
OS/2 e-Zine!

Go to a Printer Friendly version of this page

Chris Wenham is the Editor-In-Chief of OS/2 e-Zine! -- a promotion from Senior Editor which means he now takes all the blame.

Related Articles
Converging Outside
Stupid Users
Beat the Fat Cats
Cutting the Cake
Egg-In-Face Awards
Wool over mine eyes
The Truth?
Side Effects

Lash Back! - Join in the ongoing public discussion with our interactive forum. Be frank, be vicious, you can even be anonymous.

- or -

Blast Back! Send a private message directly to Chris Wenham with your thoughts:

Contact OS/2 e-Zine!

Sponsored links:
The OS/2 Supersite

Summary: It's the tools that make it possible to build the latest and greatest, not just brute willpower to write code. Chris Wenham explains why it'd be more productive to develop or ask for better tools than it would be to beg for more applications.

The creation of the fastest, biggest, cheapest cargo and passenger carrying aircraft was made possible only because of the invention of the lightest, strongest, cheapest materials to build them out of. They were also only possible because of the invention of the ultra-precise measuring tools, cutting tools, drilling tools and calibrating tools that could make a jet turbine that wouldn't vibrate itself to pieces at high speed. The better the tools and materials got, the better the aircraft was.

Or car.

Or computer.

Or application.

Even though the programs we use today are hideously complex, they still take about the same amount of time to create as the simpler and cruder ones of the mid 80's did. The only reason these games and programs are better now is because of better materials to make them from (platform, programming libraries, languages and APIs) and better tools to make them with (Editors, compilers, debuggers, IDEs and so-forth). And if you've noticed that faster chips and cheaper memory hasn't resulted in faster programs yet, it's because the pace of complexity is keeping up with Moore's law like a pilot fish keeping up with a shark.

The maturity of software is evidenced by how little of a program's bulk is actually written by the developer who puts his name on it. You can write 4K worth of code and after compiling have an executable that's 400K in size and wields ten times that much weight in Dynamic Link Libraries. Way back with C, the job of reading and writing to the console was solved after typing #include stdio.h, now you can add commodity items like an e-mail sender and web browser with as much effort too.

But where are the new tools and materials for OS/2? Where are the newest libraries? Where are the better IDEs? Where are the faster debuggers and the chrome-laden GUI builders?

As Robert Basler laments in his new game programming column that starts this month, many APIs and libraries used to build games are languishing in OS/2. The development of fullscreen DIVE has died and OpenGL's appeal is limited by the lack of drivers that could make it worthwhile in OS/2.

In one of my last conversations with Joel Krautheim of SPG, he said that one of the reasons he couldn't keep up the OS/2 version of ColorWorks was because there were no equivalents of the programming libraries he was using in Windows. Version 3 of the painting tool was able to crawl a web site and retrieve every embedded image in it, but to do that he made use of a pre-packaged library of FTP and HTTP routines. Understand that the availability of this package invented the feature for him, not the other way around. Joel's only contribution was finding a sensible way of marrying the feature with his product. Without an equivalent of the library for OS/2, there was no feature*.

This fact has not quite dawned on those who see no reason why every Windows application shouldn't be ported to OS/2 Right Away. If the libraries aren't there then the authors of the programs must write them from scratch, if they must write them from scratch then the port is going to be more expensive to produce, and if it's going to be more expensive to produce then they'll either have to charge more or expect to sell more copies. Think they can expect that?

And we almost forgot tools. If the application was written with the help of an integrated editing and debugging environment (an IDE), is that also available on OS/2? If it isn't, is the the developer expected to work with un-integrated editors and debuggers and compilers, or learn a different vendor's tool?

It would pay off, then, not to chase after application developers with pitiful whines and instead look for the attention of the tools developers and the library developers instead. If the tools are making rapid development of complex programs possible and the pre-packaged function libraries are making new features obvious, we ought to get these hauled over to OS/2 first. It may be, then, that we won't need to ask for ports of Windows programs.

It'll be Windows users asking for ports of OS/2 programs.

* - Ironically, this has caused opposite results as well. Embellish, a competitor to ColorWorks, grew out of a program called J View Pro. Among the best features of J View was a programming interface that let you control the program with Rexx, but it was dropped from Embellish. Why? Embellish was written so it could be developed in parallel on Windows and OS/2, and there was no Rexx interpreter built into Windows. So to keep feature parity in both directions Dadaware removed the feature entirely.

* * *

I propose that we give the tools developers a bigger boost than we're giving the application developers. Call it the software equivalent of "pump priming." But still stuck with the idea of trickle-down economics? Hash it out in our interactive forum. Selected feedback will be posted below.

Copyright © 1999 - Falcon Networking ISSN 1203-5696
May 1, 1999