March 93 - MADACON Madness
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)
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)
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.