Last August Microsoft decided to drop VBA from the Macintosh versions of Office. What was a strategic lock-in for Excel grew to have major strategic value for the whole Office system. In essence, in addition to giving Excel users a nice programming language, Microsoft was building a highly strategic barrier to entry, and locking in Excel users, especially corporate users who are most likely to build large systems based on macros.Įventually, all the Office apps came along: Word, Project, Access, Outlook. You don’t get partial credit when you try to emulate an API. In the brittle world of programming, such imperfections often mean your program crashes long before it does anything useful. hardly ever work the first time out of the box: in any large API or programming interface, there are so many subtle, undocumented details of the behavior, which programmers may be depending on without even realizing it, that any emulation environment will inevitably be imperfect. This is the same reason apps under Mono, Wine, etc. At some point, any Excel VBA macro they tried to run would get in trouble and crash. They thought that no matter how hard their competitors tried (in those days, they were Borland, Lotus, and, to a far lesser extent, Claris), they would not be able to emulate the VBA programming environment and the gigantic Excel object model perfectly. Microsoft thought that if people wrote lots and lots of VBA code, they would be locked in to Microsoft Office. However, it was seen as extremely “strategic.” Here’s what that meant. The whole effort took quite a bit of work. This became Visual Basic for Applications, and, soon thereafter, the standalone version, Visual Basic 4.0.
The VB team implemented an all-new version, for both Macintosh (System 7 on Motorola 68k) and Windows (3.0 on 16 bit processors). Visual Basic 1.0 didn’t support things like “rows(1).cells(2).value” because the row object couldn’t contain another object. For complicated reasons, the Visual Basic engine wasn’t object oriented “enough.” In particular, objects could have properties, but those properties couldn’t, themselves, be objects. Rather than implement two object models, the Excel team concluded that the object model for Excel had to be Apple Events compatible. To be a good Mac player, Microsoft had to support Apple’s cross-application scripting architecture, Apple Events. There were a bunch of complicated requirements, though. Thus, the obvious choice for Excel’s next macro language was some version of Visual Basic.
Much as professional programmers sneer at the Basic programming language, market research unambiguously showed that about 2/3rds of the kinds of accidental programmers who develop macros preferred Basic to other languages and perceived it to be easy. Combining a graphical UI builder similar to NeXTSTEP’s Interface Builder with a simple Basic programming language that was highly compatible with QuickBasic, it rapidly became the best selling programming language, a position it maintained until droves of developers switched to web development. In 1991, Visual Basic 1.0 had just shipped to rave reviews. The first few versions of Excel (1.0 through 4.0) had a rudimentary macro programming capability using a programming language so embarassing that it never had a name, although it was sometimes called XLM (its file extension).