AutoCAD 2008 – 64-bit application migration
We’ve been talking to ADN members (under non-disclosure agreements) for a number of months about the 2008 family of Autodesk products, and with these products officially announced I can now talk more publicly about their features and APIs.
This week I’ll focus on AutoCAD, but I plan to describe the new feature-/API-sets of other Autodesk products over the coming weeks.
So what’s new in AutoCAD 2008? There are a number of very interesting new features and APIs, which I'll talk about in coming posts, but for now I want to address the more fundamental question around application migration. Firstly, AutoCAD 2008 is a binary application compatible release, so applications built for AutoCAD 2007 should just work with AutoCAD 2008 (with the exception of needing to update installers to deal with the new Registry location - under "R17.1" - for demand loading keys etc.). For some background information on binary compatible releases, see this previous post.
One of the big news items for some users of AutoCAD is the availability of a 64-bit version of the product. 64-bit AutoCAD 2008 will behave almost identically to the 32-bit version, but will allow users to work with much larger datasets.
Developers and beta-testers have so far been downloading separate 32-bit and 64-bit versions of AutoCAD 2008, but the plan is to ship a single DVD that will install 32-bit AutoCAD 2008 on supported 32-bit Operating Systems and 64-bit AutoCAD 2008 on supported 64-bit Operating Systems.
One issue hit during development was around the use of VBA, which is simply not available as a 64-bit component. 64-bit AutoCAD runs VBA in a separate 32-bit process, which does have some impact on the performance of VBA applications.
I’m sure many of you are interested in the impact on your code of supporting a 64-bit platform. Here’s a brief synopsis:
- LISP No impact – neither for LSP nor FAS files
- .NET No impact – assemblies are platform independent
- VBA Some impact – minor code changes + performance
- ObjectARX Some impact – minor code changes
Let’s now take a closer look at the changes to ObjectARX. One thing I do as a matter of course when looking into a new version of AutoCAD is to perform a “diff” on the API headers and samples in the ObjectARX SDK. The tool I’ve used for a number of years now is called WinMerge.
The process gives you a really good feel for a few things:
- Diffing the API headers points you to the new APIs and also to the APIs that have been updated – or require migration changes – with the new release.
- Diffing the samples gives you a qualitative feel for the specific types of changes that need to be made to real code from one release to the next. For example, when looking at the differences between the 2006 and 2007 SDKs, it was quite clear that the vast majority of the work required was around the move to UNICODE (and to some degree to Visual Studio 2005). With 2008 it’s about 64-bit (as all our samples are written to be buildable for both Win32 and Win64 platforms).
The good news is that the changes needed in ObjectARX code to support 64-bit are actually very minor (honest!). A number of datatypes have changed to become “polymorphic”, which means their underlying datatype depends on the platform.
This is copied from the 64-Bit Migration Guide that ships as part of the 64-bit ObjectARX SDK:
In many cases, ObjectARX function signatures have been changed to use polymorphic types. For instance, long types that store pointers have been changed to the LONG_PTR pointer precision type. LONG_PTR remains long for 32-bit API usage and becomes __int64 in 64-bit builds. Similarly, types that represent legacy (or “old”) object IDs change from LONG_PTR to Adesk::Int-DbId. Graphics system (GS) and selection markers have been changed from int to Adesk::GsMarker.
The following list summarizes additional changes from 32-bit types to polymorphic types in ObjectARX function signatures:
- Adesk::Int32 changes to Adesk::LongPtr
- Adesk::UInt32 changes to Adesk::ULongPtr
- DWORD changes to DWORD_PTR
- unsigned long changes to ULONG_PTR
- unsigned int changes to UINT_PTR
Here’s a quick snapshot of the aforementioned guide – it’s quite comprehensive (which is great), but you shouldn’t assume this means 64-bit migration is very complicated: almost everyone who has so far undertaken a port to 64-bit of their ObjectARX applications has found it to be a straightforward process.
To give you an idea of some of the changes, here are some (somewhat randomly) selected - but quite representative - snapshots of differences between the samples on the 2007 and 2008 SDKs:
For a more comprehensive look at the migration requirements around 64-bit – including information on VBA and ObjectARX – please watch this presentation: AutoCAD 2008 - 64-bit Porting Considerations. The slides in the recorded presentation include some confidentiality notices which can now safely be ignored. Oh, and for those of you who prefer to watch this offline, here's the presentation as a download (at about 26 MB)
My team is working hard to capture more of the content we presented at our recent DevDays events – I’d be very interested to hear any feedback you have regarding how useful you find this presentation recording.
In my next post we’ll look at some of the new APIs available in AutoCAD 2008 and corresponding samples available with the new ObjectARX SDK.