Skip to content
Archive of posts tagged AutoCAD

Missing Language Pack DWG File Repair

I wrote before about corrupt text causing bogus “Missing Language Pack” warnings in AutoCAD. That case prompted me to write a file repair utility. However, since the case appeared to be isolated, I never released the utility to the public.

The problem has been rearing its ugly head again, so I decided to dust off the original code and release it. The repair utility is now available on the freebies page (look for CleanLanguage.zip) for AutoCAD 2007 and later versions of AutoCAD. I have not tested any recent cases, so I can’t be sure it is the same problem. If you try the utility, please report your results by leaving a comment here.

GlowCode Success Story

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.]

AutoCAD 2011 EULA Changes

For AutoCAD 2011, Autodesk made relatively few changes in the EULA. They fixed the grammar error that was introduced in AutoCAD 2010, but they didn’t make any changes to the convoluted “License Grant” wording that was also added in AutoCAD 2010.

There are a handful of minor tweaks here and there, but the only substantial change is some newly added text in section 9.1 that is intended to make sure that AutoCAD licenses can’t be liquidated during bankruptcy proceedings:

In the context of any bankruptcy proceeding, You acknowledge and agree that this Agreement is and shall be treated as an executory contract of the type described by Section 365(c)(1) of Title 11 of the United States Code and may not be assigned without Autodesk’s prior written consent, which may be withheld in Autodesk’s sole and absolute discretion.

Just for fun, I made a chart that shows how the AutoCAD US/Canada EULA has grown since AutoCAD 2000. The EULA grew 150% from 12139 non-space characters in AutoCAD 2000 to 30235 non-space characters in AutoCAD 2011. For what it’s worth, the size of acad.exe grew 75% in the same timeframe.

AutoCAD 2011 EULA Growth Chart

AutoCAD for Mac

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.

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.