Visually Speaking

By Don Crabb

It’s November, 1995. Do you know where your Mac development efforts are heading? Will they be linked, arm-in-arm, with Metrowerks, Symantec, and Apple, or will you set-off in the direction of one of the Mac’s third party niche tools companies, like Main Event, Pictorius, MainStay, QKS, or Digitool? Maybe you’re even making the move to client/server development and are hunkering down with Oracle, 4th Dimension, Sybase, or even Filemaker Pro 3.0 (relational) and the FM Pro Server. And how much of your efforts are to develop software for both the Mac and Windows 95?

Visual Basic 4.0 for the Mac?

No matter what direction your Mac development efforts will take you, however, they won’t take you to Microsoft’s Visual Basic 4.0. MS has said “no way” to porting VB to the Mac, thus adding yet another brick to the wall isolating you from potential customers.

Customers who might buy your Mac products for their Mac ghettos if they could somehow interoperate your Mac apps effectively with their huge installed base of Windows products, most of which are driven by OLE.

Customers you might have reached a little faster if only you’d had the aid of VB 4.0 for the Mac to prototype and develop your Mac apps to live and work in a Windows world.

But Microsoft says “no way.” They don’t want Mac developers porting their apps to Windows. They want Mac developers to dump the Mac and develop directly for the 32 bit API of Win95 and NT.

The Importance of OLE and VB

No matter how little you think of OLE 2.0, it’s not going to go away just because OpenDoc is a better SOM implementation. And Visual Basic 4.0 is the raison d’tre of OLE 2.0. VB 4.0 lives and breathes OLE. It can create every kind of OLE server and container, including in-process servers.

With VB 4.0, the OCX standard has arrived with a flourish. VBX controls are automatically converted to OCX controls. The OCX language dialect is now VB and the runtime engine is shared by all MS Office 95 applications that use VB. And every third party addon module to Office 95.

You cannot, however, create OCX controls in VB, but you’d buy Borland’s Delphi 95 for that (yet another top Windows development tool that will not make it to the Mac).

VB 4.0 is also the defacto scripting language for Windows 95, even if MS has not pushed it as such (nor bundled it with the Win95 package as they should). As much as I love AppleScript and scripting on the Mac, VB 4.0 can do things that you can’t do nearly as well with AppleScript (even with 3rd party aids like Scripter and FaceSpan), like creating commercial applications or OLE objects. Visual Basic 4.0, in short, is a big deal. And it’s a bad deal for Mac developers (and customers) not to have it available for Macintosh.

What’s Hot About VB 4.0?

VB 4.0 is what I call a bridge language. It can be used by customers used to write application or system macros and scripts. It can be used by managers to create quickie apps. And it can be used by hard core application developers for everything from simple programs to advanced, enterprise-wide client/server applications thanks to its, different editions.

Professional Edition

The VB Professional Edition revolves around building Windows solutions quickly, making it a good fit for corporate IS departments. Coupled with the Visual Basic for Applications language engine (common across many MS apps), you get core developers able to communicate easily, leveraging their skills.

Enterprise Edition

For large programming teams building big applications, Microsoft provides Visual Basic, Enterprise Edition. It enables teams to develop with Visual Basic via the integrated Microsoft Visual SourceSafe(TM) project-oriented version control system. The Enterprise Edition also features fast, direct access to remote client/server databases with the Remote Data Control.

The list of what the Enterprise Edition of VB can do is long and impressive. Assuming you have at least half a brain, Microsoft expects that you can develop and debug a fully distributed application on a single workstation, then dynamically deploy it to network servers without much special help.

You can partition your application into MS-standard reusable OLE business rule components, which makes it easy to reuse these components, across your net, with different development tools. You can also use the Remote Data control for high-speed access to ODBC data sources such as Microsoft SQL Server and ORACLE. You can also keep team projects on track by using the Visual SourceSafe version control system which works through MS’s Solutions Frameworks

Network for Distributed Services.

In addition, and in no small measure, VB was designed to work with future Windows OS architectures (including NT), making it a very forgiving environment when MS pushes all of its Win95 customers over to WinNT (Cairo) in 1997-98. The Enterprise Edition of VB touts itself as the first second generation client/server tool that encourages developers to build scalable, maintainable, and widely reusable applications in a RAD environment. While that may be an exaggeration, the Enterprise Edition of VB is an important tool that will be widely used by our Windows chums.

And we have nothing like it for the Macintosh.

Numbers Don’t Lie

And that, like everything else in the VB scenario is bad for us. More than two million copies of VB have been put into developers hands, making it one of the most popular platform-specific tools you can buy for Windows. Name one Mac development tool that has sold two million copies.

The Microsoft Way

Bottom line, Microsoft is not about to expand VB’s reach to help us. Instead, they’re contented with keeping “the Mac in its place,” as a senior MS official told me recently. He went on to say that there was “no chance at all,” of VB being ported to the Mac, because MS was “not interested long term in helping the Mac work with Windows.” In fact, since “we’d rather that you guys just go away, why should we port our best devtools to you,” he concluded.

Why, indeed?