EDITORIAL

What? Me Worry About Windows Programming?

Michael Floyd

Fenestracryptophobia: The fear of Windows programming. Symptoms range from mild headaches to outright disorientation and confusion. In worst cases, suffering programmers find it difficult to manage even simple events such as opening a window.

To truly understand the above-described phobia you have to place yourself in the afflicted programmer's development environment. For starters, Windows 3.0 programmers must face some 578 API function calls. With enhancements come new API functions; Windows 3.1 is expected to bring the total up to 771 calls. Add to this 197 multimedia extensions and 78 for pen functions and you're staring down the barrel of 1,046 API calls. It's no wonder tools such as Asymetrix's ToolBook and visual programming environments like Visual Basic are attracting so much attention.

Indeed, visual programming tools are the current prescription for ailing programmers. But one problem I see with visual programming is that it favors the look of an application over its functionality -- the visual programming GUI tail, in effect, is wagging the dog. Furthermore, visual languages that necessarily support the environment are likely to forego other language features that programmers might expect. "No problem!" the quick to answer might say, "Just design the interface and call a DLL written in your favorite language." Unfortunately, this approach does not, for instance, alleviate the need to make calls to the GDI to draw graphics or to support DDE.

Windows 3.1 promises relief for some of these programmer phobias while, at the same time, introducing significant enhancements. One big change is the introduction of the Dynamic Data Exchange Management Library (DDEML) which, according to Microsoft, simplifies DDE message passing while standardizing the DDE protocol. DDEML provides a set of functions (26 in all) that insulate you from the gory details of client/server conversations, transaction handling, memory management, and the like. This is good news to new and seasoned fenestracryptographers because both approaches work. If you're new to Windows or just tired of hacking DDE code, go with DDEML. If you've already made the investment, the old message-based DDE is still there.

And then there's Object Linking and Embedding (OLE) which allows you to create a document (called a compound document) consisting of embedded objects. These embedded objects can be linked to and managed by applications. Thus, the document takes center stage and multiple apps can do what they do best. But what's good for the user -- via 64 new functions -- isn't fun for the programmer. Consider too that you should at least entertain the ideas of making applications TrueType-aware, Pen-aware, adding support for Drag and Drop, preparing your code for 32-bit Windows, and ...I feel another fenestracryptophobia attack coming on!

The complexity of GUIs is the very reason why application frameworks are important. As you might expect, Microsoft has announced application framework to support rapid UI development that will provide a basic set of "foundation" classes that lay on top of Windows while specific UI classes will provide the interface to the application. Most notable is that the "open" design allows for third party classes at the UI level.

If you've already invested in Borland's Object Windows Library (OWL), don't panic just yet. Borland earlier this year submitted its specification for OWL to the Object Management Group (OMG). OWL is a library of reusable objects (or classes) that allow you to build the UI components of an application. More importantly, OWL is language independent. Object Windows is already available with Actor, Turbo Pascal for Windows, and Borland C++. And although it's specific to Windows, it is hoped that OWL will evolve to a platform-independent framework under the guidance of the OMG.

With Microsoft looking ahead to 32-bit Windows and Windows NT, there's little doubt that fenestracryptophobia will spread. A standard application framework that is both language- and platform-independent may help, but new innovations, dissimilar environments, and different hardware make a sure cure unlikely.


Copyright © 1991, Dr. Dobb's Journal