Outside The Box

RIP Alan Kalameja

owenw@manusoft.com (Owen Wengerd) — Tue, 09 Mar 2010 18:05:00 +0000

I saw in the March 8 edition of the TenLinks Daily newsletter that Alan Kalameja passed away at age 55. Condolences to his family. Alan hired me to write test questions for an AutoCAD certification exam in the early '90s (I don't recall which version, but probably either R12 or R13). That was one of my first real contracting jobs. Although it wasn't very glamorous, it made me feel important, and undoubtedly helped focus my fledgling consulting business on AutoCAD. Thanks, Alan, for giving me that opportunity.

Google killed the radio star

owenw@manusoft.com (Owen Wengerd) — Sun, 17 Jan 2010 17:40:00 +0000

This post is inspired by a conversation I had with a nephew, and it hearkens to the same nostalgic emotions engendered by the first music video on MTV.

I was a young inquisitive child growing up in the 70s in an Amish household. Without access to modern technology, I struggled at age 11 to build an oscillator circuit by using sheet metal cut from an old stovepipe, a 9 volt battery fitted into a piece of 2x6 pine, dynamite wire scavenged from the nearby strip mine, and a speaker and 555 timer IC that I cut out of some electronic equipment dug out of the local garbage dump.

The achievement was incredible considering the circumstances, but thinking back, I have very little recollection of the actual consummation of the project. I assume I probably showed it proudly to my friends, who would have been awestruck, but completely ignorant of how it worked or why it was important to me. I simply don't remember what I did with the project after it was complete.

What I do remember fondly is the struggle to achieve; the thrill of the hunt. I struggled to get information. I had obtained a prized 555, but I had to wait for weeks until the next trip to the city so I could stop by Radio Shack to get a pinout of the 555 along with circuit diagrams showing how to use it. Then I had to find components. I had long since built a treasure trove of capacitors and resistors that I had salvaged from discarded electronics, along with a pot full of potentiometers that I could use to adjust the oscillator frequency, but I still had to scavenge for some missing components.

The challenges of the quest made the final result more satisfying. It was the search for the holy grail that etched itself into my memory; I barely remember the grail itself.

Over the holidays during a family gathering, one of my Amish nephews was anxious to pick my brain. He explained that someone had told him that it's possible to convert an electric motor into a generator, and so he set out on a quest to build a generator from an old electric motor and a small gasoline engine. The quest involved several letters mailed back and forth between people he knew that might have information about how to go about the task. He tried and tried, but could not get his generator to work.

I explained to him how he needed to remove the external circuitry from his motor so that it wouldn't foul up the results; how he can add a rectifier and a regulator to generate direct current output. The excitement over this new discovery was written all over the young man's face as he anticipated more adventure.

On the way home, I thought to myself that Google could quickly and easily have provided the answers that my nephew sought. But then it occurred to me that Google would also have deprived him of the struggle and adventure of discovery that motivates him to continue the quest.

I wonder how many young minds are missing out on the supreme adventure of discovery because we live in a modern culture where all the knowledge in the universe is seemingly already at our fingertips, just a Google search away.

Visual Studio 2010 and VC Build Hook

owenw@manusoft.com (Owen Wengerd) — Tue, 12 Jan 2010 01:32:00 +0000

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.

Automatic LISP Loading

owenw@manusoft.com (Owen Wengerd) — Thu, 24 Dec 2009 17:12:00 +0000

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.

ObjectARX application developers have long used registry demand loading to load their applications automatically, either when AutoCAD starts or when the user enters a command that the application defines. Registry demand loading is relatively easy to set up and meets the other requirements for an ideal solution, except for one problem: it works only with ObjectARX modules (or with .NET modules in AutoCAD 2006 and later).

Many years ago, I created a solution to this problem by building a small stub ObjectARX module that did nothing but load an associated LISP file. This effectively allows the registry demand loading mechanism to be used for loading a LISP file. If you develop AutoLISP applications that could benefit from registry demand loading, then I have a Christmas present for you: LspLoad.zip contains a complete suite of newly updated stub modules for all versions of AutoCAD from AutoCAD 2000 to AutoCAD 2010, plus modules for Bricscad 9 and 10, which also supports registry demand loading.

To use the stub modules, just rename them so that the base filename matches your application's main LISP filename, then install them in the same folder as the LISP file and create the registry demand load entries. The only work you have to do is to get the stub module to load. You can simply drag and drop the appropriate stub module into a running instance of AutoCAD in order to test it.

Creating the demand loading registry keys is not difficult, but it may require some programming. I write custom actions for my installation programs that enumerate all installed AutoCAD versions and flavors, and set up the demand load keys for every one. However you do it, the final result should look something like this (for AutoCAD 2010 on my system):

In this screen shot, I created an application called "!LspLoadTest" (the "!" was added just so it displayed at the beginning of the list). I added the minimum required subkeys. The LOADER string value is set to the complete path of the stub module, and LOADCTRLS is set to a value of 2, which means I want the application loaded when AutoCAD starts. LOADCTRLS is a bit coded value; for use with LspLoad, it's only useful values are 2 or 4. A value of 4 means "load when my command is invoked"; this mode requires a COMMANDS subkey that lists the defined commands.

The way it works is very simple. In the example above, you can see that I renamed the module (but left the ".18.x64.arx" so that I can tell it apart). I then added !LspLoadTest.lsp to the W:\LspLoad folder. That file contained the following:

(princ "\nThis test file loaded from ")
(princ (if GetPathOf!LspLoadTest (GetPathOf!LspLoadTest) ""))
(princ)

Now when I start AutoCAD 2010, I see on the command line:

This test file loaded from W:\LspLoad\

These files are free to use for any purpose. Have a great holiday, everyone!

Evil Banks

owenw@manusoft.com (Owen Wengerd) — Wed, 11 Nov 2009 20:10:00 +0000

A lot of you are probably having to cut back on your expenses to make ends meet in this economic downturn. I've drastically reduced my discretionary spending, postponed the purchase of new office equipment, and investigated less expensive alternatives to a lot of my monthly expense items. I've also been streamlining and reorganizing my finances, which inevitably involves a lot of contact with banks.

Kean Walmsley's post about his recent bank customer service issue motivated me to post about one of my recent bank experiences.

First of all, I'm here to tell you that banks do make mistakes. I'm sure that the vast majority of the time when your check book doesn't balance, it was you that made a mistake, and not the bank. But if you are cursed like I am, then banks delight in creating phantom overdrafts and charging you exorbitant overdraft fees, then, when confronted with their error, apologizing and refunding the fees (after the damage is done and all those bounced checks have caused you to incur returned check charges from your creditors). That has happened twice to me in the past two months, with two different banks and two completely unrelated accounts.

In both cases, the bank eventually fixed the error, but I'm still out the returned check charges and whatever damage that has done to my credit rating.

One of the "returned" payments was a credit card payment. Of course, I did not get notified about this until the day after the payment due date, so it was too late to fix the problem in time to prevent another exorbitant late fee from being charged by the credit card bank.

Obviously the returned check triggered some alarms at the credit card bank, because I started receiving phone calls begging me to make a payment immediately. Irritated, I decided to make the credit card bank wait until the next due date before making the replacement payment. I figured my late fee bought me that extra time, so I might as well use it. My patience paid off: after a few futile attempts at collecting their late payment, the bank offered to refund the late fee if I made an immediate payment. That's what I'm talking about!

ArxDbg Utility

owenw@manusoft.com (Owen Wengerd) — Wed, 23 Sep 2009 23:31:00 +0000

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.

As you can see, the UI consists of a single context menu. One of my favorite features is the ability to spelunk through a drawing database, looking at every object and its relationships to other objects. The command is ArxDbgSnoopDb, or you can select 'Database Info...' in the ArxDbg context menu.

There is no documentation, but anyone with a basic familiarity with the AutoCAD object model can figure out what most of the commands do. ArxDbg.zip [1 Mb] includes versions of the utility for all versions of AutoCAD from AutoCAD 2000 through AutoCAD 2010.

AutoCAD Missing Language Pack Drawing File Corruption

owenw@manusoft.com (Owen Wengerd) — Mon, 03 Aug 2009 18:38:00 +0000

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. See also Shaan Hurley's blog post.]

If you want it done right...

owenw@manusoft.com (Owen Wengerd) — Wed, 08 Jul 2009 14:05:00 +0000

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.

Disable InfoCenter in AutoCAD 2010

owenw@manusoft.com (Owen Wengerd) — Mon, 30 Mar 2009 23:13:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Sat, 28 Mar 2009 21:54:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Wed, 25 Mar 2009 05:55:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Sun, 01 Mar 2009 23:03:00 +0000

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?

owenw@manusoft.com (Owen Wengerd) — Sun, 01 Mar 2009 22:48:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Fri, 27 Feb 2009 15:51:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Tue, 24 Feb 2009 19:56:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Thu, 12 Feb 2009 19:35:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Wed, 28 Jan 2009 17:00:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Sat, 24 Jan 2009 22:07:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Mon, 22 Dec 2008 23:15:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Sat, 06 Dec 2008 19:52:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Wed, 15 Oct 2008 22:58:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Sun, 28 Sep 2008 01:28:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Sun, 24 Aug 2008 19:42:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Wed, 30 Jul 2008 03:35:00 +0000

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

owenw@manusoft.com (Owen Wengerd) — Sat, 28 Jun 2008 03:48:00 +0000

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.