Outside The Box
Random thoughts about AutoCAD, ObjectARX, and the meaning of life.
All Original Content Copyright 2006 - 2008 Owen Wengerd, All Rights Reserved
2008-04-30
Hotel Autodesk
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.
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.
2007-09-06
AutoCAD 2008 Slow Startup Fix
I've noticed more frequent posts in the Autodesk discussion groups about slow startup problems since AutoCAD 2008 was released, and I have the same problem on my development system. Part of the problem is .NET loading, due to the new .NET gadgets like the dashboard palette. Another long running startup hassle is the communication center (WSCommCntr1.exe if you check running processes in task manager) that Autodesk products use to call home.
In addition to the time the communication center process takes to start up, it can also get "stuck" (either due to network or connection problems, or because of AutoCAD crashing) and cause interminable startup delays. If AutoCAD is trying to start while the communication center is "stuck", it will wait in a completely frozen state for about 2 minutes before it times out and loading continues.
In addition, AutoCAD 2008 service pack 1 introduced a new "pure virtual function call" C runtime error that shows up when the communication center closes after an AutoCAD crash.
All these problems can be easily fixed by disabling the AutoCAD InfoCenter, which is the culprit that loads the communication center background process. I disabled it by changing the demand load registry key for the InfoCenter. That key can be found in the registry at:
Change the LOADCTRLS value to 0 (zero) to disable it from demand loading.
If you disable your InfoCenter from demand loading, you can still load it manually by using the NETLOAD command to load AcInfoCenterConn.dll from the AutoCAD 2008 folder.
In addition to the time the communication center process takes to start up, it can also get "stuck" (either due to network or connection problems, or because of AutoCAD crashing) and cause interminable startup delays. If AutoCAD is trying to start while the communication center is "stuck", it will wait in a completely frozen state for about 2 minutes before it times out and loading continues.
In addition, AutoCAD 2008 service pack 1 introduced a new "pure virtual function call" C runtime error that shows up when the communication center closes after an AutoCAD crash.
All these problems can be easily fixed by disabling the AutoCAD InfoCenter, which is the culprit that loads the communication center background process. I disabled it by changing the demand load registry key for the InfoCenter. That key can be found in the registry at:
HKLM\Software\Autodesk\R17.1\[ACAD-XXXX:XXX]\Applications\InfoCenterAcConn
Change the LOADCTRLS value to 0 (zero) to disable it from demand loading.
If you disable your InfoCenter from demand loading, you can still load it manually by using the NETLOAD command to load AcInfoCenterConn.dll from the AutoCAD 2008 folder.
2007-08-17
Brutal
I've heard the word "brutal" used more than once during conversations with Autodesk employees about the Autodesk sponsored discussion groups. It's true that raw unfiltered feedback can be brutal, and it can also hurt your ego if you happen to be the target of criticism. The trick is to learn how to interpret the feedback. If you can master that skill, that raw feedback is a fast, unbiased, low noise-to-signal-ratio predictor of the future.
I've seen many recognizable Autodesk names come and go since the days of Autodesk's original online discussion group, the CompuServe ACAD forum. Oftentimes, they came espousing the virtues of such a vibrant community, only to wilt away after they got singed a few times in the inevitable flame wars. Some Autodesk names (Art Cooney comes to mind) have been around forever, and still take it all in stride. Personally, I view the discussion groups as one of Autodesk's biggest competitive advantages, even while they go largely untapped.
This week saw too issues erupt into what could fairly be termed brutal feedback. The first was caused by the Autodesk University registration site failing under the load of opening day registration. Several threads ("Dear Carl Bass" and "AU2007 Registration is now open!!!") called Autodesk to the carpet for blowing it again, after a similar fiasco in 2006.
The second event occurred when AutoCAD product manager Eric Stover announced a new "bonus" tool called CommandComplete. I pity the poor guy or gal that wrote this tool (on their own time, I'm sure), all excited to see how it is received, only to become the victim of a flame war. Okay, not really a flame war in this case because Eric employed his finely tuned flame retardant diplomacy skills to prevent it from getting out of hand -- so let's just call it a "venomous reaction".
There is a moral to this story. Some companies would kill to have access to this kind of critical, unfiltered, instantaneous feedback from the unwashed masses. I hope Autodesk recognizes the goose that lays the golden egg.
I've seen many recognizable Autodesk names come and go since the days of Autodesk's original online discussion group, the CompuServe ACAD forum. Oftentimes, they came espousing the virtues of such a vibrant community, only to wilt away after they got singed a few times in the inevitable flame wars. Some Autodesk names (Art Cooney comes to mind) have been around forever, and still take it all in stride. Personally, I view the discussion groups as one of Autodesk's biggest competitive advantages, even while they go largely untapped.
This week saw too issues erupt into what could fairly be termed brutal feedback. The first was caused by the Autodesk University registration site failing under the load of opening day registration. Several threads ("Dear Carl Bass" and "AU2007 Registration is now open!!!") called Autodesk to the carpet for blowing it again, after a similar fiasco in 2006.
The second event occurred when AutoCAD product manager Eric Stover announced a new "bonus" tool called CommandComplete. I pity the poor guy or gal that wrote this tool (on their own time, I'm sure), all excited to see how it is received, only to become the victim of a flame war. Okay, not really a flame war in this case because Eric employed his finely tuned flame retardant diplomacy skills to prevent it from getting out of hand -- so let's just call it a "venomous reaction".
There is a moral to this story. Some companies would kill to have access to this kind of critical, unfiltered, instantaneous feedback from the unwashed masses. I hope Autodesk recognizes the goose that lays the golden egg.
Labels: Autodesk, CAD Industry, discussion groups
2007-01-08
I'll take web sites for $200, Alex: Part I
I'm one of those throwbacks that learned HTML by typing it in Notepad. I've since moved up to using the Visual Studio editor; it does syntax coloring, error highlighting, and has a "design" mode for previewing the page, yet it's a very utilitarian editor that I feel comfortable with. I do use FrontPage when I need to manage connections between multiple HTML pages, but mostly in raw HTML mode. When I use WYSIWYG design mode in FrontPage, I inevitably end up cleaning out a lot of unnecessary junk that it includes in the generated HTML. I think it's fair to say that my obsession with clean HTML results in utilitarian, functional, and standards conformant presentations -- but with a decided lack of graphic appeal.
The ManuSoft and CADLock web sites are examples of this utilitarian approach. The ManuSoft site uses no fancy graphics and relies very little on client side scripting, and it supports a hierarchical navigation system using only standard hyperlinks. I like that minimalist approach, but the price for clean HTML being served to clients is a lot of work on the server to maintain the site. As a result, I don't update the site very often because it's just too difficult.
This blog was the first step toward realizing a goal of making it easier to add new content. After all, the raison d'être of blogs is to minimize the latency between the writer's stream of consciousness and words on the web by making it irresistibly easy to add new content. This is precisely why blogs have become so popular.
Unfortunately, I soon found limitations with my blog. Tabular lists of data still require manual HTML input, it is difficult to customize the content area outside the individual posts on the blog page, and most aspects of the hosted blog software are outside my control. I wanted more.
The Autodesk vs. Open Design Alliance lawsuit gave me an excuse to take the next step: implement the "blog" concept across an entire web site with software that I control. So, I decided to swallow my pride and learn how to create an entire web site that would be so easy to update that I would actually update it frequently -- even if it meant messy HTML code. Stay tuned for Part II, choosing a hosting service and deciding which software to use.
The ManuSoft and CADLock web sites are examples of this utilitarian approach. The ManuSoft site uses no fancy graphics and relies very little on client side scripting, and it supports a hierarchical navigation system using only standard hyperlinks. I like that minimalist approach, but the price for clean HTML being served to clients is a lot of work on the server to maintain the site. As a result, I don't update the site very often because it's just too difficult.
This blog was the first step toward realizing a goal of making it easier to add new content. After all, the raison d'être of blogs is to minimize the latency between the writer's stream of consciousness and words on the web by making it irresistibly easy to add new content. This is precisely why blogs have become so popular.
Unfortunately, I soon found limitations with my blog. Tabular lists of data still require manual HTML input, it is difficult to customize the content area outside the individual posts on the blog page, and most aspects of the hosted blog software are outside my control. I wanted more.
The Autodesk vs. Open Design Alliance lawsuit gave me an excuse to take the next step: implement the "blog" concept across an entire web site with software that I control. So, I decided to swallow my pride and learn how to create an entire web site that would be so easy to update that I would actually update it frequently -- even if it meant messy HTML code. Stay tuned for Part II, choosing a hosting service and deciding which software to use.
Labels: Autodesk, CMS, ODA, programming, Visual Studio
2007-01-06
AutoCAD LT Upgrade Windfall
Did you know that Autodesk is offering a promotional upgrade price to AutoCAD LT users until January 19th? Check out http://www.adskhost.net/43404/solution.php. According to that web page, you can upgrade an AutoCAD LT 2004/2005/2006 license to any one of several AutoCAD 2007 based software offerings from AutoCAD 2007 to Inventor Series -- for $1995. If you have an LT license, now might be a good time to upgrade it.
Labels: AutoCAD, AutoCAD LT, Autodesk
2006-12-12
Autodesk vs. ODA
The recently filed lawsuit has been a hot topic lately, and I've been following it along with everyone else. As a little side project, I decided to create a parallel blog dedicated to the ongoing battle between Autodesk and ODA. The new blog is at http://www.ADSKvODA.com.
The site is still a work in progress, but I hope you'll check it out, and offer suggestions for improvements. Click on the Lawsuit Tracker link to view all the court documents in the case, and subscribe to the site's feed to stay informed of new developments.
The site is still a work in progress, but I hope you'll check it out, and offer suggestions for improvements. Click on the Lawsuit Tracker link to view all the court documents in the case, and subscribe to the site's feed to stay informed of new developments.
2006-12-10
The secret world of file formats
No matter the communication protocol used to transmit it, most information gets packaged into a file format for consumption. File formats are like virtual checkpoints along the information superhighway, and we would do well to pay attention to who is manning the gates.
We've heard a lot of noise lately about the need for "open" file formats, but documenting a file format is not the same thing as relinquishing control of the format. The key consideration is who decides when and how the file format changes. This is a dirty little secret about file formats that you are not supposed to know. By controlling when and how a file format changes, an organization can maintain a mindshare monopoly over consumers of its file format -- even when the format is "open".
It may be that the relative anarchy of the internet has given us a false sense of security. We happily use "open" formats like PDF, DWF, DXF, HTM, and others with relatively little concern about who controls them, but all of those formats (HTM perhaps to a lesser degree) are controlled by corporations whose allegiance is first and foremost to their shareholders. For example, PDF is "open", but did you know that third party developers need a digital ID signed by Adobe in order to create forms-enabled PDF files that can be opened in the free Acrobat Reader?
In April of 2006, Autodesk filed a trademark application for the word "DWG" when used to refer to DWG files. This may seem benign on the surface, but if successful it will give Autodesk more legal leverage in "defending" the file format. A few weeks ago, Autodesk filed a trademark infringement lawsuit against the Open Design Alliance claiming that the ODA infringed their "AUTODESK" trademark by embedding the mark inside DWG files created with its DWGdirect libraries.
Much has been written by the pundits about the pros and cons of the ODA lawsuit, and the Electronic Frontier Foundation predictably suggests that Autodesk is using trademark claims to stymie interoperability, but the bottom line is that the contention centers around a file format -- a file format that Autodesk considers valuable enough to wage war over.
We've heard a lot of noise lately about the need for "open" file formats, but documenting a file format is not the same thing as relinquishing control of the format. The key consideration is who decides when and how the file format changes. This is a dirty little secret about file formats that you are not supposed to know. By controlling when and how a file format changes, an organization can maintain a mindshare monopoly over consumers of its file format -- even when the format is "open".
It may be that the relative anarchy of the internet has given us a false sense of security. We happily use "open" formats like PDF, DWF, DXF, HTM, and others with relatively little concern about who controls them, but all of those formats (HTM perhaps to a lesser degree) are controlled by corporations whose allegiance is first and foremost to their shareholders. For example, PDF is "open", but did you know that third party developers need a digital ID signed by Adobe in order to create forms-enabled PDF files that can be opened in the free Acrobat Reader?
In April of 2006, Autodesk filed a trademark application for the word "DWG" when used to refer to DWG files. This may seem benign on the surface, but if successful it will give Autodesk more legal leverage in "defending" the file format. A few weeks ago, Autodesk filed a trademark infringement lawsuit against the Open Design Alliance claiming that the ODA infringed their "AUTODESK" trademark by embedding the mark inside DWG files created with its DWGdirect libraries.
Much has been written by the pundits about the pros and cons of the ODA lawsuit, and the Electronic Frontier Foundation predictably suggests that Autodesk is using trademark claims to stymie interoperability, but the bottom line is that the contention centers around a file format -- a file format that Autodesk considers valuable enough to wage war over.
Labels: Adobe, Autodesk, EFF, file formats, ODA
2006-12-05
Does Vista really open DWF files?
Not according to the press release. Vista (and .NET 3.0) includes a built-in XPS Viewer (also available for Windows XP SP2 and Windows Server 2003), which will view any XPS format file. Apparently Autodesk plans to add support for output to XPS format in the future, and this output will be called DWFx -- a new file format. It's not clear what the difference will be between DWFx and the output produced using the Microsoft XPS Document Writer that is already available.
I installed the Microsoft XPS Document Writer and XPS Viewer on my Windows XP SP2 machine. Next, I started AutoCAD 2007 and opened "3D House.dwg" from the Sample folder. I then plotted this file to DWF, PDF, and XPS, with the following results:
I'm not suggesting that these files all contain the same content, I'm merely suggesting that DWFx/XPS may have some undesirable tradeoffs in practice.
This whole issue about "native Vista support for DWF" may be nothing but smoke and mirrors. There is no guarantee that publishing CAD data in the XPS format will be efficient. So what will happen if users can choose between a compact DWF, a slightly less compact but ubiquitous PDF, or a very space-hungry DWFx? Time will tell, but I think this issue of DWF in Vista is getting way to much spin and not enough critical analysis.
I installed the Microsoft XPS Document Writer and XPS Viewer on my Windows XP SP2 machine. Next, I started AutoCAD 2007 and opened "3D House.dwg" from the Sample folder. I then plotted this file to DWF, PDF, and XPS, with the following results:
| Plotter | Plot Time | File Size |
|---|---|---|
| DWF6 ePlot.pc3 | 7 seconds | 139 kb |
| DWG To PDF.pc3 | 5 seconds | 165 kb |
| Microsoft XPS Document Writer | 34 seconds | 829 kb |
I'm not suggesting that these files all contain the same content, I'm merely suggesting that DWFx/XPS may have some undesirable tradeoffs in practice.
This whole issue about "native Vista support for DWF" may be nothing but smoke and mirrors. There is no guarantee that publishing CAD data in the XPS format will be efficient. So what will happen if users can choose between a compact DWF, a slightly less compact but ubiquitous PDF, or a very space-hungry DWFx? Time will tell, but I think this issue of DWF in Vista is getting way to much spin and not enough critical analysis.
Labels: Autodesk, DWF, file formats, Microsoft, Vista
About Me
- Name: Owen Wengerd
- Location: Apple Creek, Ohio, United States
I'm a starving artist specializing in the programming genre. I work in my home office, where I am the owner and sole proprietor of ManuSoft as well as the President and chief software artist of CADLock, Inc.
Syndication
Recent Comments
ralphg:I recall an Autodesk executive telling me that Microsoft was envious at how fast the CAD company churned out releases.
@ April 30, 2008 7:17:00 PM EDT
ralphg:Thanks for the tip!
@ September 10, 2007 1:20:00 PM EDT
Scott:This seemed to work for me. How about speeding up the shutdown as well?
@ September 10, 2007 8:50:00 PM EDT
R.K. McSwain:Great tip. Thanks Owen.
@ October 30, 2007 4:01:00 PM EDT
:Thanks a lot!
@ November 19, 2007 2:31:00 AM EST
:Thanks, very helpful. The reg address was a little different for LT, but still works
@ February 26, 2008 4:12:00 AM EST
:Thanks I started getting this error after I upgraded to SP1 worked like a charm.
@ April 14, 2008 7:37:00 PM EDT
:Very good post.
@ August 19, 2007 9:19:00 AM EDT
:"..the unwashed masses." I wash every day.
The downside to having a ravenous fan base is you have a ravenous fan base.
@ September 10, 2007 4:56:00 PM EDT
Deelip Menezes:Well, I really do not care who decides to change the version or specification of an "Open" file format, as long as they provide the general public all the information (or preferably libraries) it needs to read and write the concerned files. File formats have to change over a period of time, due to a variety of valid reasons. I would prefer a corporation taking "control" of their "open" format rather than a bunch of individuals who do not all move in a single direction.
@ December 11, 2006 2:37:00 AM EST
Owen Wengerd:Deelip, I agree that corporations tend to be much better than "standards bodies" at maintaining file formats. Philosophically, I'm not against letting the free market act as the counterweight to balance corporate control of file formats -- but I still worry about being taken hostage.
@ December 11, 2006 3:24:00 PM EST
CADxp:Thanks Owen for these precisions. Very interesting indeed... I have now a very different opinion on the DWF in Vista and less in a hurry to advise Vista at work...
@ December 10, 2006 5:18:00 AM EST
Scott:Autodesk is not using the XPS Writer to produce DWFx files. We are merely swapping out the existing 2D format for one that is XPS compliant. We are modifying the DWF Toolkit to do this. We are not going through GDI like the Microsoft XPS Writer.
What will be different from a DWFx file from a vanilla XPS file is that DWFx will also have the other data, e.g. 3D and metadata. This means that an Autodesk viewer user will have a more powerful viewing experience. With the switch to DWFx, at least a Microsft XPS Viewer user can see the 2D data. Today a user has no choice but to use Project Freewheel or download a viewer from Autdoesk. In the future, he will have a third choice - the Microsoft XPS Viewer, which as a Vista user, he will already have installed.
@ December 11, 2006 10:34:00 AM EST
Owen Wengerd:Thanks for the clarification, Scott. It will be interesting to see whether DWFx can achieve parity with DWF 6 as far as file sizes and generation times. The proof will be in the pudding, I guess. :)
@ December 11, 2006 3:12:00 PM EST