Now that Vista has been generally released, it's time to put Microsoft's latest operating system into practice from a mainstream software developer's point of view. Never mind the beta releases; this is where the rubber meets the road.
The Software Approaches Tested
- Visual Studio 2005—This is the obvious choice for a Windows programming environment. VS produces .NET solutions that can run on Windows-based PCs.
- Python 2.5—This is a cross-platform interpreted language that is becoming very popular for quick and ad hoc applications.
- Java JDK6 using Eclipse as the IDE and Java using jGRASP as the IDE—Java is also cross-platform, and these two IDEs are accepted development interfaces within most Windows and non-Windows platforms.
- Applications built under Visual Basic 6—I selected this to determine the impact on legacy applications built on the older VB6 platform.
These platforms were installed and run under Vista Business Edition.
I began this evaluation with a fresh start. I built a new, powerful PC and acquired properly licensed copies of Vista, Visual Studio 2005, and Microsoft Office 2007, all duly bought, paid for, and registered. Good thing, too, because my first effort at opening Visual Studio under Vista brought up a message box informing me that I had to upgrade VS before I could use it with Vista. This led to another required intermediate step of installing Microsoft's ActiveX control that checks for legitimately licensed Microsoft products. Having passed that checkpoint, I was allowed to download and install the Visual Studio upgrade.
Although you may still be able to hack your way around the Microsoft validation checker (called Windows Genuine Advantage), a producer of commercial software can't afford to operate that way.
Folder and Registry Access
One application tested tried to create a folder within the "Program files" folder. This has been an accepted practice under Windows XP, and many older applications are going to try to do that, but out of the box, Vista won't allow it.
To deal with this condition, an application that must access protected areas may receive a request for elevation and will then display a message. That is, the user must get the password of a system administrator and key it in, just like it's done under Linux.
In testing, the problem was eventually sidestepped by changing ownership of the parent folders to the user level, but many PC administrators are not going to like that idea. It defeats the purpose of Vista's beefed-up security, you see. Instead, the individual applications will have to be updated to work within Vista's overall folder designation scheme. That is, the applications will have to store their data in a place like "Documents and Settings" or in the "public" folder.
Microsoft's intended solution for the situation uses a "virtual store," which is a redirected storage area away from the forbidden system areas. Unfortunately, this approach didn't work at first either, probably because of the UAC settings at the time the application was installed.
A similar situation exists for the system registry; the regular user is no longer allowed access to some areas like HKEY_LOCAL_MACHINESOFTWARE. This commonly used part of the registry will be redirected to HKEY_CLASSES_ROOTVirtualStoreSOFTWARE by Vista's virtual store feature.
Microsoft intends the virtual store as only a temporary solution, however. In fact, 64-bit applications are already ineligible for virtualization. MSDN says that "virtualization is intended only to assist in application compatibility with existing programs. Applications designed for Windows Vista should not perform writes to sensitive system areas, nor should they rely on virtualization to provide redress for incorrect application behavior." This is Microsoft spin-talk for "you gotta change your programs soon."
To assist in determining whether an application is going to have to be updated for security reasons, Microsoft has provided a tool called the Standard User Analyzer. Microsoft recommends that developers run this tool over older applications, even if the programs run properly under standard user mode on Windows XP, as there may be hidden dependencies.
Other, Smaller Idiosyncrasies
- Printer problems—An application written for the .NET platform received Error 482, suggesting that the system's default printer did not exist, yet other applications found it without a problem. The problem went away on its own after a Windows update, however.
- SendKeys problem—Legacy applications that use the SendKeys operation to simulate users' actual keystrokes will have to find another way. This method has been used to interface with applications that do not have an exposed public interface to one program from within another program.
- Interfacing with a program through the Component Object Model—Although doable, the long-established COM interface currently suffers under Vista when used on such external applications as Microsoft Excel. At present, the COM interface, which marshals resources across process boundaries, runs at a snail's pace on a Vista machine. Hopefully, relief for this problem will come soon because a great many applications rely on COM interfaces.
- Screen problems—Some screen problems occurred in which areas of the display did not paint properly, leaving some parts of the screen obscured.
Things That Worked Well
- Java—Ironically, since Java is not a Microsoft thing, each of the Java applications tested performed very well under Vista. These included Java console applications on the low end and Java AWT/Swing applications on the high end. This suggests that the Java Virtual Machine running within Vista is in good shape.
- Improved appearance—Aside from a couple of minor problems (like flashing squares around message boxes that do not clear properly,) older applications get a facelift from Vista's enhanced user interface. A new look at no charge.
- Mobile computing—Support for mobile computing application development has improved. Gone is the ActiveSync deployment to a PocketPC or Smartphone. Instead, support for mobile device interfacing is built into Vista, and the deployment process is streamlined.
- Microsoft updates—The gang in Redmond has put up $5 to $6 billion to develop Vista. To support that kind of investment, it appears they're working hard to bring necessary updates to the computing world as rapidly as possible. I don't think they all went on vacation just yet.
As a software developer, my greatest fear in moving to Windows Vista is the problems our customers are going to encounter when trying to install our software products. We can fix the things we run into here in the office and provide a workaround for the things that Microsoft will eventually fix...but only if we know about them. In the meantime, we are anticipating an increase in support calls as Vista works its way into business installations and the varied particulars come to surface.
We have to bear in mind that Vista comes in a variety of flavors and deploys differently on machines of differing hardware capabilities. As an ISV, this makes me nervously wonder how many individual cases there might be that must be dealt with.
It's How the Little Things Add Up
Having experimented with various programming paradigms under Vista, it appears that there are no real showstoppers here (nothing came up absolutely broken), but there seems to be a time sink of one sort or another that is attendant with almost every one of them. And often, solving one little problem will lead to the discovery of another and another. All together, solving these little problems can take days.
For example, what is apparently a desktop problem in Vista causes the shortcuts to Microsoft Office to lose their way. Icons are still there, but they're blank and do not launch the applications. An effort to fix this problem by inserting the original CD and repairing the installation then led to the discovery that there is a problem when trying to install Office on a PC that already has Office loaded. More time spent reading and researching.
At this point, the Windows programmer's most effective tools may be sound planning and good old-fashioned patience. Rollout of a critical application may best be served by restricting the application to the less flashy Windows XP platform for a few months until many of the issues that confront Microsoft Vista are resolved.
Preparing your applications for Vista is an ongoing process, I'm afraid, as the twists and turns that Vista represents are traversed and as Microsoft adjusts Vista's behavior in reaction to the cry and hue of programmers and the computing community in general. Stay tuned.