Outside The Box

I use GlowCode for profiling ObjectARX applications. As far as I know, this is the only profiler that works with AutoCAD. What makes GlowCode special is that it can instrument code on the fly, including a monster like AutoCAD. It has a clunky interface that takes some patience to figure out, but it’s a lifesaver when you need it.

Recently a CADLock customer sent us a drawing file that was apparently not very complicated, yet it took over 20 minutes to create a deep vault. To determine the cause, I used GlowCode to profile the vault creation process. I could see almost immediately that most of the time was being spent in AcDbObjectId::operator ==, which was being called from AcDbObjectIdArray::find.

This turned out to be a classic case of using the wrong type of container. Searching an AcDbObjectIdArray isn’t bad when the array is small, but this drawing contained a special case where the array was very large, and this special case exposed the flaw. I changed the array to a std::set and tested again. The new time was 30 seconds to create the vault – a slight reduction of approximately 95%.

[Full Disclosure: Electric Software has for many years provided me with a complimentary license of GlowCode in exchange for my testing and feedback.]

Visual Studio 2010 shipped today accompanied by .NET Framework 4.0. I blogged before about the switch to using the MSBuild build system, and how that theoretically could be helpful in targeting multiple AutoCAD versions from the same solution. The shipping VS 2010 does not support non-Unicode response files, so out-of-the-box it cannot target VC 7.0 (for AutoCAD 2006 and earlier). When time permits, I’m planning to see if I can find a workaround; in the meantime, I’ll continue to use VS 2008 for ObjectARX.

There have been rumblings and rumors for a while now about a native Mac OS X port of AutoCAD. The ObjectARX 2011 SDK header files contain clear evidence of a native Mac port in the works. The evidence comes in the form of code comments and changes made to the files so that they work with the GCC compiler and the Mac OS X libraries.

For example, acedads.h conditionally declares a global function to return the main window handle as follows:

#if defined(_WINDEF_) || defined(_ADESK_MAC_)
/* AutoCAD graphics window handle */
HWND adsw_acadMainWnd();
#ifndef adsw_hwndAcad
#define adsw_hwndAcad adsw_acadMainWnd()
#endif

And in acedinpt.h there’s a telling comment:

#ifndef _ADESK_MAC_
#ifndef ACAD_PORT
#ifdef ACAD_API
#define ACAD_PORT _declspec(dllexport)
#else
#define ACAD_PORT
#endif
#endif
#else
// On OS X, we will export all symbols by default and will use GCC
// attributes to exclude symbols we don’t want to export.
// In this case, we do want to export the AcEdInputPoint symbol
#define ACAD_PORT
#endif // _ADESK_MAC_

It’s clear from the type, quantity, and quality of changes that Autodesk has successfully built at least a limited AutoCAD executable for OS X (both 32 and 64 bit). It’s also clear that the Mac build still has limitations, and some of these limitations might require significant changes (i.e. changes of the sort that would break binary compatibility for ObjectARX applications), therefore one could reasonably conclude that no full-blown Mac port is imminent.

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.

Many of you use my VC Build Hook utility to target multiple versions of AutoCAD from a single solution in Visual Studio 2008. Visual Studio 2010 now includes a new feature called native multi-targeting that performs the same function as VC Build Hook. The new feature works great for using build tools back to VC 7.1, but it does not work with VC 7, which is required for targeting AutoCAD versions 2006 and earlier.

The problem is that VC 7 chokes on Unicode response files. In earlier versions of Visual Studio you could set a project property to select Unicode or ANSI response files, but that property has been removed in Visual Studio 2010. I have been told by a Microsoft engineer that the problem will be addressed in SP1, presumably by adding that project property back.

The moral of the story is that you’ll need to wait for SP1 before you’ll be able to use the VC 7 build tools from within the Visual Studio 2010 IDE. I am not planning to update VC Build Hook to support Visual Studio 2010.