Let's take two unrelated ideas and draw them together...
If you take Fred's brain and transplant it into Martin's body, have you performed a brain transplant on Martin, or a body transplant of Fred?
If the processor is your computer's brain, then the computer's hard drive is your mind.
Do you think the second sentence should have been "...the computer's hard drive is the computer's mind"? Both statements are true, but from your perspective, the first may be more important.
Why might this matter?
The practical importance of this arises if you take a hard drive out of a PC, and then come back after a while with that hard drive in your hand, and a collection of PCs without hard drives on the bench.
It's easy to tell who the hard drive belongs to, because the files it contains will be full of cues. But which PC belonged to that particular user? Less easy, because all information uniquely linking that computer to the user is on the hard drive. Unless you have kept some other record, e.g. serial number tracking, ownership sticky notes, arrival photos etc. you could have a problem.
Solving this problem
On old PCs that don't auto-detect hard drives, you can examine CMOS to look for CHS geometry etc. that matches the hard drive in your hand. But new PCs generally don't persist CHS or other hard drive parameters in CMOS; they re-detect such devices on POST instead.
You can examine the hard drive's files to look for links to the particular hardware, e.g. an OS product key that matches a case sticker, or a collection of device drivers that map to the rest of the PC hardware.
That is not as easy as looking for cues to the user of the PC; you may have to bind registry hives and look for cues in there. You could do that implicitly by CDR-booting into Bart and using RunScanner to wrap Regedit or other tools so they map to the hard drive installation's hives, or you can do that explicitly by running Regedit from any suitable host OS, and manually binding the hard drive's hives under HKLM.
Don't boot in the wrong PC!
Whichever approach you use to examine the hard drive, it's crucial not to allow the hard drive to boot in the wrong PC, in all but the most trivial of OSs. DOS would be safe, but anything more complex is likely to go wrong for various reasons.
Win9x will use Vmm32.vxd as the core driver set upon which all other drivers are loaded, and that core driver code was derived from the particular PC hardware that was in effect when Windows was installed on it. If it's incompatible, then the PC will crash before the OS has reached sufficient "consciousness" to Plug-n-Play.
This is a common crisis when changing the motherboard under a Win9x system, and can be solved by rebuilding a new Vmm32.vxd appropriate to the new hardware. Yes, there's one on the installation disk, but it's an empty stub upon which Windows Setup builds the "real" file at install time.
You could rebuild Vmm32.vxd by re-installing the Win9x over itself, but that is messy; breaks patches and subsystem upgrades, loses settings, and so on. Or you could do a fresh install of Win9x on a different hard drive, harvest the new Vmm32.vxd from there, and drop that into the "real" hard drive from DOS mode.
Having got this far, Windows should now boot to the point that Plug-n-Play can detect the rest of the new hardware and nag you for drivers. Expect problems from hardware-specific code that was not installed as drivers, and is thus not disabled when PnP detects the hardware as no longer present - think packet-writing CD software, modem fax and especially voice software, hardware-specific Properties tabs added to Display Settings, etc.
XP, Windows 2000 and older NT-based OSs may fail in a similar way, though the installation-time hardware-specific code file will he the HAL (Hardware Abstraction Layer) rather than Vmm32.vxd - same difference, in other words.
You will probably have to do a repair installation to fix this, with similar impact as installing a Win9x over itself. I'm not sure if cleaner fixes would work.
XP may have another surprise for you, if you aren't BSoD'ed by a HAL compatibility STOP error; Windows Product Activation may see the changed PC as "too different", and trigger the DoS (Denial of Service) payload.
Vista doesn't have the same HAL mechanism as earlier NT, so it may start up without a STOP error, but you'd still have the Product Activation payload to contend with - as you would with MS Office versions XP and later, regardless of OS.
I can't tell you how Linux, BSD or MacOS (pre- or post-BSD) would fare when booted in the "wrong" computer, but I suspect similar issues may apply. Aside from artificial crises caused by deliberately malicious product activation code, you may still have the core problem of needing hardware-specific information to boot the logic that can respond to altered hardware.
Safety First
If you are not certain that you're putting the hard drive in the correct PC, then you should back up C: in such a way it can be restored as a working OS, if mistakes lead to a PnP or product (de)activation mess.
For a Win9x, that's as simple as copying off all files from the root directory, all of the OS subtree, and (easiest) everything in "Program Files". For best-practice on WinME, you should preserve the _Restore subtree too. These are the only contents of C: that should be affected by the OS "waking up" in the wrong PC.
For NT, it's messier, because Windows 2000 and later (I haven't tested earlier NT) will not boot after a file-copy transfer from one hard drive to another, even if you meticulously include all files. So you're obliged to do a partition-level copy (e.g. save C: as a partition image via BING) to maintain undoability.
No comments:
Post a Comment