Updates are tempting, but are they safe? (about KB971090)

Last week, I had a task for fixing a bug related to a library from outside my company.

First of all, I found that we were using its functions in a wrong way so I made some changes to correct it. Of course, the way I fixed it is from a document of the library. It resolved the issue and worked well in my machine. But, it turned out that a few machines had another problem with my changes.

Luckily, we have source code of the library so I was able to look into it to find my mistake. However, I realized that they made a wrong assumption about some values and it caused the problem. Since I had the source code, I fixed the wrong assumption, compiled it and produced one dll file for our project. It was working just fine on my test machine as well as my own pc. Yeap, I have two machines and three monitors at work. :)

Anyway, the happy moment didn't last long though. Our build machine reported that it failed to test its final build with my newly produced dll. Our game couldn't even start with it but just showed a very simple system error dialog with a strange hexadecimal address.

From my programming experience, I know that this kind of problems could take forever if I just try to solve it by myself. I quickly noticed that I needed someone. Someone knows our project very well and understands my task. Yeah, I asked my lead programmer to help me.

We agreed that the changes I made is the proper way to do my task. The problem was why the dll working in my pc didn't work in our build machine. We found that the dll didn't work on his machine either. He was for sure that my machine had something different and it produced the dll having incorrect dependency for the other machines. So, what is it?

It took almost four hours us to find the reason. It was not because my machine is using 64 bits Windows and the build machine is using 32 bits one. It was not because of the project setting for the library. It was not even because I used their static version of project to produce dll. (Another good example why naming is so important. They named the project "static something" but it actually created a dll, "dynamic" linked library.)

When my lead and I almost gave up, I found that my Visual Studio 2005 had all the latest updates and the one in build machine didn't. It's just my habit that I runs "Windows Updates" or "Microsoft Updates" every day when I have a short break. This habit had never made any problems until this one happened.

It turned out that one of the security updates for VS2005, KB971090, made the problem. From google, I found that dlls compiled with the security update (KB971090) are not compatible with exe files compiled without it, if the machine which runs the exe doesn't have the update. To solve this problem, I simply uninstalled it instead of following the long solution which you might want to take if you have the same problem. I should mention that you need to check "View installed updates" in control panel to uninstall it. Yeah, it sucks.

Okay, here is what I've learned.

Keep the exactly same build environment with the other programmers including a build machine. Don't blindly get all updates without checking them.

What are you assuming?

Last week, I was reading src code and found that it used zero as an initial value for a handle.

MY_HANDLE handle = 0;

But, it also used INVALID_HANDLE for the same purporse.

class A
{
public:
 A() : m_handle(INVALID_HANDLE) {}

private:
 MY_HANDLE m_handle;
};

Well, I thought that INVALID_HANDLE was zero. However, it turned out that it's not. INVALID_HANDLE was defined with some weird value. Anyway, the exact value is not important. The importatnt thing is how I know what should be an initial value for MY_HANDLE?

Suprisingly, I'm told that some code use INVALID_HANDLE as a VALID value and there is a legitimate situation that a handle of an object is INVALID_HANDLE. Wow. Okay, so the real invalid value which is supposed to be used as an initial value is zero, not INVALID_HANDLE.

Yeah, I know this kind of things always happens in real world as we always see this comment;"Fix me!". But, before we fix this, I'd like to ask this question.

How can we communicate with other programmers who will work with the code we write in future? More specifically, how can we show our assumption in the code? Or, do we even need to do it? why?

Why?

Because we are all different humans. All of us have an unique appearance, personality and assumption. It's perfectly fine with having your own assumption like your own habits. But, there is no guarantee that your assumption makes sense to others. That's why we should say it very loudly whenever we assume something.

How?

First of all, name it correctly. If it is a function returning a size of array, name it "GetSizeOfArray()". If it's a value containing your grade, name it "myGrade". If it's a constant value for an invalid handle, name it "INVALID_HANDLE" and use it as it is called. You can follow your "common" sense but don't hesitate to spend enough time naming something.

Second, use assertion whenever you can. It can correct your assumption quickly if it is wrong, it is crystal clear for other programmers and you can turn it off easily so that it doesn't cost anything in your retail build. Yeah, it's cheap (almost free) but powerful enough to save your project.

One thing I should mention about assersion is that you should not mix assertions with error handling. If there is an error and you need to handle it, just handle it without writing asserion.
See the below code.

assert(pRect != NULL);
if(pRect != NULL)
 pRect->Draw();

The code says two things at the same time and they conflict with each other. It says "pRect must not be NULL." and "Call Draw() if pRect is not NULL". The latter one implicitly assumes that pRect might be NULL but the assertion says that pRect should never be NULL.

As Scott Meyers said that a female is either pregnant or she's not (in Effective C++), you should choose only one of them. Is it a part of program flow? or should it never happen? It's not possible to be partially pregnant.