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).