Let’s just wait for Service Pack 1

Every so often, I’ll hear it said, and frequently not in jest, “let’s wait until Service Pack 1 before we deploy Vista”, or sometimes “Server 2008”.

While it’s true that Microsoft has indeed announced plans to test, and then release, Windows Vista SP1 early in 2008, I have to say that I don’t find this thinking any smarter than the old “let’s buy IBM” idea, based on the “Nobody Ever Got Fired For Buying IBM” principle.

Even if it were true, someone’s eventually going to realise that if it’s your job to specify what the IT budget gets spent on, and you say things like “we’ll deploy it after Service Pack 1”, you’re just not acting as if you’re doing your job.

Somebody, one day, will call your bluff, and say “Why? What bug is a showstopper for deploying Vista RTM, and why do you believe it’s fixed by SP1? Why didn’t you find that bug out while you were beta testing the operating system? Weren’t you beta testing the operating system?”

And you’re going to look foolish, because you don’t have anything in particular to point to (UAC? That’s a bit generic – you have to say what you don’t like about UAC, and why you think SP1 will make it all better) in order to defend your mindless parroting of “let’s wait for SP1”.

For the record, there are reasons to anticipate SP1 – it adds an SSL-based VPN capability, through the SSTP, and it allows you to encrypt multiple drives using BitLocker through the UI (you can use manage-bde.wsf to encrypt multiple drives using BitLocker from the command prompt).

There are other features in SP1, and you should definitely consider whether you can use those features. But there really isn’t any break-fix that makes it important for you to stop testing and planning to deploy Vista RTM while you wait for SP1.

Are you a ‘dual’?

Last month at Tech-Ed, I was discussing with someone from the Solution Accelerators team about how I wished that Microsoft would produce some administration documentation for developers, and/or developer documentation for administrators, so that the two groups would be able to talk the same language.

[As a f’rinstance, back in the days of Windows 2000 and before, if you were a developer writing code to log a user on to the system and run a process (say, for instance, in your spiffy little FTP server), you would face an error if your code wasn’t running in the context of an account with SE_TCB_NAME privilege.

But you couldn’t tell an administrator to enable the SE_TCB_NAME privilege on the application’s account, because he’d have no idea what you mean.

To an administrator, that privilege is called “Act as part of the operating system”.]

“Well,” said my conversational partner, “That’s because you’re a jewel.”

“That’s awfully nice of you to say, you’re somewhat of a gem yourself.”

“No, not ‘jewel’, a ‘dual’ – you span the two worlds of IT Pros and Developers.”

He went on to explain that there are few duals, and that this was why there were few resources that address the disparity between what is developed, and what is administered.

A lot of the examples I came up with (e.g. the name LUA versus UAC) were rooted in the history of development – where Microsoft’s naming police have chosen a name that they felt was “catchier”, “more marketable”, or simply “not offensive to <some-group>”, as a replacement for an internal name. Changing the internal name in APIs that have already gone through beta testing is not generally possible, so the developer name stays as the old name, and the administrative interface is changed to present the new, marketing- and legal-friendly name or image.

Are you a dual? What are some of your challenges in communicating across the boundaries between two worlds?

Windows Script 5.6 – making me less nervous.

Remember my posting  “How to make me nervous“, where I talked about Microsoft’s release of Windows Script 5.7, and their rather sudden removal of Windows Script 5.6 and before? My concern was that this removes our ability to fix broken script engines by merely applying a Windows Script version that we have tested, and forces us to start upgrading on some machines before we’ve had a chance to test.

I also expressed significant disquiet about this move, stating that this behaviour implies that there is some significant flaw in version 5.6, some huge reason why Microsoft wants everyone switched now.

I just received the following response from Microsoft:

“We DO want to encourage people to update to 5.7. We’ve worked hard to
improve its performance, security, and stability while taking utmost care
with compatibility. We’re proud of the work we’ve done on scripting in the
Vista development cycle, and we’re excited to make it available for everyone
who haven’t or can’t upgrade to Vista/IE7 yet. The next SPs of all OSs will
include Script 5.7.

“Note that the script engines installed by IE7 are version 5.7, so many users
are already running the core of script 5.7.

“We haven’t found major issues in 5.6 (unless uncommon crashes, rare
deadlocks, and a slow JScript GC, are disastrous for you).  If there were a
critical issue in 5.6, we would have published a bulletin on Windows Update,
just like we do for any other critical issue.

“We ARE re-posting 5.6 install packages, and they should appear within the
next 24 hours. We’ll probably keep these up, at least until the next SPs of
Windows, which will bring everyone up to Script 5.7.”

So, if you’re still using version 5.6 of Windows Script, you can carry on using that, and will shortly be able to fix broken versions, and upgrade versions that are a few builds behind – but make sure to test 5.7 as soon as possible, because it is coming. You should find no significant differences, and I have not yet heard of any breaking changes.

Update: Microsoft has now replaced Windows Script 5.6 for Windows XP / 2000 and Windows Script 5.6 for Windows Server 2003. Use these only where maintaining production systems that appear to require re-installation of an existing script engine version 5.6. Test your existing scripts, and those under development, against Windows Script 5.7, and assume that Windows Script 5.7 will be the future path for all systems. You will get Windows Script 5.7 on those machines in any case when you install Internet Explorer 7, if you haven’t already done so.

Larry Osterman isn’t that into you, either.

In previous articles, I’ve pointed out:

All of these are on the basic theme that developers should be aware that many users – possibly even most users – possibly even most of their users – are not going to spend a majority of their time running software written by those developers.

I pick on Apple for this because it’s fun to do so, and because their attitude seems to me to be that they know what’s best for their users, and the users have no right to choose anything different. That’s insulting to power users – hey, it’s insulting to many novice users, too.

But it’s not just Apple who exhibits this attitude. For instance, on my laptop, I have this icon in my notification area called “HP Digital Imaging Monitor”Image-0050 . Clicking on it does nothing, right-clicking on it does nothing, and I can’t say that I remember it ever doing anything other than sit there staring at me.

I can at least disable some of the icons that bother me by their presence in the notification area (but have I disabled the processes they represented?) – but the point is that there is a pile of crap on my machine that I almost never use.

Quite honestly, I’ve gotten into the habit of downloading a fresh copy of QuickTime, or RealPlayer, whenever I need to play one of their format files, and then uninstalling them again once I’m done.

What does it say about your code that a user would rather install and uninstall your program every time he wants to view your file format, rather than keep your software around?

And how easy is it then for that user to be distracted away from your code to someone else’s that does the same job? Never give your users a good excuse to dump you.

But what does this have to do with the title of this blog posting?

I’ve just noticed that over the last several days, Larry, too, has been spouting off about his battles inside Microsoft to persuade his fellow developers that, quite frankly, your users aren’t that into your code, and you shouldn’t expect them to think it’s as important as you do.

A natural consequence of this is that you should think very carefully when writing software, not to view it as the most important thing (which, being your baby, it quite obviously is), but to view it as something that a user might use once every six months.

Enough of me, then, go look at Larry’s articles – he has some even more practical advice on crapplet mitigation:

Larry’s one of my favourite bloggers – I almost always learn something from reading his posts.

How to make me nervous

How to make Alun nervous in 3 easy steps:

  1. Release a new version of a tool that Alun uses throughout his home and work life.

    • For bonus points, make it a back-port from a later version of the operating system. Back-port it to operating systems as far back as you can, since this is something you generally never do.

  2. Neglect to publish any information comparing the new version to the old version. Don’t sell me on upgrading.

  3. Remove all download locations for previous versions of the tool. Make it impossible for me to go back to the original version if the new version has issues.

In completely unrelated news, Microsoft has just released Windows Script 5.7 for Windows 2000, Windows XP and Windows Server 2003. Windows Script 5.7 was previously known as “the version of Windows Script for Windows Vista”.

There is no documentation currently available to state what has changed from version 5.6 to 5.7.

Windows Script 5.6, 5.1, previous versions are no longer available for download.