Registering an ARX/BRX module as a COM server

If you’re developing ARX modules that need to be registered as a COM server, you’re faced with some decisions about how to register them. In the old days before anyone cared about user permissions, registration could be safely accomplished at runtime, even via AutoLISP. Unfortunately runtime COM server registration just doesn’t work reliably any more under limited user accounts, not to mention registry redirection on 64-bit platforms. There is only one reliable way to register COM servers, and that’s doing it at install time under elevated privileges.

A normal Windows application might accomplish install-time registration by calling RegSvr32 after the files are copied to the destination folder, but this doesn’t work with ObjectARX or BRX modules. The reason it doesn’t work is because ARX modules cannot be loaded outside the AutoCAD or Bricscad process. RegSvr32 will fail with errors like “The module <filename> failed to load” or the even less helpful “The specified module could not be found.” There are some kludgy ways to get RegSvr32 to work anyway, but the simplest and most reliable way to solve this problem is to forget RegSvr32 and just add the needed registry values manually into your installer script. It’s not difficult, though it might be time consuming initially if your server implements a lot of COM objects.

At a minimum, a COM server must register at least one COM class under HKCRCLSID. If the COM server needs to support OLE Automation (e.g. VBA, AutoLISP) it must register a type library in HKCRTypeLib. In most cases, this is all that is needed, however you may also need to register a “ProgID” in HKCR if a script or in-process module needs to be able to connect to the server via human-readable ProgID.

Most installation script software can import Windows registry script (.reg) files, so it’s often helpful (and more maintainable) to create a registry script file manually, then simply import the .reg file into the installation script. If you use Visual Studio deployment projects, this is the only way to batch import registry values into the installation script. I’ve provided a minimal template for a registry script that registers a single COM object and ProgID. The template uses special characters as placeholders for the actual values: $$ is the human readable ProgID name, ## is the COM object’s CLSID, ** is the filename of your ARX module, and %% is the type library GUID. The type library and object class version numbers should match your actual version numbers as well, and of course [TARGETDIR] is the installation target directory that will be resolved at install time.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT$$.1]
@=”$$ Class”

[HKEY_CLASSES_ROOT$$.1CLSID]
@=”{##}”

[HKEY_CLASSES_ROOTCLSID{##}]
@=”$$ Class”

[HKEY_CLASSES_ROOTCLSID{##}InprocServer32]
@=”[TARGETDIR]**.arx”
“ThreadingModel”=”Apartment”

[HKEY_CLASSES_ROOTCLSID{##}ProgID]
@=”$$.1″

[HKEY_CLASSES_ROOTCLSID{##}Programmable]

[HKEY_CLASSES_ROOTCLSID{##}TypeLib]
@=”{%%}”

[HKEY_CLASSES_ROOTCLSID{##}VersionIndependentProgID]
@=”$$”

[HKEY_CLASSES_ROOTTypeLib{%%}]

[HKEY_CLASSES_ROOTTypeLib{%%}1.0]
@=”$$ 1.0 Type Library”

[HKEY_CLASSES_ROOTTypeLib{%%}1.0]

[HKEY_CLASSES_ROOTTypeLib{%%}1.0win32]
@=”[TARGETDIR]**.arx”

[HKEY_CLASSES_ROOTTypeLib{%%}1.0FLAGS]
@=”0″

[HKEY_CLASSES_ROOTTypeLib{%%}1.0HELPDIR]
@=”[TARGETDIR]”

It’s really not that complicated for a single module. The work can be tedious to create all the values for multiple modules in scenarios where you support multiple AutoCAD and/or Bricscad versions or platforms, but these values typically don’t change over the life of the project, so it only needs to be done once. Once you have created the registry values manually, disable all other forms of COM server registration such as wizard-generated runtime registration or automatic “self-registration” at install time. A bonus side effect of the manual registration approach is that a normal uninstall reliably removes all traces of the COM server registration.

A tale of two tethers

Those of you using your Android phone as an internet connection may be paying more than you need to pay. Many phone companies here in the US charge extra to enable tethering capability, either by providing their own OEM tethering app or by enabling the phone to serve as a Wi-fi hotspot.

With some experimenting, I found that my Motorola Droid 2 Global from Verizon can be tethered just fine right out of the box, and without paying anything extra.

Recently I’ve been playing nursemaid to my ill mother, so I frequently take my work along with me on overnight shifts. I’ve settled on connecting to my main desktop machine via remote desktop, and using my 15″ laptop as the client.

The remote desktop connection works great. My 3G connection is noticeably slow, but it’s very workable. Since I’m working on my office computer, there’s no need to sync anything, and I can pick up from one place right where I left off in another. In a pinch I can even use my phone as a client (using an inexpensive remote desktop client from Xtralogic).

To get my internet connection, I installed Motorola’s drivers on my Windows 7 laptop, then enabled the Bluetooth controller on my phone and paired it with the laptop. Now I can connect my laptop to the internet via Control Panel simply by connecting to the phone as an “Access Point”, as shown below.

Connecting to my Droid 2 Global via Bluetooth

I don’t know whether this technique works for other phones or other carriers, but it has certainly worked well for me.

The MFC Balloon

The MFC version that ships with Visual Studio 2010 is known to cause major explosions in file size when you link statically. To avoid that problem, I use the Visual Studio 2008 build tools for such cases. I recently got quite a surprise when I rebuilt one such MFC application and discovered that the executable had ballooned from 400kb to 2MB in the space of one week despite only very minor changes.

I assumed that one of my piddly little changes must have unleashed a dependency that sucked in the entire MFC library, which is exactly what happens in VS 2010. To test this hypothesis, I rolled back all my changes to the previous build state and did a complete rebuild. No change; the executable was still 2 MB. Wonderful.

It turns out a recent Visual Studio update (delivered automatically via Windows Update in my case) “broke” the VS 2008 MFC files, so they now suffer the same massive bloating problem that VS 2010’s MFC library suffers from. I applied the solution mentioned in this blog post (actually in my case I only needed to hack the afxglobals.cpp file). Now the MFC balloon is deflated again and my file sizes have dropped back to normal.

[Update 1: Ted has now tracked down more specifics about this problem and posted a cleaner solution.]

[Update 2: Microsoft has now fixed this problem at the source with updated patches.]

If you link statically to MFC with VS 2008 or VS 2010 in any of your projects, check your executable sizes now.