Acrobat 1.0 was an astounding achievement. The team, engineering, QA, marketing, documentation, and management put together a nice solid product that did what it said on the box. Upon release, Adobe took out a two page spread in the Wall Street Journal expressing how Acrobat would change the world. It was awesome to be a part of that and not long after we released, Adobe’s stock value doubled.
After the 1.0 release, people (finally) took vacations. Some people moved on. New people came on board. Management started to forge plans for version 2.0 and how it would shape the future.
Acrobat 1.0 cut a lot of corners in order to meet spec and ship on time. There was shared core code, but everything that the users saw was implemented uniquely on each platform. This was the most expedient way to build the product, but certainly not a long-term solution. In addition, there were so many things that we wanted to implement, but didn’t have the time to do without a huge effect on the overall product and its stability.
As we planned 2.0, Bill McCoy, a senior PostScript engineer, joined the team. He spent a lot of the time with pages and pages of source code in front of him shaking his head at the short cuts we took and the overall design.
Carl Orthlieb and I had put together a simple API that met our needs in terms of hooking a search engine into Acrobat and allowing us to present dialog boxes, create menus, automatically navigate to pages, highlight words, and go to particular views. It was compact and met our needs. We had hacked it into the existing framework and had prototypes up and running. At one point, Carl and I did a presentation to the 2.0 planning team. While Carl and I covered what we needed and how we got there, Bill was half listening and half going over pages of source code, trying to get all of Acrobat 1.0 into his head.
The meeting felt like we were being told, “oh, that’s so cute what you put together and thanks for your time, but we’re going to do something different.” It was demoralizing and delivered in a way that was ego-crushing, but so be it.
The problem was that what they had planned was way in the future and in the meantime, Carl and I had to build our product with a shifting, unstable platform. The big plan was a plug-in architecture that would make every feature within Acrobat accessible from plug-ins as well as allowing new features to be exposed to the product and other plug-ins. This was part of a design done by Bennett Leeds for Acrobat. Around that time, there was something like 4 or 5 different plug-in architectures being using in products in Adobe and nobody was willing to share. There were some issues in making the Acrobat work because of calling convention differences on each platform (and each compiler!). At one point, when they were stuck on a problem of getting Pascal and C calling conventions to line up, I came up with a really nifty thunking mechanism that managed that problem. I liked it so much, I sent it off to one of my old college professors who was impressed that I had created a rarefied closure in portable C.
Eventually, the entire architecture was put into place. In addition to the plug-in model, it included a much more solid implementation of platform specific and platform neutral code, building on a decent MVC design with an OS abstraction layer that made sure that all the screwy things like file systems, menus, window handling, and so on were pushed way out into the fringe code. Even though it caused a great deal of pain an re-implementation of existing features, it was ultimately the right thing to do.
The process wasn’t without internal friction, but that’s a story for another day.