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.

BRX on Linux: Getting Started

When I heard that Bricsys had shipped Bricscad for Linux, I was anxious to get to work on supporting the Linux platform. The first order of business was getting familiar with Linux. For that, I chose Ubuntu 10.10 32-bit running on a VMWare Workstation 7.1 virtual machine hosted on my Windows 7 64-bit workstation.

Installing Ubuntu was straightforward, and I had no problems. Installing Bricscad went off without a hitch. I downloaded the Debian package of Bricscad v11 Pro and Ubuntu’s Software Center installed it much like Windows Installer would install an MSI file on Windows.

Bricscad v11 on Ubuntu Application Menu

After installation, Bricscad fired right up. Except for a mysterious black splotch in the layer dropdown, it looked and felt very much like Bricscad on Windows.

Black Splotch on Bricscad Layer Dropdown

The next order of business was to build and load a BRX module. I started by installing Code::Blocks, an open source cross platform C/C++ IDE that can be used in both Windows and Linux. The IDE installed fine, but then things got interesting.

First of all, I found that I had to install the build tools (namely the g++ compiler), because they are not included with the IDE. Eventually I had to set an environment variable for my BRX project pointing it to the BRX SDK, which required a Code::Blocks plugin that had to be installed separately. I did get everything working, and built a simple BRX module without error — but then it refused to load in Bricscad.

Now, one of the things about Linux that is very different to Windows is the culture of users. Googling for help on something invariably leads to instructions that start out “It’s extremely easy to do this on Linux” and end with 4 pages of command line gibberish, including a list of all the stuff that must first be installed for these instructions to work correctly, and the inevitable warning that the instructions may only work on certain “distros” and versions of Linux.

I learned this first hand when I set out to determine why my .brx module was failing to load. I eventually learned that I had to manually add the BRX SDK library path to Bricscad so it could find the needed libraries at runtime. That was the easy part. To make a long (and rather harrowing) story short, I eventually determined that I was missing a single required library (the libgl graphics library). Installing the library in Ubuntu got things working.

Loading a test BRX module in Bricscad

Next up: figuring out how to build a Linux BRX module in Windows using the Visual Studio 2010 IDE. That should prove to be very interesting indeed.

ObjectARX Wizard for Visual Studio 2010

If you’re an ObjectARX programmer, you may still be using Visual Studio 2008 because you’ve been told that you must. It’s true that you need Visual Studio 2008 installed to compile native ObjectARX code, but with Daffodil you can do all your work in the Visual Studio 2010 IDE.

Until now, the one thing that didn’t work in VS 2010 was the ObjectARX Wizard. I’m happy to report that the latest wizard seems to works fine in both VS 2008 and VS 2010. Thanks to Alexander Rivilis for revealing the secret URL: