Outside The Box
Random thoughts about AutoCAD, ObjectARX, and the meaning of life.
All Original Content Copyright 2006 - 2008 Owen Wengerd, All Rights Reserved
2007-11-26
The new Visual Studio 2008 has been released, and to celebrate, I've updated VC Build Hook. The updated utility allows you to use the new IDE while still building with older versions of the build tools.
Why is this necessary? If you build your AutoCAD 2007/2008 ObjectARX application with the Visual C/C++ 9.0 tools, AutoCAD will display a warning message about an incompatible module when you try to load it. You can use VC Build Hook to target all previous AutoCAD versions from a single Visual Studio 2008 solution (if you have the correct version of Visual C/C++ installed alongside Visual Studio 2008).
In my testing so far, existing Visual Studio 2005 projects build without problems in Visual Studio 2008 when VC Build Hook is installed and the new 'BuildToolVersion' property is set to the correct version.
Why is this necessary? If you build your AutoCAD 2007/2008 ObjectARX application with the Visual C/C++ 9.0 tools, AutoCAD will display a warning message about an incompatible module when you try to load it. You can use VC Build Hook to target all previous AutoCAD versions from a single Visual Studio 2008 solution (if you have the correct version of Visual C/C++ installed alongside Visual Studio 2008).
In my testing so far, existing Visual Studio 2005 projects build without problems in Visual Studio 2008 when VC Build Hook is installed and the new 'BuildToolVersion' property is set to the correct version.
Labels: Microsoft, ObjectARX, programming, Visual Studio
2007-03-02
No, Microsoft didn't really try to patent photons, but check out the the ironic twists described in this account of a recent US Supreme Court hearing. Here's a summary (exaggerated a bit for effect):
1. Microsoft argues that software is not patentable, therefore it is not guilty of patent infringement.
2. The US Government argues on Microsoft's behalf that software is patentable, but photons are not.
1. Microsoft argues that software is not patentable, therefore it is not guilty of patent infringement.
2. The US Government argues on Microsoft's behalf that software is patentable, but photons are not.
2007-03-01
I pointed out in a previous post that while the press release headlines pronounced that Vista will support DWF natively, the fine print says otherwise. What Vista does support natively is Microsoft's new XPS (XML Paper Specification) format. Autodesk has since clarified that they are working on a new DWF format called DWFx that is, essentially, a DWF in XPS format.
A quick test verified my suspicions that XPS files produced by the Microsoft XPS Document Writer are much larger than comparable DWF files. The jury is still out on DWFx file sizes, but a recent post on Scott Sheppard's blog (http://dwf.blogs.com:80/beyond_the_paper/2007/02/autocad_2008_dw.html) has buried within it a telling comparison point between DWF and DWFx.
The chart uses a neat gambit by comparing both DWF and DWFx file sizes to the completely different DWG format, but the math cognoscenti among you will notice that "typically 1/20 the size of the DWG" for DWF and "typically 1/10 the size of the DWG" for DWFx translates into "DWFx files are twice as large as DWF". There is no information on file generation times, another metric worth monitoring.
Autodesk has been pretty generous lately, first giving away Design Review, now perhaps gearing up for an exclusive two-for-the-price-of-one deal on DWFx. I haven't heard too many customers requesting larger file sizes, though.
A quick test verified my suspicions that XPS files produced by the Microsoft XPS Document Writer are much larger than comparable DWF files. The jury is still out on DWFx file sizes, but a recent post on Scott Sheppard's blog (http://dwf.blogs.com:80/beyond_the_paper/2007/02/autocad_2008_dw.html) has buried within it a telling comparison point between DWF and DWFx.
The chart uses a neat gambit by comparing both DWF and DWFx file sizes to the completely different DWG format, but the math cognoscenti among you will notice that "typically 1/20 the size of the DWG" for DWF and "typically 1/10 the size of the DWG" for DWFx translates into "DWFx files are twice as large as DWF". There is no information on file generation times, another metric worth monitoring.
Autodesk has been pretty generous lately, first giving away Design Review, now perhaps gearing up for an exclusive two-for-the-price-of-one deal on DWFx. I haven't heard too many customers requesting larger file sizes, though.
Labels: DWF, file formats, Microsoft, Vista
2007-01-11
With the advent of Visual Studio 2005 and automatically generated manifest files, the topic of when and how to use manifest files comes up occasionally. Since a default ObjectARX wizard generated project in Visual Studio 2005 generates an embedded manifest by default, most people don't even think about it. Of course that was the whole idea -- the manifest would ensure that the correct dependent DLLs get loaded, and voila, no *need* to think about it. One of my programming axioms applies in this case: TANSTAAFL.
The problem is that ObjectARX applications are not in charge. AutoCAD is in charge, and it will decide which VC runtime and MFC runtime DLLs to load. If your ObjectARX application loads a different VC or MFC runtime than the ones AutoCAD is using, you'll encounter big problems. I've always advised disabling the manifest completely (see my ObjectARX Tips page) to avoid such a possibility. Unfortunately, there's a catch.
The problem is that linking to the ATL80.DLL file isn't possible by just disabling the manifest and doing nothing more. ATL is now a side-by-side (SxS) assembly, and it no longer lives on the Windows support path, so a standard un-manifested DLL won't be able to find it. The preferred solution is to link statically to ATL (see Configuration -> General -> 'Use of ATL' in VS 2005 project properties) and avoid the problem altogether. If you only have one module that uses ATL, this is always the best solution.
The less desirable solution is to add a *manually-created* manifest that specifies the desired ATL SxS assembly, but ignores the VC and MFC runtime DLLs. You'll still need to decide whether to make ATL shared or private, and in either case you *must* distribute ATL with your application to ensure that it is available when your application is deployed. You can cheat, and let VS generate your manifest file (instruct it to *not* embed the file), then just edit the resulting .manifest file to remove references to the VC and MFC assemblies. For example, here's one that I generated (you'll need to generate your own to ensure that the manifest matches the version you are redistributing):
In my work, I've had very little need for manifests. The VC optimizer is able to strip the unused portions of statically linked ATL out of your code, leaving a much smaller footprint than the entire assembly would require. This eliminates the need to redistribute ATL with your application, thus reducing the overall potential for deployment issues. Nevertheless, there are exceptions to every rule, and your mileage may vary.
The problem is that ObjectARX applications are not in charge. AutoCAD is in charge, and it will decide which VC runtime and MFC runtime DLLs to load. If your ObjectARX application loads a different VC or MFC runtime than the ones AutoCAD is using, you'll encounter big problems. I've always advised disabling the manifest completely (see my ObjectARX Tips page) to avoid such a possibility. Unfortunately, there's a catch.
The problem is that linking to the ATL80.DLL file isn't possible by just disabling the manifest and doing nothing more. ATL is now a side-by-side (SxS) assembly, and it no longer lives on the Windows support path, so a standard un-manifested DLL won't be able to find it. The preferred solution is to link statically to ATL (see Configuration -> General -> 'Use of ATL' in VS 2005 project properties) and avoid the problem altogether. If you only have one module that uses ATL, this is always the best solution.
The less desirable solution is to add a *manually-created* manifest that specifies the desired ATL SxS assembly, but ignores the VC and MFC runtime DLLs. You'll still need to decide whether to make ATL shared or private, and in either case you *must* distribute ATL with your application to ensure that it is available when your application is deployed. You can cheat, and let VS generate your manifest file (instruct it to *not* embed the file), then just edit the resulting .manifest file to remove references to the VC and MFC assemblies. For example, here's one that I generated (you'll need to generate your own to ensure that the manifest matches the version you are redistributing):
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestversion="1.0">
<dependency>
<dependentassembly>
<assemblyidentity type="win32" name="Microsoft.VC80.ATL" version="8.0.50727.762" processorarchitecture="x86" publickeytoken="1fc8b3b9a1e18e3b">
</assemblyidentity>
</dependentassembly>
</dependency>
</assembly>
In my work, I've had very little need for manifests. The VC optimizer is able to strip the unused portions of statically linked ATL out of your code, leaving a much smaller footprint than the entire assembly would require. This eliminates the need to redistribute ATL with your application, thus reducing the overall potential for deployment issues. Nevertheless, there are exceptions to every rule, and your mileage may vary.
Labels: ATL, manifest, Microsoft, ObjectARX, programming, Visual Studio
2006-12-19
I've installed Visual Studio 2005 SP1 and have been busy testing all my projects to make sure they didn't break. Microsoft did fix at least one of the bugs I reported (the resource editor choked on resource strings that contained an embedded NULL character), but the IDE still crashes fairly consistently if I initiate a large solution build while the Intellisense database is being rebuilt. SP1 also managed to break my VCBuildHook utility, so I've uploaded an updated version (2.0.3.0) for use with SP1.
Labels: Microsoft, ObjectARX, programming, Visual Studio
2006-12-18
Finally, the long awaited service pack 1 for Visual Studio 2005 is released! The service pack has been in the pipeline since soon after Visual Studio 2005 shipped last November, with release dates slipping month after month. The latest official release date was announced as "early 2007". Perhaps this was an intentional attempt to alleviate some of the waiting pains with a suprise release (or maybe just the Microsoft rumor mill on autopilot).
Be prepared for a long install. The download page warns that it could take an hour or more to verify digital signatures before the service pack installation even begins.
Be prepared for a long install. The download page warns that it could take an hour or more to verify digital signatures before the service pack installation even begins.
Labels: Microsoft, ObjectARX, programming, Visual Studio
2006-12-05
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
Archive
December 2006January 2007
March 2007
April 2007
May 2007
June 2007
August 2007
September 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
December 2008
January 2009
February 2009
March 2009
July 2009
August 2009
September 2009
November 2009
December 2009
January 2010
March 2010
Recent Comments
:Very nice Owen, Thank you for this wonderful utility.
Question, do you think this will work for building mix managed/unmanaged and or
C++/CLI apps? Thanks
Daniel
@ December 4, 2007 7:15:00 AM EST
Owen Wengerd:Thanks for the feedback, Daniel. VC Build Hook should work for mixed apps, but I haven't tried that yet. If you try it, please let me know whether you encounter any problems.
@ December 4, 2007 3:31:00 PM EST
:Thanks Owen for your tool.
I downloaded the tool in an attempt to use VS2008 as IDE to develop a C++/CLI application which uses ObjectARX 2008 SDK.
It compiles well with an initial problem of incorrect library settings. After a small fix, build went well. But unfortunately the netload command inside AutoCAD exists with a "System.IO.FileNotFoundException:The specified module could not be found" exception.
I feel that this should not be related any way with the hook nor with the code.
Daniel and Owen, I request you to keep me updated in case if you come across any solution of clue that might solve my problem.
Thanks and till then, I'll use VS2008 for AutoCAD .Net API only :-(
regards,
Narayanan
SendtoNarayanan(at)Gmail[dot]com
@ March 11, 2008 5:26:00 AM EDT
Scott:File sizes vary based on content. As DWF was originally binary to be as small as possible, it is hard to beat. With DWFx being based on industry stndard XML, the files are larger. At this stage of development, files are 30% to 100% larger. Naturally we will work to reduce the difference.
@ March 1, 2007 10:33:00 PM EST
Scott:By the way, the DWFx files produced by the AutoCAD DWFx Driver will not be as large as the XPS files produced by the XPS Writer. A similar condition exists for DWF today. The DWF Writer masquerades as a printer. Hence DWF files published by the DWF Writer go through Microsoft GDI. Using GDI makes the DWF files larger than DWF files produced by the DWF6 ePlot pc3 file used directly by AutoCAD.
@ March 1, 2007 10:39: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