On Tue, 26 Oct 1999, der Mouse wrote:

> otherwise soon enough. :-)  (The real need is to fix a Windows box that
> won't boot, and I intend to do it by cloning the disk from another box
> that is fine.

This often won't work because FAT filesystems change shape depending on
the disk's c/h/s geometry, so it's conceptually impossible to copy one
from one disk to another without understanding the filesystem, unless both
disks are of identical geometry.

I tried a LOT of things to move Win95 from one disk to another.  There are
probably procedures I don't know about, but what worked for me is:

 o QUIT Win95.  You have no hope while it's running because files that are
   ``in use'' can't be read, and the only time files aren't ``in use'' is
   when you don't have long filenames available.
 o Prepare the destination disk
    o go to a working box
    o make a floppy with 'FORMAT A: /u/s'
    o copy c:\windows\command\{fdisk,sys,format} onto your floppy
    o stick your destination hard disk in another box
    o boot it from the floppy you made
    o FDISK and 'FORMAT /S' the destination hard disk so that it's
      bootable
 o Use a UNIX that understands long filenames, like NetBSD, to copy the
   filesystem.  This is really, i'm convinced, the only way it can be
   done.  Your ``hidden'' files will probably be unhidden, but at
   leastt they aren't silently ignored as on a PeeCee.  You can rehide 
   them with ATTRIB somehow.  I think there are some Secret Undocumented
   Options to ATTRIB, or maybe I just used ALTER.COM.  If it was 
   _documented_ it wouldn't be _hidden_, would it?  Does anyone else 
   find the idea of ``secret'' files a little odd?
   --you might want to try to get UNIX _not_ to copy IO.SYS and MSDOS.SYS,
   else you might have to boot off that floppy you made and type 'SYS C:'
   to fix up the damage to the Microsoft's ``House-of-cards: A completely
   novel one-sector booting framework'' [SIGCOMM v.27].
 o This will get you a hard disk with all your files on it, that won't
   boot into the GUI because the registry is broken.  Microsoft's 
   REGEDIT tool runs from DOS as well as the GUI, probably because they 
   anticipated this--it suspiciously has command line options that
   basically say ``/NETBSD -- reattach the registry files to the MSB 
   (Master Secret Block) on the disk after you used UNIX to copy them 
   because Win95 sucks so much.'' But sadly it is useless. I've tried to 
   use it to dump/restore the registry, but it (a) might not work, ever, 
   on any size registry, and (b) always crashed when I ran it, saying 
   the registry was too big.  Arranging for HIMEM.SYS and such to be
   available did not help (b).
 o Run the Win95 installer CD.  It will _reattach_ your broken registry,
   so all your dancing paperclip preferences should be happily restored.
   It will not, as you'd expect, simply give you a new empty registry.

..Wow..  i am so glad this is your job now, not mine.  i am almost a
little frightened that i know how to do this.  yet, i hope it helps.

> how do the multi-floppy sets work?

They are USTARFS.  I've never made one, but gazed at the Makefile code in
fascination.  It makes multi-disk Linux boots look hopelessly cobbled
together, since the Linux bootloader doesn't..., well nevermind--it's
cool, and it's in /usr/src/distrib/i386/floppies/fdset*

The plan is that you make a tarfile containing boot and netbsd.  You put
boot in the tarfile not because it's actually read out of the tarfile, but
just because it leaves space in the file for ``installboot'' to overwrite
it with the actual second-stage loader, which is guaranteed to be just a
little bit shorter than the ``boot'' file out of which installboot
extracts it.

It looks like the first disk is a tarball starting at 8k, on which
installboot gets run to write the first sector in PeeCee video-game-BIOS
format.  You use '-b 17' with installboot so that it starts writing the
second-stage loader at 8k + 0.5k (block 17), which is right after the
tar-header for 'boot'--the cleverly-arranged safe place to scribble.

Every disk thereafter starts with an 8k _human-readable_ text header that
looks like it probably helps the second-stage loader figure out if you've
put in the right disk, and then after that just continues with the tarball
right where you left off on the last disk.

You can glean a lot more from the Makefile's, and will probably want to
simply use the Makefile's to build your fdset, but I thought I'd summarize
just to entice you towards them--it looks really neat.

-- 
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US