I previously wrote about how to quickly convert a byte array to its hex representation and back again in C. Now I’ve converted the same source code to C#. Even though there is a built in method using String.Format, it is too slow.

  public static string ByteArrayToHexString(byte[] Bytes)
  {
	 StringBuilder Result;
	 string HexAlphabet = “0123456789ABCDEF”;

	 Result = new StringBuilder();

	 foreach (byte B in Bytes)
		{
		Result.Append(HexAlphabet[(int)(B >> 4)]);
		Result.Append(HexAlphabet[(int)(B & 0xF)]);
		}

	 return Result.ToString();
  }

  public static byte[] HexStringToByteArray(string Hex)
  {
	 byte[] Bytes;
	 int ByteLength;
	 string HexValue = “\x0\x1\x2\x3\x4\x5\x6\x7\x8\x9|||||||\xA\xB\xC\xD\xE\xF”;

	 ByteLength = Hex.Length / 2;
	 Bytes = new byte[ByteLength];

	 for (int x = 0, i = 0; i < Hex.Length; i += 2, x += 1)
		{
		Bytes[x]  = (byte)(HexValue[Char.ToUpper(Hex[i + 0]) - '0'] << 4);
		Bytes[x] |= (byte)(HexValue[Char.ToUpper(Hex[i + 1]) - '0']);
		}

	 return Bytes;
  }

How is it possible that Microsoft didn’t introduce PBM_GETBKCOLOR/PBM_GETBARCOLOR until Windows Vista? I mean, I can’t imagine it! The progress bar messages PBM_SETBKCOLOR and PBM_SETBARCOLOR are supported in Windows 95+, but it took them until Vista to develop PBM_GETBKCOLOR and PBM_GETBARCOLOR??!! How do failures like that go overlooked for such a long period of time?

Lately, I’ve been reading The Pragmatic Programmer. The book is alright. If anything it helps bring more structure to my programming knowledge. Although, some of the stuff I’ve already learned through my own experience and so it seems kind of obvious. I must say that the book takes some liberties in the naming of programming concepts.

Anyways, I was reading today the section entitled “Programming by Coincidence” and here is an except:

“Suppose Fred is given a programming assignment. Fred types in some code, tries it, and it seems to work. Fred types in some more code, tries it, and it still seems to work. After several weeks of coding this way, the program suddenly stops working, and after hours of trying to fix it, he still doesn’t know why. Fred may well spend a significant amount of time chasing this piece of code around without ever being able to fix it. No matter what he does, it just doesn’t ever seem to work right.”

One thing that I know is that in order to be a good programmer you have to be persistent when it comes to tracking down and fixing bugs. In the paragraph above, Fred spends several weeks working on code, but yet he gives up after several hours and calls it quits? Bugs can be fixed, if you spend enough time fixing them. The problem with Fred is that he is a script kiddy. He wants something for nothing and is not willing to work hard to fix his mistakes. Obviously he needs to spend a more significant amount of time trying to fix it, because given enough time, it can be done. I’ve spent days debugging and fixing bugs. Sounds to me like Fred is a wuss.

There is another section called “Refactoring” that states that gardening is a better metaphor for software development than building construction because building construction doesn’t take into account refactoring.

Unfortunately the most common metaphor for software development is building construction. But using construction as the guiding metaphor implies these steps:

1. An architect draws up blueprints
2. Contractors dig out the foundation, build the superstructure, wire and plumb, and apply finishing touches.
3. The tenants move in and live happily ever after, calling building maintenance to fix any problems.

Well software doesn’t quite work that way. Rather than construction, software is more like gardening - it is more organic than concrete.

The authors of the book got this one wrong because they didn’t fully evaluate the building construction metaphor. They imply that the building construction metaphor only includes the building’s initial construction and after it’s initial construction it has been built perfectly without flaw. While a lot of the work is complete after a building’s initial construction it does not mean that remodeling or reconstruction won’t take place further down the road, especially if their were errors in the building’s initial design. So the remodeling of the building, or the gutting of electrical or plumbing, does in fact take into account the refactoring aspect of programming. Because the authors only considered the building construction metaphor within a short timespan, they completely miss the fact that the building could be totally remodeled 20 years down the road — refactoring! Let me also say that I’ve never heard the word “development” from the term “software development” being used in conjunction with the work of a gardener. Maybe a landscape developer, but a landscape developer is more of an architect than a developer. Nevertheless if anybody wants to be a software developer that is liken to a gardener, that is completely your gay wish. But as for me, I rather my work to be likened to the construction of a building.

Toward the end of the book, it tends to repeat itself, by trying to explain the same thing 10,000 different ways. Talk about DRY (Don’t Repeat Yourself)!

Last month I finished reading The Old New Thing: Pratical Development Thoughout The Evolution of Windows. It had some interesting parts where it explained the historical aspects of Windows from a programmer’s point of view. The book contains things like the reasoning behind the decision to make Windows 95’s GetVersion() function returns 3.95 rather than 4.0. The Old New Thing shows you what goes on in the minds of the developers that work on Windows and makes you want to give them mad props for some of the stuff that they have to put up with. The book was written by Raymond Chen and most of the material was taken from his blog (which I subscribe to regularly) and organized into different chapters. You might ask why I would buy the book and read it if some of the material was freely available on his blog. The truth is that Raymond’s blog contains so much information that it might as well be a book. And I’ll never read an book online, not even those free pdf books, because the internet is for skimming not for reading.

The best way to refer to the size of an array is by using the sizeof keyword. For a long time I have been using the declared #define variable to refer to an array’s size throughout my code. Let’s take a look at the difference.

Referring to the size of Temp by the #define variable MAX_PATH.

#define MAX_PATH 260
char Temp[MAX_PATH];
String_CopyLength(Temp, “Hello World”, MAX_PATH);

Referring to the size of Temp using sizeof.

#define MAX_PATH 260
char Temp[MAX_PATH];
String_CopyLength(Temp, “Hello World”, sizeof(Temp));

Both pieces of code do the exact same thing. One calls String_CopyLength with MAX_PATH as the maximum buffer size and the other uses the compiler keyword sizeof. Now, the sizeof keyword is not “NEW”. The whole reason behind me using sizeof instead of referencing the #define variable is maintainability. If in the future you decide to change the declared size of the array, you only have to do it in one place, at the top where it is declared.

If you reference MAX_PATH throughout code instead of using sizeof(Temp) and you decide to change the declared size of Temp to say MAX_TEMP, you then have to change all references of MAX_PATH when referring to the size of the Temp array to say MAX_TEMP instead. What it is bad is if you forget to change one of the references of MAX_PATH to MAX_TEMP. It could cause a buffer overflow if MAX_TEMP is less than MAX_PATH.

Now instead of using a #define variable we might just insert the size of the array as it is declared.

char Temp[32];
String_CopyLength(Temp, “Hello World”, 32);

So in the example above, if we want to change the size of Temp from 32 to 64 characters, then we’d have to change every reference where the number 32 is mentioned as the size of Temp. If instead we use sizeof(Temp), we only have to change the size of the array once in its declaration.

When trying to compile mozilla, I got the following error.

$ ./start-msvc9.bat
"Mozilla tools directory: e:\Source\mozilla-build\"
Visual C++ 6 directory:
Visual C++ 7.1 directory:
Visual C++ 8 directory:
Visual C++ 8 Express directory:
Visual C++ 9 directory: C:\program files\Microsoft Visual Studio 9.0\VC\
Visual C++ 9 Express directory:
SDK directory: C:\Program Files\Microsoft SDKs\Windows\v6.0\
SDK version: 6
Setting environment for using Microsoft Visual Studio 2008 x86 tools.
C:\Windows\Microsoft.NET\Framework\v2.0.50727\ was unexpected at this time.

The problem is the vsvars32.bat located in C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools has a line that sets the PATH environment variable and in it. If you remove from that line the path that contains a parenthesis, “C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 (Pre-Release Version)”, it will work.

Was working on my utility today that injects an icon into an executable and found out that ResHacker does not support icons that are 256×256 pixels. It is actually a bug, because in the ICONDIRENTRY structure, which defines an icon in an icon group, the Width and Height properties are defined as BYTE’s. Well a BYTE cannot hold the value 256. So, instead the common practice has been to use 0 to indicate the value of 256. When ResHacker sees the value of Width and Height as 0 it thinks it has run out of memory and so throws a “Out of system resources” error message.

I wrote the author of the program, but the website says ResHacker it is no longer under development and that I should use XN Resource Editor. Too bad it doesn’t support drag and drop thou.

Wikipedia Icon File Format