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

[deomsh]

Every part of this project is one out of (almost) nine ways to run Windows 98se from an USB-drive. Two parts are about the Windows 98 Second Edition installation using the legacy USB-connection. The other parts are dependent on Grub4Dos. Each part gives needed changes in respect to the one before.
All installations are possible in directory C:\WINDOWS: no drive-letter assignment needed.

Needed for the first eight parts:
·         Legacy BIOS must be USB-HDD compatible.
·         512MB RAM (reasonable minimum).
·         500MB USB-drive (reasonable minimum).
·         Partitioned USB-drive (USB-HDD).

I am not sure if anything I did is new, but you will let me know. In retrospective everything is easygoing, although later parts and project extensions are more complicated. Except Grub4dos, everything is experimental and (almost) undocumented.

The results of the project are divided into following parts:
Part I: Quasi-universal Windows 98se on Legacy-USB 1.1
Part II: Quasi-universal Windows 98se on Grub4Dos Memdrive with full Legacy USB 1.1 access
Part III: Windows 98se with PCI-devices (except USB) on legacy USB 1.1
Part IV: Windows 98se on Grub4Dos Memdrive with full USB 2.0 access
Part V: Windows 98se on USB 2.0 with Grub4Dos Memdrive as bootchain
Part VI: Windows 98se from a logical partition on Grub4Dos Memdrive
Part VII: Installation of Windows 98se on a logical partition with Grub4Dos
Part VIII: Windows 98se on other USB 2.0 partition with Grub4Dos Memdrive as bootchain
Part 8½: Full installation of Windows 98se on an empty Grub4Dos Memdrive without rebooting
Concluding remarks

DISCLAIMER: THIS PROJECT IS POTENTIALLY ADDICTIVE, I DON’T PAY FOR REHAB!

Edited November 9, 2019 by deomsh
Added picture (of bad quality because of my size limit)

[deomsh]

Part I: Quasi-universal Windows 98se on Legacy-USB 1.1

Installation of Windows 98se with "SETUP /P I;S=detectbus" (without quotation marks, a space between P and I) skips installation of the PCI-Bus and dependent PCI-devices.

Although USB-drives have different speeds, Smartdrive speeds up ALL volumes running in MS-DOS Compatibility mode. I used SMARTDRV /X C+ /B:57344 for highest speed; max partition-size is 128GiB (  according to R. Loew). With my fastest USB-drive BOOTLOG.TXT gives 6 seconds boot-time!

BTW: strictly spoken, "/P I" is not needed here, but used for Part III and further on.

[deomsh]

Part II: Quasi-universal Windows 98se on Grub4Dos Memdrive with full Legacy USB 1.1 access

The “Part I”-installation can be run from a Grub4Dos Memdrive and with full access to the USB-boot-partition and with changing UUID of the Memdrive (experimental).

In my experience Windows will only boot from a Memdrive with HIMEMX.EXE and without HSFLOP.PDR (or disabling floppy-controller; also DRV*.vxd’s can give problems). Memdrive will be max 400-500MB, mainly depending on drivers and vcache. I used [vcache] MinFileCache=1024 and MaxFileCache=1024 during experimenting.
GRUB.EXE (0.4.6.a) can be started from real MS-DOS with following MENU.LST:

------------------------------
MENU.LST
------------------------------
# comments always BEFORE a command

title Boot IO.SYS
chainloader (hd0)+1
rootnoverify (hd0)

title Memdrive with Legacy USB 1.1 access
# with, or without existing second disk
errorcheck off
map (hd1) (hd)
# mapped USB-bootdrive becomes always second disk
map (hd0) (hd1)
# needed for possible use of floppy drive
map (fd0) (fd1)
map (fd1) (fd0)
# USB boot-partition loaded in memory and mapped as first drive
map --mem (hd0,0)+1 (hd0)
map --hook
map (fd1) (fd0)
map (fd0) (fd1)
map --rehook
# UUID must be different from existing MS-DOS Volume Serial Number
# 16 characters available (hex; 0 – not O)
uuid --write (hd0,0) B00D-1D11
# vol --write not compatible with labels written by FORMAT or LABEL
vol --write (hd0,0) U11MEMDRIVE
chainloader (hd0)+1
rootnoverify (hd0)

title Reboot IO.SYS on Memdrive
chainloader (hd0)+1
rootnoverify (hd0)
------------------------------

More space is possible with Drivespace and/or a logical partition.
A logical partition can get a fixed drive-letter with SUBST, but the drive-letter will shift if booting from the Memdrive.
SUBST for different drive-letters can be automated with following batch-file, USB11.BAT:

----------------------------------------------------------------------
USB11.BAT
----------------------------------------------------------------------
REM if USBLOGICAL1 label of logical partition
REM SMARTDRIVE not in AUTOEXEC.BAT

DEL C:\VOLUME*.txt
VOL C: > C:\VOLUMEC.txt
VOL D: > C:\VOLUMED.txt
VOL E: > C:\VOLUMEE.txt

FIND "USBLOGICAL1" C:\VOLUMED.TXT
if errorlevel 1 GOTO U11MEMDRIVE
SMARTDRV /X C+ D+ /B:57344
SUBST X: D:\
GOTO END

:U11MEMDRIVE
FIND "B00D-1D11" C:\VOLUMEC.TXT
if errorlevel 1 GOTO SMARTDRIVE
REN C:\WINDOWS\SYSTEM\IOSUBSYS\HSFLOP.PDR HSFLOP.PD_
REN C:\WINDOWS\SYSTEM\IOSUBSYS\DRV*.VXD DRV*.VX_
FIND "USBLOGICAL1" C:\VOLUMEE.TXT
if errorlevel 1 GOTO SMARTDRIVE
SMARTDRV /X C+ D+ E+ /B:57344
SUBST X: E:\
GOTO END

:SMARTDRIVE
SMARTDRV /X C+ /B:57344
GOTO END

:END
----------------------------------------------------------------------

In case of attached hard-drives, IO.SYS patched with PCHIO is very convenient for collecting drive-letters (part of MDCU, see: http://www.mdgx.com/web.htm ).

BTW: BUFFERS shouldn't be set too low, or “Reboot to MS-DOS Mode” from a Memdrive may fail.

Edited November 10, 2019 by deomsh
Typo, changed first sentence

[jaclaz]

Hmmm.

I have a number of doubts about the contents of the menu.lst, and particularly on the use of vol and uuid.

I can understand the change to the uuid (actually the volume serial) since it is used in the batch but I wonder what is the point of changing the label to U11MEMDRIVE if that data is not accessed and BTW I don't understand the note about it being not compatible with the LABEL command.

Also I am not sure to understand the rationale behind exchanging floppy disks?

jaclaz

[deomsh]

@jaclaz

About changing label of Memdrive: it's not needed for a batchfile, just to gave the C-drive a nice name in Explorer My boot-drive is named USBPRIMARY1, and is the D-drive after booting the Windows on the Memdrive.

About LABEL: I am used to partition my USB-drives with Partition Magic 5.01. The "vol --write"-command never gave any problems and I used it in earlier versions of Part II. The command didn't work anymore for renaming a Drivespace Host-drive, and too when I formatted an USB-drive with FORMAT. Same story with LABEL.EXE. If the label is deleted by LABEL.EXE, the "vol --write"-command is working again. In PTEDIT.EXE can be seen that the "vol --write"-command is not writing to the FAT, while LABEL does. Also labels written by Mini-Tool-Partition Magic and RMPREPUSB I found not compatible with the "vol --write"-command of Grub4Dos. As a workaround I first used "cat", but rewriting UUID is much easier in my opinion.

About my floppie-mappings: without mapping I have simply no acces to A: or B: from the Memdrive, only with mapping. With the first two mappings Drive-letters are reversed, with last two mappings everything is back to nomal. My built-in Floppie-station is now always A: and an attached USB-FDD always B: Hard-drives gave no problems after booting the Memdrive.

[jaclaz]

AFAIK the grub4dos vol --write command writes to the FAT  filesystem just fine.

The LABEL (DOS or windows) command writes to the FAT filesystem just fine.

DRIVESPACE drives may well be a diffeerent beast.

There is also a "label" in the bootsector, this is normally NOT used by anything (anymore).

So, if you did use (say) :

cat --hex (hd0)0+1

i.e. you are looking at the bootsector, you won't find the label (which is a special entry, typically with 0x08 or 0x28 attribute in the filesystem - in the root directory if FAT12/16) see:

I just tested, and the grub4dos writes it with the 0x08 attribute (like XP) instead of the 0x28 attribute (like DOS).

Probably this is part of the reasons why you have different results with different tools.

jaclaz

[deomsh]

@jaclaz

My comment about LABEL and Grub4Dos was not ment to discuss this fabulous program. I have only some experimental findings to offer.

I just repeated them on a FAT16 USB-FDD made by RMPREPUSB, and a FAT32 USB-HDD partitioned with FDISK (BHDD-version) and formatted with FORMAT (no system).

It's sad I have reached my 350KB file limit, so I can't give any pictures.

With cat --hex (fd0)0+1 there is actually a name in the bootsector. With cat --hex (hd0)0+1 not, but with cat --hex (hd0,0)0+1 too. I can't change these volume names with Grub4Dos.

After deleting the volume names with LABEL.EXE, the bootsectors say NO NAME (and so does PTEDIT.EXE for the USB-HDD). If I write vol --write (hd0,0) VOLGRUBOKE? (or with (fd0)), VOL is displaying this happily in MS-DOS, but the bootsector is still NO NAME. If try to write the same volume name with LABEL.EXE, the "?"-character is refused, luckily VOLGRUBOKE! is accepted.

BTW: thanks for your old post, interesting stuff!

Edited November 11, 2019 by deomsh
Typo's

[jaclaz]

Yep ,

This is exactly what I was trying to specify/detail.

DOS/WIN9x use BOTH the label field in the bootsector AND the "label" as special entry with attributes 0x28 in the filesystem (in the root directory if FAT12/16).

Windows 2000/XP and later (and possibly also NT 3.x/4) ONLYuse the label as special entry (but with attributes 0x08) in the filesystem (in the root directory if FAT12/16).

Very likely this is connected to the different level of abstraction of the device, DOS has direct access to storage, NT has an intermediate layer.

The grub4dos command vol evidently behaves like 2K/XP and later.

Of course (JFYI) you can change the label in the bootsector with grub4dos, by directly writing to its field in the bootsector.

The label field is 11 bytes ([SPACE] aka 0x20 padded) at offset 0x2B.

You can use *something like* catedit.g4b (shameless plug ):

http://reboot.pro/topic/18783-release-cateditg4b-script-to-write-hex-values/?hl=[release]

But it would be possible to write a small batch with the offset fixed and - possibly - the translation from ASCII to hex for the label string.

jaclaz

 

 

[deomsh]

@jaclaz

Thanks a lot for your efforts! The results of a few dozen experiments are suggesting that you are right with the attribute-"thing"

I did some new tests with help of my old Diskedit, with maybe conclusive results, at least on my system (don't try this at home......).

On a newly FAT32-partitioned 4GB USB-drive with only one primary partition, I wrote a volume-label with MS-DOS 7.1 LABEL.EXE. This gave the volume-label as first Directory-entry with attributes A - - - V and date and time of writing. The volume-label was further written to the Bootrecord in Sector 0 and to the Backup-bootrecord in sector 6. Changing volume-label in Bootsector after erasing in Directory was useless, no output from MS-DOS 7.1 VOL, DIR, LABEL.EXE and FDISK.EXE anymore.

Grub4Dos gave with vol (hd0,0) following output: "(unsupported)". Writing volume-label with vol --write (hd0,0) GRUBDOSNAME gave this volume-label as second Directory-entry only, with attributes - - - - V and as date 0-00-80 (whole entry is marked "RED" by Diskedit, but okay after writing a valid date). Output of vol (hd0,0) was still GRUBDOSNAME

In MS-DOS 7.1 VOL, DIR, LABEL.EXE and FDISK.EXE displayed all the first volume-label written by LABEL.EXE. As soon this volume-label was erased by setting first byte to E5, they displayed all the second label written by Grub4Dos.

Rewriting the volume-label with LABEL.EXE erased the label written by Grub4Dos, LABEL.EXE set first byte to E5. Grub4Dos showed this label as sRUBDOSNAME (Greek 's', can´t show it in this post) and was willing to write a new volume-label. Deleting volume-label with LABEL.EXE erased both, and the directory-entries were  overwritten after copying files to the drive.

On my 1GB FAT16 USB-FDD: same results, although I am not fully sure if LABEL.EXE erases the second volume-label if it´s on an other sector of the Root-directory. Tired of testing

I never ran into problems while using Partition Magic 5.01 because this program write volume-labels without the Archive-attribute!

I hope you are confident now with my comment "# vol --write not compatible with labels written by FORMAT or LABEL", presumably the MS-DOS 7.1 one´s - the post is about Windows 98

Edited November 13, 2019 by deomsh
Typo's

[deomsh]

Part III: Windows 98se with PCI-devices (except USB) on legacy USB 1.1

In Part I detection of PCI-Bus is omitted, but not disabled: MSDET.INF hasn’t changed. Part III  continues the installation of Part I. Full installation will be accomplished in Part IV.

After renaming USB.INF to USB.IN_, PCI-Bus and dependant PCI-devices can be installed with Wizard New Hardware, no reboot in between. Before final reboot, Standard VGA must be deleted in Device Manager; all USB-Controllers should have yellow exclamation-marks.  

BTW: The Part III installation can be run from a “Part II”-Memdrive. Same method, same limitations.

[deomsh]

Part IV: Windows 98se on Grub4Dos Memdrive with full USB 2.0 access

In this part, after booting Windows on the Memdrive, there will be full access to the USB-bootdrive – mounted as regular USB 2.0.

After renaming USB.IN_ back to USB.INF, installation of NUSB 3.3, and adding mbrint13.sys ; Grub4dos to IOS.INI [safelist], the Memdrive should be booted first to “Command prompt only” with changed MENU.LST:

------------------------------
MENU.LST
------------------------------
# comments always BEFORE a command

title Boot IO.SYS
chainloader (hd0)+1
rootnoverify (hd0)

title Win98se on Memdrive with USB 2.0 access
# only one USB-drive allowed during boot
errorcheck off
# "usb --init" is not ment to be used on an USB-hub (Grub4Dos Readme)
usb --init
# for one “real” floppie-drive; if needed 
map (fd0) (fd1)
map (fd1) (fd0)
# USB-bootdrive (hd0)should be “outmapped” by Memdrive
map --mem (hd0,0)+1 (hd0)
map --hook
# without second mapping 3½” floppie can be seen as 5¼” by Explorer; if needed
map (fd1) (fd0)
map (fd0) (fd1)
map --rehook
# mandatory, without changed UUID “open files blue screen” while mounting USB boot-partition
# USB boot-partition not visible from “Command prompt only” anymore
uuid --write (hd0,0) B00D-1D20
vol --write (hd0,0) U20MEMDRIVE
# not critical, for other possibilities see Jaclaz 09-22-2017:
# https://msfn.org/board/topic/177102-solved-as-is-windows-95-issues-with-grub4dos/?do=findComment&comment=1145058 
root (hd0,0)
chainloader /io.sys


title Reboot IO.SYS on Memdrive
uuid --write (hd0,0) B01D-1D20
vol --write (hd0,0) R20MEMDRIVE
# critical, otherwise Memdrive can be rebooted only once (experimental)
root (hd0,0)
chainloader /io.sys
------------------------------

After booting Windows on the Memdrive, all USB-Controllers and already attached USB-Devices can be installed in Device Manager. If not there yet: SYSTRAY can be started from START --> RUN. All changes can be copied “down” to the Windows USB boot-partition. It should be possible to remove the USB 2.0-bootdrive, or insert it again, in the normal way.

Without Memdrive, Windows can only be started in Normal Mode after disabling USB-Controllers (in Safe mode, or with a REG-file from “Command prompt only” before booting Windows). See attached REG-file as example (machine-specific).

USBCTLNO.REG

To enable USB-controllers again, following REG-file has to be imported in the Registry before booting Windows on the Memdrive. Example in attached Reg-file (machine-specific).

USBCTLYS.REG

Importing REG-files can be automated with attached batch-file (together with batch-commands for one logical drive already).

USB20.BAT

BTW: After booting Windows on the Memdrive, it’s important - according to my experience - to wait ALWAYS before starting any program until Mouse’ Hour-Glass has been vanished. Also it’s a good habit to run Scandisk before copying anything from the Memdrive back to the USB boot-partition.

BTW2: Max 400-500MB, more space with Drivespace and/or logical partition (fixed drive-letter for logical partition on Memdrive has to be obtained with Device Manager).

BTW3: If no CD/DVD-drive available, Windows 98se files should be copied to USB-bootdrive before. Other possibility: at least all files mentioned in in USB.INF, MSMOUSE.INF and KEYBOARD.INF has to be copied to their destination first. Afterwards they can be skipped ("missing files" installation-dialog). USB-Mouse/Keyboard is not available during installation of USB-Controllers (one PS/2 Input-Device should be available during install).

[jaclaz]

Hmmm.

Can you try adding, right after the:

map --mem (hd0,0)+1 (hd0)
map --hook

a:

cat --hex --skip=446 (hd0)0+1

pause 

What do you get?

Explanation:

at first sight 

map --mem (hd0,0)+1 (hd0)

maps the first (primary) partition to the whole device (i.e. it should be a superfloppy), unless there is something else going on , the (hd0,0) reference should not be valid.

It should be:

map --mem (hd0)+1 (hd0)

to map the whole disk.

jaclaz

 

 

[deomsh]

@jaclaz

Thank´s for posting.

I did as you asked. Can´t post pictures anymore, so here is the full screen "written-down" (except txt after hex). Not sure if you only want the partition-table of the Memdrive.

I can upload full MBR-dump's of the Memdrive and/or the USB-bootdrive - if needed.

Booting command-list

Found 1 USB devices. Device Num: 0x80;
floppies_orig=0, harddrives_org=1, floppies_curr=1, harddrives_curr=1
FAT32 BPB found with 0xEB (jmp) leading to the bootsector

probed C/H/S = 64/255/63, probed total sectors = 1028160
00000001BE: 80 01 01 00  0C 01 01 40  3F 00 00 00  41 B0 0F 00 ;
00000001CE: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 ;
00000001DE: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 ; 
00000001EE: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 ; 
00000001FE: 55 AA                                              ;

Can you elaborate please what you ment with your comment:

"maps the first (primary) partition to the whole device (i.e. it should be a superfloppy), unless there is something else going on , the (hd0,0) reference should not be valid.

It should be:

map --mem (hd0)+1 (hd0)

to map the whole disk."

I am afraid I don't see the problem, why "not valid"?

Edited November 18, 2019 by deomsh
Typo

[jaclaz]

With:

map --mem (hd0,0)+1 (hdn)

you are in theory mapping the first partition of hd0, i.e. (hd0,0) to a "whole" disk (hdn)

So, the first sector of (hdn) would be the first sector of (hd0,0), i.e. a bootsector (or PBR/VBR) and not a MBR.

whilst with:

--map --mem (hd0)+1 (hdn)

you map the whole disk hd0, i.e. (hd0) to a "whole" disk (hdn)

In theory the first one shoudln't work , but grub4dos automagically  (I believe this may depend on the specific version, I seem to remember that it was added somewhere in 0.4.5c, but I may be mis-remember) does a few things:
1) copies the MBR from the source disk to the mem disk
2) writes to the MBR on memdisk a new single partition entry (with an offset of 63 sectors, normally) for the volume, 00ing all the others (if any) partition entries
3) copies to mem the actual volume
4) corrects (if needed) the sectors before in the BPB of the volume

I am attaching a couple of screenshots that should help explain the above, I am mapping, for the sake of the example to two different mem disks to show the differences.

Everything is fine and dandy .

jaclaz

 

[deomsh]

@jaclaz

Thank´s a lot for elaborating.

As far I can judge your first mapping gives same result like mine, only mapped to (hd2). And a corroboration of mine, isn't it. Your second mapping gives a memdrive with two partitions, second active. Give also very interesting testing-possibilities!

Grub4Dos readme states (in update 4): "Here win98.img is a partition image without the leading MBR and partition table in it. Surely GRUB for DOS will build an MBR and partition table for the memdrive (hd0)". I admit I could find my desired mapping nowhere, but by trial-and-error it was a very easy job in comparison to other parts of my project.

11 hours ago, jaclaz said:

In theory the first one shoudln't work , but grub4dos automagically  (I believe this may depend on the specific version, I seem to remember that it was added somewhere in 0.4.5c, but I may be mis-remember) does a few things:
1) copies the MBR from the source disk to the mem disk

Can you explain the MBR copy-part? The bootcode-part (before partition table) of my MBR-dump of the Memdrive looks different to the original (but I can't read MBR-code).