I've noticed over that past few weeks of running Vista that certain things tend to be A LOT slower now, even given the fact that I recently picked up a gigabit network card for my server, and a gigabit switch, so I could make use of the built-in gigabit network adapter on my new workstation motherboard.

For instance, I use a program called VBLiner to line number all my VB source right before I compile it. The line numbering process itself is very fast, but the program would pause, noticeably, for each file it opened. It was almost as if the process of locating and opening the file was slow, but actually reading it was very fast.

Today, it finally got to be too much, so I had to start digging.

Come to find out, Vista has this nifty new thing called "Network Autotuning" that, apparently, doesn't work particularly well.

You can see it yourself by opening a DOS box (with Admin priviledges), and entering

NETSH INTERFACE TCP SHOW GLOBAL

You should end up seeing something like this:

That "normal" is the problem.

Execute this to turn off autotuning:

NETSH INTERFACE TCP SET GLOBAL AUTOTUNINGLEVEL=disabled

turn it back on with

NETSH INTERFACE TCP SET GLOBAL AUTOTUNINGLEVEL=normal

and, apparently, using this will sometimes work, too, though I'm a bit hesitant to bother at this point.

NETSH INTERFACE TCP SET GLOBAL AUTOTUNINGLEVEL=HIGH

Nothing like a built-in network performance de-tuner.  It's STRESS.EXE but without all the hassles of actually having to run a utility. Grrr.

I've been known to make a few spelling mistakes in code (retrieve vs retreive caused me no end of pain at one point, long, long ago), and any programmer knows that it can sometimes be tricky to get the grammar right for a particular dialog, especially when a checked checkbox causes something to not happen . I usually set up a special priority (1000 in a 1-10 system) for spelling and grammar mistake bugs in whatever bug tracking system I'm using, because, let's face, it, few bugs are more embarrassing, both for the programmer and the company, and fewer still can be located and fixed as easily.

But this one surprised me. It's in the IIS7 management console.

Ah, good to see that even billions of dollars in liquid capital can't solve this problem.

Encryption is an unbelievably complicated topic and I'm only now beginning to get comfortable with digital signatures in Office documents.

The Good News is that in Office 2007, other than the fact that the menu locations for checking signatures has changed, most everything about digital signatures has remained the same as in Office 2003, and, from what I can tell, things are compatible all the way back to Office 2000.

The Bad News is that it's still complicated as hell to deal with digital signatures.

I’ll try to cover a few of the bigger bits I’ve come up against while digging through digital signatures in Office (and in particular, in Word).

Signing a DOT file

The first thing you must do when getting ready to sign a template is to manually enable timestamping. Ok, technically, you don't have to do this, but if you don't timestamp the signature, when the certificate used to sign the template expires, so will the signature, and poof, your template will no longer be signed. Depending on how the user’s Word Is configured, that may mean that your template now fails to load.

You enable timestamping by adding a few entries to the registry. Office doesn't provide a way to do this via the UI (even in 2007), so it's all regedit (or run the REG script below).

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\VBA\Security]
"TimeStampURL"="http://timestamp.verisign.com/scripts/timstamp.dll"
"TimeStampRetryCount"=dword:00000005
"TimeStampRetryDelay"=dword:00000005

Once you've turned timestamping on, you need to verify that you have a digital certificate loaded that can be used to sign templates.

Click the Start button and RUN, enter MMC and press Enter. This should bring up an empty Management Console.

Click FILE, Add/Remove Snap-in and find the Certificates snap in, then load it up.

When it asks for what type of certificates to manage, select the computer account.

Next, it should ask about managing the local computer account or a remote computer account. You’ll normally want to only deal with the Local Computer.

Once you get the certificate manager loaded, expand the personal certificates. Generally speaking, this is where certificates purchased through online vendors (like Verisign) will end up when you download them.

Now, right click the certificate and choose Properties.

You should see code signing in the box as shown. I’m not an expert on the different types of certificates, so it may be possible to sign documents WITHOUT a code signing certificate. Best to talk with someone at your vendor for details on that. One definite benefit of a code signing cert is that you can use it to sign DLLs, and EXEs, as well as templates.

Anyway, at this point, you can be pretty sure the cert is appropriate for signing templates.

One final note: It is often a good idea to export the signature so you can use it via the command line etc. The PFX (Personal Information Exchange) file format is good for this, because it contains both the public and private keys for the certificate. The bad news is you want to protect the PFX file as much as possible, because if someone obtains it and the password used to create it, they would be able to sign documents as if they were you.

You can export to a PFX file by right clicking the certificate entry (in the middle list), selecting All Tasks, then Export.
Indicate that you want to export the private key (which will require a password), and then make sure you select the PFX output option.

Verifying the Signature

Verifying that you actually got the Digital Signature correct is one of the more frustrating parts of working with digital signatures in Office.

You'd think you'd be able to verify the signature via the Tools/Digital Signatures menu in the VBA editor screen:

If you get this far, you know that the signature was signed. You can check the valid dates on the certificate as well.

However, this screen does NOT show the date the signature was timestamped and that, unfortunately, is a key piece of information you need to verify the signature. In fact, although this screen purports to be showing the digital signature, this is really just information on the certificate used to create the signature.

Verifying the TimeStamp

To actually get information about the signature, and specifically the timestamp, you have to jump through a few hoops.
First, make sure that the template IS NOT in any of the autoload places (most commonly the Word STARTUP folder or the Excel XLSTART folder).

Next, make sure that security is set such that unsigned templates won't automatically load without prompting.

Once you've done that, if you put the signed template, say, on the desktop and load it by holding down the SHIFT key, right clicking, and selecting OPEN, you should get the message bar indicating that there are security warnings.

Click the Options button and you should get a Security Alerts Window:

Click the Show Signature Details link to see the actual details of the signature itself:

Notice the title of this dialog is actually "Digital Signature Details", not "Certificate Details". And the Signing Time is indicated here, showing that, in fact, this digital signature was timestamped.

One final note. The Office 2007 and 2003 object model (and XP, but not Office 2000), contains properties for enumerating and retrieving information on document and template signatures. Specifically, the DOCUMENT object now sports a SignatureSet property, which is a collection of signatures on the document. From there, you can navigate through the object model to retrieve all the signatures on the document, as well as details (including the signing time) of those signatures.

However, there are significant differences between the models in 2007 vs 2003, so any code written to utilize those objects would need to accommodate those differences.

The above steps work similarly in all versions of Office from 2000 to 2007. I’ll try to capture screenshots of the process in Word 2000 at some point, to illustrate the differences.

Related links

Office 2000 Macro Security

I'd been working quite happily with VB6 and Windows Vista for several days, when, this morning, I ran head long into a very disturbing problem

I had a class open, and was trying to enter:

Private myvar as Boolean

but as soon as I hit SPACE after the AS, long pause and CRASH.

Every time. Completely consistent.

Poking around in the Application Even log yielded this:

Faulting application vb6.exe, version 6.0.81.76, 
time stamp 0x3592011f, faulting module OLEAUT32.dll, 
version 6.0.6000.16386, time stamp 0x4549bd95, 
exception code 0xc0000006, fault offset 0x0000d921, 
process id 0x17e4, 
application start time 0x01c7cade79735543.

Which seems to clearly point at OLEAUT32.DLL and, I'd guess, the TypeLibrary loading and handling stuff that VB6 makes heavy use of for Intellisense purposes.

My first thought at this point was, holy crap! I'm gonna have to go back to XP to be able to get a stable VB6 environment!

I googled a bit and came up empty.

Then, I heard this voice in the back of my head (no, not those voices, one of the rational ones ) that suggested checking the SP level of VB6. Sure enough, I hadn't installed SP6 (remember, I just repaved this machine a week or so ago).

Interestingly, MS's update gizmo hadn't suggested SP6 as an update. Guess their most popular language doesn't rate high enough on the important scale.

At any rate, I installed SP6 and tried the same coding, worked perfectly.

Lesson of the day, always make sure you snag all the SPs when repaving.

Well, at least that's one minor panic attack avoided!

With the success I had with getting a bootable image of MFSTools onto my old 1GB USB stick, why not go all out.

My local Fry's has on sale Sony MicroVault USB sticks with a slide out connector.

I picked up a 4GB model for 37$ and am thinking a multi-boot setup with multiple partitions.

• MFSTools, for all my Tivo adventures.
• DOS6.2 with all my various boot tools, SpinRite, etc.
• Ultimate Boot Disk, with various OpenSource DOS's, plus some Linux stuff to, I believe.
• A BartPE Windows XP boot partition.

Anything else that might seem useful?

Niceties about the USB boot disk option:

• It's fast
• You don't have a reburn a DVD to make a change to the configuration
• The sizes are to a point now as to be actually useful

I probably won't toss my trusty DOS 6.2 boot floppies just yet, 'cause some of my machines can't boot to USB, but I suspect that will be changing over the next year or so.

And now, from the world of unbelievably arcane email minutia, comes this:

In GroupWise 7.00, create a new message, enter some text and bold a few bits, thus making the message HTML format.

Now, add an attachment, say a bitmap.

And finally, add another attachment, this one an HTML file called Text.htm.

Don't send, but rather, just close the mail window, at which point GroupWise asks if you want to save the draft. Save it to some folder.

Now, go to that folder and open the email. Your Text.htm attachment has evaporated! The other attachment should still be there.

Same thing happens if you were to just send the email, which is quite handy when the file you wanted to attach is actually called "Text.htm".

Turns out, this would appear to be a bug in the way GroupWise handles attachments and HTM emails. Internally, they save the HTM body of the email as a FILE attachment called, you guessed it, TEXT.HTM. In some cases, as when you simply send the email directly, GroupWise properly HIDES that Text.htm attachment from attachment enumeration. But in other cases, such as when you open that saved draft message and send it, GroupWise fails to hide the attachment properly.

Which means that if you're enumerating attachments in an outgoing GroupWise email, you need to be aware of that or you might end up processing the body of the email as if it were actually an attachment. That may or may not be something you want to do.

At least with Outlook, the HTML body of the email is flagged in such a way that it doesn't show up when enumerating normal attachments. You have to go out of your way to retrieve the HTML or RTF body text of a message.

Gotta love those gremlins!

I've got Vista Ultimate running on my freshly paved machine, and I finally got to a point where I want to get all my .NET stuff back and operational.

I retrieved my website from VSS (fortunately, it was all checked in and up on my server), and went to setup the Virtual Directory in IIS. Where's IIS?

Come to find out Vista doesn't install it by default, but it's easy to get.

Click Control Panel, Program and Features, then

Click the Turn Windows Features On or Off

Find IIS in the list and check it. You might also want to check the FTP server while you're there, but it's not absolutely necessary.

Once, it's installed, you'll find an "Internet Information Services Manager" item on your Administrative Tools menu.

With DotNetNuke, one of the first things you have to do is change the Default Document to include Default.ASPX, the option is highlighted above.

When I tried this, I got an "Access is denied" error. Grrrr. More Vista Access Control crap, I thought.

I spent almost an hour digging around for any settings in the IIS Manager that I might need to change to be able to make this pretty innocuous change to the website config. Nothing.

Then, I happened to think....Maybe it's because I pulled all the files from VSS. When you do that, files are automatically marked READONLY.

A little experimenting later, and turns out, you need to make sure that WEB.CONFIG (in the root of your site's virtual directory), is NOT READ ONLY.

Duh.

I have to say thought, that error message window could use just a tad more information. Even the name of the file with the problem (WEB.CONFIG) would have probably saved me an hour of digging.

Seems to me error dialogs like this ought to always have a "»more" button on them. Most people will never click it, and it'd keep the general UI light and fluffy. But when you need it, it'd be there.

Pie in the sky, I suppose.

I've worked in a variety of positions over the years, including staffing up entire development departments.

One element I usually insist on in new hires is a reasonably solid foundation of knowledge of basic PC hardware and Windows setup (I've generally worked in Windows shops, hence the bias there). Things like hard drive setup, FDISK, formatting, all the way to assembling normal PC components (i.e. box of parts to a working PC).

Granted, these days, it's not particularly cost effective to actually build out  developer machines this way, but it seems to me that generally speaking, developers ought to know their way around under the hood, maybe not at the circuit level, but at least the component level.

Is this expecting too much? Not enough? I could always wimp out and say that it all "depends on the situation." But I'm not talking about specialized hardware or device drivers. I'm talking about general business applications.

Or have computers become more like commercial airliners or helicopters, where the pilots fly, the mechanics fix, and never the twain shall meet?

Here's an oldie but a goodie.

I hadn't run into this in years, but here it was, making a nasty return.

Basically, if you're running a VB6 application under Windows XP, and you have all the XP UI goodies turned on (the default), and your app contains option buttons directly sited within a Frame (pretty typical), the text of the option buttons will be blacked out by nasty black squares.

When I first ran into this, far too many years ago to mention, there was nothing about it anywhere. I remembered looking for several days for a solution before stumbling onto one.

Fortunately, there's now a good KB article (KB936166) on the issue (though MS never fixed it).

Interestingly, as workarounds, the article offers:

•	Right-click the desktop, click Properties, click the Themes tab, and then select Windows Classic in the Theme list. Alternatively, click the Appearance tab in the Display Properties dialog box, and then click Windows Classic style in the Windows and buttons list.
•	Do not put option buttons inside frames.

While helpful, neither of these options would really do much to make my customers happy.

Fortunately, there is a third option:

Site your option buttons in a PictureBox (just set the background color appropriately and frame style to NONE) and then site the PictureBox on your frame.

Everyone's a winner, and it's not too terribly stomach-churn inducing.

I'd been meaning to upgrade/backup my TIVO hard drive for ages now (it's actually more than 4 years old, and has been running almost continually in that time).

The prospect was a tad daunting, esp after looking through the Hinsdale How to Guide. I'm not a huge Linux gearhead, but I can find my way around in a pinch. Still, at 26 pages, there's a lot to absorb there.

In the end, after a good weekend of various false starts, I'm happy to say I now have a 370 hour Tivo with a nice, fresh, cool-running, ultra quiet Western Digital 320gb hard drive. And I was able to preserve all my existing recordings to boot! I probably should have taken the time to setup the FTP daemon or telnet access while the drive was out, but I've just run out of time for now.

However, for those considering attempting this, I thought I'd document a few of my false starts to hopefully keep you from traveling down those same paths.

First, the Hinsdale guide contains great info on removing the cover of the TIVO, removing the hard disk, what hard disks you might want to use to upgrade (I happen to prefer the newer Western Digital drives), and the commands you'll need to move TIVO drive images around.

Also, I'm writing this from the standpoint of upgrading a single drive Tivo with a new, BIGGER single drive. If you're dealing with a dual drive Tivo, or just want to add a second drive to your Tivo, this page probably won't help you much.

Steps 1-6

These steps are all spot on and will get you to the point of having the TIVO drive in your PC. Make sure you have a bootable CD of MFSTools (or copy it to a bootable USB drive like I did).

Of course, having a whole step like:

Buy a Tivo

and

Buy a Torx Screwdriver

is a tad overkill, but at least they're clear on the subject.

Step 7

This is all about making a short and sweet backup of your original TIVO disks. DO THIS!  A VERY IMPORTANT POINT TO NOTE is that when mounting your existing FAT32 drive (that you'll use to write the backup to), they indicate to use the commands:

mkdir /mnt/dos
mount /dev/hda1 /mnt/dos

Take special note of that hda1. That's hugely important! I accidentally entered /dev/hda (missed the "1"), and totally trashed the drive I wanted to use for the backup. I had to reformat it to get it back.

The backup command in Step 7 worked just fine for me, but be sure you attempt Step 8 (Restoring the MFSTools backup) before assuming it is a valid backup! See below.

The backup command I used (with a Series 2 TCD24004a Tivo) was:

mfsbackup -f 9999 -6so /mnt/dos/tivo.bak /dev/hdX

where X is the drive ID of the original Tivo drive you hooked up to your PC, typically "hdc" or "hda".

FALSE START: I originally wanted to try performing the backup on a scratch drive I had lying around. Ie, backup and restore a scratch drive AS IF it was a Tivo original drive, just for practice.

Attempting to use MFSbackup on a non-Tivo drive will just end up giving you a read-block error, so that was no go from the start. Then, I came across the dd command a little later on in the backup section, so I tried it:

dd if=/dev/hda of=/dev/hdb bs=1024k

That ran for hours and hours and never completed. I stopped it after about 8 hours. One reason is that the "source" drive was a FAT32 formatted 120gb drive. Apparently, the dd command is very slow with large drives like that.

Step 8

As I mentioned above, you definitely want to verify that the backup actually worked. It failed once for me (because I didn't get the command quite right), but it didn't tell me it was a bad backup.

One point that the guide mentions and I'll stress is to unmount (using umount -f -a -r) before rebooting and then powering off the machine.

You'll want to test the restore of the quick backup using the command:

mfsrestore -r 4 -s 127 -bzpi /mnt/dos/tivo.bak /dev/hdX

where X is the letter of the NEW drive that will be going into your Tivo.

FALSE START: there is a paragraph in the guide that starts with "Note for those with already tested image" that basically indicates you should be able to perform a particular restore and automatically expand the Tivo in one shot, if you've already tested restoring the image. This didn't work for me. The command they show to use is:

mfsrestore -s 127 -xzpi /mnt/dos/tivo.bak /dev/hdX

Note the missing -r 4 and the -xzpi instead of -bzpi.

I'm not sure what the difference is, but I do know that the Step 10 instructions below DID work properly.

Step 9

Put the new Tivo drive (that you just restored a backup onto), into the Tivo and try to boot it. This is just to verify that the backup and restore worked.

After working with PC's so long, it's a bit strange to work with a device that has no OFF button. To turn on the TIVO, you plug it in. To turn it off, you unplug it!

Step 10

I wanted to preserve setup and recording so I browsed through to the proper spot in Step 10.

Once I hooked the Original TIVO drive AND the new Upgrade Drive (had to take it back out of the Tivo box from Step 9), I rebooted to MFSTools and used this command:

mfsbackup -Tao - /dev/hdX | mfsrestore -r 4 -s 127 -xzpi - /dev/hdY

where X is the letter of the original TIVO drive and Y is the letter of the new Upgrade drive.

Note that the -r 4 is here from the part of Step 8 above that worked. I'm not sure of the difference between -xzpi and -bzpi. ANy ideas?

This command took a LONG time (for a 40hr Tivo, it took about 8 hours), but it does show progress (unlike the dd command), so I knew it was working the whole time).

FALSE START: I thought it might be good to grab a backup of the WHOLE Tivo drive and then restore that, so I tried this command, after remounting my FAT32 disk I was using to save backups:

mfsbackup -Tao /mnt/dos/all.bak /dev/hdX

It ran for a while but then failed for no apparent reason. I probably just don't have the flags right, but it was 12:30am, so things were getting bleary.

Summing up...

In the end, the single step backup from original disk->restore to new disk worked just fine. Put it back in the Tivo, booted, and now I have plenty of space for Sesame Street and Stargate.