Outside The Box

Disable InfoCenter in AutoCAD 2010

2009-03-30T19:13:00.003-04:00

In case you missed it, Tony Tanzillo has posted instructions 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:
DisableInfoCenter.LSP

Alternatively, you can just paste the following lisp at the AutoCAD command line to disable it and be done with it. Note that you need to restart AutoCAD for the change to take effect.

(vl-load-com)(vl-registry-write (strcat "HKEY_CURRENT_USER\\" (vlax-product-key) "\\InfoCenter") "InfoCenterOn" 0)

ObjectARX 2010: Dealing With Missing Exports

2009-03-28T17:54:00.005-04:00

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;
}

What's New in the AutoCAD 2010 EULA

2009-03-25T01:55:00.003-04:00

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 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?

Software Licensing: A Case For Reform

2009-03-01T18:03:00.004-05:00

I want to consider software licensing practices in general, but with the specific facts and history in the Vernor vs. Autodesk lawsuit as a backdrop.

In the Vernor case, Tim Vernor purchased several boxes of AutoCAD software, and never even read, let alone agreed to, the terms of the license agreement inside the box. When Vernor listed the AutoCAD software for sale on Ebay, Autodesk sent Ebay a notice that claimed Vernor's auction violated Autodesk's copyright. In order to benefit from the safe harbor provisions of the Digital Millennium Copyright Act (DMCA), Ebay was obligated to remove the auctions. Vernor responded by filing a lawsuit accusing Autodesk of making false copyright violation claims.

Additional facts have since come to light. For one, we've learned that the AutoCAD software that Vernor purchased had been previously upgraded to a newer version. Vernor did not know this when he purchased the software; and in any case, it's not clear that this fact has any bearing on the outcome of the suit.

Given this set of facts, let's analyze the Vernor case not from a purely legal perspective, but from a more abstract "moral" perspective. After all, society is the ultimate arbitrator of what is wrong and what is right with respect to our laws. We ultimately determine whether laws are fair by whether we follow them willingly (and whether we put pressure on our legislatures to change them).

Steve Johnson opines that Autodesk is morally right in the Vernor case, because the software Vernor purchased was "tainted" due to having been upgraded by the original owner. ~~In Steve's view...~~ [see Steve's comment below where he chides me for ascribing this view to him - O.W.] Presumably, one who holds this view sees Vernor's original purchase as akin to someone purchasing stolen goods. With stolen goods, the law (and hopefully our moral compass) recognizes that the purchaser of the stolen goods has no legal right to them.

Autodesk offered the original owner a discounted price for a newer version of AutoCAD in exchange for a promise to destroy the older version. The original owner reneged on its promise to destroy the old version, and sold it to an unwitting buyer instead.

It follows that both Autodesk and Tim Vernor were treated unfairly by the company that sold the AutoCAD software to Vernor. Despite the company's history of using pirated software, Autodesk gave them the benefit of the doubt when selling them a discounted upgrade. Vernor, by all accounts, had no idea and no way of knowing that the software he purchased had been previously upgraded. This is a recipe for disaster.

Unfortunately, this sort of disaster is all too common. In many cases, software users simply don't read license agreements. If they do read license agreements, they don't understand them. After all, most of us are not lawyers, and we can't reasonably be expected to hire a lawyer to evaluate the license agreements of every software product we use. How then can we be expected to follow them exactly and without fail?

Consider that it's entirely possible that the company from which Vernor bought his AutoCAD software had no idea that they had agreed to destroy the upgraded AutoCAD software. At least from a moral perspective, we can have some sympathy for the company if they honestly had no idea they were violating any agreements when they sold the software to Vernor.

Could Autodesk have required the upgraded AutoCAD software to be returned, or required certification by an independent "software recycler" that it had been destroyed? Sure they could have. In fact, such requirements did exist in the early days of software license agreements. Had Autodesk done so, the Vernor court would probably have concluded that AutoCAD was licensed, not sold.

Why even require the old version to be destroyed when upgrading? If we stop using the old version, why shouldn't we be allowed to sell it at market value? Doesn't recycling old software make just as much sense as recycling old tires? We have been conditioned to believe that discounted upgrades are good for us, but are they really?

Would we accept a legal regime under which tire manufacturers could force us to destroy our old tires as part of the new tire purchase agreement? Oh, you say, that comparison isn't valid because tires eventually wear out of their own accord, whereas old software continues working forever! First of all, old software doesn't continue working forever. How many people still use VisiCalc? Furthermore, what would this line of reasoning conclude about potential tires of the future that last forever? We'd have to start licensing tires instead of purchasing them!

What would happen if software vendors could not legally prevent "used" software from being resold on the open market, no matter how it was purchased or upgraded? For one, it would increase competition, because new versions of software would be competing not only against software from other vendors, but also against older versions of itself. In a world where software is priced based on what the market will bear, the net effect would be lower prices and higher quality (not to mention less frequent "upgrades") for all software.

I think the Vernor case is just one example illustrating how the current software licensing system has sprung a leak, and is in need of repair. Can it be patched, or does it need to be replaced? Can the bleeding be stopped at the ankle, or should it be stopped it at the neck? This is a classical case of the Petcock Problem.

Software industry advocates like the Business Software Alliance (BSA) proclaim that the solution is educating consumers. Education may be important, but I think that "educating consumers" should not be left to an industry alliance.

I have some ideas about how the system can be reformed, but I think we have to start by recognizing that there's a problem.

Software Licensing: Who's On First?

2009-03-01T17:48:00.004-05:00

I'm a firm supporter of intellectual property rights. I fully support the rights of software publishers to own and profit from their creative work. I make my living as both a consumer of software and a publisher of software, so my views on software licensing reflect what I consider to be a healthy symbiosis between producers and consumers.

Intellectual property laws are (or should be) designed to protect this symbiotic relationship for the public good. The patent system is designed not to protect patent owners from pirates, but to promote inventions and improvements on previous inventions that benefit the public. The fact that patent laws do help to protect patent owners from pirates is merely a side effect of the underlying goal of promoting the public interest. We, the public, grant exclusive rights to patent owners for a specific time in exchange for them making public the details of their invention. Innovative inventors can thus build on a body of previously published inventions rather than starting from scratch. This system of "open source" innovation speeds the evolution of technology, and everybody benefits from it.

Copyright laws must be viewed in the same light. Copyright laws are designed to promote and enhance the public good by encouraging the production and publication of creative works. In exchange for giving copyright owners certain rights for a certain period of time, the public gets to enjoy and build upon a body of creative work. Some argue that the benefit of copyright protection provides a financial incentive to create the works in the first place, and that without such an incentive the works would never be produced at all. While this is undoubtedly true, consider that there are other ways to provide financial incentives (by providing government grants, for example), so I think it's important to view this aspect of copyright protection as a consequence of the goal to promote the public interest, not as a goal in and of itself.

Copyright laws have long recognized a need to prevent copyrights from being abused by providing exceptions to the protection they afford to publishers. The Fair Use doctrine is the most common such exception in US copyright law. The First Sale doctrine (or "exhaustion rule" in some jurisdictions) is another example of a limitation on copyrights. These exceptions and limitations evolved in response to attempts by copyright owners to abuse copyrights in a way that contravened their purpose of promoting the public interest.

Software licenses are a relatively new phenomenon, but they rely on very old law: contract law. It is important to understand that a software license agreement is a contract. The commercial software publisher agrees to give us limited and conditional copy rights and authorizes us to use the software in exchange for a fee. If the license agreement that we agreed to authorizes us to install and use the software on one computer, but we install it on ten computers, then we are violating both contract and copyright law (because we copied the software without permission). If the license agreement that we agreed to forbids us to resell the software to someone else, but we decide not to use the software ourselves and sell it anyway, we are violating only contract law (because we made no unauthorized copies).

There are several contract law issues typically encountered with software license agreements.

First, typical commercial software license agreements suffer from their unilateral nature. The contract is drawn up by the publisher with no negotiation or input from the consumer. Some question whether these are valid contracts in the first place, because they lack the "meeting of the minds" element that some judicial interpretations of contract law require.

Second, software license agreements are not usually consummated until after the sale, when the software is finally installed. We purchase the software, essentially committing to our side of the bargain before we even know the terms of the contract to which we must eventually agree in order to use the software. This is inherently unfair, and there are still many unsettled questions about whether or not such a contract can ever be equitable and enforceable.

If you've been following the Vernor vs. Autodesk lawsuit, you'll know that the US federal district court in that case ruled that AutoCAD software was sold, not licensed, and therefore subject to the First Sale Doctrine. The First Sale Doctrine says, in essence, that a publisher cannot contractually restrict the downstream resale or distribution of a copyrighted work beyond the "first sale". The court, at least in its initial ruling, rejected Autodesk's argument that AutoCAD was licensed, and therefore exempt from the First Sale doctrine. It should be noted that the Vernor lawsuit is far from over, and this first sale decision could well change before the dust settles.

The courts will eventually reach a final decision in the specific case of Vernor vs. Autodesk, but why was this lawsuit even necessary in the first place? It's difficult to envision any outcome in which every injury is rectified. It could even be argued that everybody loses, no matter the outcome. And this is just one case in one jurisdiction.

In the end, the final result of the Vernor case may not have much impact on how software is sold. It ultimately comes down to us, the union of consumers, to decide what kind of system we want. Unfortunately, right now we're doing the software limbo while we wait faithfully for the next service pack. I think that we need more than a service pack. A system restore might be in order.

The Software Limbo

2009-02-27T10:51:00.003-05:00

Bruce Schneier argues that data is the pollution of the information age, and "just as 100 years ago people ignored pollution in our rush to build the Industrial Age, today we're ignoring data in our rush to build the Information Age."

Software is still surfing the wave of technology revolution. In the tug-of-war between producers and consumers, the producers are still pulling the rope and consumers are just hanging on.

Just as the coal mines, steel mills, and sweat shops of the burgeoning industrial age led to organized labor and labor laws, the consumers of the information age will eventually need to come to grips with the predatory practices of greedy software barons through collective bargaining and regulation.

You've all heard the old software vs. car argument, right? Is buying software like buying a car? Or is it like leasing a car? Or are cars just a bad analogy, because software isn't like cars at all?

Is software really different, or have we just been conditioned to believe that it's different?

The problem is that we're still coming to terms with software, both legally and morally. Software companies have had a clear advantage in this information age frontier, and they have used their advantage to mold the software model to their liking. The software industry has successfully convinced us that software is licensed, not sold, and that because it is licensed, the old rules don't apply.

Indeed, it seems like software license agreements have been around forever. We've accepted them, adapted to them, and basically ignored them. In the meantime, software companies have added more restrictions to their license agreements, lobbied legislators to create new laws that protect the restrictions, and quietly begun building case law in support of the software license regime.

This is the software limbo. How low can we go? When will the laborers of the information age unite and say "enough is enough"?

The Petcock Problem

2009-02-24T14:56:00.003-05:00

Many years ago, I worked for the small town where I grew up. My title was Street Commissioner. This is a very small town, and I was a part time employee with one helper. Basically, I was the guy what fixed things. We had a very old network of water pipes that supplied water from several wells. The water system leaked in many places. Occasionally, a small leak turned into a big leak, and something had to be done about it.

You might think that the first response to a big water leak would be to close the water valves in order to isolate the leak and prevent the loss of valuable water. Not so fast!

First of all, in an interconnected network that had been upgraded and patched by piecework for many decades, it wasn't always possible for small localized segments to be isolated, and turning off the water for a large area would inevitably lead to discord.

Second, closing even a single valve caused pressures throughout the system to change. Any pressure change anywhere in the system had the potential to cause new failures at weak points, which would just compound the problem.

Furthermore, at some point repairs could be counterproductive and completely replacing parts of the network would be the best option. This would require time for the town council to approve the funds, and for contractors to be hired, and for the work to be scheduled and completed -- all while the leaking water is causing collateral damage to the roadway and inconveniencing the affected residents with low water pressure.

Eventually the big leak had to be repaired, and the water had to be turned off somewhere before the repair could be completed. The decision about where and how to accomplish this was not a simple decision, due to the competing factors involved, and the practical realities a small town is faced with.

I call this problem the Petcock Problem. Imagine petcock valves scattered throughout a network of pipes. I call this the Petcock Problem because petcock valves typically have three positions, analogous to the notion of closing, opening, or redirecting connections on the network in order to isolate a fault.

The Petcock Problem would apply in many situations involving complex networks, such as when a tree knocks down a power line or when an internet router dies. Sometimes the best solution is to isolate the fault to the most localized part of the network possible, thereby inconveniencing the least number of people at the expense of putting the larger network at greater risk of a much larger catastrophe. Sometimes the best solution is to shut down the entire network temporarily, thereby inconveniencing everybody that relies on the network, but removing any risk of further degradation while repairs are completed. Most of the time the best solution is somewhere in between these extremes. As the network ages and faults become more commonplace, at some point the best solution is to scrap the entire network and build a new one.

This is the Petcock Problem, or "How do you stop the bleeding?". The solution involves balancing several variables, some of which are known quantities, some of which are wild guesses, and some of which are potentially very chaotic (in that a small change in value could have an unpredictable impact on the outcome).

[Disclaimer: I'm sure that the study of network topologies has its own terms of art and well researched algorithms for describing and solving these types of problems. I'm not claiming to have some new revelation about networks here. This is just my own little custom worldview.]

In a future post I will explain how the Petcock Problem applies to something as diverse as the Vernor lawsuit.

Autodesk Design Review 2010 Snake Oil Alert

2009-02-12T14:35:00.002-05:00

From a new features overview of Autodesk Design Review 2010 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.

Autodesk Discussion Group Facelift Offer

2009-01-28T12:00:00.006-05:00

My participation in the Autodesk discussion groups has been severely curtailed since the notorious "upgrade" a few months ago. One of the many problems introduced by the upgrade is the loss of formatting. It's now virtually impossible to post messages that include inline AutoLISP or ObjectARX code without them being reformatted into unreadable garbage. Even attaching the code as a file is difficult (the "solution" is to rename files with a .txt extension!) As a result, many queries for programming help go unanswered. Autodesk has made an attempt to provide a fix, but a survey of the posts in any of the programming groups shows that it's not working*.

* [Thread has been removed by Autodesk, so link was changed to point to archived thread.]

The recently announced layoffs and related cost cutting measures at Autodesk have dimmed my hopes for a resolution. Therefore, I've decided to offer my services to fix the problem. Autodesk, I'm offering to donate my time to fix your discussion group software. Just give me access to a development and testing platform, and the right to modify or rewrite the code.

Readers, can I get an "Amen"?
Newsgroup%20needs%20complete%20overhaul.htm

AECOPEN Utility

2009-01-24T17:07:00.003-05:00

James Maeding of Hunsaker & Associates contacted me recently about an irritating problem that his users have with the AECOPEN command in Land Desktop. The AECOPEN command replaces the core AutoCAD OPEN command in AEC verticals. The problem they have is that AECOPEN displays an initial project dialog that requires users to press a [Browse] button to open the file browser dialog. Since they want to browse for a file every time they use the AECOPEN command, James wondered if I could create some code to automatically "press" the Browse button every time the AECOPEN command is issued.

I whipped up a little utility for AutoCAD 2007-2009 based products to do what James wanted, and it is now available on my freebies page as AecAutoOpen.zip. When the ARX module is loaded, AECOPEN behaves as if the user had immediately pressed the [Browse] button on the project dialog. If the [Ctrl] key is pressed, AECOPEN reverts to its original behavior.

Why not just use the built in OPEN command instead? The AECOPEN command has some important side effects, according to James.

Missing Menu Madness

2008-12-22T18:15:00.008-05:00

One of my many complaints about about the CUI system introduced in AutoCAD 2006 is that it's not very friendly to third party developers. In my opinion, it's not very friendly to end users either, but I digress...

One example of the unfriendly CUI is the case where a third party application installs a partial menu. In the pre-CUI days, adding a partial menu was an easy way to add an application specific menu to AutoCAD without making any changes to the end user's existing menu files. If the application was later uninstalled, the uninstall script could remove its menu and clean up the registry, leaving no trace behind. CUI breaks that scenario.

When a partial menu is loaded into AutoCAD 2006 and later, the CUI system actually writes a reference to the new partial menu into the main .cui file. To make matters worse, there is no clean way to programmatically remove those references because there is no deterministic way to locate all the .cui files used by a specific instance of AutoCAD from an uninstall script running outside of AutoCAD.

This would not be the end of the world if AutoCAD simply ignored references to missing files, but it doesn't. When the CUI command starts, it detects the missing files and displays an obnoxious message box that must be dismissed before the command will continue.

Then to top it off, AutoCAD displays a second message box that also must be dismissed.

I think it should be obvious even to an untrained UI designer how ridiculous this is.

In AutoCAD 2006 and 2007, the solution is to dutifully dismiss both dialogs, then when the CUI dialog finally appears, click [Apply] to rewrite the .cui file without the missing partial menu references. In AutoCAD 2008 and 2009, you have to first expand the 'Partial CUI Files' node in the Customization tab, then right-click on the unresolved partial menu file and select 'Unload CUI File', then click [Apply].

Design File Locking and Snake Oil Security

2008-12-06T14:52:00.004-05:00

The increased sharing of electronic CAD data (ala BIM) holds a lot of promise, but it also exposes companies and individuals to additional liability and risk. This additional risk is coming into focus more and more as actual cases of costly legal battles confront engineers and architects.

The June 2008 AUGI wishlist results contain "Design File Locking" as the top wish by a substantial margin, and Shaan Hurley lists it as number 3 in the AU 2008 AutoCAD wish list. Clearly, interest in file and IP security has been growing steadily.

As demand for IP security grows, there are sure to be snake oil security vendors trying to cash in on it. I received a spam email a few days ago from SafeNet, Inc. promising "a cost-effective and easy to integrate solution that provides reliable and effective security through the use of digital signatures." Whenever I see such statements with a long string of buzzwords, my snake oil alarm goes on alert. Digital signatures are for authentication and establishing trust -- they cannot and do not provide "reliable and effective security", although I suppose they could be used by a system that does.

In the last year or two, a number of companies have claimed to market software that "secures" AutoCAD DWG files. When I see such a claim, it invariably refers to software that creates an anonymous unequally scaled MINSERT entity. These can be created or "exploded" with a few lines of AutoLISP code. Frequently these companies claim to "encrypt" the drawing, which may sound sexy, but is an outright lie. If this is a level of "security" that meets your needs, at least use one of the many free versions posted throughout the internet (DETER.VLX from DotSoft is one I know of).

There are solutions, but they always require changes in the workflow process that involve difficult tradeoffs and careful evaluation of what is technically feasible and practical versus the costs of implementing the changes. There is no such thing as installing a single piece of software to instantly solve the problem. If you are looking for ways to protect intellectual property in your drawing files, don't be fooled by snake oil security vendors.

Disclaimer: One of my hats is the president of CADLock, Inc., makers of CADVault for AutoCAD.

Propagandapedia

2008-10-15T18:58:00.001-04:00

Did you ever wonder what press release writers do in their spare time? Given Autodesk's recent trademark litigation with SolidWorks and related efforts by Autodesk to trademark "DWG", and given the fact that US Patent and Trademark Office (USPTO) trademark examiners are known to use Wikipedia during their research, it doesn't take an evil genius to realize that a little subversive editing here and there might be helpful to the corporate cause. So, I decided to use Wikiscanner to go spelunking through the labyrinth of Wikipedia editing history to see if I could unearth any nuggets.

It didn't take long to find some interesting edits. For example, in the edit history for "SolidWorks" you can see that someone from an Autodesk IP address changed "and has since been copied by others like [[Autodesk Inventor]]" to "and is now part of the midrange CAD market along with [[Autodesk Inventor]]". Eventually this changes to "and is currently a leader in the 'midrange' CAD market", and from that to "It is currently one of the most popular products in the 3D mechanical CAD market" with a citation to a SolidWorks web page as evidence of the claim.

I expected to find plenty of quid pro quo, but I have to say, either SolidWorks' press release writers are a lot sneakier than Autodesk's, or they have a lot less free time. According to this list of edits from SolidWorks IP addresses, there haven't been any edits made to Autodesk entries since about March of 2007. In October of 2006 someone from SolidWorks changed a few things in the entry for "Autodesk Inventor", but then things appear to have cooled off considerably.

So what about "DWG"? The entry for "AutoCAD DWG" contains this edit from an Autodesk IP address made in January of 2007, but not much since. Two months later, someone from Autodesk changed "for that reason they constituted a consortium ([[OpenDWG]]) to develop open tools to access DWG data" to "for that reason they constituted a consortium ([[OpenDWG]]) to reverse engineer Autodesk's technology and access DWG data". Since then, things have been fairly quiet on the "DWG" front.

My conclusion is that blog posts like this one from Franco Folini at NOVEDGE Blog may have resulted in more strict internal controls being instituted over the editing of Wikipedia content. I have no doubt that it still goes on, but covertly enough to provide plausible deniability.

Update vs. Service Pack

2008-09-27T21:28:00.006-04:00

Of course I'm talking about Autodesk's newly reinvented nomenclature for bug fixes. Once upon a time they were known as bug fixes, then service packs, and now "updates". Is the Autodesk marketing department running amok? The subtle spin is certainly a sign of the times, but I wonder if the change in terminology comes about for another reason as well.
Autodesk promises "features extensions" to subscription customers. They have had difficulty delivering such extensions on a consistent basis. One of the reasons, I suspect, is that developers of extensions encounter the same brick walls that third party developers battle all the time: AutoCAD bugs, of course; but also incomplete APIs and feature limitations. It's possible that updates not only fix bugs, but also fill gaps so that extension developers can get their extensions working.
Then again, the change in terminology might be part of a new fad. My wife, who is an engineer working in the automotive industry, informs me that they no longer issue drawing revisions in her company. Instead, they now issue "updates". I wonder how long it will be before auto mechanics stop repairing cars and start updating them instead.

OpenDCL Quick Intro

2008-08-24T15:42:00.002-04:00

If you're an AutoLISP programmer, you've probably heard about OpenDCL. Maybe you've even checked it out, but it looked complicated and you weren't sure whether it was worth the trouble to learn how to use it. Either way, do yourself a favor and spend 10 minutes to go through the following 10-step quick introduction to OpenDCL.

Download and install OpenDCL Studio. Select the latest version in your desired language (ENU in the filename means US English). The download is an .msi file that can be cleanly uninstalled afterward.
Start AutoCAD (2004 or later). Use the APPLOAD command to load _MasterDemo.lsp from the OpenDCL Studio samples folder (it will be located in a language subfolder of the main OpenDCL Studio folder). When you close the APPLOAD dialog, the OpenDCL 'MasterDemo' dockable form will appear.
Click on the [ListView] button to run the ListView sample. The ListView sample is very simple and will demonstrate some basic principles of OpenDCL. Leave it running as you proceed through the following steps.
Locate and open ListView.lsp in the OpenDCL Studio samples folder. ListView.lsp contains all the code for the ListView sample. Look for the c:ListViewDlg_Close_Clicked function defined near the end of that file. That function is called an "event handler", and it is the lisp function that is executed when the [Close] button is pressed. The event handler for the [Close] button simply closes the dialog. The c:ListViewDlg_OnInitialize event handler function initializes the controls on the dialog before it is displayed.
Locate and open ListView.odcl in the OpenDCL Studio samples folder. Files with an .odcl extension can be opened and edited in OpenDCL Studio. OpenDCL Studio is used to design the user interface elements in an OpenDCL project. In the project tree pane, open the 'Modal Forms' folder, then double click on ListViewDlg. The ListView form will be displayed in design mode.
Click on the [Close] button on the ListView form. In the font toolbar at the top of the editor, press the [B] button to make the font bold. Notice that the button's caption becomes bold. In the 'Properties' pane, double click on the 'Height' property value and change it to 20. Press [Enter] to apply the new value. Use your mouse to drag the bottom of the button in design view to resize it dynamically.
Leaving OpenDCL Studio open, switch back to AutoCAD. Resize the ListView dialog, and notice how the controls it contains are also resized. Now switch back to OpenDCL Studio, make sure the [Close] button is selected, then click in the right column of the '(Wizard)' property in the Properties pane (or right click on the button control and select 'Properties' in the control's context menu). In the Control Properties Wizard, the Geometry tab shows that the button's "Left Side Alignment" has been set to "Offset From Center of Dialog" and it's "Top Side Alignment" has been set to "Offset From Bottom Edge". Once these properties are set, no additional code is needed for the control to react correctly when the dialog is resized.
Exit AutoCAD, then restart. Enter the OPENDCL command. This command demand-loads the OpenDCL Runtime using AutoCAD demand loading mechanism. The OpenDCL Runtime must be loaded before the OpenDCL functions will work. The OpenDCL Studio installation includes OpenDCL Runtime, so it already exists on your computer.
If you are developing an application for use by others, you'll need to download and distribute the OpenDCL Runtime along with your application. This is best done by incorporating the OpenDCL Runtime merge module for your language directly into your own application's installation script. Alternatively, you can distribute the standalone OpenDCL Runtime .msi file for your language, or publish the URL where end users can download the latest version.
Switch back to OpenDCL Studio and double click on the [Close] button control. Intelligent help displays all the properties, methods, and events of the selected control, including their AutoLISP syntax. Click on a property, method, or event in the left pane to see detailed information for it.

Once you complete these ten steps, you are only a few minutes away from creating a fully functional OpenDCL application. Give it a try!

Ed Foster: Loss Of A Legend

2008-07-29T23:35:00.002-04:00

InfoWorld columnist and legendary consumer advocate Ed Foster died over the weekend. Ed was a tireless crusader for consumer rights in the digital age, and he will certainly be missed. For many years Ed has authored GripeLine, where he called companies and politicians to task for abusive anti-consumer practices.

I've written before about how Ed exposed and publicised shamefully lopsided software license agreements, including Autodesk's and Adobe's. Recently, Ed commented about the May, 2008 Vernor decision (see my ADSK v ODA web site for more information about the Vernor case).

It will be no easy task to fill Ed's shoes. We can be certain, though, that his work must go on.

The Magic Baseball Bat

2008-06-27T23:48:00.002-04:00

This is a story about my 11 year old son, Nick, and a father's pride.

I coached Nick's Little League baseball team this year, and now that the regular season is over I'm coaching an 11-12 year old All Star team. Being the youngest on the team, Nick struggles with his self confidence even though he's an excellent baseball player. He's not the tallest player, but he's faster and more athletic than many of his older teammates. Even so, he doesn't want to take any risks or make any mistakes, and his insecurities often prevent him from performing at his best.

A few weeks ago in the league tournament Nick hit a ball against the fence, just short of going over. That was the closest he came all season to hitting one out, and was perhaps the first time he started to believe that it was possible. A few nights after our team was eliminated from the championship tournament, a kid hit a walk off grand slam with 1 out in the bottom of the 6th, down 9 - 6. Nick and I were there to watch it. I heard that the same kid hit one more out of the park later in the tournament. Those were very likely the only two over-the-fence home runs all year in our local league.

Sometime during tournament time, Nick's baseball bat disappeared from the trunk of my car. I suspect he didn't close the trunk all the way one night, and someone stole it during the night. The following week, in exchange for Nick agreeing to mow the lawn this summer, I bought him a shiny new baseball bat, a new bat bag, and new cleats to replace the old ones with holes in their toes. Nick was itching to play again so he could try out his new toys.

Fast forward to the all star team's second scrimmage earlier this week. In his first at bat, Nick got walked (then stole second, third, and home over the course of the next few pitches). In his second at bat, Nick hit a hard line drive into the gap, and got to second with a stand-up double. It was just a scrimmage, there was no pressure, and Nick was feeling good about himself, perhaps even daring to feel confident in himself.

His third time at the plate, Nick crushed the first pitch well over the center field fence amid groans from the opposing team. There was a mixture of surprise and elation among the other players on our team. Some had never seen a player at this level hit a ball over the fence, and I even had to remind them that they were allowed to enter the field to greet Nick as he crossed home plate.

The excitement was soon forgotten as the game moved along, until Nick came up to bat again and everyone jokingly told him to hit another home run. And then, with two strikes, two out, and two on, he did it again!

It's amazing how much difference a shiny new bat can make.

Vernor Decision Making a Splash

2008-05-22T09:03:00.003-04:00

From the NewsFeed on my ADSK v ODA web site:

"The court today issued an order denying Autodesk's motion to dismiss the charges in the Vernor lawsuit. Normally such a denial is perfunctory and mundane, but in this ruling the court performs a breathtaking analysis of whether the AutoCAD software was a sale or a license, and reaches conclusions that, if not reversed, are certain to change the face of software sales in the USA. Technically, the scope of this order is limited to simply refusing to grant Autodesk's motion to dismiss the lawsuit, but the implications of the judge's analysis are almost stunning in their rejection of Autodesk's legal claims. I'm sure you will be hearing much more about this order in the coming weeks, as the entire software industry will certainly take notice of this case."

Debugging ObjectARX: Break on Exception

2008-05-12T12:11:00.004-04:00

I have presented a class entitled High Octane ObjectARX at Autodesk University the past two years. In 2006 the focus was on project organization, and last year I focused more on techniques for supporting multiple versions of AutoCAD with a single Visual Studio solution, touching briefly on testing and profiling. For 2007 I plan to focus on debugging.

To get you in the mood, I decided to blog about a capability of Visual Studio that often goes unnoticed and unused: breaking on an exception. This works just like breaking on a code breakpoint, except the debugger breaks execution *before* the exception handler gets control, thus allowing you to get a clearer picture of what was happening immediately before the exception occurred.

In an ObjectARX project, all kinds of exceptions can occur. Sometimes they are perfectly normal exceptions caused by and handled by AutoCAD. Many times, especially during development, your code triggers an exception that causes AutoCAD to crash, and it's not obvious what caused things to go haywire.

When unexpected things happen while running your code under the debugger, the first order of business is to inspect the debug output window to determine what happened. The debug output window (Debug->Windows->Output) displays a message whenever an exception occurs. Sometimes a series of exceptions occur, usually all caused by the same root problem. Breaking when the first exception occurs will likely yield the most useful information about the cause.

Once you examine the debug output window to determine the type of exception that occurred, open the Exceptions dialog (Debug->Exceptions) and tell Visual Studio to break when the exception is thrown:

Visual Studio contains a prepopulated list of common exceptions to choose from, or you can add new ones if you need to break on an exception that is not already listed. Many times, breaking when the exception is thrown allows you to inspect the stack trace to determine which one of your functions is to blame -- and in the vast majority of cases, it will be your code that is at fault!

Hotel Autodesk

2008-04-30T13:06:00.004-04:00

Steve Johnson asks "where have all the developers gone?", and Deelip Menezes wonders in a comment whether Autodesk's annual release cycle for AutoCAD is part of the problem. I've always said that an annual release cycle is untenable. The annual release cycle is motivated by Autodesk's desire to make the subscription program look attractive. Has it worked?

Based on what I've read and heard through the grapevine, it has definitely worked. More customers than ever are choosing the subscription model. In many cases, the annual subscription business model actually works well for software like AutoCAD, providing benefits for both Autodesk and their customers. But subscription is not for everyone.

In typical greedy big corporate fashion, Autodesk have overplayed their hand. Instead of concentrating on those customers for whom subscription makes sense and leaving the others to choose a different model, the "more is always better" marketing machine kicked in. Ergo, the annual release cycle carrot and the AutoCAD retirement program stick were invented. [Oh sorry, it's called the Autodesk Loyalty Program.]

I am already seeing the beginnings of a movement of discontent among Autodesk customers, and I expect the annual release cycle to collapse under its own weight within another year or two. In the meantime, tremendous damage is being done. Customers, third party developers, authors, and consultants all suffer under the strain of the annual release cycle, but that's only the tip of the iceberg.

To pull off annual releases, Autodesk have to be working on multiple versions of AutoCAD in parallel. While AutoCAD 2006 was being beta tested, AutoCAD 2007 and 2008 were already under development, and AutoCAD 2009 was already in the planning stages. When CUI was first introduced to the public, the new ribbon UI was likely already in the planning stages. Is it any wonder that the angry feedback about CUI was ignored?

When you have an annual release cycle with 3 or 4 future releases on parallel tracks, you can't just stop and fix a fundamental design flaw. All you can do is increase your public relations budget. The harm done to third party developers is substantial, but the inability to shift gears and correct fundamental design flaws is the real travesty of the annual release cycle.

ManuSoft Software Updated for AutoCAD 2009

2008-04-16T02:10:00.003-04:00

QuikPik and Periscope are now available for AutoCAD 2009, and SuperPurge will be available later this week. QuikPik users, note that the quick buttons feature does not work with buttons on the new ribbon UI.

The Day the ObjectARX SDK Died

2008-03-27T16:09:00.003-04:00

Like that day almost 50 years ago, could today be the day that ObjectARX has died?

There have been a flurry of posts in the ObjectARX discussion group about problems downloading the new ObjectARX 2009 SDK. At first I dismissed the problems as new release hiccups, and expected things to get resolved in short order. Seeing that there were no new complaints this morning, I headed over to http://www.objectarx.com/ to download the new ObjectARX 2009 SDK. Instead of the new ObjectARX 2009 SDK, I received the following:

Maybe it's a technical problem with the web site, and the download just didn't start, I thought. I checked my email, and found this from Autodesk:

Thank you for your interest in development tools for Autodesk's products. If you are not already an Autodesk developer partner, be sure to visit the Autodesk Developer Network website at http://www.autodesk.com/joinadn to learn more. As a member, you can access timely technical information, training and support to help you stay competitive.
If you are looking for self-help resources for your Autodesk software-based development efforts, visit our Support page at http://www.autodesk.com/support or access the ObjectARX newsgroup at news://discussion.autodesk.com/autodesk.autocad.objectarx.
Regards,
The Application Development Team

Putting two and two together, it looks to me like the ObjectARX SDK is no longer freely available. It's not altogether surprising that Autodesk would try something like this in an (almost certainly misguided) attempt to make it more difficult for organizations like the Open Design Alliance to reverse engineer the API.

If this is true, I foresee a major sea change with a ripple effect that will change the face of third party add-on development. It's a risky legal maneuver, first of all. Any time a large corporation like Autodesk picks and chooses who it will do business with, it risks running afoul of the Sherman Antitrust Act. Secondly, the practical effect of limiting access to Autodesk's SDK will be to give Open Design Alliance more influence vis à vis its DRX SDK.

For now, there is not too much of an immediate impact. AutoCAD 2009 is binary compatible with AutoCAD 2007 and AutoCAD 2008, so software developed with those SDKs will work in AutoCAD 2009 (of course without utilizing the new features). Therefore, development of AutoCAD 2009 software can continue with only a minor hit. The problem will not be felt until the next release of AutoCAD, which presumably will no longer be binary compatible.

Where is all this headed? I'm still holding out hope that it's all a big misunderstanding; otherwise we're headed for some upheaval in the AutoCAD add-on industry.

[Update: as of early Friday morning the ObjectARX 2009 SDK download is now working!]

Creative Marketing

2008-02-23T10:33:00.002-05:00

This Autodsys press release made me chuckle. Their IntelliCAD based AcceliCAD now supports custom entities, announces the press release. "Instead of creating custom objects as is necessary in some other CAD packages the application developer can instead use the primitives already built into the program such as LINEs, ARCs, CIRCLEs, and POLYLINEs." Hmmm, that sounds an awful lot like blocks in AutoCAD -- a feature AcceliCAD has surely supported since its inception.

The press release continues, "That means there is no need to define grip points or editing operations for the entities because those functions are already built into AcceliCAD."

ObjectARX programmers have been able to create custom objects in AutoCAD for years. One of the most common reasons for creating a custom object is to "define grip points or editing operations". Otherwise, blocks work just fine in most cases.

Maps Are Evil

2008-01-16T23:55:00.000-05:00

One of the defining characteristics that distinguish humans from computers is our ability to act irrationally. Our biological computer system is capable of interjecting an otherwise logical thought process with random perturbations that often result in completely unpredictable outcomes. Looked at in the abstract, this is the essence of how we escape the shackles of destiny and turn an otherwise mundane march of time into a serendipity of human experience.

In practical terms, it's our ability to make mistakes that gives us supremacy over mere electronic circuits. If we were simply pre-programmed machines, we would be no better, and perhaps no different, than a computer. By making mistakes, we learn. By taking risks, we discover. By challenging and disregarding what is already known, we learn what is not.

And that, my friends, is why maps are evil.

Periscope Speaks HTML

2007-12-22T17:06:00.000-05:00

I hit the jackpot at Radio Shack, so I'm back early from my last minute Christmas shopping today. That means I have time to tell you about the new Periscope 4.0 just released this week, in case you're looking for a last minute stocking stuffer for that CAD geek friend of yours that already has everything.

Periscope shows information about the entity beneath your AutoCAD cursor in a tooltip window ("scope window") as you hover over an entity in AutoCAD. Periscope 3 added a COM interface that made it very easy to program a custom "extender" that added to or modified the displayed entity information. Periscope 4.0 goes even farther -- it uses an excellent open source class by Eugene Pustovoyt to render simple HTML in the scope window. Custom extenders for Periscope 4.0 can now use selected HTML tags to format and beautify their output.

If you're upgrading from a previous version of Periscope and you already use a custom extender, note that you will need to make a few minor modifications to your extender code. In addition to referencing the new type library (now version 4.0), you'll need to add a new "GSMarker" argument to your extender's AddScopeText event handler.

I've added a new .NET sample extender to show how easy it is to write a Periscope extender in .NET via COM interop. AutoCAD Map 3D 2008 and Topobase 2008 users, check out the commented code in the .NET sample extender to see how you can display feature data in the scope window!

Happy Holidays!