We're making the move to 64-bit at work, and one of the things that's annoying me the most is all the 32-bit shell extensions that I rely on and didn't realize it.  For example, we use Subversion for source control and use the excellent TortoiseSVN shell extension to work with it from explorer.  Since it's a 32-bit extension, it doesn't show up in the context menu.

There are two workarounds I've found for using these 32-bit extensions.

1. Use the 32-bit explorer.exe in the SysWow64 directory.  You have to have the "Launch folder windows in a separate process" option turned on, otherwise it will just see that explorer is already running and start a new 64-bit window instead of a new 32-bit process.
2. Use 32-bit IE.  There's already a shortcut to it by default in the start menu.  Just fire it up and navigate to the filesystem instead of a web page.  Voila! 32-bit extensions start showing up.  I like this method since I don't have to have a bunch of explorer processes for each window.

There's probably a cleaner way of using the 32-bit explorer, but I haven't figured it out yet.

Becky's dad was in the Dallas/Fort Worth area for a conference, and "dropped by"  By dropping by, I mean he took a 6 hour round trip out of his way.  I suppose that's better than the 16 hour round trip it would be from El Paso.  We went to Pasado's for dinner Friday night and had a nice time catching up.  Thanks for stopping by!

My dad came down today to help me with a bathroom remodelling project.  We were basically removing a wall in the bathroom, but it was a little more complicated.  The wall goes all the way to the roof, and takes a couple of corners.  Luckily, the upper portion was structurally sound enough to support itself without the lower wall. Click through the picture on the left to see the stuff we did.  You can also check out the bathroom remodelling photoset for some more context.

A big thanks to my mom and dad for coming down to help.  I'm sure he'll have his pictures up soon.

[Update] Dad's got his entry up with links to pictures.

Last night, I completed my STDF file parser that I started over the weekend.  I'm pretty happy with it.  I now fully support all of the version 4 spec.  It's written with the Feb. 2005 CTP of Whidbey.  It was primarily a good example of a "real world" application, so I wanted to use it to try out some of the spiffy new features and see how they might fit into an application that was not built for the sole purpose of showing them off.

I'm not entirely sure what I should do with it now that I've built it.  There's not much non-commercial demand for something like that that I am aware of. I might be persuaded to license it for use commercially once there is a "go live" license for Whidbey.  I'm sure it will need some testing to work out issues.  I'll probably build a viewer using it and use it at work to get the kinks out of it.  Anyway, I thought it might be useful to capture how some of these features played out in a real scenario.

Lightweight Code Generation

I used attributes to annotate my record classes in order to define the "on disk" layout of the record.  I originally put the attributes on the properties of the record, but decided to move them to the class level so that I could define the fields that are only used for parsing, and not useful after that.  At runtime, I register the record types with the parser, which uses lightweight code generation to generate converters from unknown records to the concrete records.  If you're not familiar with LCG, it is essentially Reflection.Emit without the overhead of a dynamic assembly, module, or type.  If you're unfamiliar with Reflection.Emit, it is essentially generating executable IL code on the fly, which has may benefits over generating C# or some other language and running it through the compiler with CodeDOM or soemthing else. (If you're not familiar with IL, then this entry is somewhat irrelevant) Having dealt with assembly on lots of different instruction sets from 68000 to x86 to DSPs and microcontrollers, I must say that working in IL is wonderful.  I was a bit worried about the startup time for the parser, but it seems to happen very quickly.  I'll need to experiment more to come up with the overhead of the dynamic code.  Again, I was disappointed in the lack of debugging support in LCG.

Generics

Unfortunately, generics did not work into the equation near as much as I had hoped.  I did find them very useful in places where I would normally pass a Type.  Now I can have a much stronger contract on such methods using generic methods with constraints.  I must say that I love the generic collections.  Working with strongly-typed data without having to generate the classes is very nice.  I also like being able to do a custom sort with an inline anonymous delegate with closure-type semantics rather than have the overhead of a separate class with the code in a different place.

Iterators

Iterators came into play in several places.  In the pull-based record parser, it was simple to implement IEnumerable.  I believe it only took 3 or 4 lines of code.

Delegate type inference

I don't remember what the official name of this feature is, but instead of having to do something like SomeEvent += new EventHandler(SomeMethod), you can just do SomeEvent += SomeMethod.  This seems small, but I appreciated it quite a bit.

Visual Studio Enhancements

These were a very pleasant surprise.  I hadn't thought about the exercise as testing the VS enhancements.  The snippets were the most useful improvement in this project.  Implementing properties didn't make me want to rip my hair out. Just type 'prop' and hit tab and fill in the blanks.  The built-in snippets for things like exceptions, attributes, indexers, etc. all work really well.  The one for implementing an indexer/iterator as a nested class was very interesting as well. It was also easy to create my own snippets.  I also found the strongly-typed resources to be very handy.

The debugging stuff is awesome.  I love being able to mouse over variables and drill into them dynamically.  The little popup windows for exceptions are cool, but don't really give you any good information that you couldn't get before.

I found the refactoring support to be extremely useful, although it was a little hard to shift into the mode of making sure everything compiled all the time.  Before, I would jump around alot in the code, so I would leave things in a state where it didn't compile.  It worked great once I got used to it.

Well, it looks like the Lady Bears are gonna win it all.  That's really exciting.  They really deserve it.  I played in the basketball band at almost every home game while I was at Baylor.  Just heard the 'bones playing Emperial March.  Cool to see the band still doing some of the things that Dave, Jeff, and I started while we were there.

[Update] It's now official

[Update] changed 'game' to 'band'. He he

So, my recent drink of choice is also Robert Scoble's.  I found it to be one of a very small number of diet drinks that I can stand.  Among them are Diet Dr. Pepper and Diet Dr. B (a knock-off).  I find Diet Mug Root Beer to taste almost exactly the same as the regular version.

Robert, just don't leave it in the freezer and forget about it.  I wanted a cold one and the cans we're cold yet, so I thought a little freezer time would speed things up.  So, I forgot about it.  It was a mess.  It was pretty cool though.

This is what happens if you break your XBox communicator and still want to play.  Dave broke the plastic part that rests on your ears, so he's using a headband to hold it onto his head.  He said he was really hot after playing a while. Hilarious. 

Well, it's a new month, and you know what that means.  That's right, another 1GB of photos to upload to Flickr.  Most interesting of the uploads this week is my full set of 4th of July fireworks pictures.  These are from two sessions of fireworks launching.  One out west of Belton with my brother and his in-laws, and another with Jen and Dave's family out in Copperas Cove. During the later session, we were much better prepared for taking photos, so they turned out really good.  My new digital processing techniques really brought out alot of detail as well.

I have now loaded all of my pictures back to the point where I got my Canon 300D, so next comes the flood of older pictures from my old Sony DSC-S70.

I had two projects over the weekend.  One was to get my bathroom ready to install a new bathtub.  The other was an experimental coding project.

The bathroom preparation went fairly well.  I ripped out all the cabinets and countertops.  I'm glad my brother showed up unexpectedly because that countertop was incredibly heavy.  We also got alot of the carpet ripped up.  I'm going to be putting down new flooring as well.

On the coding front, as an experiment in adopting new features in Whidbey, I implemented a binary file parser for Standard Test Datalog Format (STDF) files.  These files make up 99% of the data we work with at work and that fill our many-terabyte test result database.  We have a fairly complex parser and db loader framework, implemented in C# on 1.x.  It works very well, but it was written early on in our adoption of .net with little knowledge of what the CLR could do for us. So, my experiment was basically to see how new features in Whidbey, along with my now deep experience in .net, could make the parser better.

STDF is record-based.  The spec defines alot of records, and leaves room for user-defined records.  The new parser reads chunks of the file based on the record headers and produces "unknown records".  I define the record layouts using attributes on record classes.  Then, the parser uses LCG (lightweight code generation using DynamicMethod) to generate converters to read the content of the unknown records into the concrete record classes (based on the attributes).  The benefit of using LCG is that record types could be registered or removed on the fly and the GC could collect the generated code.  I could have just as easily implemented it using on-the-fly interpretation of the attributes.  I'll measure and see how the performance works out.  The parser is pull-based, meaning that you ask it for records, or alternately just "foreach" through them using an iterator-based IEnumerable implementation, which is pretty sweet.  On top of the pull-based parser, I built an event-based "processor" where a consumer can register to receive certain record types.  This is the model used in our current parser, but after the XmlReader vs. SAX discussions, I thought exposing the pull-based approach was the right thing to do.

I had a few challenges, which I think represent work for the next version of the CLR:

• Endian-ness - To my knowledge the framework does not have any mechanism to work with binary data with non-native endian-ness.  The STDF is written in whatever endian-ness is native to the platform, so the parser must adapt.  This was a simple enough problem to solve, but now that most of the other gaps have been filled, endian-ness represents a hole in what the framework provides.
• Generics' proliferation - Generics are great, and saved me tons of code, but they have not made their way into the rest of the platform where they could be leveraged.  For instance, if I create a RecordField, there's not a simple way to do something like BinaryReader.Read() to actually get one, so I was forced into tons of ifs and switches, and passing Types around to get the work done.  It just didn't feel right.
• LCG debugging - From what I understand, this was cut from Whidbey.  The workaround for me was to have two generation paths.  One would do LCG, and the other would do traditional Reflection.Emit that could be debugged and PEVerified, etc.  The problem with this was the argument were not aligned between the two.  When doing the traditional Reflection.Emit, ldarg.0 would give you the "this" instance, which didn't exist in LCG.
• Handler registration (Generics compatibility) - Ideally, record handlers should work with concrete record types, but the way generics work a Converter is not assignable to a Converter even though Mir : StdfRecord.  Of course implementing that would complicate many things.  Interestingly, delegate(UnknownRecord unknownRecord) { return new Mir(); } will satisfy both delegate types.  So, this was just frustrating that Generics didn't help me out in solving my record handler registration problems.  There may be a solution that I'm not seeing here because of my approach.  Any ideas?

Oddly enough, I spent about equal time on both projects, but I seem to have alot more to say about the later.

[UPDATE] I realized that the entry box swallowed some of my generics syntax, so I fixed that, as well as fixing some minor spelling and grammatical errors.

My dad got the pictures up of our water heater fiasco from yesterday.  He's got just about the whole process documented in pictures.  I had actually forgotten about using the chainsaw.  Check out the photoset!

Evidently, this is the weekend for floods.  Jeff (Flint) evidently had a flooded basement, and Becky and I discovered our guest bedroom was full of water.  We thought it was our washing machine, but it turned out that our hot water heater had developed a leak and had been dripping for some time.  So, I ripped it out of there and, with the help of my dad, put in a new one.  It was pretty easy.  I bought a torch because I had to sweat on a threaded adapter to make any future work easier.  That was pretty fun.  Thank goodness Lowe's was open on Easter.  Otherwise, it would have been a cold shower for me tomorrow.  Thanks, Dad!

With my mom's help, Becky was able to pull up the carpet and dry things out in the guest bathroom.  Thanks, Mom! (and Becky)

My dad got some pictures.  I would have taken some, but I was pretty busy and ticked off that I was having to spend my Easter replacing my water heater.  When he gets them up on Flickr, I'll link to them.