Firefox DHTML

After many years of corporate (Internet Explorer only) web development, I got my first taste of Firefox DHTML and it wasn't pretty. Here's the code (minus some styles to counteract the default blog stylesheet):

<table border="1" cellspacing="1">
    <tr>
        <td>Column 1</td>
        <td>Column 2</td>
    </tr>
    <tr id="trhidden">
        <td>x1</td>
        <td>x2</td>
    </tr>
    <tr>
        <td>y1</td>
        <td>y2</td>
    </tr>
</table>
<script>
function Toggle()
{
    var h = document.getElementById('trhidden').style;
    if (h.display == 'none')
        h.display = 'inline';
    else
        h.display = 'none';
}
</script>
<button onclick="Toggle(); return false;">Show/Hide</button>

And the result is:

Column 1	Column 2
x1	x2
y1	y2

Click the button a few times in Firefox and IE to see the difference. How Firefox can screw up something so basic is beyond me.

Gratuitous Configuration

I have always been annoyed by developers who try to put every possible option into configuration files.

First, they inevitably fail. The space of possible application behavior is more than exponential in the number of actions the user performs. It is exponential in the amount of actions available to the user. This abstract fact has a simple practical result. Most changes requested by the business are not feasible by adjusting a configuration file, no matter how universal you try to make it. So you have gained almost nothing.

Second, they are difficult to use. Nobody ever documents these monsters, and you have to dig through code to figure out what you have to change, or whether the change is configurable at all.

I recently had an epiphany on why so many developers continue to use them. It is related to the fact that good application architects are about as common as flying pigs. There is a mindset that the code on large projects is expected to be a tangled mass of spaghetti. Since it will be virtually unmaintainable anyway, it is beneficial to set aside a fixed space of customizations which will always be possible. Configurations do just that. The more behaviors which are controlled by configurations, the more customization which will be possible.

I reject this mindset. I have never had trouble designing maintainable systems. My challenge has always been preventing self appointed experts from mucking up the architecture.

Virtual PC

Using Virtual PC can be frustrating as it is easy to screw up and end up wasting lots of time, and little guidance is available. So here are some tips.

First some concepts. A real PC can be described by the hardware, the contents of the hard drive and the state of memory. So a virtual PC is described by a settings file (hardware, sort of), a virtual hard drive, and a state file. The state file will not be saved if you 'shut down' within the virtual OS. If you stop the VPC while it is running, the state file can be saved. If you then delete the state file, it is as if you powered-off the PC without shutting down. For example, the OS will complain when you start back up. You can swap hard drives when the VPC is not running, or change memory size. What is hard, and the subject of this blog entry, is changing the hard drive size.

When you set up a hard drive, you can choose fixed size, or dynamic. Dynamic is nice because the file adjusts itself to whatever space is needed, instead of taking up the full space from the getgo. It's a little confusing, because it asks for a maximum size, and offers a size much larger than your real hard drive. You should resist the tempation to reduce it at all as it is hard to change later. This is the number which will show up in the VPC as the size of the disk. It has little to do with the actual size of the virtual disk file.

But lets suppose you already made that mistake and installed XP on a 16GB-max dynamic disk. That's plenty of space, of course, as XP takes up about 4GB. Then your boss tells you to upgrade the virtual OS to Vista. You refuse of course, so he waterboards you to make you do it. You confess to terrorism after 20 seconds, and finally agree to upgrade to Vista after 3 minutes of torture.

First thing you find out is that the Vista upgrade requires 15 GB of free space, beyond the 4GB you already use (despite the fact that the final result only uses about 7GB).

Tip #1: There is a 3rd party utility from vmToolkit called VHD Resize.

Sounds like just what you need. So you follow the instructions and you get a 64GB max dynamic virtual hard drive file. You then boot up your VPC and the hard drive size is unchanged *frown*. What the instructions fail to tell you is that there is a step you always have to do after resizing. They don't tell you this because to them it is completely obvious. What you have done is analogous to buying a new hard drive and copying your old smaller one bit by bit. That too will look to the OS like the size hasn't changed, because the partition hasn't changed. Aha! we have to expand the partition.

Tip #2: There is a DISKPART utility which comes with the OS.

I forget the exact syntax (yeah, it's a console app with text commands, fun), but you have to SELECT the drive, then SELECT the partition or volume, then EXPAND to fill all available space.

Ok, now you have enough space to do the upgrade. Once that's done, your disk is all fragmented and takes up about 14GB, even though there's only about 7GB of data on it. This is bad becuase you want to copy your disk file to a safe place whenever you have finished a critical and time consuming step (like after you activate the OS). You know there is a command to compact the disk file, so you defrag and then run it. Takes a while, and there is no improvement. If you read the instructions carefully, there is a little tidbit in there about running precompactor (what's that?).

Tip #3: You have to run precompactor before compacting.

Precompactor is located on a virtual CD ISO file in the Virtual PC directory in Program Files. You will find it next to the extensions ISO that you probably have run by now. Just attach to it in the usual way (sorry, this is not a general help screen), and it will blank out the disk sectors so compactor can remove them.

Still, the drive file will be significantly larger than the data. This is because compactor does not move data, it only truncates empty space at the end of the disk. Unfortunately, I don't know of a defragmenter which does a good job of moving files to fill the unused space. If you do, please add a comment.

Tip #4: <your defrag suggestion goes here>