I use GlowCode (http://www.glowcode.com) 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. ...
Visual Studio 2010 shipped today (http://blogs.msdn.com/visualstudio/archive/2010/04/12/visual-studio-2010-is-now-available.aspx) 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.
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.
[Update: See Visual Studio 2010 Native Multi-Targeting] 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. ...
There are a myriad of ways to load AutoLISP applications in AutoCAD, including acaddoc.lsp, an .mnl file, the Startup Suite, and manually by various means. For application developers wishing to deploy their applications to others, all of these methods have drawbacks. The ideal solution should be easy to implement in an installation program, require minimal or zero changes to the user’s AutoCAD configuration, work the same way across all versions of AutoCAD, and easily undone when the application is uninstalled. ...
ArxDbg is the name of a sample project that has been included with the ObjectARX SDK for many years. It’s primary purpose is to demonstrate how to use the ObjectARX API, but it is a complete free-standing utility in its own right. ObjectARX programmers often use this utility during development for testing and exercising their application code, but it can be useful to anybody, not just programmers. ...
I’ve been chasing a drawing corruption problem on behalf of a customer. The problem manifests itself by causing a “Missing Language Pack” dialog to display when the drawing is opened (but only in Windows XP with no language packs installed – my Vista installation apparently has all the language packs installed). Installing the language packs “fixes” the problem, in that the drawing files open without error. However, the real problem is that some drawing objects were corrupted in memory, and corrupt data was subsequently written to the .dwg file. My customer thinks the corruption might be linked to a virus that they were infected with (and have since eliminated). I have a copy of the virus for testing, but I have not been able to catch it in the act of corrupting an open drawing file. Therefore, I cannot conclusively link the virus with the corruption. So, I need your help. Have you recently noticed a “Missing Language Pack” dialog appearing in drawing files that have opened fine in the past? Has your virus scanner recently detected an AutoCAD related virus? If you have, please send me an email describing your situation and AutoCAD versions involved. I would like to determine conclusively whether the virus is causing drawing file corruption, and if so, whether the corruption is always in the same location of the drawing file. [Update: Autodesk has released a technical document with information about the virus (http://usa.autodesk.com/getdoc/id=TS13717811). See also Shaan Hurley’s blog post (http://autodesk.blogs.com/between_the_lines/2009/08/malicious-code-alert-acadvlx-and-solution.html).]
I’ve proved once again that if you want it done right, you have to do it yourself. The ManuSoft web site is fully functional again after my longtime ISP had a major network meltdown. I waited for two weeks for them to repair it, then finally moved to a different provider. The new provider’s promised “24/7 tech support” turned out to mean “24 hours to respond, 7 days to fix” every problem, not to mention that I would need to provide step by step instructions to their techs so they could configure the server the way I needed. After two weeks of that, I gave up and configured my own server and now host it myself. Let this be a warning to all of you hosting web sites with reputable providers, or storing your data somewhere in the cloud. I paid big bucks every month to my old provider for secure servers, redundant power supplies, managed and air conditioned server rooms, nightly backups, 99% uptime, etc., but they still lost everything. Almost a month later they still haven’t restored their customers’ data. Luckily, I make my own backups.
[Update: See Disable AutoCAD InfoCenter] In case you missed it, Tony Tanzillo has posted instructions (http://discussion.autodesk.com/forums/thread.jspa?threadID=721735&tstart=1) for disabling the InfoCenter in AutoCAD 2010. AutoCAD 2010 starts faster when the InfoCenter is disabled. To make it easy, I’ve created an AutoLISP file that defines commands named DisableInfoCenter and EnableInfoCenter: ...
In the new ObjectARX 2010 SDK, Autodesk has added some new virtual member functions that are not exported as they should be. For example, the AcGiFaceData class has had two new virtual functions added for setting and getting the face transparency: class AcGiFaceData: public AcRxObject { //[… deleted for brevity] ACDB_PORT virtual AcDbObjectId materials() const; ACDB_PORT virtual AcGiMapper mappers() const virtual void setTransparency(const AcCmTransparency transparency); virtual AcCmTransparency transparency() const private: AcGiImpFaceData mpAcGiImpFaceData; }; As you can see, whoever added the new functions neglected to prefix them with the ACDB_PORT macro. ACDB_PORT evaluates to __declspec(export), which tells the compiler to export the function. Since the macro is missing, the new functions are not exported from acdb18.dll. Since these are virtual functions, you won’t have any problems calling them through a pointer to an AcGiFaceData object that was constructed by AutoCAD. The problem arises when you derive a class from AcGiFaceData. Since the functions are not exported, the linker has no way of resolving their address for creating the virtual function table of your derived class. This results in linker errors: acrxEntryPoint.obj : error LNK2001: unresolved external symbol “public: virtual void __thiscall AcGiFaceData::setTransparency(class AcCmTransparency const )” (?setTransparency@AcGiFaceData@@UAEXPBVAcCmTransparency@@@Z) acrxEntryPoint.obj : error LNK2001: unresolved external symbol “public: virtual class AcCmTransparency * __thiscall AcGiFaceData::transparency(void)const " (?transparency@AcGiFaceData@@UBEPAVAcCmTransparency@@XZ)Following is an example that results in these errors: class AcGiFaceDataEx: public AcGiFaceData { public: AcGiFaceDataEx() {} ~AcGiFaceDataEx() {} } Test; The only solution is to provide an implementation of the missing functions. In this case, it could be accomplished by something like this: class AcGiFaceDataEx: public AcGiFaceData { AcCmTransparency mpTransparency; public: AcGiFaceDataEx() : mpTransparency( NULL ) {} ~AcGiFaceDataEx() { delete mpTransparency; } virtual void setTransparency(const AcCmTransparency transparency) { delete mpTransparency; mpTransparency = (transparency? new AcCmTransparency( transparency ) : NULL); } virtual AcCmTransparency transparency() const { return mpTransparency; } } Test;This will fix the linker errors, but there is no guarantee that it will work as intended. AutoCAD might access its internal transparency value directly without calling through the member functions, which means it would never “see” the transparency set through the replacement member functions. Furthermore, the addition of the new pointer member changes the size of the class, which causes AcGiFaceDataEx arrays to have a different memory footprint than AcGiFaceData arrays. Lastly, what if Autodesk fixes the problem in a future AutoCAD service pack? The ideal solution should not change the size of the class. It should check at runtime whether the function is exported, then use the exported function if it exists. That way, code that is written now will use the exported function if and when it becomes available in a future version of AutoCAD. When the function is not exported, an alternate implementation must be provided. This is not an unusual scenario, and the solution I present for the specific case of AcGiFaceData can be adapted to the more general problem. In the AcGiFaceData case, the missing functions are virtual functions. Knowing this, it is possible to use a trick to get the address of the real function. In the code below, the function getAcGiFaceData_vtable() constructs a temporary AcGiFaceData object, from which it extracts a pointer to the object’s virtual function table. The virtual function table is just an array of function pointers, so the address of the desired function can be obtained by indexing into the virtual function table. The question is, how far? By counting virtual functions and data members starting from the top of the class hierarchy: in this case, 6 virtual functions in AcRxObject plus 16 virtual functions in AcGiFaceData = 22. Note that obtaining a function pointer this way relies on Visual C++ implementation details, but this is safe to do since all ObjectARX modules must be compiled in Visual C++. Following is my solution to the missing AcGiFaceData functions: #pragma warning(push) #pragma warning(disable: 4608) template < typename Src, typename Dest > Dest force_cast( Src src ) { union _convertor { Dest d; Src s; _convertor() : d(0), s(0) {} } convertor; convertor.s = src; return convertor.d; } #pragma warning(pop) static FARPROC getAcGiFaceData_vtable() { static FARPROC rfVTable = (FARPROC**)&AcGiFaceData(); return (rfVTable? rfVTable : NULL); } void AcGiFaceData::setTransparency( const AcCmTransparency transparency ) { typedef void (AcGiFaceData::F_setTransparency)( const AcCmTransparency ); static F_setTransparency pfSetTransparency = force_cast< FARPROC, F_setTransparency >(GetProcAddress( GetModuleHandleA( “acdb18.dll”), “?setTransparency@AcGiFaceData@@UEAAXPEBVAcCmTransparency@@@Z” )); if( !pfSetTransparency ) { static FARPROC rfVTable = getAcGiFaceData_vtable(); if( rfVTable ) pfSetTransparency = force_cast< FARPROC, F_setTransparency >( rfVTable[22] ); } if( pfSetTransparency ) (this->pfSetTransparency)( transparency ); } AcCmTransparency AcGiFaceData::transparency() const { typedef AcCmTransparency (AcGiFaceData::F_transparency)() const; static F_transparency pfTransparency = force_cast< FARPROC, F_transparency >(GetProcAddress( GetModuleHandleA( “acdb18.dll”), “?transparency@AcGiFaceData@@UEBAPEAVAcCmTransparency@@XZ” )); if( !pfTransparency ) { static FARPROC rfVTable = getAcGiFaceData_vtable(); if( rfVTable ) pfTransparency = force_cast< FARPROC, F_transparency >( rfVTable[23] ); } if( pfTransparency ) return (this->*pfTransparency)(); return NULL; }
Everyone else is discussing all the cool new features in AutoCAD 2010, so I decided to have a look at what’s new in the EULA (End User License Agreement). I compared the AutoCAD 2010 EULA for US/Canada to the AutoCAD 2009 EULA. I won’t divulge the process I used to automate the comparison, because the odds are pretty good that I violated the EULA somewhere along the way, and I want plausible deniability. The first change I noticed is that the AutoCAD 2010 EULA contains more shouting. The 2009 EULA started out in a fairly mellow mixed case with a few shouts thrown in for effect, but the 2010 EULA dispenses with the lower case and launches right into a multi-paragraph avalanche of screaming block letters. Apparently nobody was listening, so they turned up the volume. Substantively, there are a number of very interesting changes. The following was added to the preamble: SOFTWARE OBTAINED FROM THIRD PARTIES THAT HAVE NOT BEEN AUTHORIZED OR ALLOWED BY AUTODESK, DIRECTLY OR INDIRECTLY, TO SUPPLY SOFTWARE IS LIKELY TO HAVE BEEN MADE AVAILABLE IN VIOLATION OF AUTODESK’S RIGHTS. IN SUCH AN EVENT, AUTODESK IS NOT OBLIGATED TO ISSUE AN ACTIVATION CODE OR OTHERWISE PERMIT YOU TO INSTALL OR USE THE SOFTWARE. Next time you’re eyeing that used copy of AutoCAD 2010 on eBay, be warned that Autodesk is not obligated to permit you to install or use the software. They don’t come right out and say that they won’t allow it, so maybe they won’t mind – but then what’s the point of including this clause? Tim Vernor (http://www.cadcourt.com/Docket/207cv01189.aspx) won’t be very happy about this change. Moving along, I see that they added a definition for “Uninstall”, defining it as “to destroy or remove”. The definition of “User Documentation” was very slightly changed from “…after You acquire or Install the Software…” to “…when or after You acquire or Install the Software…”. Incidentally, did you know that Autodesk considers an AutoCAD reseller’s invoice to be “user documentation”? Rounding out changes in definitions is a change in the definition of “You”. Yes, Autodesk has redefined “You” whether “you” like it or not. I could go on and on about small wording changes, and while it would be interesting to contemplate why each change was made (and how many scheming lawyers it took to do it), we’d risk missing the forest for the trees. Section 2.1, “License Grant”, contains ominous new language. The following has been added: You may Access the application programming interfaces that may be included with or in the Software or otherwise available from Autodesk for use with the Software (“API’s”) to develop programs, modules, components or functionality that (i) are compatible with and are used and/or interfaced with the Software and (ii) contribute significant value-added functionality or enhancements to the Software (“API Modules”) provided You may Install and Access such API Modules solely on Computers where a licensed copy of the Software is also installed and further provided such Installation and Access is solely in connection with Your Installation and Access of the Software and solely for Your internal business needs. You may not redistribute all or any portion of an API Module. Read that again. That’s right, you may not write any “programs, modules, components, or functionality” unless they “contribute significant value-added functionality or enhancements” to AutoCAD. Furthermore, if you do manage to write a program that adds significant functionality, you may not redistribute all or any part of it. What are those guys smoking out there in California? Finally at the end of section 2.1, they changed “No license is granted under the terms of this Agreement if You did not lawfully acquire the Software” to “No license is granted under the terms of this Agreement if You did not lawfully acquire the Software from Autodesk or from a third party who has been permitted or authorized by Autodesk either directly or indirectly to supply the Software”. Take that Tim Vernor! In another nod to the Vernor case, section 2.3, “Upgrades”, adds a new requirement to “destroy all Autodesk Materials relating to the Previous Version or, upon request by Autodesk, return all such Autodesk Materials relating to the Previous Version to Autodesk or the company from which they were acquired”. This is important language that could persuade a court to view an AutoCAD purchase as a license instead of a sale, thereby giving Autodesk the power to control the secondary market. Interestingly, section 2.4, “Crossgrades”, requires that the previous software be uninstalled within 60 days, but has no requirement that it be destroyed. However, new language in section 2.7, “Termination”, which requires the software to be destroyed “upon termination of the license grant or this Agreement”, apparently covers both cases. A funny change in section 3.2.3, “Transfers”, appears to close a loophole. The AutoCAD 2009 EULA disallowed transfers to “any other person”; the AutoCAD 2010 EULA disallows transfers to “any other person or legal entity”. Considering a license transfer? Make sure it’s to an illegal entity! Section 4, “ALL RIGHTS RESERVED”, was rewritten. The rewrite introduced a grammatical error (“and You have not other rights”), but otherwise I don’t see that much changed. It still ends with the now familiar directive that “The Software and User Documentation are licensed, not sold." Finally, the infamous “audit clause” has been revised. Not the way you may have hoped, I’m sad to report. Luckily the change was a minor one that doesn’t make the clause any more overbearing than it already was. Isn’t change wonderful?
From a new features overview of Autodesk Design Review 2010 (http://dwf.blogs.com/beyond_the_paper/2009/02/autodesk-design-review-2010-new-features-overview.html) comes the following snake oil claim: Digital Signatures To help secure your data, you can now digitally sign DWFx files. As I’ve explained before, digital signatures do not provide data security; they simply authenticate the person that applied the signature. Digital signatures are a welcome feature with many potential uses, but data security is not one of them.