Warp's impressive control of DOS, Win16, Win32s, and OS/2 applications makes it an attractive choice for savvy integrators
Jon Udell
I'm dedicating this column to the folks at V Communications, whose excellent multiboot utility, System Commander, is enabling me to juggle DOS/Windows, Windows 95, Windows NT, and OS/2 Warp without dropping any of these balls. Who needs to perform this juggling act? Software developers and reviewers do, of course, but so do a growing number of system integrators and advanced users. The new 32-bit operating systems--Windows 95, NT, and Warp--use DOS and Windows as personality modules that support legacy applications. DOS/Windows isn't supposed to be the dominant personality, because these new systems are designed to
host new breeds of applications. But the old code has a way of hanging around, and for Windows 95 and Warp in particular, effective use of it will be crucial.
Warp can be an amazingly effective integrator
of legacy applications. Two of these that matter to BYTE are called bixlan and bd. The bixlan program connects users to the BIX conferencing system by a circuitous path that involves an INT 14 terminal emulator talking through an SPX network link to an Eicon X.25 card hooked to a 56-Kbps leased line. One variant of bixlan works in DOS, but reliably blows up when run in a Windows DOS box. Another variant, using an Eicon-supplied COMM.DRV replacement, supports Windows telecommunications software but precludes modem communications on the COM port that it uses. Both variants require either a TSR or a CONFIG.SYS driver, which eat up a big chunk of conventional memory. NT 3.5 and Windows 95 beta 2 won't run bixlan, but Warp handles both the DOS and Windows variants flawlessly. Because
they talk to a virtual COM port in an OS/2 VDM (virtual DOS machine), they can't monopolize a physical port. And because the conventional memory hit is confined to that VDM, there's no impact on another homegrown program, bd, a FoxPro 2.0 application that tracks information about articles and authors. bd likes as much conventional memory as it can get, plus a big hunk of EMS memory, and while it can get these things from NT and Windows 95, it runs noticeably faster on Warp.
INT 14 and X.25? FoxPro 2.0 and EMS? You're right, these technologies are embarrassingly long of tooth. Of course, we'll be replacing bixlan with telnet, and bd with one of the cross-platform, client/server, component-based, buzzword-compliant solutions we keep experimenting with, just as soon as we find the time (translation: don't hold your breath waiting). Meanwhile, it's valid to avoid fixing what's not broken, and to extend the useful life of sunk investments (I'll bet you have a few skeletons in your closet, too). Particularl
y in vertical markets such as insurance and retail, investment in PC software is substantial, and Warp's ability to leverage those applications is a major strength.
Not for the Fainthearted
Warp can revitalize legacy code; however, it's not guaranteed to do so, and when it does, it's not quite in the way that IBM's marketing campaign envisions. The product is pitched, for the most part mistakenly, at end users. ``Gordon, a lawyer in Halifax, Nova Scotia,'' a typical ad might say, ``has Warped his PC, and now he's surfing the Internet while printing a mail merge in the background.'' To Warp your PC means to install the latest version of OS/2 for Windows on top of an existing DOS and Windows 3.x substrate. The resulting system boots OS/2, supplies its own version of DOS, and runs Windows system components (with some scary in-memory patches) and applications (unmodified) in a VDM. IBM's marketing says that Warping is an end-user exercise that makes a PC more productive, which is ver
y possibly true, but also simpler to use, which is generally false, because where Gordon formerly had two operating systems to contend with (DOS plus Windows), now with the addition of OS/2, he has three.
Consider Gordon's likely experience with FaxWorks for OS/2, the nifty fax software included in the Warp Bonus Pak. He installs it, tests it by faxing a document from the IBM Works word processor, another OS/2 application that comes in the Bonus Pak, and is delighted to find that it just works. Encouraged, he fires up Windows, connects to the FaxWorks queue on LPT3, then previews and faxes off a Winword document. This time, however, what rolls out of the fax machine is a page of hieroglyphics. Why? Winword is set up to print to Gordon's LaserJet, and the stream of PCL (Printer Control Language) it emits means nothing to FaxWorks, an OS/2 printer driver that (unbeknownst to Gordon) emulates an IBM Proprinter.
This problem can in theory be fixed in two ways--setting FaxWorks for PCL or installing
the Windows Proprinter driver and telling Winword to use that instead of the HP driver. In practice, only the latter solution will work, because while a settings page in the FaxWorks driver tantalizingly lists PCL emulation, it won't actually let you select it. Now, this is not rocket science, but Gordon is only vaguely aware of what Windows printer drivers do, has never encountered an OS/2 printer driver, and is certainly not equipped to spot--never mind repair--a fumbled handoff from one to the other. However, once someone does straighten out Gordon's Warped PC, he is likely to be very happy with the results. FaxWorks can really crank, because it's native OS/2 software and because it's more streamlined than the ambitious but rather baroque E-mail-and-fax At Work technology included with WFW 3.11 and Windows 95.
The Integrator's Platform
IBM likes to call OS/2 the integrating platform, but I think it's more accurate to call it the integrator's platform. Beyond running DOS and Wi
ndows code side by side with OS/2 applications, here are two important things a savvy integrator might want to do with Warp:
(1) Field distributed applications
On one of my Warped PCs, I'm running the Lotus Notes Server alongside the Notes client and a mixture of DOS, Windows, and OS/2 applications. As companies deploy database, fax, communications, mail, and other more specialized network services, the question becomes where to put them. Consolidation onto powerful servers, as exemplified by the Microsoft BackOffice strategy, presumes that services are few and clients relatively feeble. Distribution across a network of peers, on the other hand, might make more sense as services multiply--if the peer workstations can capably run those services. On the 8-MB workstations that Windows 95 and Warp (but not NT or Unix) can productively use, Win 95's bias is heavily toward the centralized model, but Warp (like NT or Unix on bigger hardware) can go either way. Warp's small footprint and its
robust multithreading and memory management, plus IBM's network-capable SOM (System Object Model) technology, add up to a recipe for distributed computing.
(2) Create customized user interfaces
Because native OS/2 applications are scarce, and because many that do exist (e.g., Lotus SmartSuite) are sadly out of date, the radical openness of Warp's Workplace Shell has gone largely unappreciated. The OS/2 version of cc:Mail, which uses customized WPS folders and provides a message template that you can drag from the Templates folder, only scratches the surface. DevTech's DeskMan/2 utility hints at the more pervasive customization that is possible. It alters the Workplace Shell's drag-and-drop behavior in a deep way, so that a Copy/Move/Shadow menu pops up when you release a dragged object. As a result, you needn't remember how pressing the Alt or Ctrl keys modifies the drag operation to perform these actions. A modest enhancement, but it shows how the SOM hierarchy that underlies the Wor
kplace Shell can orchestrate systemwide, not just per-application, behavior.
Onward to Win32?
Warp runs Win32s applications handily. That might not seem like a big deal, because there are only a few such applications around today, among them SPSS, Mathematica, and one I use a lot, Visual SlickEdit. While reviewing Mathematica, BYTE technical editor Doug Tamasanis was intrigued to find that Warp ran the Win32s version of the program faster than did Windows 3.1, in some cases a whole lot faster. What's the future of Win32s? Some developers will bet on a slow uptake of Win 95 and NT and opt for the common-denominator Win32s API, sacrificing threads and advanced graphics to create a single 32-bit binary for all Windows platforms. Others will sacrifice Windows 3.x compatibility to exploit the richer Win32 APIs in Win 95 and NT. Win32s normally needs a VxD (virtual device driver) that, according Microsoft's documentation, provides exception handling, floating-point emulation, and memor
y management services. Enabling Warp to run VxDs was how IBM originally planned to support not only Win32s but also other VxD-based services, including the WFW 3.11 networking code. It didn't turn out that way, though. Warp doesn't run VxDs. Win32s works because Warp provides an OS/2 VDD (virtual device driver), W32S.SYS, that does the job of the Win32s VxD, W32S.386. The services that Win32s applications normally get from that VxD come, in this case, straight from OS/2.
Suppose IBM had instead delivered VxD support in Warp. VxDs normally run under Windows Virtual Machine Manager control, so Warp would have had to find a way to run (or emulate) that VMM, which in turn would run the Win32s VxD, which in turn would provide services to the other Win32s components. That would be the ring 0 analog to the way Warp now encapsulates the ring 3 Windows subsystem to run Windows applications on top of it. It's true that many of Win 95's Win32 features, including threads and linear memory management, are VxD-based
. But OS/2 shouldn't require VxDs for services that it can supply natively. NT certainly doesn't. Like NT, OS/2 is going where no x86-specific VxD can go--onto the PowerPC. And on x86-based PCs, OS/2 runs well in half the RAM that NT requires. Finding ways to plug Win32 directly into the robust and capable OS/2 kernel is the smart play. The way IBM chose to implement Warp's Win32s support is a step in the right direction.
screen_link (54 Kbytes)
Here's Warp running a DOS FoxPro application, Win16's Terminal, on top of Eicon's TSR-based X.25 redirector, the Win32s version of Visual SlickEdit, and the OS/2 version of cc:Mail. Making it all work can be a challenge, but the result is a mighty productive desktop PC.
Jon Udell is a BYTE senior technical editor at large. You can reach him on the Internet or BIX at
judell@bix.com
.
A Warped Perspective
