Over the weekend I received an email from Jürgen Becker. It came with this image, which certainly brought back memories.
The email referred to our recent trip down memory lane…
I read your last post and remembered a poster. Do you remember that release, it was terrible?
This is one of my favourite “chat over a beer” topics, and one that seems relevant to where we are today with Fabric, so I wrote Jürgen a quick note to say that I’d reply via my blog. Here is that reply.
R13 was bad, but it had to happen
I joined Autodesk in August 1995, which was about when the R13 release had stabilised (I have some recollection of c4 or c4a being released soon after I joined, but I can’t track down the exact timing of the R13 point releases). So I didn’t experience the full pain caused by the quality of that particular release… while I can empathise with it, I didn’t exactly live it myself on a daily basis (like many of our customers did). If people would like to share their own experiences with R13 – whether positive or negative – then please feel free to post a comment. This post is absolutely not about me trying to rewrite history.
What I do see – and often talk to people about when they raise it with me – is the importance of the R13 release to AutoCAD as a product and to Autodesk as a company. I have absolutely no hesitation in saying that if the R13 release hadn’t happened, Autodesk would not be here today. (I suppose that’s an obvious assertion, in the sense that there’s no way our user base could still be using AutoCAD R12 for DOS today, but to understand exactly what I mean, please read on. :-)
The initial R13 release was basically unusable. I was busy finishing my studies, at the time, and so can’t comment firsthand, but it’s something everyone says. I can’t give any insights into the management pressures and engineering issues that led to such a release going out the door, but as an organisation the AutoCAD team certainly learned a lot from this misstep. By the time I started working with them (initially to advocate for external software developers and later on as a member of the team) the organisation had become extremely quality-focused, which I suppose was the first positive impact of the R13 debacle.
Enabler for The Great AutoCAD Diaspora
Beyond the lessons learned by the AutoCAD engineering organisation, R13 was an important milestone for the AutoCAD product. Software development with the AutoCAD platform prior to R13 – both internal and external to Autodesk – was possible using either AutoLISP or ADS, the AutoCAD Development System. ADS allowed executables written in C to interface with AutoCAD via a set of messages… both AutoLISP code and ADS executables ran in a separate process, talking to AutoCAD via an inter-process communication (IPC) buffer which meant said communication was inevitably slow. ADS was important because it allowed people to write compiled applications that could interface with AutoCAD, but the integration was very limited. It was great as a mechanism for professional software developers to integrate data from other systems – perhaps performing serious number-crunching or interfacing with external databases via ASI – but it wasn’t an architecture that lent itself to high performance.
Not having been involved in it, I can’t talk about the goals for the R13 release, but I can talk about its impact in later years. R13 saw major parts of its codebase move to the object-oriented paradigm – via C++ – and saw the birth of the AutoCAD Runtime eXtension (ARX) API layer. Developers could now write DLLs – whether via C++ using the new ARX mechanism, or by porting legacy ADS code to ADSRX modules – that could be loaded by AutoCAD into its own process. Performance became lightning-fast: you were essentially creating modules that were executed just as if they were a core part of the product and had been written by Autodesk.
In fact, ARX (which was later renamed to ObjectARX during the R14 timeframe) enabled teams within Autodesk – some of which were even outside of San Rafael! – to start to build code that worked with the AutoCAD product – as if it was part of AutoCAD – without having to build the into the codebase. This may sound like something that’s obvious in hindsight as being important to do, but nevertheless its impact should not be underestimated: the rearchitecture of the AutoCAD core – and exposure of ARX – was a change that led directly to the verticalization of Autodesk, whether via internal projects or the acquisition of external products that could now be developed by Autodesk Developer Network partners. The Great AutoCAD Diaspora (and yes, that’s a term I’ve just coined, so blame me for it) would not have happened had it not been for R13.
Rearchitecting AutoCAD over the years
I tend to think of R13 as the first major rearchitecture of AutoCAD’s codebase, although this point is probably ready (and about) to be argued: there were certainly efforts such as the Tugboat and the Titanic – which led to Autodesk releasing AutoCAD R10 for Macintosh – but I suspect even John Walker wouldn’t classify this as a rearchitecture. There were almost certainly others that I know nothing about – whether related to supporting new platforms, back in the day, or perhaps to enable 3D – so you can safely take this numbering scheme to indicate the major ones that I’m aware of. Something that’s important to note is that the R13 rearchitecture was in many ways the last major “logical” rearchitecture: where AutoCAD’s object model was established, something that’s reflected heavily in its APIs and the structure of data it serialises to and from files.
The second major rearchitecture came in the AutoCAD 2000 timeframe, when the product was reworked to support multiple drawings via Windows’ MDI (Multiple Document Interface) mechanism. This was the first release that integrated fibers. If my recollection serves me correctly, this was also the first release to use ObjectDBX (which had been born during the R14 timeframe as DWG Unplugged, but that version was built from AutoCAD core code – it wasn’t then separated out as a component used by AutoCAD) to manage DWG files. (ObjectDBX was an overloaded term, in the sense it was used for both the runtime mechanism and the external SDK… it was later renamed RealDWG for the SDK side of things.)
While not really about rearchitecture, it’s worth giving honorable mentions to Visual LISP, VBA, COM and .NET. All of these programming environments were made possible by the work done in R13. Both Visual LISP – post the acquisition of Vital LISP – and VBA were integrated in R14, COM was probably there in some manner in R14 to support VBA and VLISP, but was reworked significantly for AutoCAD 2000 (at least that’s my recollection) and .NET was previewed in AutoCAD 2004 and properly released in 2005. None of these would have happened without having ObjectARX as a foundation.
Two more efforts that were both significant and yet somewhat independent of ObjectARX were to make AutoCAD Unicode-aware and 64-bit. I want to say these happened around AutoCAD 2008, but I could be out by as much as a few years on each. In both cases they involved touching a whole lot of code – in both AutoCAD itself and external products built on ObjectARX – but I hesitate to classify them as rearchitectures of the codebase. By saying this I know I’m risking an argument about semantics, but hey.
The third major rearchitecture project was The Big Split, which happened for AutoCAD 2010: the effort to allow AutoCAD to be built for OS X, with the secondary (but arguably more important) goal of creating a headless core of AutoCAD that could be run in the cloud. While the second (ObjectDBX) rearchitecture essentially componentised file-level access for both DWG and DXF, this third rearchitecture created the AcCore.dll module that hosted a significant amount of AutoCAD’s command- and canvas-related capabilities: essentially everything that wasn’t about the application UI layer (i.e. the application window with its toolbars or ribbons). It was a first attempt at creating a cross-platform codebase although – as mentioned recently – it wasn’t as clean a split as we’d have liked (there were lots of #ifdefs to conditionally compile code for different platforms).
The fourth major rearchitecture is Fabric. It raises the bar on The Big Split by adding 2D graphics into the one-codebase-to-rule-all-platforms – along with RealDWG and AcCore – as well as enforcing discipline around the use of platform-specific UI (above Fabric, architecturally) and the Platform Abstract Layer (below Fabric, architecturally, but above the OSes themselves). As well as extending support beyond Windows and Mac desktops to mobile and web. All from the same codebase. But we’ll dig more into this in a future post: this one has already gone on long enough. :-)
Summary
Wrapping up… AutoCAD’s codebase has benefited from a number of significant architectural projects, over the years. That said, the core logical architecture was established in the R13 timeframe, while the projects since have largely focused on physical architecture (componentisation and modularisation). Which isn’t to say they weren’t extremely important in their own way – Forge’s Design Automation API would not exist if we hadn’t done The Big Split, and I’m expecting Fabric to have even wider-reaching impact, over time – it’s just that they’re standing on the shoulders of giants.
So, to answer Jürgen’s question, R13 was indeed a terrible release but probably the most important one in the company’s history.
I hope people feel free to comment on this post, adding commentary and pointing out any inaccuracies (most of the above was dug up from long-term memory, so I’m very likely to have inadvertently made mistakes). Or maybe you just see things differently – if so, let me know!
