The Group 'W' Bench

.NET 2.0 Makes Me Feel Good

Fri, 26 May 2006 05:47:09 +0100

It's been a long time since I've bothered to write anything here. I had some technical difficulties (my server wasn't tough enough to run the DB and everything else I do, and e-mail/DNS were more important than the blog).

Not that anyone cares.

Anyway, for those of you who haven't gotten all wacky over Ruby, you may or may not have discovered the ConvertAll method on the Generic List class.

I was all proud of myself the other day for using anonymous delegates to loop through a list of something and churn out a list of something else. My coworker, the handsome Eric Liu, pointed out this method to me.

Shout out to my old friend Jim Arnold in jolly olde, who will be sure to find something wrong with this post.

I've got Mono and it Hurts so Good

Mon, 23 May 2005 20:27:19 +0100

So I have a small webapp I wanted to write. It's kind of a simple productivity tool for me. I'm sure I could have downloaded something, but I wanted to play around with some web technologies.

I started out with Ruby. I read some great intro documentation and installed both Ruby and Rails in about 10 minutes. That's on Linux, doing everything from source as is my habit. Both the documentation and the software were pure ease and delight to get going.

So instead of using that, I decided to check out what the Mono project is doing with ASP.NET. Some context: I'm a pretty experienced linux user. I run my own DNS, MySQL server and web server. I've been using UNIX variants for a long time. I build my own kernel about every month of so (blah, blah, blah, etc). It took me about a week and a half (light evening work, mind you) to get mono running ASP.NET pages which grab data from the MySQL database and put it on the screen.

I just kept running into problems. Getting the Mono runtime and and C# compiler going didn't take too long. Getting mod_mono (the Apache module that handles .aspx requests) to not segfault took a couple of hours. Incidentally, this is one of the few times I've taken advantage of open source and put my own debugging messages in the code to solve a problem. That was kind of nice, in the same way Apple users drool about customer care when their stupid computers break due to faulty design. In my defense, the main problem with mod_mono wasn't getting it going, it was getting it to find my own DLLs when the codebehind auto-compiles my aspx.cs at request time (more on that Mono quirk some other time).

The MySql ADO.NET data libraries helpfully (please read the sarcasm) put their documentation in .chm files. That's compressed HTML and is easily readable by Visual Studio. Reading that stuff in Linux would take another evening of faffing about so I didn't bother.

The biggest annoyance for me was the Mono documentation. The online stuff is fine, but I have this weird dark spot on my home wireless network where I sit when my kids are having trouble going to bed. So I tried to build the mono help reader thingy. That was a huge mistake. I lost an entire evening understanding the long and painful history of the gtk-help libraries and why I'm better off using the source as my documentation (which I do now when I'm away from the network).

Anyway, doing C# on linux is a lot of fun. I love C# and .NET, and I love linux so it works out for me. The amount of work that has gone into Mono is amazing and it seems to be really quality work. Part of my problem is probably that I prefer to build everything from source. My Gnome version is 2.10 which is a bit cutting edge and maybe that's why I'm having GTK lib issues. In fact, in retrospect it was easy to get the bare framework going. It was the getting my ASP pages to work the way I wanted that was tricky.

It's kind of funny that mono, as well as being Spanish for monkey, is short for "infectious mononucleosis". That's a nasty infection that makes you really tired for a long time.

Point is, it works now, but it was a bit of a painful process that probably could have been solved by me buying a book rather than relying on Google which is normally enough. I guess this blog entry is a way of getting closure on a number of evenings faffing. I would be happy to help any other poor suckers out there get their own installation going.

You Are Possibly Very Annoying

Wed, 6 Apr 2005 08:01:10 +0100

Have you ever met someone who is difficult to be around? Maybe this annoying person is angry all the time. Maybe she just goes on and on and on and on about stuff that you just don't care about. Maybe he smells bad.

There's something interesting about this person. This person has NO IDEA that he is annoying to others. Your polite hints aren't working. Social cues are not registering.

Here's the problem: this person walks around all day being annoying, but not knowing he is annoying. You and I walk around all day thinking that we're not annoying too. Other people are crossing the street to avoid having to listen to us prattle on about some nonsense, and we don't know. To us, we are just fine.

You (and I) are possibly very annoying.

It's like having a bit of food on your face. This is especially difficult if you are in a position of authority or respect. Nobody wants to tell the boss she has food on her face. She gets to walk around having food on her face. If I were her, I would want to know.

This is why I'm a believer in company feedback reviews of employees, especially in a company that hires outspoken computer programmers. I want to know if I've got food on my face, because I really can't tell.

VB.NET ruined my day: Part 2

Wed, 23 Mar 2005 12:36:52 +0000

I wouldn't share this stuff with anyone except that I found out that there are a few people actually interested in it. Thanks to you folks for giving me something to rave about.

Two instances of day ruinedness:

1. VB.NET ruined my day a while go by surprising me with some weird typing behavior. Imagine, if you will, a function that takes a string as a parameter. Imagine that you turn option strict on, because you refuse to be associated with those unwashed VB programmers who have the audacity to leave it off. Turn option explicit on too, because even though you can't remember what it does it sounds like a good idea. Then pass in a character array into that function. It will work.

I know!

I was not amused. A string is different than a char[]. I think it must be a backwards compatibility thing.

2. VB.NET ruined by day yet again recently, and Jim Arnold (my evil nemesis) doesn't believe me about this one, even though I showed it to him in the profiler. We had some code that looked roughly like this:



Dim someString as String = nothing



For index As Integer = 0 to 2500

   someString = " trim me "

   someString = Trim(someString)					

Next

The thing you should be looking at is the Trim method. This is in a .NET module called Strings. It would have been written in VB.NET and provides some VB string functions for those who want them.

Thing is, for some reason, it is SLOOOOOW. Instead of doing that, do this:



Dim someString as String = nothing



For index As Integer = 0 to 2500

   someString = " trim me "

   someString = someString.Trim()					

Next

The first loop took 65% of my .EXE's processing time. The second took 3%. I'm curious why. I decompiled them to try to understand why. The version on the String class does a call to an internal CLR TrimHelper function. The Microsoft.VisualBasic stupid slow version does a bunch of checks and then calls the String version. Not that much different.

I've found the same thing with other Microsoft.Visualbasic String functions like ToUpper. Very slow. The application we're working has a ton of this stuff. Ideally we would just make it better so we don't do so much string processing in loops.

Update: Jim denies being my evil nemesis.

Update again: ok. Jim showed me that my benchmark was stupid. We had reason to believe that it was slower when we came across it in the original code. I need to look at it more because we had cases where that was ALL we changed and we saw a marked improvement over large lists of strings.Anyway, I should have clicked down a few more levels in the profiler execution tree. Don't lose hope though! Stay tuned for MORE exciting (and correct) VB.NET insights.

Non-Obvious .NET for n00bz: BindingContext

Fri, 4 Mar 2005 15:00:34 +0000

My way of knowing if something is noteworthy is whether or not my superhardcore .NET programmer coworkers know the answer. If one of them doesn't, then it's worth talking about.

Recently I needed three independent ComboBox instances all displaying the same 3 lists of cities. I made an IList field in my class and loaded it up with the cities. I then set the DataSource property to the IList instance.

The behavior was initially a bit strange to me. When I selected a value in one ComboBox it changed the value in all of them.

The reason is this: there is a BindingContext object which appears to be shared for all objects that inherit from the Control class. It manages a bunch of BindingManagerBase objects.

One way around this is to assign a new BindingContext to the control's BindingContext property:



myCoolComboBox.BindingContext = new BindingContext();

The other way around it is to not use the same datasource for your three comboboxes.

The MSDN says this: "The CurrencyManager is necessary because data sources do not necessarily maintain a current-item pointer. For instance, arrays and ArrayList objects can be data sources, but they do not have a property that returns the current item. To get the current item, use the Current property."

This doesn't make sense to me. I would think that it's up to the control, not the data, to decide which item is current. Data is just data. Perhaps it will become clear, or someone who cares enough to read this can comment.

On a side note, I'm annoyed that SortedList doesn't implement IList, so I can't bind a SortedList to a CombBox. Silly.

ps. Java's for wimps.

A first look at reading Windows PE files using .NET managed code - Finding out when a File was Compiled

Thu, 3 Mar 2005 12:49:26 +0000

I wanted to learn a bit about Windows PE files because some guy on usenet was asking how to tell when a file was compiled and I thought there whould be a simple solution. PE stands for "Portable Executable" and is the format for both .NET (the headers at least) and standard windows executables. You would think that there would be a standard API making it simple to grab this info, but I couldn't find it.

The first 64 bytes in a PE file is the MS-DOS header. It seems kind of useless except for the last 4 bytes which contain an offset to the "new" header. The struct IMAGE_DOS_HEADER in WINNT.h describes the contents of this first 64 bytes. The other interesting thing about that struct is the first element, e_magic, which when converted to ASCII is the initials of the guy who created this stuff. I imagine he needed to round out the struct to 64 bytes.

Between the IMAGE_DOS_HEADER and the GOOD_STUFF is a BUNCH_OF_CRAP, including the error message you get if you run one of these PEs on 16 bit DOS.

So I wanted the offset to the good stuff in the other header, which is called IMAGE_NT_HEADERS32. I got at that by reading in the raw bytes and grabbing the 60th to 64th byte and putting them into an integer:



   byte[] fileData = new byte[2048];



   using(Stream fileStream = new FileStream(path, FileMode.Open, FileAccess.Read))

   {

      fileStream.Read(fileData, 0, 2048);

   }



   byte byte0 = fileData[OFFSET_TO_e_lfanew];

   byte byte1 = fileData[OFFSET_TO_e_lfanew + 1];

   byte byte2 = fileData[OFFSET_TO_e_lfanew + 2];

   byte byte3 = fileData[OFFSET_TO_e_lfanew + 3];



   int offset = ConvertBigEndianBytesToInt(byte0, byte1, byte2, byte3);

I had to write a quick function to switch the byte order and make an int since Intel machines are big endian. The last time I had to care about that stuff was on a little endian machine which is a bit nicer for stuff like this. Here is a great summary of byte orderings and the corresponding religious debate.

Note that I could have done this in unsafe code or in C++ by simply casting those 64 bytes to the IMAGE_DOS_HEADER struct. Since the exercise was to do this without unmanaged code I didn't go that route.

Now that we know what the offset is we can grab the IMAGE_NT_HEADERS32 info. It looks like this:



typedef struct _IMAGE_NT_HEADERS

{  

	DWORD Signature; 

	IMAGE_FILE_HEADER FileHeader;

	IMAGE_OPTIONAL_HEADER OptionalHeader;

} IMAGE_NT_HEADERS,

The important part is the IMAGE_FILE_HEADER because it has a field called TimeDateStamp which is the compilation date in seconds since midnight of 1970.

You can grab it out like this:



   offset += OFFSET_TO_DATESTAMP;



   byte0 = fileData[offset];

   byte1 = fileData[offset + 1];

   byte2 = fileData[offset + 2];

   byte3 = fileData[offset + 3];

			

   int secondsSince1970 = ConvertBigEndianBytesToInt(byte0, byte1, byte2, byte3);

			

   DateTime exeCompilationDate = _standardWindowsDateStartPoint.AddSeconds(secondsSince1970

Notepad.exe on this computer was linked on August 17th, 2001 at 8:52pm.

Update: Here's the code and the program if anyone cares. Maybe that usenet guy will go googling. If you ever actually find this stupid little program useful let me know because I would get all warm and happy. The code has Jim's mad skillz code changes too.

Update: A nice fellow named Jeff Atwood tried this code out and blogged about it. Scroll to find his April 14th entry. He discovered that my code always returns the time in GMT, which I didn't notice because I live in England, which at that time of year is GMT (BST right now). He has a fix on his website, which involves adding an offset to the original date. It's too bad I didn't wait a month or two to write that code or I would have noticed that I was an hour off due to BST.

VB.NET ruined my day: Part 1

Fri, 25 Feb 2005 14:57:20 +0000

I felt like writing a bit about the differences between VB.NET and C#. I used to think that it would be easy to go back and forth between the languages. It still is, for the most part. However there are a number of subtle gotchas that can really ruin your day. I'm flabbergasted, yes flabbergasted, at how different VB.NET is from C#. They really are totally different languages.

My apologies if this is boring, but you .NET programmers who occasionally have to sully your C# purity with the occasional VB.NET stint would be well advised to read on.

I discovered recently, much to my shock and dismay, that Visual Basic .NET rounds the results when you cast a double to an integer. I always assumed that because casting in VB was a compiler keyword there was some kind of CLR standard for casting.

There isn't.

Doing a CInt(myBigFatDouble) in VB.NET is the same as calling Math.Round(myBigFatDouble) on it and then converting it to an int.

I'll show you how smart I am by laying down some IL that you'll probably ignore:



IL_000b:  call float64 [mscorlib]System.Math::Round(float64)

IL_0010:  conv.ovf.i4

That's from a CInt cast in a VB.NET program. It gets worse though. System.Math.Round always rounds to the NEAREST EVEN NUMBER! So 1.5 rounds to 2, and 2.5 rounds to 2.

So what do you do if you want your CInt to truncate like a reasonable cast should? It's obvious. You use the Microsoft.VisualBasic.Fix function. Pass fix a double and it will spit out a truncated int.

Like all strange VBisms, this one has a historical reason for existing. It's because historically VB was created by a bunch of drunken monkeys.

Changing a .NET MDI Form's background colour

Fri, 11 Feb 2005 16:55:26 +0000

While rewriting an app using .NET that was originally in VB6 we come across interesting problems because things you used to do in VB6 are no longer supported.

We needed to change the colour of the MDIParent form because that's how the way they show certain warnings to the user. The problem is that you can't set the background colour of the MDI form. It has no property to do it, and it wants to use the same colour as the Windows system background.

Some Googling found some documentation explaining that there is a "secret" form of type MdiClient which is stored as one of the controls in the main form which acts as the MDI parent. We copied some nasty code which uses Win32 calls to find it. I just noticed right now that my coworker Jim rewrote to make it 100 times better.

So to set the colour of an MDI form, find it's MdiClient and set its BackColor property. Jim's code below, in beautiful VB.NET:



For Each ctrl As Control In Me.Controls

    If ctrl.GetType() Is GetType(Windows.Forms.MdiClient) Then

        ctrl.BackColor = newColour

        Exit For

    End If

Next

Simple, but not at all obvious.

Operation Completed Successfully Exception.

Tue, 8 Feb 2005 20:46:22 +0000

I love .NET. I mean it. It's fun.

I was pairing with Swellsie the other day and we got a sweet exception. It was a System.ComponentModel.Win32Exception and the message was, "Operation Completed Successfully".

It made my day. I love that the system was throwing an exception to tell us that it completed successfully. I'm sure some crusty old Windows programmer knows exactly what it is.

We don't know what caused it. We were working on some code that had been badly generated from Microsoft's VB6 to VB.NET wizard. We rewrote it to be better, and the exception went away.

Kenesaw Mountain Landis and distributed projects

Fri, 21 Jan 2005 09:20:20 +0000

I've always thought that if a development team is going get stuff done, they have to be in the same room. Lots of people think this. Nothing new here. Since companies can save money by splitting people up and putting them in far off places with cheap currency (like India and the United States) a lot of work has been done to figure out how to get teams productive when they're scattered all over. We've done work on this at ThoughtWorks, and a guy in Calgary named Frank Maurer studies this stuff too. His team does MASE, which is a tool for organizing distributed projects using agile methods.

Still though, having a team in one place is really the way to go. People generally seem to agree on that. My question then is this: why are the big open source projects so successful? There are big projects, like GNOME, Linux, gcc (and many, many others) which are of an amazing complexity and quality. Why does this work?

Enter Kenesaw Mountain Landis.

Kenesaw Mountain Landis was the Baseball chairman in the US starting in the 1920s. He's the one who got Shoeless Joe kicked out of baseball and took the game back from the mafia. He cleaned things up. The cool thing about Kennesaw, in my opinion, is that when they offered him the job of chairman, he wouldn't take it unless they offered him "absolute power". He was a man of integrity. He knew it, and he wasn't going to waste his time with bureaucracy.

Open source projects seem to have a Kenesaw Mountain landis running the show. I know they tend to get complicated, and I've read some of the funnier scandals on the mailing lists, but there still often tends to be someone who runs the show. With Linux it seems to have been split in to a few different Kenesaws, but the idea is the same.

If Kenesaw likes your patch, it goes in. If not, try again.

Maybe this is a good idea. It's a bit of a change from what we normally do on teams using XP. Frank Maurer, the guy I mention above, once said that one think they KNOW works in software engineering is code reviews. XP depends on this through pairing. If you're not in the same room, get Kenesaw there to make sure your code doesn't suck.

There are lots of reasons why open source works so well. The programmers have passion. They work on smaller teams (side note: I think almost all development teams are at least twice as big as they actually need to be).

Finally, they have Kenesaw Mountain Landis there and he isn't going to take any crap.