A couple of months ago I broke down and decided I need to get familiar with Windows Vista and so I installed it on my main development machine, which is my laptop. It’s a fairly recent Dell dual-core machine that has plenty of horsepower, memory, and disk to run Windows Vista Beta 2.
When it comes to software and hardware installations, I tend to be the “Murphy’s Law case” where if anything can go wrong, it will. To my surprise, however, my stint with Windows Vista has turned out surprisingly well.
My primary reason for installing the Windows Vista Beta was to check out some of the new developer features and technological pieces that primarily live under the new OS. My main interest-being a Web developer for the most part-has been in IIS 7.0 and making sure I get an early handle on configuration and upgrading existing applications to run on IIS 7.0, as well as experimenting with the many new features that IIS 7.0 opens up for .NET code. And while I’m at it, using Internet Explorer 7 is also vital to figure out what’s changed between the release of IE 6 over five years ago and IE 7. But even beyond that, I’ve wanted to take a look at a few next generation features including the .NET Framework 3.0 (formerly WinFX) which I’ve been putting off for quite some time.
So this month I’ll share some of my experiences and thoughts related to installing and developing applications for Windows Vista.
Installation
Installation went very smooth, albeit very slow. Surprisingly, Windows Vista picked up most of my devices without a hitch. The exception was my video card (which is weird because there’s a driver for it), and my sound card which is a one-off Dell Sigmatel card that never wants to install anywhere. The video driver gave me some problems causing odd behavior, until I explicitly downloaded a new driver from NVidia. Still, that’s pretty good given that I had almost as much trouble installing Windows XP on the same machine.
Almost everything I’ve thrown at Windows Vista works well. All of my core applications that I use on a daily basis run, although a few give me a warning saying they are not compatible. Among the notable ones are QuickBooks and Virtual PC, but both seem to work without any problems.
More importantly, Visual Studio (both VS 2005 and VS 2003) run great on Windows Vista as do my Visual FoxPro installations. None of these environments seem to have any problems although Visual FoxPro has some window drawing slowness when dragging MDI windows around the IDE. All of my custom Windows Forms and FoxPro desktop applications and all ASP.NET applications run without problems, although IIS configuration required a few tweaks to get it going. Later I’ll discuss IIS in more depth.
Overall I am pleasantly surprised how smoothly things went. It is now two months later and I have yet to crash Windows Vista. The only application that seems to crash frequently is Office 2007 Beta, but beyond that I haven’t seen any application crashes other than self-inflicted ones during debugging. Performance is also on par with Windows XP-Windows Vista certainly feels no slower for everyday development and business application work. (I can’t speak for the gamers out there though.)
Aero UI
One of the big selling features of Windows Vista is the new UI called Aero, which is a DirectX-driven user interface. Rather than relying on GDI+ to draw the user interface, Aero uses new APIs to directly render output to the video card, which supposedly results in better graphics performance for every day operations, and offloads some graphics-intensive processing to the video card rather than the CPU. Aero is a high-end feature and requires a recent video card with at least 64 MB of video memory. If your machine doesn’t have an appropriate card, Windows Vista uses a classic view that foregoes some of the advanced features.
Aero looks nice but I don’t think it’s anything to get too excited about. I think the key feature is the glass effect for windows that provides a transparent frame for windows so you can see the background of the window underneath. Windows also have a drop shadow behind them so it’s a little easier to see where a window lives in the 3-D space. Windows Vista also features smooth animation effects to open and close windows which are nice. Another useful feature is the ability to see all minimized applications as a small preview window when your mouse hovers over them. Beyond that-ho hum.
I will say that all applications except Office 2007 look really ugly under Windows Vista. The Windows Vista color schemes are all washed out white and there’s no contrast for forms. So menus and menu backgrounds are white-on-off-white with black text on top of it. It’s usable but it’s not exactly pretty to look at. This looks similar to running the grey theme in Windows XP which is also very bland. Aero doesn’t support any real theming as XP did-applying theme colors merely changes the color of the window transparency. It looks pleasing but it has no effect on the client area of the window.
For existing applications this means that they all have that same washed out white-on-white look. If you’ve build .NET 2.0 Windows Forms applications and you’ve used the Office 2003 renderer for menus and toolbars that were themed before, you now just get the default grey-on-white theme which is, well, boring by comparison. Most third-party components that provide toolbar rendering typically base their default colors off the theme and they have the same effect. Bland. Hopefully this will still change with theme colors providing better hints for toolbar renderers, but it looks to me that theming at the OS level is a thing of the past.
I haven’t seen any definite recommendations, but it does seem like Microsoft expects developers to use their own color schemes, thereby moving back to fixed schemes. Certainly Office 2007 is going that route because it always uses a fixed color scheme regardless of which theme is active. Office 2007 provides two schemes: A dark grey professional scheme and a bright blue Windows XP-like scheme. Other built-in Windows applications also seem to use this hard-coded color scheme approach. Take Windows Live Messenger, for example, which has a completely owner-drawn user interface. Many of the other built-in Windows applications, like Mail, Contacts etc., stick with standard Windows Forms user interfaces but add hard-coded colors. It sure looks like the days of unified user interfaces are numbered and we’re heading into a direction where UI chaos returns.
The color scheme issues are even worse if you don’t use Aero or if your hardware doesn’t support it. Aero has pretty stringent video and hardware performance requirements, and won’t run on machines that don’t have reasonably recent video hardware. If you don’t use Aero the UI is back to using GDI+ for drawing and you get a more standard interface without all the bells and whistles. This UI is really ugly at least in Beta 2. Microsoft says it will adjust the base color schemes and it sounds like the non-Aero interface will get an airy, light blue look, which will certainly be an improvement over the current drab gray look.
Security
Beyond the user interface, the most striking thing about Windows Vista is probably security and how incredibly annoying it is in its default configuration. By default, a Windows Vista User is not an Admin user and it’s actually somewhat tricky to even set up a user to be an Administrator. Running as an Administrator, even on a development box, is supposed to be a bad practice and I agree. However, in Windows Vista I consider running under limited rights just about impossible without going crazy.
With limited (default) rights set, most Windows applications pop open a security dialog box for User Access Control. It asks whether you want to allow this program to run and you click Yes to run it. Now this doesn’t sound so bad until you click the Yes button the 50th time in ten minutes.
The idea of this security mechanism sounds noble-it prevents malicious code from executing on your machine even if your machine is infected since the operating user has practically no rights for anything. Unfortunately, “no rights for anything” is pretty close to accurate, so that you find yourself clicking away at dialogs all the time, blindly most of the time because you are fuming. Worse, there’s no way to set up a profile where Windows remembers that you’ve previously allowed this application to run so it happily prompts you again the next time you run the app.
It took me about one hour before I decided there’s no way I can sit through this pain. So I added myself to the Administrator group, but to my surprise this didn’t really change anything. An administrator is not really an Administrator (Fake Out!) until you change the user security policy on the machine to make and Admin user a real Admin user. You gotta be kidding me! Even with these settings made I still do not have full access to my system and I’m locked out of various folders like other user profiles and some folders below the System directory. Microsoft apparently knows better than to trust me with my own system.
Security must be dealt with at the point of entry. That’s where the effort should go to make it much harder to install anything suspicious on your machine and I’m all for big fat prompts there. Modern software, and the OS for that matter, should be able to sniff out what resources an application requires and tell you up front what’s required and allow you to check off on that. If it goes beyond that then pop up a security dialog box because then at least you’ve explicitly allowed the limits to be overstepped.
IIS 7.0
Since I spend most of my time doing Web development, IIS 7.0 is a big part of what I interact with on a day-to-day basis. Ever since I saw early previews of the new IIS 7.0 feature set, I’ve been excited about the new integrated pipeline that brings the .NET Framework into IIS as a full citizen. With IIS 7.0 you can now write IIS system-wide code that can interact with every request against the server.
One important aspect of IIS 7.0 is that it will ship on both Windows Vista and Longhorn Server, so unlike the current situation where you have IIS 6 on Windows 2003 and IIS 5.1 on Windows XP, on Windows Vista and Longhorn Server you can have a much closer development environment with Windows Vista to match your server environment. IIS 7.0 builds on the IIS 6 model so the basic server components like application pools and the isolated worker processes are still the same. IIS 7.0 is also a better match with an IIS 6 server than XP’s IIS 5.1.
But IIS 7.0 is also a big change from IIS 6. Given that the move from IIS 5 to IIS 6 was a pretty big change (moving from COM hosting to application pools, process isolation, security lock downs, etc.) the move from IIS 6 to 7.0 is even more drastic. The componentization of IIS 7.0, which breaks out most of the server’s core functionality into pluggable modules, also makes IIS 7.0 more difficult to administer as there are many more options to set. IIS 7.0’s admin interface also shows both IIS and ASP.NET settings in one place. In fact, ASP.NET is, in effect, becoming part of the core Web server. The new Admin Console looks much nicer but it’s still very difficult to find what you’re looking for. Microsoft renamed and moved many common settings to new group associations, so finding some settings is going to be frustrating at first.
IIS 7.0 blurs the lines between ASP.NET and IIS to the point where ASP.NET is much more integrated and really considered an IIS core component. Some of the core modules (like the Forms Authentication Module, for example) for the server are actually managed modules so ASP.NET settings apply to the Web server in many situations where you might not expect them.
But the advantage of this additional “clutter” is that it’s much more flexible to configure IIS 7.0. Most of the settings that are specific for Web Application/Virtual are now stored in a web.config file rather than the binary metabase file of previous versions, which makes most settings portable with your application. Some settings like the name of the virtual directory and the pipeline type and authentication are still global, but you can locally set the immediate configuration settings that apply to a virtual directory. This makes it much easier to move an application to a new machine, for example, as most of the settings are stored with the application as just another file.
IIS 7.0 also lifts the hard connection limit against the Web server so that you can have more than ten connections, although according to Microsoft there’s an internal governor that queues additional requests. I’ve had lots of problems on Windows XP with some applications-especially AJAX debugging sessions-overloading the ten-connection limit. On XP, the overload results in a refused connection-IIS 7.0 queues the request and processes it once the queue gets to it. You won’t be able to use IIS 7.0 for stress testing but otherwise you should be able to have a consistent environment that mirrors a live Web server running Longhorn server in the future.
The first thing I did with IIS 7.0 was to try to get my existing applications to run on it, and it took a bit of twiddling to figure out exactly how to do that. One helpful thing to do is to install the IIS 6 metabase support so that you can configure IIS using the ADSI configuration services. You can only use the ADSI-based interface in compatibility mode, but it’s vital if you have any applications-such as Visual Studio or any third-party Web application with installers-that need to configure IIS.
When you set up applications/virtuals-especially for ASP.NET applications-it also helps to set them up in ISAPI compatibility mode which runs a virtual directory, like IIS 6 does, in an application pool that runs stock ISAPI extensions. This allows you to use Visual Studio like you normally would for debugging and doesn’t require any changes to the application or configuration in any way. The new default pipeline mode is an integrated mode that allows both managed and native components as part of the pipeline. In this environment, HttpModules and HttpHandlers run as part of the IIS pipeline and can participate in the core Web server processing even against non-ASP.NET requests. In order to run in integrated mode you need to make a few changes to the web.config file to move HttpModules and Handlers to the new <system.webServer> section where IIS stores system settings. IIS will automatically write any local settings to your web.config file in this section. One thing to keep in mind is that Visual Studio 2005 current doesn’t support debugging IIS 7 integrated pipeline applications by pressing F5 to start debugging. Instead, you have to manually attach to the IIS worker process (w3wp.exe), after which you get full debugging functionality.
I’ve spent a bit of time building a handful of custom global IIS modules and the process is straightforward and satisfying. Existing modules and handlers just work without changes as part of the core server pipeline. I have a few customer applications that can immediately benefit from these global features in ways that I would have never even bothered with using an ISAPI filter because of the C++ and low-level code requirements. With .NET code these tasks are almost trivial.
Internet Explorer 7
Windows Vista will ship with a new version of Internet Explorer after five years of neglect. The new version is a welcome enhancement but also a big disappointment in many ways. The browser includes many new user interface features. Of course, IE 7’s tabbed browsing is the most visible and probably most useful new feature, but that’s really old hat if you’ve used any other browser recently.
More important though, Internet Explorer 7 addresses some HTML/CSS compatibility problems and Microsoft finally brings IE up to a reasonable level of compliance with Web standards. But it’s still not enough and CSS 2.0 compliance is still way below par compared to other browsers. IE still has many holes and inconsistencies and some inconceivable omissions. I continue to have countless issues with IE’s container rendering which works just fine with FireFox or Opera. It’s also amazing to me that some core CSS properties like opacity simply aren’t implemented. How hard could it have been to map the CSS property to the filter property IE requires internally?
It seems like Microsoft put exactly as much effort into IE as they thought they had to in order to quell the hardest criticism against IE, and not an ounce more. If this attitude is indeed the case it seems hard to understand, since Microsoft has a renewed focus on Web technologies with the Live initiative and all the hoopla surrounding ASP.NET “Atlas.”
Everybody suffers when vendors create browser incompatibilities and IE will only make issues more complicated because there’s now another browser to check for. Though IE 7 is more compliant, you but can’t treat IE 7 like you would most other CSS-compliant browsers.
IE 7 on Windows Vista Beta 2 is still pretty buggy and incorrectly renders many complex pages altogether. I also notice major problems with pages that redirect to https pages. I think online banking may be impossible with the beta version of IE 7. I’m sure Microsoft will fix these issues before they release IE 7, but I don’t have high hopes for some of the various engine CSS issues that are more of a core interpretation problem.
.NET Framework 3.0
Windows Vista is the catalyst for shipping the .NET 3.0 Framework (formerly WinFX). The framework consists of a number of high-level framework components that provide .NET with a ton of system-level functionality that is better integrated than in current versions of Windows. Although .NET 3.0 is tightly tied to the Windows Vista release cycle, the components that make up .NET 3.0 also run on Windows XP.
I think Microsoft’s decision to name .NET 3.0 what they did is odd in that .NET 3.0 is really the .NET Framework 2.0 plus the WinFX components-the actual CLR version remains at version 2.0, so existing 2.0 applications will continue to run just fine. I am not yet clear whether Microsoft will ship .NET 3.0 as a single install that installs both the 2.0 Framework and the WinFX components or whether they will install separately. Windows Vista and future versions of Windows will, of course, ship with the framework installed, but for Windows XP and Server 2003 you’ll have to install these components separately (hopefully they’ll install with Windows Update).
Windows Communications Framework (WCF)
Out of all the technology that’s coming out with the .NET Framework 3.0, I think that WCF is the most important. Most developers will work with this technology sooner rather than later. WCF is decidedly unsexy in that it’s basically system-level plumbing. It’s technology that has matured by way of a massive refactoring, which has resulted in consolidation and integration of a number of scattered communications technologies into a consistent API. WCF provides a consistent and somewhat interchangeable model for communication between applications and services both locally and on remote servers.
WCF brings together many disparate technologies from current versions of Windows including Web services, DCOM, Message Queuing (MSMQ), COM+ Enterprise Services, and peer-to-peer services, and combines them into a single framework that has consistent semantics for communications. This is especially true if you’re a .NET developer and the scattering of current technology in many cases relies heavily on COM to provide the infrastructure. WCF brings many of these technologies together with native .NET interfaces and provides much-needed consistency when calling these interfaces and in many cases providing interchangeable protocols. For example, you can use a service client to fire off a message to a Web service and with a configuration change allow your application to send that same message to a Message Queue server without actually using different APIs. The abstraction of the underlying messaging mechanisms with a top-level framework like WCF is a welcome addition to Windows. In this day and age when more and more applications need to communicate with each other, simplifying the communication services is key.
I personally see that WCF Web service implementations are much more flexible in separating contract from implementation, and the framework will provide much better low-level support for managing the underlying system messages. In .NET 2.0 and prior it’s been rather difficult to manually deal with SOAP messages or parse raw XML data. All of that changes in WCF, which brings many low-level interfaces into your developer toolkit that makes real-world service applications easier to work with.
From the handful of things I have tried with WCF so far I have to say that I’m impressed with this implementation that provides the right mixture of ease-of-use and low-level access. WCF provides a variety of configuration points, most of which are optional. This makes it easy to hit the most common scenarios with relatively little code and then gives you the ability to dig deeper as needed. While the base implementations and separation of contract and implementation requires a little more discipline and code to start with, it also helps in visualizing service-based applications more clearly before coding begins.
I will certainly integrate WCF into applications as soon as it ships to production.
Windows Presentation Framework (WPF)
WPF was going to be the most visible component of WinFX since it presents the new user interface paradigm for Windows. WPF provides some amazing features that developers can implement with relative ease, opening the door to build truly interactive and visually sophisticated applications in ways that is very difficult to do with current Windows applications. WPF provides XAML to separate the user interface from the application logic. XAML is a markup language that defines the user interface layout and behavior and allows declarative, Web-like semantics to describe the user interface and hook logic up to it, but without the limitations of a stateless Web environment.
WPF was going to be one of the cornerstones of Windows Vista, but lately Microsoft has downplayed WPF. If you look at the developer tools Microsoft has put out to date to harness the power of WPF, I think you’ll be disappointed. In its current state [neither the platform nor the products have been released and are only available as CTPs - ed.], WPF has a ways to go as a platform for line-of-business applications. Currently, Microsoft does not ship a lot of standard form-based controls or support for common line-of-business scenarios in general. In its current state, WPF lacks many common controls like TreeView, and DataGrid, and WPF’s data binding semantics are fairly limited. The idea is that you can build controls like this on your own using the lower-level block components that WPF provides, but from what I’ve seen it’s not a trivial exercise. If you’re building business applications you certainly don’t want to re-invent the wheel and build your own basic controls. It’s clear to me that Microsoft is not ready to target developers of standard business applications in this first release for WPF. Rather, I think the focus of this platform seems to be consumer applications that want to build rich, custom user interfaces. It’ll be interesting to see if third-party vendors step in here to fill this void to provide a more mainstream target.
As I look at Windows Vista’s built-in applications, most of the internal applications don’t use WPF yet [since WPF wasn’t yet ready when other parts of the Vista Team started building their apps months ago. - ed.]. The majority of Windows uses standard Windows API-style user interfaces. To me this means that Windows Forms will continue to be the main platform for desktop application development for some time to come. I think this is ironic as I remember the hype from a few years ago when I heard that Microsoft was going to stop enhancing the Windows Forms platform and focus on the feature set of WPF.
Unfortunately, this also means that developers are stuck in the middle of two diverging technologies. Windows Forms is stuck on version 2.0 of the framework with user interface themes and focus on Windows XP. As I mentioned earlier, theme support from older applications provides a rather bland UI experience on Windows Vista.
For me, all of this means that WPF is a technology I can hold off on. I’ll wait until it gels and Microsoft or some of their partners figure out how to make this technology fly in a more mainstream environment.
Gadgets
Microsoft has gone out of their way to promote the not-so-new concept of gadgets both on the Windows platform for the Windows SideBar as well as for Live.com. The idea is to create byte-sized, generic content and display it in your environment. Windows gadgets look like Mac widgets or Yahoo widgets and even the syntax is similar.
I suppose the idea is not a bad one. In fact, I’ve needed to build a component that pulls data off the Web on timed intervals and display it actively on the desktop, so I thought I’d give the Gadget APIs a spin.
It turns out it’s very easy and requires nothing more than a text editor to create an XML manifest file and an HTML document with the content. A gadget is really a small HTML component that runs in the confines of a mini, borderless Internet Explorer that can float on the sidebar or be disconnected and float on the desktop. The HTML file can contain script that either runs standard HTML DOM-style JavaScript or it can access some of the system components that are part of the Gadget API. These components include functionality from checking system power status and your CPU load to playing sounds and loading images. There’s a fair amount of functionality there, but it’s far from enough of what you likely will want to do-it’s a far cry from a desktop development environment.
Creating a gadget that displays content or even lets you write a note onto the desktop is actually childishly easy. However, to do anything a little more useful you can get hamstrung pretty quickly by the dearth of functionality available and more importantly, the security limitations. Specifically, I need some way to call out to a Web site and download data. I thought I’d use the XmlHttp object with JavaScript to do this with a few lines of code, but alas I got stopped short by security restrictions. Since gadgets are essentially minimal instances of Internet Explorer you’re limited by that security environment. Windows Vista’s security model for IE is the local machine environment which is the most restrictive way to run IE. So, even by explicitly enabling cross-domain calls in the browser (which technically isn’t the problem) I still could not call out to get my data.
It also doesn’t look like there’s an API to retrieve remote data-at least not one that’s documented. Obviously there’s got to be one since the default Feed Watcher Gadget is reading RSS feeds in semi-real time, but I couldn’t figure out a way to make this happen in the restrictive IE HTML environment.
Based on this experience, I think this set of tools has a serious identity crisis. It seems these controls are stuck between the desktop and the Web and are not providing the functionality of either. I like the idea that I can quickly generate something that tacks to the desktop, but with the security of IE, gadgets are hamstrung. You have to write JavaScript code to handle desktop programming-talk about the worst of all worlds given that there’s no development support for JavaScript to date.
Yet with all of the security limitations there seems to be access to some of the system components that allow access to local files, which seems really scary. Here’s another set of components that a user installs on their local machine that uses Internet Explorer for dynamic scripting on the client side. Am I the only one who thinks this is a crazy idea in terms of security?
I suppose it’s still early to look at this technology. There’s very little documentation and no samples of anything much more concrete than a useless Hello World component. For this technology to work and take off it needs good developer support and more importantly, it needs access to common functionality which currently looks very limited (or at least not documented).
Other Stuff
There’s certainly a lot more in Windows Vista that I would love to check out and play with, but the reality is there’s just not enough time to get to it all. Windows Vista and the wave of tools and technologies that comes with it will bring a massive load of new stuff that I know I won’t be able to absorb all at once.
While I’ve made a case here for explicitly going out and looking at new technology, it’s important to not lose focus so you can understand what’s important and what’s not. Most of the technology that Windows Vista will offer is not crucial or really changes things so drastically that it makes anything else obsolete. I’m thankful for that. Over time most of this technology will work its way into the mainstream. In the case of WCF, especially, I think this will happen a lot sooner than for other technologies like WPF. We’ll see. I’m curious to see what lies ahead.
