Virtualization is a concept greatly expanded in Vista. This article discusses the impact of Application Virtualization on you development. It can have a huge impact on how the programs you write will behave when installed on Vista.
No, the title is not a value judgment about Windows Virtualization itself. Love it, hate it it doesnt matter. My point of view (for this article anyway) is that Windows virtualization is here, and we developers have to learn how to take advantage of it.
"Windows Virtualization" is the act of isolating or unbinding one computing resource from another. Windows virtualization added virtualization services to the core Windows operating system at a fundamental level starting with Vista. Here are the categories of Windows Virtualization:
Application Virtualization
Desktop Virtualization
Server Virtualization
Storage Virtualization
Network Virtualization
This article dives into some of the pitfalls of Application Virtualization as implemented in Windows Vista. Application Virtualization is a new term that extends Microsofts push toward truly distinct user accounts on a single machine. It creates application-specific copies of all shared resources. It separates the application configuration layer from the OS making deployment easier in some cases. Not a bad idea on its face.
The New Learning Curve
Much has changed in Vista, and the leap is much greater than the switch from, say, Windows 98 to Windows XP. From a developers point of view, XP was little more than a new face on the long familiar Microsoft NT operating system. It incorporated many of the user interface enhancements we found in Win98, improved upon them, introduced a few new concepts and, for a developer already familiar with NT v4, not much else was new. Pretty much business as usual; at least thats how it feels in retrospect.
The leap from XP to Vista is much higher. It will take many, many articles to cover all the new facets. In this article, we merely focus on one aspect new to Vista, virtualization, and we deliberately touch on it lightly. The reason for the light touch is covered later in this article.
Introducing Vista Virtualization
Virtualization is a little hard to describe without some context. Its easier to understand it if we consider some real-life application scenarios.
Lets say that youve been using MyCheckRight, a fictitious program for managing your finances, reconciling your checkbook, etc. MyCheckRight, of course, needs some kind of database in which to record your transactions and related activities.
Under XP, you could have your machine set up with two user accounts; one for you, one for your spouse. When either of you ran MyCheckRight, youd be interacting with the same database. That is, entries made by either of you, would be visible to the other. Thats obviously a nice state of affairs for an application designed to manage family finances.
Under Vista, things change! Unless the authors of MyCheckWrite issue a Vista update, things could get messy and quickly.
Lets start with a fresh, per-machine installation of MyCheckWrite, and lets say the man of the house, Bob, is the first to use it. When Bob fires up the program, hes able to make entries, just as he did under XP.
Next, Bobs wife, Sue, logs into Vista under her machine account, fires up MyCheckWrite, and begins to work. Initially, she can see Bobs most recent entries. So she goes to work, adds her entries, then logs out.
A day or so later, Bob logs in, fires up MyCheckWrite, and sees his previous entries. But Sues entries are nowhere to be found. You can imagine the family squabble that might ensue! But, lets say Bob is unaware that Sues made any entries and, thus, theres no altercation for the moment. Bob goes ahead and makes new entries, then logs out. A while later, Sue logs in. She can see Bobs initial entries, as well as the ones she posted, but she cant see Bobs most recent entries. She makes more entries, but Bob will never see them. As you can imagine, an uproar is coming soon!
What Virtualization Does
Why does this happen?
Virtualization is the culprit. Bob used the initial database. But when MyCheckWrite, running under Sues account, first attempts to use the database, Vista created a copy of the database, especially for Sue.
Now, as casual computer users, Bob and Sue are 1) completely unaware of this, and 2) even if they were, they wouldnt have a clue how to resolve the problem. Actually, by the time they reach that point, any sort of convenient resolution is probably going to be impossible without a herculean effort on the part of MyCheckWrites authors.
And that, dear reader, is the ugly aspect of virtualization (setting aside, for the moment, what the authors of the MyCheckWrite program are facing).
The good side of Vista Virtualization is that, at long last, different user accounts on the same machine are truly different in virtually every way. Not only does each user have their own set of preferences (desktop, shortcuts, menus, etc.), their data is truly theirs. Ill leave it to you to decide how good individualized data really is.
For many applications, virtualization is a good thing, indeed. For MyCheckWrite, its a disaster waiting to happen. So, whats a mother to do?
End User Solutions
If youre a casual user of an application like our fictitious MyCheckWrite, you can try a couple of things:
Contact the programs authors and get their best advice. If an upgrade charge is involved, bear in mind that it isnt their fault. They didnt ask Microsoft for these changes. They had no control over the matter. And they probably had to make a substantial (and unexpected) investment to make MyCheckWrite Vista-compatible. Anger at them is misdirected.
If a Vista-compatible upgrade is not available, then, immediately after installing MyCheckWrite on your shiny new Vista machine, do two things before you even use it:
Using Windows Explorer, locate the main executable file for MyCheckWrite probably named MyCheckWrite.exe. Right click and locate the Run in XP Compatibility Mode Option. Check that and save. This wont cure all ills, but it will make a good start. If you doubt this, fire up Excel 2007 on Vista and note that, in the caption bar, it says [Compatibility Mode]. Thats right: Not even Microsoft has caught up with Vista!
Locate the folder that contains the database for MyCheckWrite. Again, using Windows explorer, find the Security settings and grant modify rights to EVERYONE. When Vista detects Sue attempting to use MyCheckWrites database, and realizes that she already has rights to it, Vista wont virtualize a database copy for Sue.
Developer Solutions
For Developers, weve mentioned the bad, and the good. Time for the ugly This all gets real hairy, real fast. Future articles will deal with more issues, more detail.
Whatever you do, dont slip into denial just because you happen to be developing in the latest, greatest version of Visual Studio. It may insulate you from some of the problems, but not all. For example:
Youve developed a desktop (WinForms) application with VS, and believe youre ready to deploy to XP and Vista. So you fire up a new, VS MSI installer project. Now, go find the file/folder permissions editor. You need it to grant permissions to everyone in order to prevent virtualization. Cant find it? Surprise! It isnt there.
So you go the MSDN sites to search for answers. Good luck! New TLAs (three-letter acronyms) have been introduced. If you dont know the TLAs, you cant find the relevant articles. But you cant learn the new TLAs until you read the articles. Catch-22! What you will find are arcane entries about how to build MSI installers using the low level MSI Installer SKD. Have fun! One of the first surprises, when you land there (the MSI SDK), is that, in order to set file/folder permissions, a byte position (a bit) needs some flipping in the MSI database. Despite all the wonderful things Microsoft has to say about doing everything in XML, youre back to flipping bits! What is up with that?
The good news is that you arent stuck building your MSI installers in Visual Studio, or the low level SDK. 3rd party installers do include permissions editors. Check out the free InstallShield Express bundled with Delphi 2006.
The key thing your installer needs to do is to grand modify rights to your local data stores to EVERYONE. These could includeINI files, the folder containing your local database, or the database files, themselves. Modify rights are sufficient; there's no need to grant full access.
Another Way Out
If your application's local data store can be referenced via a system DSN, and if your installer creates such a DSN, you're home free. If your application gets at its database via a DSN,Vista won't virtualize it.
It's almost enough to tempt a programmer to convert his INI file to a DBF!
Now, why the light touch instead of detailed, authorative prouncements and prescriptions?
Youve probably seen the humorous television commercials that feature PC Guy and Mac Guy. With the current incarnation of Vista, Microsoft has handed Mac Guy more ammunition than he can use in a year of non-repetitive commercials. Vista simply has to change. As it stands right now, if Apple reduced their prices to within twenty or thirty percent the cost of a comparable Vista PC, they could easily win up to, oh, 50% of the personal desktop market.
I dont think Microsoft is ready to cede that much market share, and there are only two things they can do: Either continue to make XP readily available on new computers or fix Vista. Since Vista has a lot of compelling new features, and because Vista represents a huge Microsoft investment, Im betting on both imminent fixes to Vista, and an extened life for XP.
Which is the reason that, at the moment, we dont want to encourage developers or clients to spend too much time, effort, and money on attaining 100% compliance with an operating system that is simply bound to change and soon.
Yet it is crucially important to rapidly achieve some level of Vista compatibility. This promises to be an exercise in choosing the correct side of many fine, gray lines.
DBA
Print This
Tags:
KB Post: 
Article: 
