I never wanted IGES to be in the AutoCAD core. When I began the IGES project in July of 1985, I intended that IGES would be an extra-cost application, selling for say $500, rather than being included with every copy of AutoCAD. Not only did I hope by this to raise some extra revenue to fund IGES development and support, but, recognising from the start that IGES would be a difficult and messy chore, albeit an essential one, my intention was to limit the market for IGES to those serious customers who would use it for practical purposes and generate useful requests for change, rather than frivolous users writing bug reports every time an IGESOUT/IGESIN ``lost something'' a DXFOUT/DXFIN preserved.
Keep not always the same stance:
Attack however there's a chance.
In 1985, the only alternatives to implementing IGES within the core were as an AutoLisp application and as an external program that processed databases in DXF form. AutoLisp could be ruled out easily, as the restrictions on program size and execution speed were intolerable for a task as complicated as IGES translation. In addition, access to the entity database was not added to AutoLisp until Release 2.6 in June of 1986 (having been coded during the Week of Rest at the end of 1985), and access to AutoCAD's symbol tables, essential for IGES to obtain block definitions, line types, text fonts, etc., was not added until even later. A DXF-based translator would have certainly been feasible (indeed, several have been marketed by third parties), but it would have been far more cumbersome to use and difficult to implement. IGES translation, which already involves processing a huge ASCII file, would require an intermediate DXF file, also huge and slow to write (binary DXF not having been implemented until Release 10). In addition, many operations in an IGES translator require flexible and efficient random access to the AutoCAD database and symbol tables, and the support of a wide variety of geometry service functions. These routines are available within the AutoCAD core, but an external DXF-based application would be forced to create its own AutoCAD-like database from the DXF file and replicate all the processing facilities so readily at hand within AutoCAD.
Bring all your resources into play;
Wrangle, tangle, be flayed and flay.
Regarding this soberly, and remembering that IGES was initiated at the very end of the development cycle of what was eventually called Version 2.5, I concluded that the best way to get IGES done and out the door was by going ahead and implementing it within the core. After all, overlaying would prevent IGES from increasing the memory requirements to run AutoCAD, and we'd already decided to abandon support of floppy disc only machines as of Version 2.5, so growth of the on-disc size was not a major consideration. Integration of IGES in the core would not preclude marketing it as an extra-cost option; after all, at that time AutoCAD was offered in base, ADE-1, ADE-2, and ADE-3 trim levels, differing primarily in which overlay files were supplied on the release disc (actually, it wasn't that simple, but you probably don't want to know any more than that). With a little ingenuity and native cunning, we could figure out a way to sell an IGES package consisting of overlay files you copied into your AutoCAD directory to enable the IGESIN and IGESOUT commands. This would be packaged with the IGES document, and, if done in a sufficiently elegant (read sneaky) fashion, might even permit updates to IGES without the need to release a new AutoCAD.
Draw arguments old from out your store,
Venture subtleties never used before.
In the words of Dennis the Menace, ``You can't tell how deep a puddle is from the top.'' Even though we walked into IGES knowing it was going to be difficult, IGES has never failed to surprise us with the amount of work needed to usably interchange drawings with other CAD systems, themselves only marginally compliant with the ill-defined and mutable IGES standard. With the camel's nose of IGES within the AutoCAD tent, IGES became a part of the mainstream of an AutoCAD release, at least in the sense that IGES bugs had to be closed out before an AutoCAD release could be shipped, even though the overwhelming majority of AutoCAD users never used IGES. However, IGES never became fully integrated in the minds of the developers, so that new features would be added to AutoCAD without implementing them in IGES. This would lead to crises in the final development phase of AutoCAD releases, when furious efforts had to be mounted to implement new IGES code, delaying the AutoCAD shipment date.
To compound the pain, what with everything else we had to do between mid-1985 and the shipment of Version 2.5 in 1986 (this was the first year after our initial public stock offering and was the period in which we were struggling to get the hardware lock ready for introduction with Release 2.5), we never managed to separate IGES from the AutoCAD product, foregoing the additional revenue this would have generated and making it impossible to distinguish an IGES user from any other AutoCAD customer. The following years have not seen IGES and AutoCAD coming to co-exist on any better terms. Virtually every major AutoCAD release has been delayed by an ``IGES crisis'' of one form or another, resolution of IGES bugs critical to obtaining business remains rigidly coupled to the AutoCAD release cycle, and the memory constraints imposed by the AutoCAD core have required the IGES code to become increasingly fragmented and convoluted and consequently harder to maintain.
Our decision to support IGES in 1985 was correct; IGES has become an essential part of a CAD system today, and with the growing focus on CALS, of which IGES is a part, will continue to be the price of admission to sales to government agencies, their contractors and subcontractors, and, increasingly, large industrial customers. We can only expect our commitment of resources to develop, maintain, and support IGES to increase as our business expands in those sectors. Any steps we can take to reduce the difficulty of IGES development will further the achievement of our goals. The whole smelly, dirty camel's in the tent, and his tail's flickin' at the 640K tentpole that holds the whole mess up. It's time to see if there's a better way to go about this.
Editor: John Walker