"Hardware-Independent Restore": Real-World Feasible?

[dadiOH]

Again with the "you" "you" "you" !!

Actually, it was "I", "I", "I"

It's not about what one person does, it's about the sort of software
that's typically installed on today's machines

And that depends on the user, right? I would guess that in the great
majority of cases it is whatever was bundled with their machine. Including
the ubiquitous "trials" and or stripped down stuff like Nero.

A fair number have a few things downloaded from the internet, especially if
there was a pop up shreiking that their computer was infected and they can
save it only by pushing the "install" button.

Another fair number managed to avoid the latter but have many utilities and
general purpose apps (which can include those dealing with only one thing)
from the net.

Then there are a relative few that use their machines in a highly
specialized manner and whose programs - huge and expensive - reflect that.
_______________

and most of it now
cannot be simply copied over to another system by transferring it's
"Program Files" folder across!

And I have tried, that's how I know.

You must have a strange set of programs then as I have tried too.
Successfully. Several times. That's why I wrote what I did.
_________________

3rd party software is now far more integrated with the OS and
hardware.

In what way?
________________

It's not a case of saying it's a better world for it's ever getting
more complex, but a statement of fact that a working Windows
installation is a very different concept from one that it used to be
only ten years ago...

I definitely agree than a working Windows install is not only a nice thing
but a necessary thing. I would also agree that some apps - MS Office, for
example - would probably not work if not "installed"; but then, MS is pretty
persnickety (less so about the machine than money). Other apps could not
care less about the OS as they totally bypass it; Paragon's Hard Drive
Manager for example when is is writing an image to HDD or restoring same.
Most apps don't care about the hardware because they let the OS handle it
when the app needs to have hardware do something.

I might - possibly - build one more machine before passing on to that great
unformatted HDD in the sky; if I do, I'll be copying over my programs.

--

dadiOH
____________________________

dadiOH's dandies v3.06...
....a help file of info about MP3s, recording from
LP/cassette and tips & tricks on this and that.
Get it at http://mysite.verizon.net/xico

 

[Tim Meddick]

You must have a strange set of programs then as I have tried too.
Successfully. Several times. That's why I wrote what I did.
_________________

Yes, about that..... You say what you did (quoted above) concerning you
being able to simply copy programs across, but then go on to admit that M$
Office cannot be copied that way and would require all it's many registry
settings!

But I would contest that, rather than it being an unusual eccentricity, the
case of M$ Office is far more typical of today's software than you think!

I have no doubt that you know what you're talking about, when it comes to
your own favourite apps on your own machine (some of which you may have
possibly had and "transferred" since 1998!!!).

I myself have many programs that CAN be copied and who simply reset their
registry values when begun for the "first time" (Winimage.exe is one that
can be copied without problem).

However, there will be a great many that are of the M$ Office variety, in
that they spread their associated files and application extensions all over
the drive and also cannot function unless provided with the relevant mass
of associated registry data (I cited some in an earlier post).

Even so, I may well have it wrong about your computer, but I still assert
that in the majority of cases, the majority of installed software will be
ones that are unable to port to other machines by simple copying of their
program folder.

Also, the fact that a user has specialized software on his machine is
neither here nor there to whether or not it uses of a more modern approach
to the way it installs itself - using the registry and sharing resources
with other parts of the OS in an essentially more integrated manner - not
isolated enough to be simply "copyable".

==

Cheers, Tim Meddick, Peckham, London.

 

[VanguardLH]

It's not about what one person does, it's about the sort of software that's
typically installed on today's machines and most of it now cannot be simply
copied over to another system by transferring it's "Program Files" folder
across!

And I have tried, that's how I know.

3rd party software is now far more integrated with the OS and hardware.

It's not a case of saying it's a better world for it's ever getting more
complex, but a statement of fact that a working Windows installation is a
very different concept from one that it used to be only ten years ago...

Registry and file system. That's ALL there is for where a program can
install. Regardless of how complicated is the program, it's still the
same OS and the methods for installation haven't change.

Installation of drivers isn't magic or alchemy. Driver SDKs exist to
help with the known methods for installation. HAL replacement may not
be necessary. I mentioned ACPI/APM because switching between them
requires a different HAL but the ACPI HAL, for example, is the same one
used by many if not most installations. There isn't a separate HAL for
every motherboard brand and model.

The fact that it is hard for you to do with a manual migrate doesn't
obviate that software migrators can incorporate large databases of
drivers and their registry and file entries. With a migrate the
registry files follow, too, so there's no need to reinstall
applications. It is trivial to register DLLs and drivers and, besides,
the registry would be directly modified instead of registering the
drivers. The tricky part is detecting the hardware correctly as some
devices aren't specific enough in their firmware signature to
differentiate between different drivers needed for the similar sig but
different device - but then a mismatch on the driver is just as likely
if not more so if relying on the user to select the correct driver (but
the software migrator doesn't make a wrong guess regarding the OS and
its version). The migrated registry will already have all the entries
for the apps. The migrated file system will already have all the
entries for the apps.

Software app migrators have been around for a long time, probably way
over a decade. They weren't super common in corporations that instead
relied on sysprep images to setup their computers which were regulated
to control what hardware got used for their workstations. However, with
more competitive pricing there ends up a more mixed batch of hardware
platforms in a corporation so OS migration has become more important.
Moving apps isn't a problem. It's moving the drivers or detection of
hardware that's the problem along with a *possible* (not necessarily
required) change of the HAL. For the migration to be successful doesn't
mean all the hardware must be supported. Video and user I/O devices are
the biggies but then basic or generic drivers exist and thereafter the
user can choose to upgrade to more specific drivers. The migration is
to get the new hardware platform up and running. That doesn't mean it
has to be a perfect migrate, just a usable one.

It takes longer to build from scratch as apparently you think you must
do. It takes much less time to migrate to a usable state and then
modify from that point. That's why companies do sysprep images or users
do image backups: if they restore to the image, well, the host won't be
in the same state as before but instead in a prior state and the host
will have to be recovered for the changes made after that image got
backed up. Still, it's a starting point that saves a lot of time.

Was anyone here thinking that a migration from an Intel-based hardware
platform for Windows would suddenly make the migrated copy work on an
old Motorola-based Mac? Of course not, so obviously there must be some
minimal hardware compatibility between the source and target hosts.
Just because you have one machine with an old lesser video card and the
new host has a bleeding edge video card doesn't mean they don't still
support the old VGA video modes. Just what video mode do you think gets
used when you boot into Windows' Safe Mode? The IDE and SATA interfaces
haven't suddenly mutated to be incompatible between the hosts. You
might think there are too many mobo chipset driver packages to keep
track of but that's not a difficult task for a database full of them.

You're stuck in what it used to be like in trying to migrate an OS
instance between similar hardware platforms. No one is saying you're
going to be able to migrate between far dissimilar hardware. When you
look at all your hosts, you can pretty much classify them into a small
set of groups or hardware platforms. Within THOSE groups are where
migration is possible. For end users, they typically remain within the
same hardware group. Companies tend to prefer sticking with a very
small number of hardware platforms for their workstations to reduce
training and support costs. No one is saying you'll be migrating from
Windows 7 on an Intel x386 consumer-grade hardware platform to a Windows
Phone 7 or to an old Motorola x68 based Mac or to an IBM 360 platform.
Of course the hardware platforms will have to be similar enough for the
migration to give you *basic* functionality so you can *start* from
there without having to start all over from scratch.

Migration software has been around for a long time. You're just seeing
it now because, as always, it takes time for enterprise-level solutions
to filter down to the end-user market. Since end users might bitch
about the effort to start over from scratch, they often consider their
time as near worthless and don't equate it to some monetary value when
it's on their own time. Migration software was an expense for which
instead they chose to expend their own time. These are the same users
that won't pay for technical support. They'll buy expensive bleeding
edge video cards but then wander into newsgroups trying to get free
support. End users aren't the ones most likely to be interested in
migration apps. If they migrate to only get basic functionality and
then have to spend more days tweaking up their system with retrieving
and installing model-specific drivers for more than basic features then
they'll probably just start from scratch. A few days or even a week
lost to get it back up to full features is not nearly as expensive for a
company whose employee's host is down for that same amount of time.
When a company re-images your workstation to get you back up and
working, do they really care about the specialty apps you installed
which are probably not authorized by the company? No, they just want
you working as soon as possible.

When you migrate your OS to a new host, does having it usable with basic
features save you time from having to build it from scratch? Yes, but
then you might still be doing some rebuilding but obviously not as much
as doing a fresh rebuild. If saving time to start with what you have to
get up to something better weren't an issue with consumers, why the hell
do you think upgrade versions of Windows or any OS exist? Most
consumers want to do the upgrade so they had a working system and end up
with another working system. Unlike you and me, they don't like to do a
fresh build every time they move to a new version of the OS. It's about
saving time, and a migrate does save time.

A long time ago I started seeing programs that migrate apps. A little
long ago I started seeing programs that compile a database of the
drivers on your host so you could use them in a reinstall. Everyone
knows that Windows comes with a large set of drivers. The latest aren't
necessary to gain basic or better functionality with similar hardware on
a target host. Might this end up with a "dirty" migrate versus a clean
setup when you start from scratch? Possibly but then the same happens
for users that upgrade to a new version of the OS rather than build from
scratch. I'm not claiming the migrate will be perfect, just usable and
save you time to then do your further tweaking with model-specific
drivers to get all the functionality you had before.

I suspect you do realize that migration is possible and you're just
playing devil's advocate here. I don't believe anyone here was claiming
the migration would work across dissimilar hardware but typically those
that are migrating are doing so across similar enough hardware for the
target host to be usable.

Have you even scripted an installer program to write up your own
installer for your own software? What does the installer program do?
It writes registry entries and dumps files into your file system. Would
a migrate of the OS with its files and registry suddenly make all those
registry entries and files disappear? Of course not. They're still all
there. There are utility apps that may be hardware specific and won't
after the migrate but then utilities are not critical apps on your host.
They don't get your work done. That's why their called utilities.
Might those USB-connected printers not work after the migrate? Perhaps
but then they're not critical to the functioning of the OS or the apps.
After the migrate, if the Windows embedded drivers won't work then you
simply follow the migrate with a driver install for your printer. Is it
faster to do a fresh build and then install the printer driver or to do
an OS migrate and then do the printer driver install? Obviously the
answer is that it depends on the time to do a fresh build versus doing a
migrate. The assumption is that a migrate will take a lot less time
than a fresh build.

To finish up, I'll give an example of other software for another purpose
but proves to you that migration applications is not impossible or even
that difficult. Besides the app migration data of the past, SVS
(software virtualization solution) is something that's been available
for several years now. For use end users, we would install the software
into a virtual layer where all its changes got recorded (registry and
files) and we could switch in or out that layer to make the software
appear or disappear from the host. By the way, apps that monitor
installs is an old scheme for recording registry and file changes, and
putting them into a database is not rocket science. Instead of
recording each install on each workstation, companies can produce and
make available a layer that they deliver to their workstations for their
employees to swap software in and out of their hosts. Well, all those
registry entries and files are recorded, they're all known, and it's
possible to swap them in an out at will. Altiris came out with SVS
(well, they're the first ones I remember playing with), they had a free
version for end users, but then Symantec gobbled them up to incorporate
into their migration and SVS apps. As I recall, ThinApp is another
software virtualization product that can make apps appear and disappear
on your host. You could even have multiple versions of the same
software available but select only one to use to test your product
across them all but eliminate conflicts if you tried to install them all
in the same host. Flipping in and out the registry entries and files is
not magic. Neither has installation of drivers or apps become the magic
you think or wish it to be.

 

[Tim Meddick]

I'm perfectly aware of where changes can be effected on a given system by
any installed software.

And your quite right, it is not dependent on how complex an installed
application is.

But I was pointing out observed facts that, to date, software installations
*have* been growing in size AND complexity, notwithstanding, and as they
do, their integration with the OS that it becomes a part of, also is
becoming more complex in it's integration.

Modern features of today's software installations include their own driver
databases on cd-rom setups, that select and modify the nature of the final
files to be copies to the target system, dependent on their specific
hardware.

And, of the other point that were being discussed with "dadiOH", was
that more and more, today, software installs have been dependant on their
initial install procedure detecting system and hardware configuration,
writing the results to the registry forming part of the application's setup
process. Importantly, such setups do not work if the software's
accompanying registry entries are not also "ported" by some means also.
Even "dadiOH" admitted as much when allowing that M$ Office is dependant on
the registry in this way, and cannot be simply "copied across" to make it
work on another system.

Perhaps, Mr Vanguard, it is I who lacks the dexterity of words to describe
what is in my mind, and that I have failed to explain my position? I am
merely attempting to echo facts that I understood from sources I respected,
facts that I know to be almost universally accepted.

1). One cannot copy a Window's installation from ne system to another and
hope that it will successfully boot.

2). There are many programs (especially today) that cannot be expected to
function on another system, if they are just copied from their program
folder onto another system, and, has by-passed that program's setup
process.

...although, as I have stated more than once, I'm quite ready to concede the
fact that many (especially older) programs can be "ported" to another
system BY just copying it's program folder across to another system!

Whereas, I am certain that, in my statements, can be found errata and
cannot, I admit, be applied to every circumstance without exception, but if
the "spirit" of what I am stating is respected, then I have faith that
common-sense will ultimately vindicate my words.

==

Cheers, Tim Meddick, Peckham, London.

 

[VanguardLH]

One cannot copy a Window's installation from ne system to another and
hope that it will successfully boot.

I have done this MANY times by simply restoring from an image backups.
In fact, an image backup is the restore of which we speak but is usually
but not always onto the same hardware platform. The restore could be to
a slightly different hardware platform. Drives may change their type
(from IDE to SATA). I take care of the drivers later but the OS usually
boots okay. I have run into occasions where I need to boot once into
Safe Mode and then reboot into normal mode to get the normal mode
operational. If the OS detects new hardware, I install the
model-specific drivers but obviously the OS had to boot to do the
detection and alert.

The apps work just like before after an image restore even to a similar
but slightly different hardware configuration. After all, the registry
came along with the image. Where I granted there may be some problems
is with hardware-specific apps and typically those fall into the
utilities class of software and that software is not critical to use or
operability of the new host. Where I've run into problems is with the
HAL when moving between a host configured in the BIOS to use ACPI to
another that is configured for APM, or from a single-core to multi-core
host. However, I've now seen backup software that during a restore can
be told which HAL to install in the new image. I've seen mention of
updating the HAL by replacing the %windir%\inf\hal.inf file during the
restore, or maybe the restore uses one of the entries in this inf file
to determine which HAL to use. I haven't investigated this to determine
if is this is the sole trigger needed to insert the correct HAL into an
image restore. In the past, I remember reading articles on how to
switch in a new HAL.dll file when switching from from single- to
multi-core.

If image backups only worked to exactly the same hardware configuration
that existed when they were made, they would have very limited
usability. You couldn't even modify the hardware in your old host after
doing an image backup unless the later re-image was usable.