Slashdot Mirror
Windows 7's Virtual XP Mode a Support Nightmare?
CWmike writes "Microsoft's decision to let Windows 7 users run Windows XP applications in a virtual machine may have been necessary to convince people to upgrade, but it could also create support nightmares, analysts said today. Gartner analyst Michael Silver outlines the downsides. 'You'll have to support two versions of Windows,' he said. 'Each needs to be secured, antivirused, firewalled and patched. If a company has 10,000 PCs, that's 20,000 instances of Windows.' The other big problem Silver foresees: Making sure the software they run is compatible with Windows 7. 'This is a great Band-Aid, but companies need to heal their applications,' Silver said. 'They'll be doing themselves a disservice if, because of XPM, they're not making sure that all their apps support Windows 7.'"
...but didn't Apple successfully pull this off twice?
stop posting troll articles!! :@
On one side, you have the convenience of having an OS thats tested, your apps work on it, everything is good. On the other, you're perpetuating an old system, and keeping people from moving forward. Support nightmare isn't the half of it, you're going to have a very mixed level of application compatibility as well. In fact, the better option might have been a better more robust compatibility function to better support older apps. Because while it's all well and good to say that companies need to upgrade their products, how about the apps that are no longer supported, but switching away from them is no option. In many larger companies it can take years to migrate to another system, even upgrading may not be an option.
The musings of just another geek and his junk.
This is exactly what we want them to do. Virtualize the deprecated, old stuff, and get it out of the main operating system. Move on from the cruft of yore and build in some sweet new fundamentals that break backwards compatibility. We've been crying for them to do this for forever, so let's encourage it. It might add a bit of a support burden, but if it gives us a better product overall, what's the big deal?
As opposed to what, supporting an install of XP and an install of Windows 7? Or Windows XP in a VM and Windows 7?
Just think about it.
The need for a separate antivirus makes sense because the virtual machine is running a different operating environment with susceptibility to different viruses. A separate firewall does indeed seem superfluous.
...but didn't Apple successfully pull this off twice?
... Apple doesn't have every IT criminal on the planet gunning for their OS. They are bloody lucky to be in that situation and should IMHO be less smug about Windows security problems in their advertising. On the other hand running the defense grid for one Windows instance was fatiguing enough to persuade me to abandon Windows and become a Linux user and then an Apple customer. I still have to put in work to secure my machine but it is a lot less work than if I was using Windows. If this really means MS is doubling the security workload on each Windows box then.... hell.... I don't even want to think about it.
Only to idiots, are orders laws.
-- Henning von Tresckow
I'm 100% sure that a competent IT dept that has no use for this feature will, unsurprisingly, NOT USE IT, saving themselves all the support hassles entirely.
And for those that DO need this feature, they know there's basically no other way and it's worth the extra support hassle because they know they will have people saying Application XYZ MUST work I don't care how.
I suspect this means that the old applications that have to work and only currently work on XP can now be moved forward and the IT dept can get everyone onto Windows 7. Once there, the devs of these applications will have Windows 7 rather than XP to test against/run with and they'll have an incentive to update their programs to just work on Windows 7 because, like Classic on Mac OS X, this mode will have just enough 'impedience' that programs will be updated to work on Windows 7 native; but they will work okay in the meantime.
That's the thing - this isn't seamless. It's going to be a little tricky to set up applications to run in the XP box rather than natively on Windows 7, even if launching them is easy.
The trick is "Just enough impedience to get people to update to 7 native while providing a path."
You guys are missing the point, do you know how much "corporate legacy software" is written using VB6 - which will not run on Vista? That is the single reason for XPM in Win7 - and it is the single reason why many corps do not want to update to Vista, they have to re-write all of their apps.
It's the "cobol" problem.
I don't really see the issue here. If the virtual OS is running off of a directory tree in the host OS's file system, then any virus checking can be done via that route. If the host OS detects a virus, spyware, rootkit or whatever being installed (this is going to have to hit the disk at some point), then deal with it via the host OS.
Some of us have been asking MS to do this for a couple of years or longer, and with pretty much every modern x86 CPU now supporting virtualization, the time seems right. I'm no pro-MS advocate (quite the opposite, as my posting history shows, I loathe Redmond), but to my mind, sandboxing via virtualization is the very best way to deal with legacy apps, and with all the potential security holes they may have.
As others have mentioned, with a virtualized XP instance, MS has total control of the virtualized hardware, so a whole avenue of support issues large disappears.
The world's burning. Moped Jesus spotted on I50. Details at 11.
I see no reason for a second AV program, providing the VM's virtual drive is readable by the host operating system. If any kind of nasty program gets installed, it's going to have hit the file system at some point, and if the host's AV can plug in to that file system, it can suspend or terminate the VM.
The world's burning. Moped Jesus spotted on I50. Details at 11.
The bottom line is that I can't do a seamless implementation into the environment, the amount of overhead for the extra testing, training, hardware, certification means that it simply cant cost justify. Microsoft needs to remember that their two biggest competitors are XP and Linux. Any CIO worth his salt is going to ask one very simple question when presented with these costs. "Why aren't we sticking with Windows XP to begin with?".
I'm not opposed to things like VMWare, I have set up labs professionally for clients as a consultant and personally have paid for the workstation application and run it at home. I think it's great for IT needs, but the above issues should help explain why this feature is not the answer that Microsoft thinks it is. On a personal level I like this feature, and will almost certainly run it at home, so I speak professionally, not personally.
How stupid are these people?
Windows alreadys supports multiple OSes, from the Win16 and DOS subsystems to the BSD/UNIX subsystem, and also the Win32 and Win64 subsystem.
Which all have their own kernels, and run in NT OS subsystems.
So adding in a VM'd version of XP is going to add to 'support'? How?
The updates still come from MS Update, it isn't like the in house people are writing the patches themselves.
If anything this creates more work for MS, not a freaking IT department.
I'm not sure where to even begin with how stupid this sounds...
More tech support? Really?
If an IT department isn't using group policies and the business centralization and integration technologies of Windows, they shouldn't be using Windows and instead move to something that has almost no central control or mangement like Linux or OS X.
The hallmark of why business CONTINUES to choose Windows deployments is the ease and control that MS continues to give IT administrators, along with their centralized server management concepts that really do make anything else out there look foolish.
A well deployed Windows server/client environment is peanuts to administer, even when the IT people shove Firefox on users and have to run around and do 'manual' updates because Firefox is 'retarded' about allowing remote or admin level updates without giving your users administrator rights.
The second part of this is not understanding the virtualization technology being used. They assume it is like a 'free window' VMWare mode.
It isn't, it somewhere better a VM and a Subsystem on the NT architecture, which is one thing that makes HyperV as powerful as it is.
Truly people forget that NT is a user mode OS-less architecture, and that everything anyone sees is a 'virtual' subsystem, even Win32 has its own kernel and doesn't really know that NT is running under it.
Ok, I'll let people go grab the facts on this crap themselves, and give Win7 a week or two i people's hands that actually 'do' know what they are talking about...
PS The XP Virtualization is mainly for corporate clients, as 99.9% of all software works on Vista and Win7.
It is only the in house written or 'corporate' written software crap that has no concept of NT security that has problems with Vista or possibly Win7 that enforces the 20yr old NT security model that the software developers should have written for in the first freaking place.
yeah, the whole thing reeks of FUD, since XPM was just announced days ago.
Some slashdotters can't be happy with anything...
To be fair, every OS that I've ever dealt with has had issues with major upgrades. Whether it's glibc problems with older Linux binaries, or compatibility and driver problems moving to newer versions of Windows, there's always pain. For most of the history of computing, upgrading basically meant old binaries were FUBAR. Either you didn't upgrade or you had to compile/buy new versions of critical software, and put up with all the headaches that went along with it. Binary compatibility has always been as much a dream as a reality, and I think pretty much all *nix versions now do recompiles. Certainly most Linux distro familes at least recompile for all the major versions, and in many cases if you're a Debian user, you'll likely be using a different build of any given piece of software than an Ubuntu user.
Microsoft's chief problem for much of its history has been insisting on insane degrees of backwards compatibility, meaning a lot of legacy code is passed on from generation to generation, making getting new versions of Windows out the door has been an increasingly complex process. The newest generations of CPUs, the better average baseline hardware, and significant strides in virtualization technology now means that in future versions, a lot of this legacy code can be essentially left behind, and if users need to support older apps, they can run it in VMs, while Windows itself can be taken in any direction Microsoft sees fit. The underlying architecture becomes an open book again, as opposed to be constrained by a quarter century of legacy support.
And as to the concerns that some have raised her that developers won't write for newer versions of Windows, I don't buy that either. We're talking about a VM running an old OS which will not contain any new features, ever. At best some resources may have to be dedicated for the foreseeable future to keeping XP patched beyond current abandonment dates, but providing Microsoft gives users real reasons for upgrading beyond the eye candy crap, developers will be pursuing that brass ring.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Legend has it that XP will run in a virtual machine in (gasp!) Linux.
As long as you're going to run all your legacy apps in a VM and everybody has to learn a new interface anyway, why not get off the train to crazytown now? You can keep your legacy apps, you can keep paying Microsoft their Software assurance, and - hey - I'll bet you will be amazed how well some of your stuff migrates.
Help stamp out iliturcy.
That Windows 7 has such problems with XP apps that Microsoft thinks some users will want to run them in a virtual machine says a lot to me.
What it says to me is that the cumulative changes between Windows 3.1 and Windows 7 are now so great that it's cleaner to just calve off a small chunk of your computer and run old stuff in its own environment than it is to try and keep it integrated with the rest of the system. And I can't see how this is in any way a bad thing; if nothing else, crashes in legacy apps should be confined to those apps rather than taking your system down.
In particular, this is a great way of dealing with legacy XP apps that insist on being run as Administrator because they were written without any concept of functional file permissions. Whether or not these apps are good or "should be updated by their publisher" (who most likely no longer exists), they're a huge part of the day-to-day running of many companies. Being able to run them without risking your system stability would, I'd think, be a huge drawcard for corporate users.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
Just for the record, I've used Vista at work since it was released (doing .Net development and Database work on SQL Server).
Before SP1 was released, it was a pain in the ass. Since then... not so much.
In fact, I'm now used to Vista, and like it's extra features and perks, and find going back to XP annoying. I miss too much (the instant search everywhere, for starters, the snipping tool for another, I could go on and on) when I'm forced to use XP. And XP is so much less secure than Vista. Vista has proven to be remarkably stable and I haven't had ANY issues with viruses or trojans (not so, every XP install I've had over the same time period). It performs well, but of course I do have 4GB of memory, and wouldn't dream of saying anyone run Vista on less than 2GB.
The trash-talking of Vista is, at this point, mostly habit based on old info. It's ridiculous. ANYTHING that will help get people off XP and onto the newer more secure OS's (hopefully Win7) is a GOOD THING.
Hopefully most people won't need to use this new virtual XP VM in a regular way, in perpetuity. It can be and should be used as solely a stepping stone to get people on Win 7 and off XP, giving time for any software that refuses to run on Win7 to be updated or replaced. Mostly, the "XP Compatibility Mode" works well. For those apps that are just so badly written and so insecure and obsolete that they can't run even under that, this new XP VM provides a solution.
Of course, if software had been written correctly in the first place, then it'd run on Win7 correctly without issue.
Of course, one of the more laughable things is that SQL Server 2000, Microsoft's own product, won't run on Vista or Win7. Of course, it's a crappy database and nobody should be using it at this point... but there you go :-)
- Spryguy
There are three kinds of people in this world: those that can count and those that can't
Actually bus master DMA does make PCI harder. It's still possible on Windows though - the model is that Windows creates scatter/gather lists for you. The API also has plugs for the HAL potentially adding an extra layer of buffering in software once you start a transfer and tear it down at the end of the transfer. On x86 most of these plugs have traditionally been unused. On Risc they were used but with PAE enabled they are used to allow devices that can't bus master above 4GB to be used on 64 bit systems. I think some NUMA servers might have a non trivial implementation of DMA too. Basically the NT kernel has always had an abstraction for things like DMA to keep code portable.
I still think you're too blase about virtualising USB though. Of course you can add a driver to do it, my point is that by doing so you add a lot of latency. I'm suspect a lot of USB device drivers won't be able to handle that.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
It would also be better if we didn't need policemen and lawyers, but that's not going to happen either. In any reasonable future there will be computer security threats.
No, in Windows the a WDM driver calls Windows and asks for a scatter gather list. Also you allocate something called map registers
http://blogs.msdn.com/peterwie/archive/2006/03/02/542517.aspx
Map registers are an abstraction the DMA API uses to track the system resources needed to make one page of memory accessible by your device for a DMA transfer. They may represent a bounce buffer - a single page of memory which the device can access that the DMA will use to double-buffer part of your transfer. They could (in the world of the future) represent entries in a page map that maps pages in the physical address space into the device's logical address space (another DDK term). Or in the case of a 32-bit adapter on a 32-bit system where there's no need for translation, it might represent absolutely nothing at all. However since you probably want to write a driver that makes your device work on any Windows system, you should ignore this last case and focus on the ones where translation is needed.
You'll want to allocate enough map registers to handle your maximum transfer size. This limit might be exposed by your hardware, or as a tunable parameter in the registry, or just by common sense (you probably don't need to transfer 1GB in a single shot now do you?). However since map registers can be a limited resource, you may not always get the number you asked for (it's an in/out parameter to IoGetDmaAdapter). In that case you'll need to cut down your maximum transfer size - either rejecting larger transfers or breaking them up into smaller pieces and staging them.
A map register is a abstraction for a resource that maps one page of memory into the memory that is visible to the device. When you map a transfer the HAL could double buffer, or program an IOMMU, or it could do nothing (this was almosts always the case on x86). And the Intel version of IOMMU is apparently better optimised for virtualising DMA. Though it seems like the AMD one would work too.
Mind you, there's an issue with drivers not following the rules because they could get away with it on x86. Still the NT DMA model has always supported all of these options (no buffering, an IOMMU or a bounce buffer) though - it's very foresighted in that respect.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;