MADACON Madness

Steve Mann

The conference title was almost as long as the opening address-Microsoft Windows™ Programming Conference for Macintosh® Developers. Just to make it easier to reference, I'll shorten it to a convenient TLA-WPC (Windows Programming Conference). When the people at Microsoft decide to do something, they usually do an excellent job. WPC was no exception. There was one lame presentation, there was very little marketing dreck (even their marketing speakers are pretty technical), there was good food, and there was humor (thanks to James Plamondon, MADA's own standup comic and creator of this conference). And there was lots of meaty detail.

Microsoft has decided to target Macintosh programmers as a market niche (as if the first 45,000 people who bought the Windows System Development Kit were not enough). WPC focused on three areas: programming in Windows, porting strategies, and how Windows is similar to and differs from the Macintosh. There was also a session by Apple and Symantec about Apple's cross-platform strategies (more about that later), and a spiffy presentation by the Microsoft Developer Network. The overall impression that I came away with was this-Microsoft has a very good idea of what it's doing and where it's going (and they have the resources and savvy to deliver). Oh, and Windows looks like a good development environment.

Programming in Windows

James P. delivered the bulk of the detailed programming sessions, acting as a translator between Mac and Windows concepts and vocabulary. Overall, Windows has many similarities to the Mac. There is a large complex API, lots of documentation to wade through (much of it obsolete), resources, event handling, multitasking, and so on. C is the preferred programming language.

Microsoft has a tough time clarifying all the different versions of Windows currently out there. I'll give it a try (note: the first three versions run on top of MS-DOS):

• Windows 3.0 - 16-bit addressing, rapidly becoming obsolete.
• Windows 3.1 - TrueType, OLE (more about this later), multimedia, performance improvements.
• Windows for Workgroups 3.1 - peer-to-peer networking and bundled workgroup applications.
• Windows NT (New Technology) 3.1 - new (non-DOS) kernel, real 32-bit addressing, high-end system.

In addition, there are three addressing modes-real, standard, and 386 enhanced. Real mode is becoming obsolete, standard and 386 enhanced are hardware dependent. On top of that, there's a backward-compatible runtime environment called Win32s that let's you run 32-bit Windows NT applications in a 16-bit environment like plain Windows 3.1 in 386 enhanced mode. Got that?

Other than having an identity crisis, however, Windows looks very good as a programming environment. James walked the audience through several examples, pointing out the similarities to and differences from the equivalent Mac code. Other than the fact that there are probably 10 times more Windows machines as Macs, on the surface Windows looks like a better environment to program. Here are a few reasons.

Windows architecture is based on object-oriented principles. For instance, window controls are subclasses of windows, and windows are subclasses of applications. A Windows event is handled like an object message, passed up through the subclass hierarchy until someone intercepts it. This is done automatically. Each class of object has its own default behavior which only needs to be overridden if you want to change the defaults. Sounds suspiciously familiar doesn't it? James pointed out that it's easier to port a Think Class Library (TCL)-based application than a typical Mac program with one big event loop because the TCL event handling is similar to Windows.

Windows is based on Dynamic-loaded Libraries (DLLs), reentrant code chunks that can be used by multiple tasks simultaneously, reducing memory requirements, and eliminating code redundancy. Because the bulk of a program's code is in DLLs, Windows resources have no code, just data. This makes Windows resources simpler.

Finally, because of the underlying architecture, the Windows API is simpler and more robust than the Mac toolbox interfaces, and Windows validates all parameters before a toolbox routine is executed. That can save you a lot of development time early on by eliminating parameter-based bugs. The proof that all these architectural differences create an advantage for a programmer is shown in the code-the Windows examples were straightforward and understandable. A basic "Hello Windows" program takes about 80 lines of code.

But Wait, There's More

One top of the basic architecture, Windows has some excellent additions. The most impressive one is Object Linking and Embedding (OLE, pronounced olay). On the surface, OLE is an extended Publish and Subscribe with in-place editing of shared objects. When you double-click on an embedded object in a container document, the application used to create the object is automatically launched, and the primary app's menu bar is replaced with the creator's menu bar. You can then edit the contained object in place in its native environment. When you're finished, you click outside the region of the object and the container application's menu bar reappears. OLE makes for a great demo (let me rephrase that-Macintosh Common Lisp makes for a great OLE demo). Users will love it.

OLE is much more than a fancy Publish and Subscribe however. Based on an underlying object messaging model (different from the one that drives Windows), OLE supports such features as unlimited nesting of objects, object-sensitive verb lists, automatic object type conversions, alternate display formats, and client-server negotiation for inplace editing. It's a very robust, sophisticated model that seems suited to a lot of different tasks.

OLE looks and feels like Publish and Subscribe and Apple Events and more. It's only going to be useful if lots of applications support it. Microsoft intends to include inplace editing based on OLE in the next release of all its major applications, including the Mac versions. They're going to accomplish this by providing an OLE library for the Mac (much like Apple is providing QuickTime for Windows).

Apple Cross-Platform Strategy

Surprisingly, Apple was in attendance to talk about their cross-platform strategy. As you might guess, much of it has been heard before-DAL, TrueType, QuickTime for Windows, OCE, and so on. And there was the usual Bedrock presentation, but with a few more details.

For instance, they actually showed a class hierarchy diagram for a window with components. It looked suspiciously like a TCL class hierarchy. Also, they mentioned that the Bedrock command hierarchy is based on TCL which uses what are called bureaucrats and supervisors. Resources are an extension of the Apple Rez language, uniform across all platforms. Finally, they actually showed some code for a sample program that opens a nonscrolling window with zoom and close boxes.

I'm not going to try to regurgitate the explanation that went along with the code fragments. I'll let you ponder them yourself and draw your own conclusions. A few things seem pretty sure-the more C++, MacApp, and TCL you know, the easier it's going to be to get up to speed with Bedrock.

Basic App-Resource File

resource STRTABLE
BEGIN
    1, "Basic Application"    // the title
    IDS_APPNAME, "wind.exe"
    IDS_DOCTITLE, "Basic Document Window"
END
resource bclmenu (IDS_APPNAME)
{
    MenuBar
    {
        TextMenu ("File")
        {
            MenuItem (cmdNew, "New"),
            MenuItem (cmdQuit, "Quit")
        }
    }
};

resource ICON   IDS_APPNAME, "wind.ico";
resource CURSOR IDS_APPNAME, "wind.cur";

Basic App-Subclass cDocument

// Constructor, just call superclass constructor

cBasicDoc::cBasicDoc (cApplication& supervisor) :
cDocument (supervisor, FALSE)
{
}

// NewWindow, create new document window

void cBasicDoc::NewWindow (void)
{
    cStr32 winTitle;
    cApplication&  app := GetApplication ();

    cDocWindow *pDW = new cDocWindow (app.GetAppDesktop (),
                                      *this, 0);

    app.LoadString (IDS_DOCTITLE, winTitle);
    pDW -> SetText (winTitle);
    pDW -> Show ();
}

Basic App - Subclass Application

// Constructor, just call superclass constructor

cBasicApp::cBasicApp (cSystem& system, HANDLE hInst,
                      HANDLE hPrevInst):
cApplication (system, NULLOBJECT (cModule), IDS_APPNAME, hInst,
              hPrevInst);
{
}

// CreatDocument, create a new doc and open window for it

cBasicApp::CreateDocument (void)
{
    cBasicDoc *newDoc = new cBasicDoc (GetApplication ());

    newDoc -> NewWindow ();
    return *newDoc;
}

Basic App-Main ()

int Pascal WinMain (Handle hInst,
            Handle hPrevInst,
            LPSTR lpszCmdLine,
            int CmdShow)
{
    cSystem *pSystem = new cSystem;
    cApplication *pApp = new BasicApp (*pSystem, hInst, hPrevInst);
    pApp -> MakeAppDesktop ();
    oApp -> Run;
    delete pApp;
    delete pSystem;
    return 0;
}

Porting from Mac to Windows

As James pointed out in "Postcard from WindowsLand" in the last issue of FrameWorks, there were also presentations about porting Mac applications to Windows. The three case studies highlighted three different approaches: rewriting from scratch and maintaining two sets of code, developing core code that works on both platforms, and using source code porting technology. Unfortunately, I missed Aldus' presentation on developing core code (it's rumored they used MacApp as a basis for their framework). I heard it was the best of the three presentations.

Software Ventures talked about maintaining two sets of source code. They basically said it was tough to do, tough to maintain, and they might not do it that way if they could start all over today. Altura software talked about their porting tools which appear to do a pretty good job. They claim they can port a complex Mac application to Windows in a few months. Altura only does this as a consulting engagement-you can't buy their tools outright.

Microsoft Developer Network

Finally, there was a closing presentation about Microsoft Developer Network, a rough equivalent to Apple's certified Developer Program. The differences are that Microsoft learned from Apple's mistakes, they're not trying to make this program a profit center, they did a lot of research before finalizing the program, and they are putting more resources into it.

It costs $195 to joint the developer network. For that you get a quarterly CD (and a bimonthly tabloid) with a huge quantity of stuff, including on-line documentation for all Microsoft's developer tools, white papers and specifications, independent articles about Windows programming, sample code, the complete text of several Microsoft press books, and Developer Knowledge Base articles from Microsoft's Product Support Services. But they didn't just throw all this information on a CD-they developed a custom navigation front end, and they licensed some very sophisticated search technology from a third party.

The end result is an information-packed CD with very intelligent access tools. You can find just about anything very quickly. Much of the material is cross-referenced and hyperlinked. There are several indexes you can browse linearly, and a most recent reference stack. The CD is an excellent value, and Microsoft is working hard to improve it all the time.

There's Some Good Stuff Here

If this conference is any indication, Microsoft's OS technology is rapidly approaching parity with the Mac OS. They appear to be poised to beat the Mac in many areas as well, and have already done so in some respects. If the Developer Network is any indication, Microsoft has the resources to do a very good job of supporting and encouraging developers. And they have the know-how to develop a great operating system.

At the risk of sounding like James, Microsoft is doing a good job. They make it sound easy and attractive to develop for Windows (of course the truth may be different). And they make Windows sound like a better alternative than the Mac, both market-wise and from a technology point of view. As James said toward the end of the conference-Microsoft is not the evil empire you might think, and there's some good stuff here. He's right about both.