jostein.kjønigsen.net

The Windows Vista licensing: A code perspective

Recently there's been lots of bad noise about how Microsoft has decided to license Windows Vista. Most of the complaints that has been adressed so far has been from a user's point- of view and how the new licensing is unnecessarily restrictive. Considering how most of this is self-evident, I'm not going to dive deeper into that.

Instead, I will be looking at this question from a code-perspective and how this probably will affect the actual codebase of Windows Vista itself and why I think Microsoft has made a really bad decision.

A little about me

I'm a guy whose general philosophy is to use whatever tool does the job best, and I'm not opposed to consider the OS a tool in itself. That is, while I am mainly a (Windows) .NET-developer, I don't exclusively use Windows to cover my needs. There are things which Windows really doesn't do well, if it does it at all. In these cases Linux and various *nix OSes usually triumphs.

There will always be Linux-supporters bashing everything from Microsoft and anyone working with Microsoft products, as well as there will always be people who consider Microsoft-products the only viable option, bashing Linux as an immature platform.

I honestly consider myself rather neutral in this respect, refuse to side with one platform only, so please consider the rest of the article in that fashion. I'm not trying to claim any OS to be superior, just point out why I think Microsoft is making some bad moves when it comes to Windows Vista.

Back to Vista

As you may or may not know, Microsoft is going to licence Windows Vista in quite a few different editions, each with their own set of functionality. On top of that the actual functionality offered will differ based on CPU architecture (32 vs. 64-bit), if the installation has been activated yet, if you are running on so-called "trusted" hardware or if you are running in a virtual environment. That's some of the parameters known today.

Now, from a business point of view, some of these decisions make sense. Selling a home-edition of the Windows OS with a install tailored to suit the needs of most home-users and a business-edition with a install tailored for corporate needs makes sense. It ain't such a bad idea preparing the OS and installing what is most likely needed based on who the buying customer actually is.

However, with Windows Vista Microsoft takes this much further than that. Like Windows XP (and Windows 2000) there will be artificial limitations introduced in various editions, so Microsoft can demand higher license-fees from business-customers needing more advanced functionality. But as already mentioned, these artifical limitations are taken to new heights with Windows Vista.

And no doubt these new restrictions will require code to be implemented.

Looking into the code

To illustrate my point, I will present a scenario, and use C#-like pseudo-code to implement the code that would be required to accomplish the task at hand.

Now, Windows Vista ain't written in C#, the code I write won't be anywhere near the production code. Probably there will be better solutions in some cases, but I don't see any troubles with this approach. This experiment merely intends to highlight the evolution from the "raw" form to the "restricted" form of the code, and the effect of this evolution will be apparant anyway.

The scenario

I have a home-network. One machine is a file-server which stores all my media. Another machine is some sort of desktop or laptop which consumes the media stored on the file-server.

A simple scenario really. For this experiment we will use 32-bit Windows Vista Home-Edition on both machines, stream high-definition content and see how it evolves.

The code run-down

There's a philosophy that goes along these lines: "Keep it simple, stupid" or KISS for short. In that respect implementing the scenario at hand shouldn't be too complicated.

A short (and simple) example of the code used to implement our scenario could look like this:

// code running on the desktop/laptop doing the playback

public void PlayFile(string uncPath)
{
	DirectShowHandler dsh = new DirectShowhandler(this.videoFrame);
	File someFile = File.Open(uncPath);
	dsh.Play(someFile);
}

this.PlayFile (@"\\MachineOnLAN\Share\Some_720p_file.avi");

For the actual video-processing, let's just assume the DirectShowHandler class looks something like this:

// a very simple implemenation of video-playback

public void Play(someFile)
{
	VideoDecoder vd = this.GetDecoder(someFile);

	while (vd.HasMoreFrames)
	{
		this.videoFrame = vd.GetNextFrame();
		System.Threading.Thread.Sleep (vd.FrameInterval);
	}
}

The File-class will most likely use some underlying network code to connect to the other machine, and the other machine will probably have some sort of code handling incoming connections. Pressuming security-related concerns have already been adressed and handled, it might look something like this:

// code running on the file-server

public void GetFile(string filename)
{
	File localFile = File.Open(filename);

	while (! localFile.EOF)
	{
		this.socket.WriteBytes (localFile.ReadBytes (bufferSize));
	}
	localFile.Close();	
}

Let's consider this the "raw" form of the code, and if we had no licence-based restrictions to consider we could use the KISS-approach and leave it like this.

However, due to the artificial limitations added to Windows Vista this code will not be enough. We will have to add excess code to make sure the limitations defined in the license are actually present. That is, we are not keeping things simple.

Network limitations

Windows Vista Home-edition will not allow more than five concurrent incoming network connections to Windows network services. Different editions will no doubt have different limitations. Code will be required to implement these.

I will in the following code assume that connection limit is imposed dynamicly based on edition, and that it will be machine wide, independent of what services are using these connections. We will therefore require some sort of additional network session management.

public void GetFile(string filename)
{
	SysInfo si = Global.SysInfo;
	SessionManager sm = si.SessionManager;

	// check for Windows edition
	if (si.Edition != WindowsEdition.Ultimate)
	{
		int maxConnections = Global.LicenseManager.GetConnections(si.Edition);

		while (sm.Connections >= maxConnections)
		{
			bool success = sm.WaitForAvailableConnections(maxConnections);			}
		}
		if (! success)
		{
			throw new NetworkTimeOutException("No available connections.");
		}
	}

	sm.ReserverConnection();

	// do the actual job
	File localFile = File.Open(filename)

	while (! localFile.EOF)
	{
		this.socket.WriteBytes (localFile.ReadBytes (bufferSize));
	}
	localFile.Close();	

	sm.ReleaseConnection();
}

Wow. That got ugly pretty fast don't you think? So far nothing unmanegable, but the base code has more than trippled in size. Add to this the actual implementation of the different sub-systems, like the Session-manager, the the LicenseManager, and what used to be simple has now grown from a small code-snippet into a full-blown project of significant magnitude.

On top of this, we can also imagine the code required to verify the windows-edition, that the license-code fits the windows-edition, that no files has been tampered with to spoof any of this information, the code required to verify this with Microsoft, including hashes.

Also, Microsoft has in the past changed how restrictions are enforced. I haven't even considered the code required to dynamicly handle different licensing-restrictions and rules on top of this, and what would be required to seperate this from all code present in Windows so that it can be updated without replacing the entire codebase. There's also the issue of adding code to secure this information from being spoofed.

Wow. What used to be four lines of efficient code have by now most likely been increased to tens of thousands. Now imagine a full-fledged OS built on this kind of architecture and design-philosophy. This is not pretty.

None the less: Let's for a second forget what this consumes of system resources and move on.

Trusted hardware

The content-industry has demanded that Microsoft will secure their content from copyright infringement using various techniques generally described as Digital Rights Management or DRM for short. This is basicly encryption with a concealed key.

To avoid any chances of tampering, only trusted hardware will be allowed playback of "protected" content. On top of this only "trusted", digitally signed drivers will be allowed.

Again, this will require additional code. What used to be a simple matter of piping data to the videobuffer has now grown somewhat in complexity.

// a DRMed implemenation of video-playback

public void Play(someFile)
{
	VideoDecoder vd = this.GetDecoder(someFile);

	if (vd.IsProtected)
	{
		DriverCollection dc = Global.Drivers;
		foreach (DriverInfo d in dc)
		{
			if (d.HardwareType = HardwareType.Multimedia)
			if (! (Global.HardwareManager.IsTrusted(d.DeviceInfo) && d.IsSigned)
			{
				throw new DRMexception ("Untrusted hardware");
			}
		}
	}

	while (vd.HasMoreFrames)
	{
		VideoFrame vf;
		if (vd.IsProtected)
		{
			ByteArray encryptedByteStream = vd.GetFrameBytes();
			ByteArray decryptedByteStream = Global.DRM.DecryptStream (encryptedByteStream);
			vf = new VideoFrame (decryptedByteStream);
		}
		else
		{
			vf = vd.GetNextFrame();
		}

		this.videoFrame = vf;
		System.Threading.Thread.Sleep (vd.FrameInterval);
	}
}

We have made what used to be a simple task a lot more complex, dependent on a dozen underlying sub-systems, not to mention reduced performance by introducing encryption.

Restrictions on 32-bit systems

Microsoft has decided that for some reasons 32-bit systems are not "powerful enough" to handle high-definition content. This is odd, seeing as I am fully capable of playing full-resolution 1080i content in my 32-bit edition of Windows XP.

Again, nevermind this. What will happen in the 32-bit editions of Windows Vista is that HD-content will be downsampled to SD-res and there's nothing you can do about it. Again, this restriction will be imposed by the OS itself, at least on "protected" content.

Now how would this affect our code? On top the encryption already in place, we would now need to spend CPU-time to downsample the video. What alghoritm is being used, we don't know. There are a dozen of different ones, and alghoritms that provides good picture quality are generally more complex and computationaly expensive.

You probably want to play your video fullscreen, so this downscaled video will again at some point require to be scaled back up, now only with lower quality. Net effect? Intentionally reduced quality and performance.

Also, let's not forget about the increased code-complexity, shall we?

Activation

Windows Vista will not be activated unless the copy has gone trough a process of ensuring that all these things mentioned so far (and probably more) has not been tampered with. The new Aero-interface will also not be available until after Windows has been activated.

Now, disregarding how this takes eye-candy away from the end-user, this again means adding more code. Either a new layer between the applications and the actual GUI-implementation will have to be added, or intermediate layer already present will have to be at least doubled in both size and complexity.

For any changes done to the GUI code, two seperate, redundant (but different) brances will now have to be maintained. Just because someone thought it was a good idea to take the eye-candy away from the "pirates".

Removal of the volume licences?

It can seem like Microsoft has proposed the removal of volume-license keys and now wants businesses either to manage a large set of license keys themselves, or maybe even running a license-server to make sure they are running legitemate copies.

God knows how much extra complexity this adds to something as basic as having the system running. How about laptops which may not always be connected to the corporate net? There will have to be added even more code to handle scenarioes like this.

All in all

In case you had forgotten, all we were trying to do was to playback one high-definition video file across a network share.

Yes, I know my code is simplified. Yes, I know my "implementations" probably could have been done better. That is however not the point! There are a countless factors that could be illustrated, there are even more examples of how these combined will produce even more code. Do I need to go on?

The net result: Much more complexity than I can possibly present you here. Not to independent components, but to every part of the core OS itself. This system, in case you also forgot, is the opeartion system required to do anything at all on your computer. Any instability here will result in instability in everything you do. Which is why keeping things simple is such a good idea.

Does anyone believe these restrictions will benefit anyone? They don't appeal to the corporate customers. They don't appeal to home-users.

The added complexity will result reduced performance. It will also make the system less maintainable, and more bugs and errors will most certainly be overlooked. Result: a less stable and a less secure system.

So... Who will this actually benefit? Customers? Who will want a operating system whose main feature is preventing you from doing what you intend to do? For each line of code doing something you actually want, there are 1000 lines of code running to make sure you don't do anything Microsoft has deemed unlicensed behavior.

I fail to see how these restrictions that Microsoft intends to add will benefit anyone, Microsoft included.