When we ported AutoCAD to non-MS-DOS systems, we were faced with numerous compatibility issues. Although all systems use the ASCII code, compatibility stops about there. Various systems have adopted different conventions for end of line and end of file detection; they store multiple byte binary values in different orders in memory, require different physical alignment of values on byte boundaries, and even use different floating point formats.
These issues make it very difficult for systems to interchange binary files. The only reasonable approach is to define a portable format, hopefully close to the middle point between the systems, then require every system to convert that format to and from its own computational requirements.
Our existing (2.5 and 2.6) AutoCAD releases do not allow interchanging binary files among major machine types (current major machine types are MS-DOS, Apollo, IBM RT PC, Sun, and Vax). To move data between systems, one must convert it to ASCII form, possibly translate the ASCII file due to end of line conventions, then load the file onto the other system and convert it back to binary. For drawing databases, this means one must DXFOUT on the sending system and DXFIN on the receiving system.
Given the difficulties in physically moving files between systems, the small market initially anticipated for non-MS-DOS AutoCAD s, and the major work needed to make binary files portable, we chose not to address this problem previously. Sales to date of non-MS-DOS machines indicate that this decision was correct.
The advent of high speed networks and file sharing protocols such as Apollo's Domain, DEC's Decnet/Vaxmate, and Sun's NFS have begun to erode the justification for this decision. Many AutoCAD users, particularly in larger companies, have inquired about configurations involving a file server, one or more 32 bit workstations, and a number of MS-DOS machines, all on a common network. Such a configuration economically provides large central storage, high performance when needed, and very low cost individual workstations for routine work. The usefulness of such an installation is drastically reduced if every transfer of a drawing from a PC to a 32 bit workstation requires a DXFOUT and DXFIN, as these are lengthy operations which consume a large amount of disc space and network bandwidth. As we increase our sales efforts in large accounts, a competent solution to the issues raised by heterogeneous networks will be a major point of distinction which can distance us from the competition.
The first step toward a compatible database was taken when Bob Elman redesigned the entity database code in release 2.5. Galt broke in, ``The Bob Elman''. ``Yes'', I responded, and showed him the listing of EREAD.C. He shook his head and said, ``That's Bob''. Bob's code resolved all issues of byte ordering and alignment in the entity data portion of the database, and did it in a particularly efficient way that takes advantage of the properties of the host machine's architecture. Entities are written with no pad bytes and Intel byte ordering. Thus MS-DOS machines, the overwhelming segment of our market, pay no speed or space penalty. Bob's code did not address machines with non-IEEE floating point (the VAX is the only exemplar of this class).
Providing drawing database compatibility between machines, then, is primarily an issue of fixing the drawing header record (MASTREC), the symbol tables (SMIO), and the headers on the entities themselves, plus resolving the issue of differing floating point formats. In addition, the other binary files that AutoCAD uses, such as DXB files and compiled font and shape definitions should be made compatible. The work described herein defines canonical forms for these files, implements a general package for system-independent binary I/O, and uses it to make AutoCAD drawing databases and the other aforementioned binary files interchangeable. The code has currently been installed and tested on MS-DOS and Sun systems, which may now share files in an NFS environment. The work needed to port it to the Apollo and RT PC should be minor. A VAX version will require certification of the code to interconvert VAX and IEEE floating point formats.
Galt interrupted, ``So what you're saying is that before, if you hooked big ones and little ones together on a wire, it was a pain in the neck, and now you've fixed it so it isn't''.
For a longwinded pedant, the man does have a talent for coming to the point.
Editor: John Walker