eWeek recently reported here that the Gartner Group released a report back in May stating that the 40 hour work week is “going the way of the dinosaur.”

Maybe, but I wouldn’t put money on it.

I’d be more willing to bet that the concept of spending 40 hours a week in an office environment might be dying off. But as anyone who’s worked in tech will tell you, only 40 hour weeks are more an oddity that the norm.

And as the labor pool continues to shrink (think boomers and college students disillusioned with the whole idea of tech), how realistic will it be for those getting into the field to insist on 20-30 hr weeks? When I was looking, I saw more than a few postings with comments along the lines of “involves on-call rotation”, “must be willing to work hours as necessary”, “able to open a vein on demand”, that kind of stuff.

One read through just about any Network World or eWeek and you’ll see interviews with C-level execs and tech managers describing how they love their 80+ hour a week jobs, and how things are so much better now that they can work via blackberry while climbing in the Rockies with their families (I just don’t want them belaying me!).

Interestingly, there was another article in the issue about telecommuters and how they tend to burn out quicker than non-telecommuters because they actually inadvertently work more than if they were going into an office. When your office is your home, it’s easy to get sucked in like that. The author also mentions how, as a telecommuter, you tend to believe you need to work harder to prove you’re actually working. In an office, apparently just showing up means you’re doing your job.

It’ll definitely be interesting to see how all this shakes out over the next 20 or so years.

Something that’s always bugged me about the scroll wheel is that it seems you have to upgrade your mouse with each new Windows in order for the scrolling to work properly.

For instance, I have an older Logitech MouseMan Dual Optical Corded mouse. Great mouse. Lousy scroll support.

The Logitech MouseWare drivers don’t scroll legacy app windows that have scroll bars but don’t react to the newer mouse scroll messages.

All the latest Intellipoint drivers don’t scroll legacy apps properly with it either (and possibly not even with a newer mouse, but I don’t have a newer mouse so…)

Way back when, I came across the Intellipoint 4.1 driver set that DID scroll legacy apps properly (like VB6, the main one I’m concerned with anyway).

Well, Vista flat refuses that driver set . I tried the latest Intellipoint, 6.1. It installs but doesn’t scroll right. I tried the latest SETPOINT400.EXE from Logitech. No good either. Uninstalled both and I’m back to the built-in Vista Mouse Driver.

Then I came across KatMouse. Tiny little app, but works a treat. Sends legacy scroll messages to the window under the mouse. And it doesn’t screw with newer apps that DO handle the mouse scroll wheel messages. Plus you can customize the scroll support per App or Window Class (and God knows my favorite thing to do is poke around windows with WinSpy looking up window classes so I can set each one to different scroll numbers<g>)

I’m sure there’s more involved, more flexible utilities out there to do the same thing, but I haven’t seen any yet. Any pointers?

Like any good developer, I have two ton crap load of Utilities, config, scripts, etc that I regularly make use of. Unfortunately, they’re all tailored towards Windows XP and I’m now in the process of setting up a Vista machine for development.

The first thing I ran into is that you can’t just dbl-click REG files anymore to merge them, unless they only modify the HKEY_CURRENT_USER hive. Grrr. Running Regedit as Admin is a workaround, albeit not a great one.

A bit more problematic, though is my favorite DOSHERE.INF file. This little jewel goes back to, what, Win95 and the old PowerToy kit, I believe.

At any rate, here’s my modified version that works fine under everything up to Vista, but no-ops now.

;
; "DOS Prompt Here" PowerToy
;
; Copyright 1996 Microsoft Corporation
;
[version]
signature="$CHICAGO$"

[DosHereInstall]
CopyFiles = DosHere.Files.Inf
AddReg    = DosHere.Reg

[DefaultInstall]
CopyFiles = DosHere.Files.Inf
AddReg    = DosHere.Reg

[DefaultUnInstall]
DelFiles  = DosHere.Files.Inf
DelReg    = DosHere.Reg

[SourceDisksNames]
55="DOS Prompt Here","",1

[SourceDisksFiles]
DOSHERE.INF=55

[DestinationDirs]
DosHere.Files.Inf = 17

[DosHere.Files.Inf]
DOSHERE.INF

[DosHere.Reg]
;DWH Modified the below lines so that
;they work under NT
;How would you indicate the actual COMSPEC environment var?

HKLM,%UDHERE%,DisplayName,,"%DosHereName%"
HKLM,%UDHERE%,UninstallString,,"%10%\rundll.exe setupx.dll,InstallHinfSection DefaultUninstall 132 %17%\DosHere.inf"
HKCR,Directory\Shell\DosHere,,,"%DosHereAccel%"
;HKCR,Directory\Shell\DosHere\command,,,"%10%\command.com /k cd ""%1"""
HKCR,Directory\Shell\DosHere\command,,,"cmd.exe /k cd ""%1"""
HKCR,Drive\Shell\DosHere,,,"%DosHereAccel%"
;HKCR,Drive\Shell\DosHere\command,,,"%10%\command.com /k cd ""%1"""
HKCR,Drive\Shell\DosHere\command,,,"cmd.exe /k cd ""%1"""

[Strings]
DosHereName="DOS Prompt Here PowerToy"
DosHereAccel="Command &Prompt"
UDHERE="Software\Microsoft\Windows\CurrentVersion\Uninstall\DosHere"

From what I can tell, the main problem is that INF files just can’t alter HKLM or HKCR when run as a normal user (even with admin privileges).

I have used a simple little reg script from time to time also

REGEDIT4

[HKEY_CLASSES_ROOT\Directory\shell\DosHere]
@="Command &Prompt Here"

[HKEY_CLASSES_ROOT\Directory\shell\DosHere\Command]
@="C:\\WINDOWS\\system32\\cmd.exe /k cd \"%1\""

and this works quite nicely on 2000 and XP, but it does not work when fires via the Context Menu in the tree portion of Explorer under Vista.

However, in poking around the registry on Vista, I discovered an interesting little tidbit.

Vista already has support for a “command prompt here” built in (at least Vista Ultimate does, which is what I’m using. The reg entry looks like this:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\cmd]
@="Command &Prompt Here"
"Extended"=""
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Directory\shell\cmd\command]
@="cmd.exe /s /k pushd \"%V\""

The Extended entry appears to cause the item to only show up when SHIFT is held down.

Notice the difference in the command line from the earlier version. Why the /k cd {path} doesn’t work from the tree, but the pushd %V does, who knows?

So, I hack a little to come up with this:

REGEDIT4

[HKEY_CLASSES_ROOT\Directory\shell\Cmd]
@="Command &Prompt Here"
;remove this property so that command shows all the time, not just when you hold down SHIFT
"Extended"=-

[HKEY_CLASSES_ROOT\Directory\shell\Cmd\Command]
@="cmd.exe /s /k pushd ""%V"""

And lo, the angels sing and I can continue on my merry way.