jaybaz [MS] WebLog

Parting words for dear friends

MSDNArchive — Fri, 09 Nov 2007 19:56:00 GMT

I have a few thoughts that I'd like to express about Microsoft's software development before I go.

Clearest code wins.

Most developers at Microsoft haven't yet learned the incredible value of writing the clearest code possible. Once I saw a someone make a checkin that added 200 lines in the middle of a 600 line function. I'm thinking it was already about 597 lines too long. Use Extract Method to break them in to bit-sized chunks. Use Extract Class to manage the plethora of methods you suddenly produce. Don't stop there.

OO isn't a fad

Microsoft has pushed hard over the last ~5 years to make its software secure. Security is hard, but there's no reason to make it harder. For example, countless security issues came down to buffer overruns in C++ code where a buffer was passed without a corresponding length. The response? Let's write tools that help you find places you pass buffers, and make sure you pass a length along side.

Hey, when you find yourself passing two or more values around together, why not put them in to a class? Just start there. Polymorhism, inheritance, and encapsulation can come later.

(Hey Windows: I'm looking at you!)

It's OK to use someone else's code

At one point, the Visual Studio code base had about a dozen implementations of a C++ String class, most of them hacked out of MFC. That's a vast improvement over passing the buffers around, but hey... these library writers are paid to work on these things full time! Why aren't you using STL or ATL yet?

This isn't just in C++... in the original implementation of the .Net Framework, there were countless implentations of hash tables. Woah, guys! Let's get some libraries!

Design your problems away

Every time you run in to a problem, step back & ask "How can I make sure this never, ever happens again?"

Got buffer overruns? Using a buffer class makes them go away. Having trouble with refcounts? Try CComPtr. Is your cache getting corrupted? Remove it, or encapsulate it.

When we did this in my last C++ project, we found our C++ code started to look remarkably like C#. That's a clue: C# has already designed away most of the tedium of C++.

Most importantly: we can do better.

The above complaints are specific, local issues. In time they can be addressed indivdually, and this blog post will become obsolete. But there's one thing that Microsoft developers should always be working on: doing their job better. Ask yourself questions like:

"How can I make sure this problem goes away forever?"
"How can I produce fewer bugs?"
"How can I make it easier to fix the bugs I have?"
"How can I make it easier to respond to change quickly?"
"How can I make it easier to make my software fast enough?"

I once managed a team that did this very well. They were largely new hires, mostly straight out of college. But after a year, they were rocking. They produced features faster, had fewer bugs, fixed bugs faster, and reliably beat the schedule every time. They far outperformed teams of experienced developers working on familiar code bases, often with well-understood problems. It was amazing.

EDIT: I wish I could have addressed these issues while I was at Microsoft, but that's hard, and I wasn't successful. This blog post is about the last chance I have to do anything here; now it's up to you to decide if you can use this.

Lastday

MSDNArchive — Fri, 09 Nov 2007 19:49:00 GMT

Today is my last day at Microsoft.

This morning I bike to work & shower. There's a lunch out with the team. In the afternoon there's an "exit interview". Then I leave early for a doctor's appointment, while I'm still insured. :-)

Last night I tried to log in to work from home and couldn't. Looks like they were a little overzealous with the permissions!

What's next? http://jbazuzi.blogspot.com/2007/10/new-adventure.html

How to make a bootable USB flash drive

MSDNArchive — Thu, 25 Oct 2007 01:25:00 GMT

This can be useful with Windows Home Server in a number of ways.

- If you are building your own WHS in a small case, and don't have a DVD drive, you can transfer the WHS software to a USB flash drive of WHS to install from.

- If you are building your own WHS and require special drivers for your mass storage devices or network connection, you can make a USB flash drive of WHS w/ drivers. You'll especially want this if the primary drive fails, and you want to use the "Server Recovery" option.

- If your PCs that are connected to the WHS require special drivers for your mass storage devices or network connection, you can make a USB flash drive of the recovery CD which includes these drivers.

Here are instructions for making such beasts. Written for WinPE, but applicable to WHS. http://www.realtime-vista.com/general/2007/05/preapring_windows_pe_to_boot_f.htm

My Windows Home Server

MSDNArchive — Thu, 18 Oct 2007 02:34:00 GMT

I built my own Windows Home Server box. You can buy some decent pre-built units, but I wanted to build my own. I wanted a small, quiet, low-power device. I was willing to compromise on performance & capacity to get it. I decided that my collection of movies should live on my media center, just because I wanted to have a small WHS.

Dell D600 laptop

A laptop meets the small & low-power requirements without effort. They also have a built-in keyboard/mouse/display and battery backup, while still being small.

Dell leases these to corporations. After the lease expires, they are sold for cheap. I bought mine at a popular auction site for ~$300. It had a 1.4GHz P4 and 512MB RAM. Most have USB 2.0 (important for adding storage) and GigE (important for pushing a lot of data back and forth). Many have Wi-Fi, which may be useful.

D600 parts are easy to come by, and their online manuals are very good.

Pair of 160GB 2.5" drives

Hard drive prices (per GB) follow a "saddle" curve. At the time of building, 120GB were at the bottom of the curve; 160GB were a bit higher. Above 160GB were much higher. I knew that I wanted space for 100GB today; 160GB would give me a little breathing room. Since replacing drives is expensive (and replacing the primary drive is annoying), breathing room seemed wise.

For the secondary drive, I bought a 2nd HD caddy, which replaces the DVD drive.

Great print server!

It's small enough that it can fit comforably under my printer on my desk. (I was careful to leave a little venting room.) I like simple, obvious names, so my printer path is now \\SERVER\Printer. The USB cable from server to printer only spans ~6 inches.

What if I need more storage?

One of these days I will probably decide that my movies should be moved to the server. I rip my DVDs lossless, and currently have ~400GB, so I'm going to need more room. Upgrading the internal 2.5" drives won't be feasible for a while - they're still too small. Until then, I will need to add external storage.

I can use the pair of USB 2.0 ports. With these, an external enclosure with a pair of large 3.5" drives are a good choice. (Two drives means I can fully use the USB bandwidth without dramatically overloading it.).

Another option is to get a PCMCIA card (there's only one slot) with USB 2.0 or eSATA.

One downside is that the external drives won't be on the battery that's built in. That means I will need a separate UPS if I want them protected.

Windows Home Server on a virtual machine

MSDNArchive — Thu, 18 Oct 2007 02:17:00 GMT

Here at Microsoft, when we talk about Windows Home Server, one of the things that comes up pretty often is a question about hosting WHS in a virtual machine under Virtual Server. Most often people want this because they already have one always-on machine (a doman controller, a media center PC, etc.), and they don't want another.

In discussing the problem, a few key bits of advice have come up, and I thought it would be a good idea to write them down here.

One of the key problems appears when you consider using the WHS to back up the host. It can certainly be done, but when the host goes down, restoring it is a catch 22.

Dedicate whole drives

Take whole drives & put only one file on each - the .VHD. Make it as large as possible.

Use external drives

Make all of WHS's drives external. Consider putting them all in a single enclosure for convenience. eSATA w/ port multipliers may be a good choice.

Have a 2nd physical machine ready

It should already have Virtual Server or Virtual PC installed. A laptop is fine. Make sure it has appropriate ports for the WHS drives.

Recovery strategy

When the regular host goes down:

Unplug the WHS drives
Carry them to the 2nd host, and plug in
Boot the WHS virtual machine. (You may need to create a new VM with the existing .VHD files.)
Restore the primary host
Unplug the WHS drives
Carry them back to the primary host, and plug in
Boot the WHS virtual machine

Screenshot of Select-GraphicalFilteredObject.ps1 in action

MSDNArchive — Wed, 12 Sep 2007 22:53:00 GMT

A picture would be helpful in understanding what this script does.

dir $pshome | Select-GraphicalFilteredObject.ps1 -title "Jay's blog is the best!"

gives this UI:

Powshell GUI for selecting objects in a pipeline ("Select-GraphiphicalFilteredObject.ps1")

MSDNArchive — Wed, 12 Sep 2007 22:39:00 GMT

This is an enhanced version of a script from Lee Holmes' book Windows PowerShell Cookbook (O'Reilly). The original script takes a pipeline & presents a GUI that lets you select which elements to pass on to the next step in the pipeline. That's unchanged, but my enhanced script does a little more:

Added 'All' and 'None' buttons
A little space around the checked list box
Option to set the title to something domain-specific
Turn off CheckOnClick behavior because I think it's annoying but leave it as an option, if you like that sort of thing.

EDIT: Fix the attachment.

Domain-Specific Languages

MSDNArchive — Tue, 19 Jun 2007 19:57:00 GMT

I'm quite attracted by the idea of domain-specific languages, but so far I haven't found a satisfactory way to create them.

For a while I was writing a lot of MSBuild tasks. I found the programming model for a MSBuild tasks to be a bit awkward. You have to write properties where fields should be sufficient. For MSBuild to see a property accessor, it has to be 'public', even though you don't want anyone else to ever use the accessor (not even yourself!).

So, I wrote a tool that generates the boilerplate MSBuild task code. (I also took the opportunity to convert T[] to List<T> in your code, which is usually nicer to code against.) I wrote it as an MSBuild task, which is convenient when it comes time to hook it in to the build system. The input language is MSBuild, which is XML. XML is an awkward language for humans to read & write, though, so it wasn't quite satisfactory.

(Yes, the task is built with itself. Not the latest version, but a last-known-good ("LKG") version.)

I later needed to write a lot of Windows Workflow Activities. When you want to add a property to an activity, you have to write a lot of code. You want to express a simple idea (type, name, and comment:) and you have to write all this:

/// <summary>

/// DependencyProperties allow input parameters to be bound at runtime to any class member property

/// of compatible type in the workflow/activity hierarchy.

/// </summary>

[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA2211:NonConstantFieldsShouldNotBeVisible", Justification = "WF requires this.")]

public static DependencyProperty SkuNameProperty = System.Workflow.ComponentModel.DependencyProperty.Register("SkuName", typeof(string), typeof(ComputeRpsInputsActivity));

/// <summary>

/// Input parameter. The name of the SKU that is being tested. E.g., 'vs_vsts'.

/// </summary>

[Description("The name of the SKU that is being tested. E.g., 'vs_vsts'.")]

[Browsable(true)]

[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]

public string SkuName

{

get

{

return (string)base.GetValue(MyActivity.SkuNameProperty);

}

set

{

base.SetValue(MyActivity.SkuNameProperty, value);

}

So, using my task-generating task, I wrote a new MSBuild task that would generate this sort of property definition code. It went pretty quickly, since I already had the task generator code in hand, and CodeCom still fresh in my mind. It was a big win, cleaning up the activity code dramatically. However, I'm still disappointed by the use of XML as an input language.

In both cases, the work of writing the DSL tool was difficult to justify. In a general-purpose programming language, it makes sense to make a big investment in the tools & design of the language. You want the use of the language to go smoothly, the language should be powerful, and the result should be readable. However, in a DSL, you have to balance those goals against the need to make the DSL cheap. Cost of entry is a big deal in DSLs.

In a couple places (his book, his interview), Bruce Payette talks about using PowerShell to create a DSL. I'm hopeful that this technique can meet the goals above.

What have you used to create DSLs?

PowerShell polyglot

MSDNArchive — Thu, 26 Apr 2007 20:20:00 GMT

Here's an example of a CMD script that is implemented in PowerShell.

@@:: This prolog allows a PowerShell script to be embedded in a .CMD file.

@@:: Any non-PowerShell content must be preceeded by "@@"

@@setlocal

@@set POWERSHELL_BAT_ARGS=%*

@@if defined POWERSHELL_BAT_ARGS set POWERSHELL_BAT_ARGS=%POWERSHELL_BAT_ARGS:"=\"%

@@PowerShell -Command Invoke-Expression $('$args=@(^&{$args} %POWERSHELL_BAT_ARGS%);'+[String]::Join(';',$((Get-Content '%~f0') -notmatch '^^@@'))) & goto :EOF

If you don't need to support quoted arguments, you can even make it a one-liner:

@PowerShell -Command Invoke-Expression $('$args=@(^&{$args} %*);'+[String]::Join(';',(Get-Content '%~f0') -notmatch '^^@PowerShell.*EOF$')) & goto :EOF

Is Virtual Memory dead?

MSDNArchive — Thu, 19 Apr 2007 22:36:00 GMT

To figure out whether virtual memory makes sense, you have to look at the following factors:

RAM size
Disk size
RAM speed
Disk speed

It's the relationship between these values that matter. (All of these are considered in the context of a fifth factor: price. For example, you can usually find a way to buy more RAM, but it may mean replacing the motherboard, switching to a 64-bit OS, etc.)

In the last decade or two, we've seen RAM and disk sizes grow steadily. RAM speed has increased quite a bit, as well, but disk speed has lagged behind. For example, in 1994 I bought a PC for personal use for $3000. Of that, and $1000 was for a 1 GB hard drive (I don't know the speed, let's guess 5400 RPM). I had 16 MB of RAM, and 33 MHz front-side bus.

Today, if I try to spend the same money on a PC, it's pretty hard to do. If I adjust for today's dollars, it's even harder. But we can look at a high-end PC today. Let's say 4 GB RAM, 500 GB hard drive @ 7200 RPM, 800 MHz FSB. This PC will probably cost $800-$1000. So, by comparison:

HD size 500X
RAM size 256X
HD speed 1.3X
RAM speed 24X
Price 0.3X

As you can see, price has dropped dramatically, the HD and RAM sizes have grown at close to the same rate, but their relative speeds have not.

So, I ask, why is virtual memory still ubiquitous? If I have 4 GB of RAM, I probably only need the virtual memory if I'm doing "big" things, like compiling all of Visual Studio or editing video.

Perhaps what's missing here is something in between. Some kind of solid-state storage, faster than hard disk, cheaper than RAM. Making up numbers, give me 24 GB of it today, at 100X the speed of a HD, for $100. Use it for page file, and perhaps HD caching.

A formula for a home platform

MSDNArchive — Wed, 28 Mar 2007 23:16:00 GMT

In Picking a home PC platform I described my requirements for my ideal home PC platform. I've put together a "system formula" - a list of parts to use when building a machine.

The first decision to make is to select a CPU socket. This in turn confines you to a certain set of motherboards, a certain set of CPUs, and a certain type of memory. I ended up going with "Socket AM2".. It supports low-power "Manila" processors starting at 1.6GHz ($40), so the cost of entry is low. The fastest AMD processors are AM2, and even processors for the next socket (AM2+) are back-compatible with AM2 motherboards. It is likely to be viable for quite a while, giving my formula a long lifetime. AM2 sockets take DDR2 RAM.

The next question was motherboard form factor. FlexATX and mini-ITX are interesting, but there are many boards in those sizes. The only mini-ITX AM2 board I found was $300, too expensive for my purposes. There are lots of MicroATX (9.6" x 9.6") boards and cases out there, plus they fit in ATX cases, too.

With that in mind, I went motherboard shopping, and found the ASUS M2NPV-VM ($85). This board has a lot going for it:

GeForce 6150 video
DVI and VGA out, plus TV out on headers
4 memory slots - DDR2 800, 8GB max.
PCI-x16, PCI-x1, and two PCI
2 PATA
4 SATA
onboard RAID
5.1 audio, including digital out
Gigabit ethernet
4 USB jacks + 4 USB headers for the front.
1 1394 jack

Aside: why do they bother with PS2 and LPT ports on the board?

With so much built-in to the motherboard, there's not going to be a lot of deviation in the various roles.

There doesn't seem to be much point in configuring this machine with anything less than 1GB RAM, as buying a pair of 256M sticks doesn't save much money, and buying small RAM is always a waste. However, buying 667MHz RAM is probably find for a low-end machine. $66.

You can use any good quality case that suits your needs. $90 with PSU is normal.

Small hard disks aren't differentiated by price, so there's not much point in getting a tiny one, no matter what the role. A WD Caviar is a good choice for a basic box. 80GB = $45, although going up to 200GB is perfectly reasonable.

DVD writers are so cheap that there's not much point in skipping them, no matter what the role of the machine. (CD writers and DVD readers are no savings). You can even get them SATA today for only a couple bucks more. $35.

That's $360 for a basic machine. (If dollars were really tight, you could squeeze it down to $300, but I don't think it's a good idea.)

This machine would fill any of the roles I listed before, with only the following modifications:

SERVER - a slightly larger case + only 500GB or 750GB drives

GAMING - fast CPU, 800MHz RAM. Optionally a very fast CPU, a WD Raptor (10K RPM) system drive or two Caviars in RAID0, more RAM, and a very fast video card.

I don't know what the minimum requirements are for HD TV and DVD playback, but when the day comes that I care about that, I'm sure this platform will be easily upgradable to support it.

Picking a home PC platform

MSDNArchive — Mon, 12 Mar 2007 20:42:00 GMT

In my home, I a bunch of computers.

ENVY - used by everyone, has the best CPU, RAM, video card, monitor, etc.

WRATH - alternate PC for when ENVY is busy. Usually running Age of Mythology for my 5yo.

PRIDE - sits OFF most of the time, but is available when there are suddenly a lot of people in the house

LUST - a tiny Sony Vaio laptop, usually OFF because it's way too slow running WinXP. Sometimes useful for MS Streets & Trips in the car.

HTPC1 - The media center PC. Primarily for DVD & music playback.

JAYBAZ_HOME - a Microsoft-owned laptop that I use to work from home.

SERVER - A, uhh, server running Windows Home Server Beta 2 (which is, like, totally awesome)

Only two of these PCs are the same model (WRATH and PRIDE). Each of the others is something different. Some can boot from USB, some can't. One is free of PS/2 slots, so I keep a spare USB keyboard in the closet just for that one.

Each one has exactly 1 hard drive in it, except for SERVER, which is filled to the gills. Each has exactly one optical drive - some are CD/R, some are DVD. Each desktop is a full-sized tower, which is way overkill for what I'm doing.

Keeping track of which PC can do what is a hassle. So is making sure they all have the latest BIOS. WRATH has trouble going in to standby on Vista, but the others are fine. Etc.

I'm thinking I'd like to move to a single PC platform (excluding laptops for now) for the whole home, to keep things simpler. I'm thinking:

Small is important to me, and shouldn't be hard:

Only one HD required
No floppy allowed!
Optical drive space is optional, as I have an external DVD RW drive that I can card around if needed.
Card readers are not required, as my Dell 2405FPW has them built-in

Motherboard with the following features:

video at least as good as an nVidia FX5200 (DVD playback)
VGA and DVI out
Gigabit ethernet
Generous USB front and back
1 or 2 expansion slots
able to take both cleap & fast CPUs

I want to be pretty low power, and very, very quiet. (Hey, while I'm at it, can it be cheap, too?)

For most roles that I described above, this PC is fine - add HD, RAM, and CPU and you're done.

For the main PC, I'd add a strong video card, and upgrade the CPU, HD speed, and RAM size. Some motherboards have onboard multi-channel audio, which might be nice. Alternatives include an internal sound card, and external (USB) sound "card", or a USB speaker set (e.g. these). The last one is nice because it leaves me with one less component.

One day I'm sure I'll want to do HD-DVD playback on the media center, at which point I'll upgrade the video, CPU, RAM, and HD on that box as well. But for now, the basic config is fine.

In the server role, I would take advantage of the incredible shrinking HDs (750G units are $300 these days), and either 1-2 USB enclosures, or a 4-drive enclosure if I really wanted a lot of space.

I'm hoping there's a barebones SFF PC that meets these requirements, and has good build quality, works out of the box with Windows XP and Vista, and is generally trouble-free.

The future

We're approaching the end of days for the desktop PC. To be less sensational: the desktop case will continue to be important for both commodity PCs (they're cheap) and high-end PCs (room for high-end components) for a long, long time. However, unless you're playing the latest games (can't wait for HL2:EP2!), or processing lots of video, or something, you don't need the fastest that PCs have to offer.

For many years, the "good enough" PC was $2000 - that was the minimum you'd spend to get a PC worth spending money on. The PC that you really wanted was $5000.

Today, the "good enough" is more like $400-$500, and the PC you really want is $1000-$1500. It's hard to get a PC for more than $2000 without getting exotic.

Meanwhile, laptops have come way down, too. Instead of paying $1000 for a laptop that wasn't quite as good as your desktop, now the difference is only a couple hundred bucks. When you consider the savings in space, power, cooling, clutter, etc., the difference looks even smaller.

With that in mind, I think that I'm about 2-3 years away from a strict laptop-only diet. You might think that the media center PC would need to be a desktop to hold a tuner card (I don't watch TV) or lots of storage (I keep it on the server). You might think the server should be an exception, but remember that laptops come with built-in battery backup, and a compact keyboard/mouse/monitor that is good for a console you rarely touch. (Storage goes can go external, still.). Even the gaming PC could be an exception, but consider the Dell XPS M2010, with a Core Duo CPU, 20" widescreen LCD, a full-sized bluetooth keyboard, dual DVI out, 7.1 audio out, built-in subwoofer + 8 speakers, up to 4GB RAM, dual hard disks. Sure, it's $4000 when decked out, but that's still less than the $5000 "PC you really want" price of the early 90s. And the specs will continue to improve, and prices will continue to drop. In 2-3 years, it won't seem outrageous to get a laptop like that even for gaming, I suspect.

(Also, note that 3.5" hard disks will probably be phased out, even in desktops, in the next couple years. Consider how price, speed, power draw, noise, and heat are playing together here.)

properties vs. fields... again

MSDNArchive — Fri, 09 Feb 2007 00:14:00 GMT

Eric Gunnerson just posted Properties vs public fields redux... It's no secret that I agree with Eric whole-heartedly on this matter. I've posted about this before as well: http://blogs.msdn.com/jaybaz_ms/archive/2004/04/29/123333.aspx. Fundementally, the problem is one of "speculative generality", where you are writing code today that has no use, because you think that it might be needed sometime in the future. Of course, since you can't predict whether it will be used, and you can't predict how it will be used, your guesses are wrong most of the time. That is, most public properties are trivial forever.

It's interesting that the strongest objection some people have is that it requires a rethinking of some of the common naming conventions to adjust appropriately. Such a minor issue, and so easily resolved.

Since my original post, I've come across a couple other reasons why the "always use properties" guidance is broken. Specifically, if you are correct that you may need to maintain binary compatibility while changing implementation, then you'll probably need it in other places:

1. Constructors lock you in to a type. If you really want binary compatibility, you should stop providing ctors, and start providing factory methods:

public class MyClass

{

MyClass() { }

public static MyClass New() { return new MyClass(); }

}

The purpose, of course, is to allow you to return a different object type that derives from MyClass in the future, while maintaining binary compatibility.

2. Types lock you in to a type. If you really, really want binary compatibilty, you should stop providing types at all, and start dealing only with interfaces:

public interface IMyInterface

{

void F();

}

public class MyClass : IMyInterface

{

MyClass() { }

public static class Factory

{

public static IMyInterface New() { return new MyClass(); }

}

void IMyInterface.F()

{

// ...

}

Now, I look at this code, and I think I'm writing a lot of lines for nothing. That is, in my domain, this kind of generality is unnecessary. That's why I don't generally use factories, interfaces, or properties. I consider them to be kin.

There are probably some other constructs that go along with these, for speculative generality. These are just the 2 that come to mind.

If you still believe that you need to use properties in the trivial cases, I hope you will examine these constructs and consider them seriously in your own code. I suspect you should be choosing all or nothing.

Controlling Virtual Server through Microsoft PowerShell

MSDNArchive — Tue, 23 Jan 2007 00:26:00 GMT

In his post by the same name, Ben describe a series of steps required in order to manipulate Virtual Server from PowerShell.

I'm still a PowerShell novice, so I decided to use this problem as an opportunity to see if I could make things a little easier.

The reason it's hard is that you have to make a call to a native Win32 API, which is not accessible from PowerShell directly. Ben's solution includes a peice of C# code that makes this call via interop, and then you have to compile it & load the assembly before you can do any work. In my solution, my script does that work, as well.

Here's the code:

$csc = (join-path ($env:windir) Microsoft.NET\Framework\v2.0.50727\csc.exe) $code = [IO.Path]::GetTempFileName() + ".cs" echo @" using System; using System.Runtime.InteropServices; public class PowershellComSecurity { [DllImport("Ole32.dll", CharSet = CharSet.Auto)] public static extern int CoSetProxyBlanket(IntPtr p0, uint p1, uint p2, uint p3, uint p4, uint p5, IntPtr p6, uint p7); public static int EnableImpersonation(object objDCOM) { return CoSetProxyBlanket(Marshal.GetIDispatchForObject(objDCOM), 10, 0, 0, 0, 3, IntPtr.Zero, 0); } } "@ > $code $assembly = [IO.Path]::GetTempFileName() + ".dll" & $csc /nologo /target:library /out:$assembly $code [System.Reflection.Assembly]::LoadFrom($assembly) > $null function SetSecurity { [PowershellComSecurity]::EnableImpersonation($args[0]) } $vs = new-object -comObject "VirtualServer.Application" SetSecurity($vs) $vm = $vs.FindVirtualMachine("public") SetSecurity($vm) $guest = $vm.GuestOS SetSecurity($guest)
$guest

It could use a little tuning. If I was going to do this a lot, I'd put it all in to a new script.

export environment variables from CMD to PowerShell

MSDNArchive — Thu, 18 Jan 2007 03:52:00 GMT

If you want to use PowerShell, but already have a CMD script that you want to keep, and that CMD script sets environment variables, you're in a pickle. Now I like pickles of all kinds, but Lee can help you get out of this one, with a script that exports the env. vars. back to the PS host.

It's all in his post on entitled Nothing solves everything – PowerShell and other technologies.

random debugger tip: catching COM exceptions

MSDNArchive — Thu, 18 Jan 2007 03:25:00 GMT

I was cleaning out some old mail and came across this tip. You can tell it was a long time ago, because it really only matters if you're writing COM objects, something I haven't done in a long, long time.

Some parts of Visual Studio use COM as a layer to handle cross-thread calls and enable cross-machine remoting. One of the downsides of this technology is that a COM exception in a server is caught by COM and converted to an HRESULT. That HRESULT is harder to notice & catch in a debugger than the original exception.

However, there is a registry key that will change this behavior. When this key is set, the exception is passed through normally, and can be detected & debugged through normal mechanisms.

The key is:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole]
"IgnoreServerExceptions"="Y"

(The real reason I'm blogging this is so that I can find it in the future if I ever write COM again. :-))

Microsoft PowerShell is awesome

MSDNArchive — Sat, 13 Jan 2007 02:20:00 GMT

At work I've been playing with Windows PowerShell. I could try to describe it, but Wikipedia has already done a better job:

Windows PowerShell, previously Microsoft Shell or MSH (codenamed Monad) is an extensible command line interface (CLI) shell and scripting language product developed by Microsoft. The product is based on object-oriented programming and the Microsoft .NET framework.

Windows PowerShell 1.0 is available for download from the Microsoft web site.

It blows my mind how cool it is. Unfortunately it also, uhh, fries my brain because I don't know how to use it. I'm a cmd.exe expert. Seriously, I know way, way too much about writing CMD scripts, to the point where most people can't keep up. I don't want this knowledge, and I see that PowerShell may give me freedom from the burden of the knowledge.

My biggest annoyance is that it's not universally available. I want to be able to sit down at any machine and just start using PowerShell, not having to worry about installing it (and the .Net Framework) first. I want to be able to offer .PS1 scripts for anyone to use, without them having to jump through the same hoops.

Too bad it missed the Vista train. That means it'll be 10 years before it's everywhere. We'll get there.

The next Accidental Difficulty in software

MSDNArchive — Fri, 13 Oct 2006 21:13:00 GMT

First, go read this article by Joel: Book Review: Beyond Java. He mentions this list, of great advances that have address some accidental difficulties in software:

Assemblers
Algebraic languages (including Fortran)
Structured languages (Algol-60 and C)
Declarative languages (including SQL)
Memory-managed languages (including Lisp, VB, and Java)

First, I'm disappointed he didn't list C# next to Java in #5. By no means did Java (or VB) invent automatic memory management (garbage collection). Perhaps you would give those languages credit for bringing managed memory to the masses, but in that case, C# belongs on the list.

I remember a very interesting discussion here a couple years back, about this very topic. Cyrus was saying that at some point we'll expand the domain of the Garbage Collector to non-memory entities, like files, database connections, etc. Sure, figuring out of it's time to dispose of those things is hard, but computers are getting more powerful, and we'll eventually build that in to our programming systems.

So, think of all the times you have written 'using' statments in your code, and consider the possibility of a language that made them unnecessary.

Backing up your data

MSDNArchive — Wed, 04 Oct 2006 21:21:00 GMT

I've been engaged in a bunch of discussion about how to keep your personal data safe at home. I hear a lot of people say they want to build a RAID5 array in a server, and put their family photos on it.

I can think of many ways to lose my data:

Hardware Failure
Fire, earthquake, or other natural event
Power surge
Theft
Confiscation by police
Virus, Trojan, or other malware
Accidentally deleting it

While all of them are potentially real, only #1 & #7 are actually likely to affect my data. In my lifetime, I have lost data to #1 & #7, and never to #2-#6.

RAID5 and the like only protect against #1, and even then a dying controller can nuke your data.

Seriously though, my biggest fear is that *I* will delete my data.

The only way I know to protect against all of them is to have an offsite and offline backup. (Even that may not be enough for #5.)

To that end, I keep an external drive at work, disconnected. I update it periodically. Luckily this is simple enough for anyone to do. (You probably need to be selective about what you back up this way, to keep it all on one drive).

Another strategy that complements this one quite well is to provide mutual data duplication with a friend or relative in another part of the world. The further, the safer. Foldershare makes this doable.

Finding the correct source

MSDNArchive — Mon, 21 Aug 2006 22:57:00 GMT

From a previous comment:

> A copy of the source tree that exactly matches that test VS.

Why IDE unable to keep track versions of sources for me ?
Why not embed meta-information in PDB's on how and there to retrieve correct source file version ?

Actually, it does. In VS2005, the debugger team added two features along these lines. The first is "source file checksums", described here: http://blogs.msdn.com/andypennell/archive/2004/06/29/169002.aspx

The second is Source Server, described here: http://msdn.microsoft.com/msdnmag/issues/06/08/UseTheSource/default.aspx

However, the problem that I'm dealing with is a little more complex (and much less likely to occur in the wild). On my dev machine, I need a copy of Visual Studio and the sources that built it, so that I can modify the sources, build one component, and try it out. If the sources I start from don't match my copy of VS exactly, then I can't know which changes in behavior are due to my changes. Furthermore, if interfaces have changed, then the product is likely to stop working entirely.

Does that explain things?

new job

MSDNArchive — Fri, 12 May 2006 02:01:00 GMT

Quiet here, huh? Been busy, including a 12 week parental leave.

Now that I've been back at work a couple weeks, I can tell you what I've been up to.

I'm no longer on the C# or Debugger teams. I have a new gig.

The neat thing about working on development tools is that we write code for people who write code. It's meta-software-development.

Now I'm doing meta-meta-software-development. The devs that write Visual Studio need tools to make their jobs easier, and that's what I get to do now.

For example, in order to set up a machine to develop VS, you need:

- An instance of VS that is fast (optimized), and stable

- An instance of VS that is current, easy to debug, and probably has a bug that you're about to fix

- A copy of the source tree that exactly matches that test VS.

- A variety of tools, like bug tracking and profiling.

My plan is to make setting up a machine this way foolproof, so the devs don't have to worry about it any more, and focus their attention on making great features.

Good news: I get to write my tools in C#! That means I'll be using what I spent the last few years building.

Transition time

MSDNArchive — Thu, 20 Oct 2005 18:26:00 GMT

We're at the point in the process for VS2005 where there is basically no work left for devs to do. (The product hasn't shipped yet, but devs are not busy.)

Before starting the next product cycle, there are a few things that we're doing differently. One of them is "transition time", a form of slack. The end of a product cycle is always a lot of hard work, with a lot of pressure. We strive for maximum efficiency, and a lot of other important things get pushed off. The slack time is a chance to restore balance.

The first part is 7 days of self-directed time. These are work days, but there is nothing scheduled. Different people are doing different things:

Talking to teams that are exploring long-lead ideas about new technology
experimenting with retrofitting our legacy code for unit tests
cleaning & rearranging their office
building applications with VS2005
reading

I have been reading the new XP book (Extreme Programming Explained: Embrace Change, Second Edition, by Kent Beck). Combined with the first edition, it's very good stuff.

I have moved in to a new, larger office. I'll have to get some pictures to share & gloat.

my side project

I have been working on my side project, which is written in C#. It's not something that would be useful outside of Microsoft, so I won't go in to details about what it does.

I always wrote it in C# 1.0, so I could deploy on the 1.0 CLR. However, I can soon require my users to install the 2.0 CLR without it being draconian. It's really nice to be able to use generics and anonymous methods.

It's a command line app, and I've always struggled with the command line parameter handling. What does a good syntax look like? How should I parse it? I've been rewriting the parser in a more generic way, so it's easy to expand the syntax as the tool grows.

The original implemention has sparse unit test coverage. Of course, retrofitting is hard; your code is no longer well-factored.

However, the new lexer & parser were implemented from scratch, in isolation, and done test-first. I've been using unit testing for TDD, as well as using FIT for acceptance testing. A powerful combination. I just wish I had a pair to make up for all my pesky weaknesses.

The second part is 3 days of comp time (days off), where we get to meet our families, rest, go sailing, etc. Not sure what I'll do with that time... we'll see.

Farewell, C# IDE

MSDNArchive — Tue, 04 Oct 2005 22:50:00 GMT

After a few years working on the C# IDE, I have moved to a new job. I am now the development lead for the Visual Studio Debugger. This was Andy's job before he left to work on Windows Media stuff.

This sounds like a bigger change than it is. I have the same boss (Steve), I'm still in the C# Product Unit (although the debugger is for all languages), and I'm on the same floor of the same building. When Andy left, I took on two of the debugger devs as their acting manager, so even that stays the same.

For those playing along at home, my reports with blogs are: Gregg, Steve, Raj, and Jim.

The C# IDE team is now led by Mike, who previously was a dev on the C# compiler. Congratulations, Mike! I'm confident he will do a great job with that great team.

Are we ready to ship VS?

MSDNArchive — Thu, 18 Aug 2005 03:18:00 GMT

There was an interesting Ladybug issue suggesting that we release a Beta 3 & slip VS 2005.

This is a politically sensitive issue. It has generated some press, so I want to be careful about what I say here.

I'm very glad that Clint took the time to provide us this feedback, and want to say thanks to everyone who commented and/or voted on the issue. This is excellent feedback.

I do want to comment on a few things.

"many issues get resolved as Postponed." That's concerning to me. It's normal for us to ship a product with many known, unfixed issues. This is mostly because our testers do such great work (finding lots of issues that we can ship with, and still have a great product), not because we're shipping too soon (with issues that will cause lots of customer pain). I have a very high standard for the quality of our software, and I hold my team to that standard. I've seen a lot of non-Microsoft software that was surprisingly bad, and which just tells me that we're doing a good job with reliability here.

That said, I know that we have gotten this wrong, too. We have shipped some broken software in the past, so it's possible (likely!) that we would make the mistake to ship something broken again in the future. We need to admit that we can make mistakes, and do the work to make sure we're making the right choices here.

One of the interesting things that I've learned in my Shiproom role is that most of the perception of poor quality is not due to bugs, per se. It's not about whether we introduced a bad bug late in the product & decided not to fix it, or didn't even notice it. It's about design decisions made early on that cause problems we don't fix. You can see that in the discussion of this Ladybug issue. There's a lot of concern about the project-less model for the Web Developer. This isn't a bug, it's a design decision that we made a long time ago.

Well, I think I'm rambling. Thanks for all your passion about the quality of VS, and for putting in the effort to give us your feedback. We love it all.

Presenting at Shiproom

MSDNArchive — Thu, 18 Aug 2005 03:09:00 GMT

Today I got to present a bug in Developer Division shiproom. I haven't gotten to present since Beta 2, as ScottNo has being doing it for C# all this time. He's doing a fine job, but I get a real rush out of it. I like the feeling of having all the answers lined up and presenting well.

It comes from a lot of hard work beforehand, of course. I spend a lot of time studying the bug and asking the developer & tester some hard questions:

If we created this bug, does that mean we made similar mistakes elsewhere?
Are there more bugs waiting here?
If we were confused about this before, why do we think we can get it right this time?
How long has the bug been in the product?
If test didn't find the issue before now, why do we think we can confidently test the fix?
If test didn't find the issue before now, how many other bugs have they not yet found in the area?
If we know there are more issues in the area, will fixing this really improve the customer experience, or will they still think it's junk?

This particular bug had been in the product for 14 months before we found it. It's clear that no one had ever executed this broken line of code - not dev, not test.

One of the hard parts about this decision is that, while the scenario was in the "design time" (it affected debugging), the fix was in a "platform" component (the C# compiler). If we get it wrong, we could potentially break the .Net Redist, every app that you create in C#, cause the CLR to miss its stress-test goals, and cause Whidbey to slip. (I don't think any of this will happen, but it's good reason to choose carefully.)

There were 7 reports of the issue from Beta 2 customers. That was a factor in deciding to take the fix. Thanks for hitting "Send Report" on a hang, folks!