Exploring "SETUP /P I;S=detectbus" and Grub4Dos: 8½ times Win98se on USB-drive

[jaclaz]

Well, I expressed myself incorrectly. the MBR is not copied, some parts of it are copied and a new MBR is created using some of this data, correcting it when needed - loosely - the MBR is made of three (actually four, please read as five) parts.

1) Bootcode 440 bytes (0-439)
2) Disk Signature 4 bytes (440-443)
2.a) Unused 2 bytes (444-445)
4) Partition table, 4 entries 16 bytes each=64 bytes (446-509)
5) Magic Bytes 55 AA (510-511)

The bootcode can in theory be empty, but some BIOSes/OSes might *want* or *need* some leading bytes 
The DIsk Signature is only used on NT based systems to "ID" the disk uniquely.
The unused bytes are - well - unused an they are normally 00 00.
The Partition table's entries contain a byte (either 80 or 00 ) for active/bootable, a byte for partition filesystem ID (not really-really, it is actually a "protective ID", but for years it has been used as ID) some data with the CHS addresses of the extents of the partition and the last 8 bytes are the LBA addresses of the extents of the partition.

 The boot code cannot be "read" (it can be read but it cannot be interpreted), it could be disassembled,  but it is not normally needed/useful, set apart some special code (like grub4dos itself, or - say - MBLDR) there are tens of different MBR bootcodes (including those standard for DOS/Win9x and those for the NT family of OSes) that all essentially do the same, i.e. they parse the partition table contents and chainload the bootsector of the (porimary) partition that is set active.

In the example I posted the MBR is completely blank (00's) exception made for the disk signature, the two partition table entries and for the Magic Bytes.

What grub4dos does is (on the mem mapped disk MBR)

1) insert a few boot code bytes <- these are not a real boot code but rather some bytes that are needed on some particular BIOSes or OSes, it is only a "compatibility" provision, anyway since you are alreasy in grub4dos you will proceed by-passing the MBR code and either boot the PBR or firectly chainload the OS loader or System file (the io.sys in this case).
2) insert a new disk signature (it cannot be the same as the source)
3) copy the size of the chosen partition and maje an active entry for it with a default offset of 63 sectors
4) write the magic bytes

Then on the given partition PBR it corrects the "Sectors Before".

Of the partition table, even if you haven't got a parser like (shameless plug) this one for grub4dos:

 http://reboot.pro/topic/17728-release-mbrviewg4b-a-bat-tool-for-grub4dos/

or (even more shameless plug) Tinyhexer with my Structure viewer:
http://reboot.pro/topic/8734-tiny-hexer-scripts/

the relevant parts are easy enough to read manually, namely, for each partition entry:

1) the first byte is active if 80 or non active if 00
2) the fifth byte is the partition (protective) ID
3) the last four bytes are the size of the partition in sectors
4) the 4 bytes preceding the last four are the offset to the beginning of the partition (still in bytes).

Now, with this info, let's read the data in the partition table in the screenshots I posted:

On the mem drive  (hd3) (mapped from the whole disk (hd0), first entry:
1) 00 non active
2) 1C Type 1C
3) B8 0B 00 00 = 0x00000BB8 = size 3000 sectors 
4) 3F 00 00 00 =0x0000003F = offset (or starting at LBA or "Sectors Before") 63 sectors

Second entry:
1) 80 active
2) 01 Type 01 (this means FAT12)
3) 00 3F 00 00 =0x00003F00 = size 16128 sectors 
4) C0 0F 00 00 =0x00000FC0 = offsset (or starting at LBA or "Sectors Before") 4032 sectors

The above is exactly the the same as the "original" (hd0) MBR.

On the mem drive (hd2) (mapped from only the second partition (hd0,1)), there is only one entry:

1) 80 active
2) 0E Type 0E (this means actually FAT16 LBA mapped [1])
3) 01 3F 00 00 =0x00003F01 = size 16129 sectors [2]  i.e. same size (+1 sector) as the second partition on (hd0)
4) 3F 00 00 00 =0x0000003F = offset (or starting at LBA or "Sectors Before") 63 sectors (which is a "default" offset for first partition in any OS before Vista)

Now let's see the bootsectors, the interesting parts are (this is a very small FAT volume):
1) at offset 19 or 0x13 "small sectors" 2 bytes 00 3F= 0x3F00= 16128 sectors
2) at offset  28 or 0x01C "sectors before" 4 bytes, respectively:
(hd3,1) - same as (hd0,1) C0 0F 00 00 =0x00000FC0 = 4032 sectors
(hd2,0) 3F 00 00 00 =0x0000003F =  63 sectors

 

jaclaz

 

[1] this is a little "bug" of grub4dos, see here for the story of this queer bug:
http://reboot.pro/topic/21732-windows-for-workgroups-311-grub4dos-and-protected-mode/

(it won't affect you since you are not going to use Windows 3.1/3.11)

[2] strangely enough there is a (rather perverted) reason for this, the partition was originally created in XP and as NTFS, so the "backup bootsector" at the end of the partition (but outside the volume) has been "included" in the volume when it was re-formatted to FAT12.

[deomsh]

On 11/20/2019 at 11:35 AM, jaclaz said:

The bootcode can in theory be empty, but some BIOSes/OSes might *want* or *need* some leading bytes 

Thanks for clarification. I'd run some time-consuming tests with my MBR-aware tools while on the Memdrive. Indeed, Grub4Dos and Win98se doesn't care if the bootcode is made empty. But my USB Legacy BIOS definitely needs the bootstrap code to boot the USB-drive.

 

On 11/20/2019 at 11:35 AM, jaclaz said:

1] this is a little "bug" of grub4dos, see here for the story of this queer bug:
http://reboot.pro/topic/21732-windows-for-workgroups-311-grub4dos-and-protected-mode/

(it won't affect you since you are not going to use Windows 3.1/3.11)

I've read that post several times during my Part VII-research . Please, can you clarify why my project won't be affected?

[jaclaz]

10 hours ago, deomsh said:

I've read that post several times during my Part VII-research . Please, can you clarify why my project won't be affected?

That issue is with Windows 3.1/3.11 (and - similar but different - with any DOS earlier than 7.0).

It was released in times on par with DOS 5 and 6.

Last "real" DOS (6.22) only understood FAT12/16 volumes AND CHS mapped only, (partition types 01, 04, 06).

Windows 3.1/3.11 having been developed in the same period, and being actually a graphical shell over DOS. uses the same data.

Windows 95 and conversely DOS 7.x was, starting with 2nd release, extended with the LBA mapping for "BIG" FAT 16 volumes and FAT32 (partition types 0B, 0C and 0E).

To be exact 7.0 introduced LBA FAT16 (0E) and 7.1 FAT 32 CHS and LBA (0B and 0C).

More or less *any* tool before Win95 2nd version (DOS 7.1) came out only understood 06 and created only 06 FAT partitions, while later tools, depending on the case, may create either 06 or 0E partitions, more likely 0E.

Even if it is not "common" it is perfectly possible to run 3.1/3.11 over DOS 7.0/7.1, but the FAT16 partition needs to be 01, 04 or 06 or Windows 3.x will throw a fit (in protected mode) if it finds a 0E partition.

The grub4dos map feature (BOTH the map --in-situ used in that referenced thread and when you map a volume to a whole disk like you do here) creates on the fly a new MBR partition table and for FAT 16 it creates it with an ID of 0E, that Windows 3.1/3.11 cannot fully understand, so the underlying DOS 7/7.1 boots fine, but when the protected mode (and some related drivers) kick in it will error out.

Dos 7.x/8 (standalone) and Win9x/Me won't be affected as they understand 0E just fine, besides 0B and 0C, what happens when grub4dos through the map command creates the new MBR partition table entry is seen here:

http://reboot.pro/topic/21732-windows-for-workgroups-311-grub4dos-and-protected-mode/?p=206527

In more detail the automatic "conversion" of partition ID is:

01->0E
04->0E
06->0E
0B->0C
0C->0C

So I wrote the small batch to allow changing (when/if needed) the partition ID (which may in itself be useful for some other "crazy" experiments) and YaYa (one of the grub4dos Authors/Maintainers) added the feature through the --in-situ=FLAGS. (,both cover and are tested for the "map --in-situ" option only),

Some tests would be needed to see if my batch works "as is" or needs to be modified in the case of a map --,mem (hdm,n)+1 (hdm) case (your case) but there is no need for this since you are using Win 9x and a 0C partition ID already.

jaclaz

 

Edited November 25, 2019 by jaclaz

[deomsh]

@jaclaz

Thanks again.

I will will thorough test 0E in final testing of Part VII. Although tempting, I have not yet decided to reuse my project for other flavors of Win9x, or try running Windows 3x on a Memdrive.

For the time being this project is very time consuming, for now I have to return to final testing of Part V.

Edited November 25, 2019 by deomsh
Typo

[deomsh]

Part V: Windows 98se on USB 2.0 with Grub4Dos Memdrive as bootchain

If the MS-DOS “Volume Serial Number” of the Memdrive isn’t changed, Windows will boot further from the USB boot drive – partition with identical serial. The “outmapped” USB boot drive is invisible to IO.SYS while booting from the Memdrive, so not mounted in MS-DOS. If the Memdrive is (almost) identical to the USB boot partition, Windows doesn’t care.
It´s really nice to see BOOTLOG.TXT, on the primary (boot) partition of the USB drive, starting with Init Success usbmphlp.pdr.
Installation of USB-drivers should be finished before (see Part IV).

In MENU.LST of Part IV only the UUID command has to be deleted (or commented out). “Rebooting” the Memdrive is only possible before starting Windows.

BTW: “Reboot to MS-DOS mode” is impossible (Memdrive is not accessible anymore), no restarting Windows and no normal shutdown. "Restart" is the only option left, turning off the computer after a full reboot from ""Command prompt only".
BTW2: USB 2.0 boot drive cannot be removed anymore.
BTW3: Not all programs are working if Windows is on an USB drive with removable bit (no IOCTL ??). USB hard drives gave no problems.
BTW4: On my hardware and with Grub4Dos the primary partition as Memdrive bootchain is max 3406MB (with minimum 16BM memory left for Windows 98se and 32MB for Grub4Dos!). On a SATA-II drive in an USB 2.0 caddy, my “best” load speed was 38MB/sec. (with “usb --init”).
BTW5: This part can be combined with a logical partition. Desired fixed drive-letter should has been set one “higher” in Device Manager (logical partition “slips” one “down”).
BTW6: For automation I start GRUB.EXE with a batch file after renaming HSFLOP.PDR and importing USBCTLYS.REG in the registry to enable the USB-drivers. To boot Windows from an USB legacy drive I use another batch file with “:USBLOGICAL1” (see Part IV), further CHOICE to load SMARTDRV.EXE for USBPRIMARY1 only, enable HSFLOP.PDR and disable USB-drivers by importing USBCTLNO.REG in the registry.

[jaclaz]

10 minutes ago, deomsh said:

BTW5: This part can be combined with a logical partition. Desired fixed drive-letter should has been set one “higher” in Device Manager (logical partition “slips” one “down”).

Just in case, Letter Assigner:

jaclaz

[deomsh]

@jaclaz

Thanks for the tip. I tested the latest version of the program using Win98se and on two machines, with following results:

1) Can be used for Part I, Part III and Part V installations (no UUID changes in these parts!). A Reboot is always necessary.

2) Letter Assigner changes letters in MD-DOS already, assignments are found to be NOT compatible with SMARTDRV.EXE - Warning: Unable to use a disk cache on the specified drive (not mentioned in the HELP doc's). So speed gained for ALL drives in MS-DOS Compatibility mode, is lost by using Letter Assigner for assigned drives. This is less severe in Part V: the USB 2.0 drivers don't use Smartdrive; for some "Administrator" activities (starting Windows with USB-controllers disabled), the root partition in USB legacy mode is still cached by Smartdrive.

3) Letter Assigner checks for the Windows partition with UUID entrances in the file LETTERS.INI. In Part II and Part IV the UUID of the Memdrive is ALWAYS different from the UUID of the Windows partition on the USB boot drive. Since it's a goal of the project to have always access to this partition, the results with Letter Assigner are not compatible with starting Windows from a USB legacy drive after installation on a Memdrive; and the other way round. In the first case the C-drive will vanish after LETASSIG.EXE is started during execution of AUTOEXEC.BAT. In the second case I had a very, very bad crash while booting Windows on the Memdrive. It should be possible to replace LETTERS.INI-files before, but for sure this will not be easier than just calling SMARTDRV.EXE and SUBST.EXE in a batch file, with the right drive letters.

4) If the Windows volume is commented out in LETTERS.INI, assignment of other volumes is still working. The program gives only a message during execution of AUTOEXEC.BAT:
Bad descriptor: ;;C=(1234-5678)
Bad descriptor: ;;W=(8765-4321)
Bad descriptor: ;;/WD=(8765-4321)
The new volume mapping has been set up.
Volume D was mapped without problems to X (except Smartdrive caching)!

5) Volumes on real USB 2.0 drives are changed roughly in the same way as Device Manager operates. Only in case of a non-removable USB drive, Letter Assigner is special. Using Device Manager the USB drive has first to be set as "Removable", to change drive letters. After first reboot the drive can be set back as non-removable, new drive letters will be still there, but a second reboot is needed first. With Letter Assigner there is just one reboot needed. In the Registry (in HKLM\ENUM\SCSI\..somedrive..\) only one line "UserDriveLetterAssignment"="XZ" is added, while "CurrentDriveLetterAssignment" is changed to ="XYZ" (if XYZ are new volume letters of an USB hard drive with three partitions). With Device Manager there will be three other lines in the Registry-entrance left, but they are only needed in case of a truly removable USB (flash) drive and do no harm otherwise (as far as I observed).

6) Labels changed, by Letter Assigner are NOT compatible with the GRUB4DOS "vol --write"-command.

[deomsh]

Part VI: Windows 98se from a logical partition on Grub4Dos Memdrive

With a second, logical partition there are new possibilities. After writing a bootsector and “system” to the logical partition with SYS D: (or other drive letter), booting an existing Windows installation (copied to the logical partition) from the logical partition, or from a Memdrive is easy with following MENU.LST:

------------------------------
MENU.LST
------------------------------
# comments before a command

title Boot IO.SYS from logical drive for Win98se
errorcheck off
# needed if floppy drive is in use 
map (fd0) (fd1)
map (fd1) (fd0)
# assuming one logical partition only
# one of four primary partition entries should be empty
map --in-situ (hd0,4)+1 (hd0)
map --hook
# experimental
map (fd1) (fd0)
map (fd0) (fd1)
map --hook
# map --rehook
root (hd0,0)
chainloader /io.sys

title Windows 98se on Memdrive (from logical partition) with full USB 2.0 access
# “usb --init” found incompatible with “map --in-situ” (experimental)
# if GRUB.EXE is started without full reboot
map --unhook
usb --init
errorcheck off
map (fd0) (fd1)
map (fd1) (fd0)
map --mem (hd0,4)+1 (hd0)
map --hook
uuid --write (hd0,0) B00D-1D20
vol --write (hd0,0) U20MEMDRIVE
map (fd1) (fd0)
map (fd0) (fd1)
map --hook
# map --rehook
root (hd0,0)
chainloader /io.sys

title Reboot IO.SYS on Memdrive
uuid --write (hd0,0) B01D-1D20
vol --write (hd0,0) R20MEMDRIVE
root (hd0,0)
chainloader /io.sys
------------------------------

Further same as Part IV.

A Part V bootchain is possible too, but USBCTLYS.REG will be imported exclusive from “Command prompt only” during an “in situ”-session; should be done before loading the Memdrive. Automation with batch-files is still possible, but for bootchain three batch-files will be needed.

Part I, Part II and Part III installations are also possible (USB 1.1 legacy mode only).

BTW: I found the use of “map --in-situ” incompatible with HSFLOP.PDR, tested on two machines (other two test-machines don’t have Floppy-controllers).

[jaclaz]

Quote

# one of four primary partition entries should be empty

Why?

in-situ (when it works) virtualizes the MBR, creating a new one with just the entry/partition/volume you mapped.

******************************************************************************
***                   About the new map option --in-situ                   ***
******************************************************************************

--in-situ is used with hard drive images or hardrive partitions. With an
in-situ map, we can typically use a logical partition as a primary partition.

In-situ map is a whole drive map. It only virtualize the partition table and
the number of hidden sectors in the BPB of the DOS Boot Record.

While disk emulation may encounter various problems with win9x, the in-situ map
works fine with win9x.

Note that --in-situ will not change the real partition table.

Example:

	map --in-situ (hd0,4)+1 (hd0)

 

jaclaz

[deomsh]

There should be one free partition entry, or "map --in-situ" gives me ALWAYS "error 65", with various combinations. This is not in the readme, but years ago already mentioned by tinybit. 

http://www.boot-land.net/forums/index_showtopic_11675.html 

And mentioned here too (not by tinybit this time). 

http://reboot.pro/topic/15167-how-to-boot-win9x-from-logical/

I just tried again some combinations with "(hd0,4)+1" and the third partition entry empty.

With just "map --in-situ (hd0,4)+1 (hd0)" the logical partition becomes the first entry, the second and the fourth are unchanged. The original first entry becomes the third (the original free entry).

Only with "map --in-situ=1 (hd0,4)+1 (hd0)" there is a standalone -mapped- (hd0,0), without other partitions. But the original (hd0) is auto-mapped to (hd1), without change. 

Mappings to (hd0,0) instead of (hd0) made no difference.

Edited December 14, 2019 by deomsh
Added second link

[jaclaz]

On 12/13/2019 at 12:30 AM, deomsh said:

Only with "map --in-situ=1 (hd0,4)+1 (hd0)" there is a standalone -mapped- (hd0,0), without other partitions. But the original (hd0) is auto-mapped to (hd1), without change. 

Very good .

jaclaz

 

 

.

Edited December 14, 2019 by jaclaz

[deomsh]

On 12/13/2019 at 12:30 AM, deomsh said:

There should be one free partition entry, or "map --in-situ" gives me ALWAYS "error 65", with various combinations.

To avoid possible misunderstandings, I found this for "map --in-situ=1 (hd0,4)+1 (hd0)" too.

Today I repeated my experiments, I could reproduce anything EXCEPT "the original (hd0) is auto-mapped to (hd1), without change". I must have made some mistake.

The in-situ (hd0) still have one partition, but the original (hd0) is fully "out/over-mapped" and needs to be mapped to be find again.

For Part VI this has no consequenses,  I prefer my setup; no need of more mapping and shifting of hard drives.

[jaclaz]

Anyway someone that took the pains to instal Win9x to a logical volume already should know that some issues may come with it.

Just in case, good ol' XOSL FAQ's contain some good information about this (and various other "old OS" knowledge that is little by little being forgotten):

http://www2.arnes.si/~fkomar/xosl.org/faqhow/faq.html

jaclaz

[deomsh]

Part VII: Installation of Windows 98se on a logical partition with Grub4Dos

Installation of Windows 98se on a logical drive gave me some troubles. After writing a boot sector and “system” to the logical partition in use with SYS D: (or other drive-letter), there where in-situ related installation problems with SCANDISK.EXE. With about 6-8 logical drives while the last one was hidden, all IO.SYS versions except RLoew´s PATCHPAR version, had problems accessing the primary usb boot drive as last in-situ drive. Installation from CD-ROM will install original IO.SYS and can give this problem with use of map --in-situ (hd0,4)+ (hd0). Although there are several workarounds, following MENU.LST will do the job:

------------------------------
MENU.LST
------------------------------
# comments before a command

title Boot IO.SYS from first primary partition
unhide (hd0,4)
root (hd0,0)
chainloader /io.sys

title Install/boot IO.SYS from first logical drive for Win98se
errorcheck off
# no double access to first logical drive anymore
hide (hd0,4)
# shift (hd1) “up” if existing
map (hd1) (hd)
# shift usb boot drive “up”
map (hd0) (hd1)
# needed if floppy drive is in use. 
# after this mapping first “seen” by GRUB4DOS find-command
map (fd0) (fd1)
map (fd1) (fd0)
# assuming first logical partition in-situ
# one of four primary partition entries should be empty – else error 65
map --in-situ=1 (hd0,4)+1 (hd0)
map --hook
# experimental, after this mapping not “seen” anymore by “find”
map (fd1) (fd0)
map (fd0) (fd1)
map --hook
root (hd0,0)
chainloader /io.sys
------------------------------

BTW: Most reliable Win98se setup will be SETUP /is /p i;s=detectbus,detectfloppy (because of HSFLOP.PDR incompatibility and possible Scandisk problems). For continuing the installation, see earlier parts.

BTW2: The primary boot drive needs “system” only (SYS C:), together with GRUB.EXE and MENU.LST. The in-situ logical drive needs basic MSDOS 7.10 files. Easiest is copying the content of a WIN98SE bootdisk (without Ramdrive). This will give CD-ROM access too, if needed.

BTW3: With in-situ Windows never detected a bootvirus ( https://jeffpar.github.io/kbarchive/kb/143/Q143281/ ). Otherwise see Part IV for a possible workaround.

[deomsh]

Part VIII: Windows 98se on other USB 2.0 partition with Grub4Dos Memdrive bootchain

It's possible to extend Part V to bootchain a full Windows installation on a logical drive with boot sector and “system”. All that has to be done is adding "uuid --write (hd0,0) "Volume serial number"" of the wanted Windows boot partition to MENU.LST (after "map --hook", no quotes).

The  Memdrive partition has same limits as Part V, but 400-500MB will be enough for the bootchain. The Windows boot partition will be limited only by the USB legacy BIOS (all my test machines can’t pass the 137GB/128G(i)B border while booting USB drives; IDE/SATA drives has no problems).

If the Windows-directories are identical, the bootchain gave no troubles. During my testing the bootchain “worked” if at least all configuration files are identical and the Memdrive bootchain partition has all the system files needed until the Windows boot partition “takes over” (in BOOTLOG.TXT up to Init Success usbmphlp.pdr ).

BTW: Changes made to critical files in the Windows-directory should be copied to the USB boot partition before next boot. These changed files can be “loaded” from “Command prompt only” after booting IO.SYS on the Memdrive (changes to real-mode drivers should be “implemented” earlier).

BTW2: Bootchain is also possible with a Memdrive from other logical partition or virtual hard drive/image. The full Windows installation can be made on another primary drive too.