Skip to content
Archive of posts tagged Autodesk

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 HKCR\CLSID. If the COM server needs to support OLE Automation (e.g. VBA, AutoLISP) it must register a type library in HKCR\TypeLib. 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\$$.1\CLSID]
@=”{##}”

[HKEY_CLASSES_ROOT\CLSID\{##}]
@=”$$ Class”

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

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

[HKEY_CLASSES_ROOT\CLSID\{##}\Programmable]

[HKEY_CLASSES_ROOT\CLSID\{##}\TypeLib]
@=”{%%}”

[HKEY_CLASSES_ROOT\CLSID\{##}\VersionIndependentProgID]
@=”$$”

[HKEY_CLASSES_ROOT\TypeLib\{%%}]

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0]
@=”$$ 1.0 Type Library”

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\0]

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\0\win32]
@=”[TARGETDIR]**.arx”

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\FLAGS]
@=”0″

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\HELPDIR]
@=”[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.

Infinite Computing: Bah, Humbug!

At Autodesk University, Autodesk CEO Carl Bass introduced the term “Infinite Computing” in an attempt to define Autodesk’s perspective on “the cloud” from a unique angle. I think the term is a brilliant and effective use of terminology because it focuses an otherwise nebulous concept and it radiates a sense of real and immediate purpose.

Infinite computing is not really infinite, of course, and it’s certainly not infinitely accessible. However the metaphor is apt, because like the physical universe, as long as the virtual universe keeps expanding it is essentially infinite. [I can't resist having some fun and taking the analogy a little bit further: at some point, Moore's law will encounter relativistic effects, and we'll realize that every transistor warps the virtual space-time continuum in proportion to the square of its clock speed.]

So why am I bearish on the prospect of infinite computing?

Let’s say you buy a computer with multiple processors for, say, AutoCAD. Two processors can produce a nice performance boost, because AutoCAD can utilize 100% of one processor while the operating system uses the other. But what happens if you quadruple your capacity to eight processors? Unless you’re running independent programs that can use the extra processors, they offer very little benefit and are essentially wasted.

The moral of the story is this: an infinite computer is ineffective and inefficient unless it has an infinite number of simultaneous tasks to perform. It costs computing power to manage parallel tasks, so the practical limitations of “infinite” computing make it obviously unrealistic for all but highly specialized tasks. Even if we give it a more accurate name like “massively parallel computing“, such a system is hardly “sustainable” (to use another modern term of art) due to the inherent inefficiencies.

A compromise is necessary. There are new ways to look at old problems that enable a more parallel approach to finding solutions, and I have no doubt that many engineering problems can be restated in a way that makes them amenable to parallel processing solutions — but that’s hardly a revolutionary concept, and it certainly does not require an infinite computer for its implementation.

In the final analysis, “the cloud” is going to be about individuals connecting to each other and to their data seamlessly and in a location-agnostic way, and the “infinite computer” will be what they use to do it. Nothing more, nothing less.

Deelip Menezes Predicts a Cloudy Future

I had the good fortune of hearing Deelip Menezes deliver the keynote address at the Bricsys 2010 Conference in person. If you missed it, check out the video now at the Bricsys web site. The question and answer session after the speech is an excellent harbinger of the discussions to come if Deelip is correct in his prediction about CAD on the cloud.

Bricsys 2010 Developer Conference Post Mortem

I am back home after a whirlwind trip to the Bricsys 2010 Conference. I’m very happy to be back to Ohio food and my own bed. It was a great experience and well worth the trouble.

I’ve written before (and here) about the problem with food at conferences, and this one was no different. Unfortunately, there are no Burger Kings in Belgium, so the problem was compounded. I was excited when I saw a restaurant touting “American Food”, unfortunately it was “American Food as Europeans Imagine It”, which is not American food at all.

The hotel was, well, let’s just say you got that genuine experience of living in the past. Not quite the stone age past, but clearly before the age of modern locks and clocks — and well before air conditioning was invented. To make matters worse, housekeeping did not replace the provided shampoo and soap, so I had to make do with no soap on day 2 of the conference. The concert hall where the conference was held was also not air conditioned, which just compounded the problem — and certainly contributed to the dispersement of attendees from initially a small intimate group on day 1 to most of us sitting in the galleries by ourselves by the end of day 2.

The good news is that all the suffering was worthwhile. Bricsys was very accomodating, and it was a pleasure to meet modern day Robin Hood and Bricsys CEO Erik de Keyser and his merry band of men. Deelip Menezes’ keynote address about the future (cloud) of CAD (cloud) was (cloud) excellent, and the discussion that followed turned into a 12 round bout that Deelip played to a draw. Well done, Deelip, well done. I’m sure the fight will continue virtually, so take heed, and stay out of the line of fire.

I learned that Bricsys has made an impressive investment of time and resources into a foundation upon which to build a “DWG CAD” business. This is no longer about who can take on Autodesk. Autodesk conceded the AutoCAD (or “DWG”) market with their push toward subscription (aka “maintenance”), annual release cycles, and artificially high pricing on their platform technologies. There are literally dozens of companies trying to capture that market: products like ZWCAD and GstarCAD from China are hot on the heels of Bricscad. This is about who will emerge to control the market that Autodesk abandoned, and to some extent about how Autodesk will respond.

Bricscad is currently the clear leader among DWG CAD companies in terms of technical capabilities, but at least to date, it’s mostly AutoCAD application developers that recognize this (because of Bricsys’ very successful effort to make their BRX API source code compatible with ObjectARX). The question is whether they can convince consumers that Bricscad is the best choice. I think we will be a long way toward answering that question by this time next year, and of course the answer will be critically important to the DWG CAD market. I think it was shrewd of Bricsys to invite thought leaders like Deelip to this conference, but that is only a first step. Still, the very fact that I am writing and Deelip is blogging and tweeting about Bricscad is an important milestone on the road to respect.

[Full Disclosure: Bricsys paid for all my travel and conference expenses.]

AutoCAD 2011 EULA Changes

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

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

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

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

AutoCAD 2011 EULA Growth Chart