Windows 7 – or is it 6.1?

Posted on By Mark Wilson

There’s a lot of speculation about Windows 7 right now but specifics are a bit thin on the ground. Aside from the Engineering Windows 7 blog (which is information rich but makes some of my blog posts look short), as I said last year, pretty much the best place to watch right now is Paul Thurrott’s Windows 7 FAQ (Michael Pietroforte has an synopsis for IT administrators). Come PDC and WinHEC and the ‘net will be awash with Windows 7 news as that’s when developers and journos will finally get their grubby mits on a pre-release version of Microsoft’s latest operating system.

There has been some official news this week though. Yesterday, Mike Nash, Corporate Vice President for Windows Product Management at Microsoft, announced on the Windows Vista blog that the Windows 7 codename will not just be the codename but will also be the actual name for the next version of Windows (I understand that relates to the Windows client operating system and that Windows Server 2008 R2 will be the name for the server release):

“Over the years, we have taken different approaches to naming Windows. We’ve used version numbers like Windows 3.11, or dates like Windows 98, or ‘aspirational’ monikers like Windows XP or Windows Vista.”

OK, I get it. And Windows 7.0 would make sense for a major update (as Mike explained today in a follow-up post, but I’ll provide a few more details here):

  • Windows 1.0 and 2.0 (Windows 286) existed as products but were not widely adopted.
  • Windows 3.0, 3.1 (codename Janus), Windows for Workgroups 3.1 (codename Kato) and 3.11 (codename Snowball) were the first widely adopted versions.
  • At that time the OS forked and Windows NT (New Technology) was born at v3.1, then 3.5 (codename Daytona), 3.51 (all minor release updates).
  • The original Windows (not NT) 4.0 (codename Chicago/Detroit/Knoxville/Nashville) was called Windows 95 (and there were several variations of this operating system).
  • Windows NT 4.0 (codename Cairo) was the first major update for Windows NT.
  • Windows 98 (codename Memphis) and ME (Millennium Edition) were minor updates from Windows 95 (still 4.x) and then someone saw sense and closed down that product line, merging the codebase back into NT.
  • Windows NT 5.0 was marketed as Windows 2000 (a major update).
  • Windows NT 5.1 (codename Whistler) was marketed as Windows XP (a minor update).
  • Windows NT 5.2 was marketed as Windows Server 2003 (codename Whistler Server) and Windows Server 2003 R2.
  • Windows NT 6.0 (a major release) was marketed as Windows Vista (codename Longhorn) and Windows Server 2008 (codename Longhorn Server).

(See Bitzenbytes for more details of Windows development that I chose to skip over here.)

So far, this all makes sense (at least to me)… but then Mike Nash announced that:

“We decided to ship the Windows 7 code as Windows 6.1 – which is what you will see in the actual version of the product in cmd.exe or computer properties.”

So, Windows 7 (codename Blackcomb/Vienna/7) will not be v7.0 (indicating a major release) but will actually be 6.1 (i.e. a minor release). Based on recent history that really ought to fit with a Windows Vista R2 (marketing disaster waiting to happen), Windows Server 2008 R2 or Windows 2010 name. Nash continues by highlighting that:

“Windows 7 is a significant and evolutionary advancement of the client operating system. It is in every way a major effort in design, engineering and innovation. The only thing to read into the code versioning is that we are absolutely committed to making sure application compatibility is optimized for our customers.”

So, Windows 7 will be more like the move from Windows 2000 to Windows XP/2003, a significant step forward but still not a major update (unlike NT 4.0 to Windows 2000, or XP/2003 to Vista/2008). That’s good – especially for corporate IT departments struggling with Vista application compatibility (mostly through their own lack of foresight it should be noted). I understand why it’s numbered 6.1 internally but why confuse the issue by calling it 7 for marketing purposes?

I have a feeling that Windows 7 will not, despite yesterday’s announcement, be the final product name.

Microsoft Virtualization: part 5 (presentation virtualisation)

Posted on By Mark Wilson

Continuing the series of posts on Microsoft Virtualization technologies, I’ll move onto what Microsoft refers to as presentation virtualisation (and everyone else calls terminal services, or server based computing).

Like host virtualisation, Terminal Services is not a new technology and Microsoft has provided basic Terminal Server capabilities within Windows Server for many years, with Citrix providing the enterprise functionality for those who need it. With Windows Server 2008, Microsoft has taken a step forward, introducing new Terminal Services functionality – with new features including:

  • Terminal Services Web Access – providing a web portal for access to RemoteApps – applications which run on the terminal server but have the look and feel of a local application (albeit subject to the limitations of the RDP connection – this is probably not the best way to deploy graphics-intensive applications). Whilst this is a great feature, it is somewhat let down by the fact that the Web Access portal is not customisable and that all users see all RemoteApps (although permissions are applied to control the execution of RemoteApps). For web access to RemoteApps, v6.1 of the Remote Desktop Connection (RDP) client is required but for v6.0 clients an MSI may be created using RemoteApp Manager (which may be deployed using Active Directory group policy).
  • Terminal Services Gateway – provides a seamless connection to Terminal Services (over HTTPS) without need for a VPN. It’s not intended to replace the need for a firewall (e.g. ISA Server) but it does mean that only one port needs to be opened (443) and may be an appropriate solution when a local copy of the data is not required or when bandwidth/application characteristics make the VPN experience poor.
  • Terminal Services Session Broker – a new role to provide load balancing and which enables a user to reconnect to an existing session in a load-balanced terminal server farm.

There are improvements on the client end too – for details of the client enhancements in Remote Desktop Connection (v6.1), provided with Windows XP SP3, Vista SP1 and Server 2008 see Microsoft knowledge base article 951616.

One of the more signicificant improvements in RDP 6.1 (but which requires Windows Server 2008 Terminal Services Printing) is Terminal Services EasyPrint. Whereas printing is traditionally problematic in a server-based computing environment (matching drivers, etc.) – Terminal Services EasyPrint presents a local print dialog and prints to the local printer – no print drivers are required on the server and there is complete transparency if a 32-bit client is used with a 64-bit server. If the application understands XPS (i.e. it uses the Windows Presentation Framework) then it prints XPS using the EasyPrint XPS Driver (which creates an XPS spool file). Otherwise there is a GDI to XPS conversion module (e.g. for Win32 applications). On the client side, the spool file is received over RDP using the Remote Desktop Connection with an EasyPrint plugin to spool the XPS through an XPS printer driver (converted by print processor if required). If the print device does not support XPS, the print job is converted to EMF by the Microsoft.NET Framework and printed using a GDI printer driver.

Terminal Services EasyPrint

Whilst Microsoft’s presentation virtualisation offerings may not be as fully-featured as those from other vendors, most notably Citrix, they are included within the Windows Server 2008 operating system and offer a lot of additional functionality when compared with previous Windows Server releases.

In the next post in this series, I’ll look at how the four strands of Microsoft Virtualization (host/server, desktop, application and presentation) are encapsulated within an overall management framework using System Center products.