Microsoft support for Windows XP SP3 (the last supported SP level for XP) is due to end April 2014. By “support”, I don’t mean the help line center, but the testing and repair of exploitable code defects, as well as perhaps technical assistance to software and hardware developers. Articles on vulnerabilities won’t state XP may be vulnerable; they will simply ignore XP as if it never existed.
New or revised hardware will likely not have drivers for XP, and new software will start to exclude XP from the list of supported OS versions. This is likely to be more severe than it was for Windows 2000, because there’s a far bigger difference between the 2000/XP and Vista/7/8 code bases as there is between 2000 and XP, or within the Vista to 8 spectrum.
The trouble is, many of us still have software that “needs XP”; that gulf between the 2000/XP and Vista/7/8 code bases makes it far harder for XP-era software to work on newer Windows versions, even as these versions attempt to support such limitations in various ways. Some of this software may have hardware dependencies that can no longer be met, or delve “too deep” into OS territory for virtualization to manage; examples include licensing protection code, close relationship with hardware (e.g. DVD burning software), and deep-system stuff like diagnostics, data recovery or anti-malware activity.
There are different ways to accommodate old software:
0) Keep (or find) an old system
If you already have an XP PC running what you need to use, then you could keep that – as long as it lasts. Monitor the hardware’s health, by:
- Eyeballing motherboard capacitors
- Checking fans and dust ventilation problems
- Watching SMART details and hard drive surface
- Running MemTest to check RAM if PC becomes unstable
If the PC fails, you can try and repair or replace it, while preserving the existing installation. Back that up, as the first boot may well fail in various ways; BSoD STOP crash, lockup, demand to activate Windows and other vandor feeware, protracted (and possibly doomed) search for new drivers, etc. If you can get the hard drive installation working within tested-good hardware, that’s probably the best result from a compatibility perspective. It may be your only choice, if you lack installation discs, or pre-install material, and/or product keys etc. for your crucial “needs XP” software.
XP-era kit is quite old now, and reliability is becoming a problem – like buying a used car with hundreds of thousands of kilometers on the clock, to start a road trip across the Outback. Digital systems are based on analog parts, and at the volts-and-microseconds level, slew times can grow with no apparent problem until they fall outside the digital yes/no detection criteria. Metal-to-metal contact points get corroded, and you’ll often find an old PC either works fine, or not at all; maybe it “just needs this card to be wiggled a bit” to get it working again, etc. Welcome to Creepyville, you won’t enjoy your stay.
An alternate approach may be to harvest the hard drive installation into a virtual hard drive (.vhd file) and try getting that to work as a virtualized PC; jump ahead to (4). You’d run the same “different hardware” gauntlet as dropping the hard drive into a different PC, with added virtualization-specific issues. So far I’ve had no success with this; it’s been a non-trivial mission to attempt, and I’ve only made the attempt once so far – but maybe better tools will help.
1) Build a “new” old system
In other words, if an app needs Windows XP and can't run on anything later, why not simply build a "new" XP system? That would give the most compatible result, and should run well.
In practice, XP doesn't properly embrace new hardware and/or use it effectively, degrading the value of the hardware. There's no (native, or in some cases "any possible") support for:
- AHCI, which reduces hard drive performance
- 64-bit addressing, limiting memory map to 3G or so
- USB 3.0, so you're limited to USB 2.0 performance
- 2T+ hard drive capacity
- Touch screens
Some of the above are not yet relevant (USB 3.0) or may never be relevant (touch screens, for which Windows 8 is designed) but others (AHCI, 4G+ memory access) already bite deep. The 2T hard drive limit is also currently impossible to breach via internal laptop hard drives, but may become relevant for shared externals.
So building a "new" XP-only PC is something of a dead end, suitable only to shrink-wrap a crucial and irreplaceable application, on the understanding that the system won't be safe for general use (any Internet access, perhaps even inward file transfers via USB etc.).
Availability of new XP licenses is an issue, given that it has long been off the market as a saleable product. In theory, Home costs the same as the cheapest non-Starter edition on later Windows, and Pro the same as corresponding versions of 7 and 8, but in practice you'd struggle to find legitimate stock.
There’s also uncertainty around the activation of Windows XP after support ends. At the time the activation system was rolled out, we were assured that when Microsoft lost commercial interest in activated products, the activation system would be disabled so that software could be used without hassles, but it remains to be seen whether that promise is kept. Worst-case scenarios are where new XP activations become impossible, possibly including those triggered by WGA (“Windows Genuine Advantage”), or even where existing installations are remotely disabled.
2) Build a new system, app must "take its chances"
There's an element of "app must take its chances" involved in all solutions other than "build an old system" and dual-booting as such. This is the most extreme case, where one simply ignores the application, builds a no-compromise modern system, and then hopes the old application can be made to work.
There are settings within Windows to treat applications as if they were running in older particular versions of Windows, but these don't handle every case successfully.
The main point of incompatibility arises from changes introduced with Vista, which attempted to curb the rampant malware threat. Things that applications were formally allowed to do with impunity, are no longer allowed, and some apps aren't satisfied with fake compliance with what they demand to be able to do. It's like moving from an unlocked farm house to a gated community!
Less likely to be a problem, is the change from 32-bit to 64-bit OS, as required to access over 4G or "memory" (i.e. RAM plus swap space plus allowance for non-memory use within the map).
Some software can break when the hardware is unexpectedly "big", i.e. "too much" RAM, hard drive space or processing speed, independently of the 32-bit vs. 64-bit thing. But most application software should not have a problem with either set of issues as such, though there are some other safety changes that stealthed in during the change to 64-bit that could hurt.
3) Build a dual system
It's possible to build and set up a PC to run either one version of Windows, or another. Only one can be run at a time, the hardware has to be compatible with both, and each OS runs natively, as if it had the whole system to itself.
Hardware compatibility becomes something of an issue; you either stunt the new OS, or you have to manually toggle CMOS settings to match the OS you're booting so that the new OS can run at full speed in AHCI mode.
You should get as good a result as (1), but have the same problems finding a new XP license. Both OSs have to have their own licenses, which is costly, but new OS can be a cheaper non-Pro edition.
There are some issues where each OS can trample on the other, if the C: partition of the inactive OS is visible. I've dealt with such issues before, though not yet with Windows 8, and may have to adjust the specifics for that and/or if the free boot tools used previously, have changed version and/or availability.
In essence, I use a boot manager to hide the “C:” OS primary partition that is not booted, so that each OS can see its own primary as “C:” and doesn’t mess up System Volume Information etc. on the other OS. All data and other shared material is on logical volumes D:, E: and F: on the extended partition, leaving one free slot in the partition table for boot manager and/or Linux, etc.
4) Virtualize one system within the other
In practice, that means virtualize the old within the new. The reverse is possible in theory, but will work less well as the new OS won't get the resources and performance it needs, so your "new" PC would run like a dog in "new" mode.
This is something of a gamble, because not all applications will work when the old OS is virtualized. Anything that needs direct access to hardware, and/or access to specific hardware, is likely to fail. That shouldn't apply here, but may, especially if the application fiddles with hardware as part of attempts to prevent unlicensed use - another facet of how feeware sucks.
The choice of parent OS becomes complicated, i.e. from...
- Cheap editions of 7 or 8, with 3rd-party virtualization host
- Pro edition of 7, for XP Mode
- Pro edition of 8, for Hyper-V based Microsoft host
In all cases other than XP Mode within 7 Pro, you would need an XP license, as you'd do for solutions (1) or (3).
If this approach works, it gives a more convenient result than (3) because you can at least run old and new OSs and the apps within them at the same time. Interaction between the two systems may be as separate as if they were to physically separate PCs on a LAN, unless the virtualization host can hide the seams, as XP Mode may do to some extent.
I've had some experience with 7's XP Mode, but as yet none at all with 8's Client Hyper-V virtualization host. So while 8 Pro and Hyper-V are more attractive going forward (Hyper-V is a more robust and faster technology than that of XP Mode), they are more of a jump into the dark for me at present.
No comments:
Post a Comment