Port Your ObjectARX Code to 64 Bit

AutoCAD versions since AutoCAD 2008 (and since AutoCAD LT 2009) have included both 32 bit and 64 bit flavors on the same media. If you install on a 64 bit Windows system, you get the 64 bit AutoCAD; otherwise you get the 32 bit AutoCAD. The 64 bit AutoCAD can take advantage of as much memory as you can throw at it, whereas the 32 bit version is limited to 2 GB (3 GB if you cheat). They should be otherwise identical in theory, but in practice there are major differences.

One big difference is VBA. Microsoft put VBA out to pasture many years ago when they introduced the .NET framework, so there will never be a 64 bit version of VBA. Autodesk had to resort to a seriously inefficient kludge to get it to work at all in the 64 bit flavor of AutoCAD (VBA has to run in a separate 32 bit process, which makes typical applications two orders of magnitude slower).

The other big difference is that any third party ObjectARX applications must be installed for the correct architecture. A 32 bit ObjectARX application will not work in a 64 bit AutoCAD. [Note that .NET (or “managed”) applications typically work fine in both architectures — I’m referring to native C++ ObjectARX applications only.]

On the Autodesk discussion groups, many people ask how they can install the 32 bit version of AutoCAD on their new 64 bit operating system. Why would they want to do that? Almost always because they need to use an application that is only available for 32 bit AutoCAD architectures, or because they discover that their VBA applications become unbearably slow.

It is possible, with some hacking of the AutoCAD installation database, to install the 32 bit flavor of AutoCAD on a 64 bit system, but I don’t recommend that. There is just no excuse any more to not support the 64 bit architecture. If you find yourself in this situation, put pressure on the developer of the application to get it ported.

In fact, if you rely on an application that hasn’t been ported to the 64 bit architecture, I’d like to hear from you. Add a comment to this post and let me know the name of the application. If you are a vendor or developer that has not yet ported your 32 bit application, please contact me — I will gladly port it for you. Even large applications can typically be ported in several hours.

BTW, I am well aware that even Autodesk is guilty of not supporting 64 bit platforms in some of its vertical market AutoCAD versions (and corresponding object enablers). I certainly hope they remedy that situation in the next release cycle.

8 thoughts on “Port Your ObjectARX Code to 64 Bit”

  1. I have a home-grown app that relies on a free 4th party 32-bit DLL that is extremely unlikely to ever be updated, regardless of any pressure I may attempt to apply. Does this count as a valid excuse? 🙂

  2. I'm running 64-bit AutoCAD 2010 on XP SP3 64-bit and the VBA Enabler loads and runs just fine. Never had a problem installing it or with it running. Also, Autodesk didn't pull VBA out of the base installation setup until 2010. AutoCAD 2009 still installs it. Am I missing something?

  3. Owen, I have discussed this issue with you in the past, Eagle Point has refused to port their product to 64 bit, and now that they are closing the doors on their civil software for vanilla cad, I dont expect them to. Our office was forced to install 32 bit Windows, just because of this one program. I wish they would have taken you up on your offer to port their software, but for now, I just have to wait until Eagle Point goes away, then our office will switch to some other software that supports 64 bit.

  4. VBA still works in 2009 and 2010, but any application that requires interprocess communication between AutoCAD and VBA is much, much slower on 64 bit AutoCAD.

  5. It's unfortunate that a respectable company like Eagle Point is leaving customers high and dry on the 64 bit architecture, but I suppose they felt that even a few hundred dollars is too much to invest in a dying product.

  6. I find it humorous how intense the Autodesk marketing was to push developers away from LISP to VBA, saying it was "the future". Then they dump VBA after years of customer time spent doing just that. Only to realize (quietly, of course) LISP is still sitting there, working fine as always. Now they're starting the same bs marketing with .NET. Anyone remember the story of the boy who cried wolf?

  7. skatterbrainz, I know how it feels. I just started Lisp when VBA arrived. And i just submerged myself into VBA. It was very nice and i loved how easy it was in comparison with Lisp. I have developed a lot of code and now i have to re wright all into VB.NET . . . but i am also thinking that in the future VB.NET will be keeled too and all the reassures will go into C# or another animal they come up with. Time will show, at the mean time i just have to buy some Vaseline an assume the position.

  8. dear sir
    when i install Eagle point 2009 , it shows error.. as it is on 64 bit OS

    please help me in this regard.

Leave a Reply

Your email address will not be published. Required fields are marked *