Tag Archives: visual studio 2010

An introduction to three VC++ Macros: How they came to be

I’ve been recently working on a C++ project and ran into a task where I had to move many inline header functions out of the header and into the corresponding .cpp file.

Visually, I wanted to convert:
Biscuit.h

class Biscuit
{
public:
    virtual void Taste(int chompiness) { m_ChompRating = chompiness; }
private:
    int m_ChompRating;
}

into
Biscuit.h

class Biscuit
{
public:
    virtual void Taste(int chompiness);
private:
    int m_ChompRating;
}

Biscuit.cpp

void Biscuit::Taste(int chompiness)
{
    m_ChompRating = tastiness; 
}

We’ve all been there. It is usually an exercise in our copy and paste skills, and an opportunity to work on our RSI. I thought there must be a better way! So I scoured the Internet but noone seems to talk about it. It seems every programmer has just accepted that the only way to get this done is to stop mucking about on Google and push your fingers to the keys.

I was still not satisfied. I asked the collective brains of Stack Overflow and the only solution I got was to purchase Visual Assist. I’ve tried Visual Assist. It is a brilliant product. It is also a brilliantly expensive product. Nawaz, from Stack Overflow (he is the one that looks like a baby) challenged me to write a macro myself, and share it, because “it wouldn’t be too difficult to write”.

Hah! It was not that difficult to get something that worked some of the time. It was difficult to create something that worked all of the time. I knew nothing about macros, other than how to record them and see the generated code. Finally, after a bit of reverse engineering, a tiny bit of reading and some code stealing inspired coding, I have a set of macros I am quite happy with. Over my next 3 blog posts I will share these macros with you, and on the way we will build up a few good utilities:

  1. How to flip between the header and cpp file
  2. Automatically adding an implementation skeleton to the cpp file from the header definition
  3. Moving a function defined inline in the header into the cpp file

And hopefully some Googler will be able to make use of these macros. See you soon.

Your ADO is broken

I found today that Microsoft has violated the holy rules of COM and broken their msado15.dll. The violation occurs after the installation of Windows 7 Service Pack 1 (version 6.1.7601.17514).

What’s happened is Microsoft has changed a few function signatures due to a 64bit problem, and changed the class IDs while they are at it. Thus, backwards compatibility has been broken, making COM absolutely useless. Executables compiling on Windows7 SP1 will now only run on Windows7 SP1. We’ll have to assume that any other alternatives were carefully thought through and resulted in the world ending, because on face value this looks like a terrible fix.

In this epic saga spanning five months, we’ve still not reached a warm fuzzy conclusion. The best solution seems to be reverting this change made in the service pack and created a new set of 64bit functions. This would probably break all ADO code compiled in the last five months, but at least the last 15 years would work again.

In the meantime, here’s our official workarounds:

  1. Use late binding. Because, you know, type safety and efficiency aren’t all that.
  2. Uninstall Service Pack 1. I think they are laughing at us.
  3. Temporary workaround for C++ developers. Yay!

So we’ll go for the only attractive option, #3. Details are here: http://support.microsoft.com/kb/2517589, but it basically boils down to installing and registering a file called “Msado60_Backcompat”, which is a truly ironic name if you remember what the whole point of COM is.

Except I’d deviate a little from the recommended steps, because forcing your team to install and register these files is a bit inefficient, and playing around in your common files location is plain nasty. There’s also no indication on how to swap them in and out for 32 and 64 bit builds. So here’s my lazy “it-just-works” method for Visual Studio 2010:

  1. In your 3rd party area of your source control, create a branch for Microsoft and Ado. Then branch off for the 64bit and 32bit versions. ie


    3rd Party
    =>Microsoft
    ====>Ado
    ======>x86
    ======>x64

  2. Download the 64 and 32 bit .tlb files, place them in their respective folders and rename them both to “msado60_Backcompat.tlb”.
  3. Check these files in.
  4. Open up properties for your project, and under C/C++ add the path to your tlb files.
    Shows the proprties screen in Visual Studio 2010. The path to the new ADO .tlb file has been added to the additional Directories field,
    Add the path to the .tlb file to Additional Directories

    Don’t forget Release settings!
  5. Do the same for your 64 bit version.
  6. Change the #import "msado15.dll" part in your code to #import "msado60_Backcompat.tlb"
  7. Recompile, build, wait for the next hotfix to come along and destroy your working programs.

Meanwhile, your programs will just work using COM black magic that nobody really understands.

I can only assume everyone who understands COM at Microsoft who could have prevented this fairly fundamental error from occurring has gone mad, senile or died. I know they are keen to get us all writing .NET code (I hear that’s what the cool kids are doing these days), but if no-one understands the technology that .NET is built on, we’re in trouble. I imagine in the near future, mythical COM developers will be held up in great esteem like a lost Mayan civilisation, revered as demi-gods with alien intelligence and magical powers. Or starving as unemployable geeks crying into their RSI-riddled hands.