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.

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

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

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.

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:

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

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:

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.

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:

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?

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

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.

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.

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.)

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.

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.

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.