20 Nov
2001
20 Nov
'01
8:35 a.m.
Well, remember that M$ is in the business of making money, which they seem to do
really well. Lots of folks have drawn the erroneous conclusion that they're in
the business of writing software. That's not the case. They're in the business
of SELLING software. It's not their job to protect the consumer. It's the
consumer's job to protect himself. The consumer's been falling down on the job,
hence, he keeps on buying that Microsoft product line. If he were smart, he'd
stick with the devil he partially knows, and let M$ go under. SO much for
Billy-bashing ...
I'd like to see someone write a chunk of software that does as much as this one
in 20 minutes, BTW. I don't think something this size will even link in 20
minutes.
Image recording was OK when one had a firm grasp of what the controller did with
the bits from the drive and what the OS did with them afterward. That's no
longer the case. In fact, so much wierd stuff goes on internally to the drive,
since the controller function is dedicated on each drive, that it's hard to know
what is different between two drives.
Dick
----- Original Message -----
From: "Christopher Smith" <csmith(a)amdocs.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, November 20, 2001 1:28 PM
Subject: RE: OT: paging MAC expert(s) --- What's a Performa?
-----Original
Message-----
From: Richard Erlacher [mailto:edick@idcomm.com]
It's the "quite a bit of extra
work" that concerns me, as the
boys at M$ haven't
managed to do it right yet, and they've been at it to the
tune of 100K man hours
per year for a decade or so. Recording a bitwise image of
Well, I haven't got much faith in them to begin with. They could work for
1000 years on a 20 minute job and still mess it up. I'm not saying that it
might not actually take that long, just that m$ aren't competent enough to
be a good indicator.
what you receive from
the disk may or may not give you all the information you need
to recreate the
files, since you may or may not know how the OS deals with
them. What's more,
I was assuming you'd know the filesystem type at the time of the backup. I
don't suppose it would be absolutely necessary. You might also recognize a
filesystem by magic number/signature, or the like.
[snip]
which you write such an image must be an EXACT
duplicate of
the one from which
the image was recorded. The second drive may otherwise claim
to be identical
but have a different number of sectors per physical track,
use different mapping
arrangements, etc, and, especially, have different bad
blocks. Since you're
Well, "otherwise identical" is dangerous territory at any rate. :) You're
right, though, in that depending on the way the software components interact
with the drive, one or more of these things might really screw things up. I
suppose that would require one to know the internals of each system with
which you plan to use this method.
going to send data that goes to where the drive
sends it and
not necessarily to
the same physical location from which you got it because the
... which may be ok, depending on how the system interacts with the device
in question. Of course, if you find that the system depends on the data
being in some physical location, rather than in a logical location, you'd
have to correct for that or _just not do it_ ;)
[snip]
sent, you may be disappointed with the results
because IDE
drives hide too many
details from the end-user.
Yep. Tell me about it.
[snip]
absolutely for certain, what
the drive does with the data you send it, and what the OS
does to process data
to and from the drive, you're on thin ice.
That depends. For instance (This will now get very hypothetical), if the
O/S handles data in logical blocks, and doesn't care too much the actual
geometry of the drive, you might be ok with not knowing about the device.
That is, with the exception of bad blocks. (Really I guess I'm talking
about faking a standard interface even when it doesn't exist here)
[snip]
all. Since SCSI is well established as to how it
operates
its data management,
it yields more hope that you can process an image, though the
vagaries of the OS
are still a limiting factor.
On the other hand, as some friends of mine are wont to say: "Neither S in
SCSI means standard."
Image recording should work fine with MFM- and
RLL-encoded
drives, even on a
track-by-track basis, and those offer some hope that one
could substitute one
sort of drive for another but hte ones which use BOTH CHS and
LBA addressing
won't tolerate the sort of operations to which an
incrementally developed OS
like Windows could create.
Can't argue with that.
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl
Hacker.")."\x08!\n");
'