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

[deomsh]

Tried  on Android/ Firefox (desktop site)

@jumper Thanks a lot. Scandisk never complained (only if I made a mistake during the develoment of my LFN-driver ATTRIBFT.LLL).
 
I did an extensive search.

In the wikipaedia '8.3 filename' article is stated that a 8.3 mixed case file name is used as the Long File Name, the Short File Name is simply converted to uppercase. See https://en.wikipedia.org/wiki/8.3_filename
 
 

Edited August 31, 2024 by deomsh
Trying which part of my text was 'Forbidden'

[deomsh]

Also Save As 8.3 filename in Windows 98SE with Notepad with different case, gave results as found earlier (except if all characters are uppercase of course).
 
My conclusion is that in the FAT32 spec a conflict between different files/ directories with same Long and Short File Name is described, if the names are different in case only. Which makes sense on a case-insensitive file system (but case-rententive, see https://jpsoft.com/help/filenames.htm).

[deomsh]

Also Save As 8.3 filename in Windows 98SE with Notepad with different case, gave results as found earlier (except if all characters are uppercase of course).
 
My conclusion is that in the FAT32 spec a conflict between different files/ directories with same Long and Short File Name is described, if the names are different in case only. Which makes sense on a case-insensitive file system (but case-rententive, see https://jpsoft.com/help/filenames.htm).

[deomsh]

Inserting earlier part

In the patent text of 'Common name space for long and short filenames' is stated something like that (but not if a short filename API is used).

Somewhere in the patent text is a forbidden part, so use google (see steps 82, 84, 86 in patent US5579517)
 

Workaround with picture:

Edited September 1, 2024 by deomsh
Trying exclude forbidden parts of my text, workaround with picture

[deomsh]

On 8/26/2020 at 9:51 PM, deomsh said:

If FATCOPY.G4B is ready, I will move on with FATMKDIR.G4B, FATDEL.G4B (both FAT-only) and FATLSDIR.G4B (for all file-systems supported by Grub4Dos). During my holiday this summer I made the first versions on my smartphone with Limbo Android/X86 (I had no PC around).

A long time ago already I announced an outline of front-ends for grubutil 'fat' (and two for internal grub4dos function 'ls' too). I fully forgot my announcement, although I use all these scripts for years. Lately I finished them all and published them on my Github page.

In the first version(s), all scripts could handle Short File Names only (except for ls-directory parsing in FATLSDIR.G4B). Now the other three scripts can handle Long File Names too, if the Loosely Linked Library ATTRIBFT.LLL is present. The concept of  Loosely Linked Library is an idea of Wonko the Sane (Jaclaz) and discussed on reboot.pro (sadly still 'down', maybe forever?).

Script FATCOPY.G4B, front-end for grubutil 'fat' function 'copy', was published earlier in this thread, latest version 0.3:

Version 0.4 has following changes:

Version 0.4
NEW: switch /lfn[:]@ to add Long Files Names from previously saved to XXXXXX#n/@n[.EXT]-files to 'tilded (XXXXXX~n[.EXT])' Short File Names (needed: Loosely Linked Library ATTRIBFT.LLL)
NEW: switch /lfn[:case] to copy Long File Names (needed: Loosely Linked Library ATTRIBFT.LLL)
NEW: switch /z to copy zerobyte-files (NOT possible if source is NTFS)
NEW: switch /a to copy all atrributes on source files to target files
NEW: switch /maxfiles:n to limit maximum of copied bytes
NEW: switch /maxfiles:N to limit maximum of copied files
NEW: dialog to overwrite read-only files, do in advance with switch /r
IMPROVED: switch /sfn:@ has auto-set tilded file number by read-out of already saved Long File Names
IMPROVED: protection against errors on command-line
Changes to switch in use to change MDBASE
Various bugfixes

Script FATLSDIR.G4B, front-end for grubutil 'fat' function 'dir' or for internal grub4dos function 'ls', was discussed earlier in this thread. Version 0.1 is ready, with more than twenty switches, including basic one's like '/b', '/s', '/w' and '/p'. Like 'DIR' wildcards are supported, but only simple asterisk-wildcards (even ONE '*' at the end of last directory in PATH), switches like '/[-]x:~' and '/[-]y:DIR' can be used to filter on chars in file/ folder names. Also the special switches '/size:n' is worth mentioning, to filter on filesize. On next print-screen the use of this switch to find all zero-byte files in a directory, and in all it's sub-directories. Watch the difference between output of FAT-directory parsing and ls-directory parsing:

Script FATMKDIR.G4B, front-end for grubutil 'fat' function 'mkdir', is small, compared to the other three. Purpose is to make full path, convert Long File Names to Short File Names, or write the LFN's as external attribute to file, or to make Long File Names using ATTRIBFT.LLL.

Script FATLDEL.G4B, front-end for grubutil 'fat' function 'del', to to delete files and folders, or whole sub-directories, Deleting Long File Names is possible if using ATTRIBFT.LLL. As an illustration a print-screen, also with use of switch '/t', for ' trial' (Also present in FATCOPY.G4B and FATMKDIR.G4B).:

All scripts, with more information an many print-screens, can be found on : https://github.com/deomsh

Edited October 23, 2024 by deomsh
choice of word

[deomsh]

One of the better 'assets' if using Grub4dos is Grubutil 'fat'. Many of my scripts use this program to do basic operations on FAT file-systems. However, grubutil 'fat' can write Short File Names only.

Almost three years ago I finished my first version of Loosely Linked Library ATTRIBFT.LLL, one of my ideas was to use this library to write a grub4dos script with same command-line as grubutil 'fat', but fully compatible with Long File Names. So again a front-end.

This script is finished: FATLFN.G4B, and available on Github: https://github.com/deomsh/FATLFN

I added a few extra switches and functions.

1) Because grubutil 'fat' does not copy the original date and time (Modification Date & Time), I added this functionality;

2) Because grubutil 'fat' can not overwrite read-only files, I expanded switch '/o' to '/o[:r]', same for deleting files ('del') with extra switch '/r';

3) I added switch '/a', used to copy all attributes too (FAT-source only - also available in FATCOPY.G4B);

4) Function 'dir' shows Long File Names (if available). Like grubutil 'fat' always the whole directory is parsed (filtering on specific file-names would break the compatibility I wanted to be established);

5) New function 'dirx' shows Short File Names, filesize and associated Long File Names (if any). This function is more like 'dirx' in Windows 10 cmd. Also simple filtering on specific file-names is possible (ls-style);

6) New function 'dira' shows Short File Names, Attributes, Date & Time, Creation Date & Time (WRI) and Last Access Date (ACC). Filesize is not showed, not enough space in textmode/ 640x480 graphicsmode. Also simple filtering on specific file-names is possible (ls-style);

7) New function 'dellfn' will delete Long File Name only (actually not dependent on the existence of an associated Short File Name, orphaned duplicates in the targeted directory will be deleted too).

Functions 'ren' and 'copy' of grubutil 'fat' are enriched with possibilties to add or change Long File Names. For example change case of a Short File Name, which for instance is NOT possible in Windows 10 (on FAT file-systems). Microsoft advises to do a two-step rename: https://answers.microsoft.com/en-us/windows/forum/all/how-to-change-file-names-from-lower-case-to-upper/2305aad9-5743-4e95-83bd-64b191e312eb

This time I used the NT-method to abbreviate Long File Names: first four identical (resulting) Short File Names ('seen' as full 8+3 SFN) in a directory are tilded '~1'-'~4' after the first six characters of the name-part of the Short File Name. If more Short File Names would be identical, they have same first TWO characters, followed by a hash of the Long File Name and tilded '~1' up to '~9'.

FATLFN.G4B is using following functions of ATTRIBFT.LLL: getsfnpath, getsfn, getlfn, makelfn, dellfn, isreadonly, getattrib, setattrib, getntcasebyte, setntcasebyte, getdate, setdate, gettime, settime, getdatetimeattriball and calclfnhash.

I also made a Loosely Linked Library version: FATLFN.LLL (not used yet). This gives a library with a dependency to another library, because ATTRIBFT.LLL is still used. I hope I am not creating my own lll-hell .

One print-screen with new functions 'dirx' and 'dira' (more on Github):

BTW: it is funny the 8+3 'LOWCASEx' Short File Names have no associated Long File Name. This is because made on a NT-file-system, only - what I call - the NT-casebyte is set in the Directory-entry. No Long File Name is written if name-part, extension or both are FULLY lowcase (if only one is lowcase, the other must be HIGHCASE, otherwise a Long file Name will be written). But with grub4dos' internal function 'ls' this byte is read-out and corresponding case is showed.

[deomsh]

Lately I finished a second version of MKFATIMG.G4B, a Grub4dos script to make FAT-image files: https://github.com/deomsh/MKFATIMG.G4B

This script descends from an earlier project in this thread: to write a FAT-volume on a ram-disk and map to hard-disk. See: https://msfn.org/board/topic/180597-exploring-setup-p-isdetectbus-and-grub4dos-8½-times-win98se-on-usb-drive/page/4/#findComment-1178197

However, the new script is more universal, only mapping is not a part of it anymore. But the chosen FAT-volume is still written (partly) to a ram-disk first, before dd-copied to file. File-creation uses Grubutil 'FAT'. In latest version 0.4 of MKFATIMG.G4B Loosely Linked Libraries mentioned in previous post can be applied to use Long File Names (FATLFN.LLL with dependency ATTRIBFT.LLL). If these libraries are not found, only Short File Names can (still) be used.

The Small-help shows four modes of use:

Instead of targeting an image-file, also writing a FAT-volume on a ram-disk '(rd)' is possible, only limited by available (high-)memory. But if an image-file is targeted, max 64MB is written to the ram-disk and later dd-copied to the start of the image-file. Because production of the image file with grubutil 'FAT' is only possible on a FAT-filesystem, maximum image-size is < 4G(i)B.

If only 'size' and target are specified, there will be a disk-type and FAT-type produced depending on that size only, with no bootcode and no label, but with a valid MS-DOS uuid so each image is unique (unless some Swiss watchmaker is involved). Up to 4MB a floppy-image with FAT12, above up to 16MB a harddisk-image with FAT12, then a FAT16 harddisk-image up to 512 MB and above a FAT32 harddisk-image. Instead of 'size', also number of 'sectors' (512-byte only) can be specified, or even 'C/H/S'-values.

With what I call 'Use 1', there are numerous switches to specify desired properties of disk and FAT-image. With 'Use 2' and 'Use 3' there is access to a set of predefined floppy-images or (old) AT/PS2 disk-types for harddisk-images. Still many switches available.

Values used for predefined floppies are most of the time grabbed from 'Known_floppies2.xls' of Jaclaz:

As an example a print-screen of the making of a 12240KB floppy-image while using Long File Names. According to my tests this is the biggest floppy that can be used with VMware:

BTW if the switch '/BOOT' without ':OS' is used, the standard Win9x-bootcode will be written to the PBR, different for FAT12/16 and FAT32 (and to the MBR too in case of a harddisk-image). Script MKFATIMG.G4B has numerous bootcodes in textual form 'on board'. From MS-DOS 3.3 upwards, Freedos, ReactOS and Grub (Grub-bootcode is written to the PBR only). More information is in the Help.

As a specimen I produced two 12240KB floppy-images (one without bootcode). Also two 3840KB floppy-images (one with Grub-bootcode too, and one without bootcode), because this is the biggest floppy accepted by Virtual Box (only if used from the start, no so good if changed during a session!).

Use of the attached images with Grub-bootcode is simple: copy 'grldr' (comes with Grub4dos) and some menu.lst and other desired files to the image, for use in a virtual machine.

Use of the attached images without bootcode: load the image with System Files of choice and boot directly using grldr grub4dos (NOT possible on MS-DOS 6.22 and below), or transfer desired bootcode too with some program like SYS.COM.

As last print-screens the making of an almost 2GB FAT16 harddisk-image (values are rounded down by the script, also always ONE empty cylinder is added) together with mapping, copying Windows 98 system files and booting:

BTW 'Use 4' is not showed, is used to copy an image on a ram-disk afterwards to file. With these use some files can by copied to the ram-disk first, to pre-load the image.

Flop_12240k_(255t,2h,48s)_BCGRUB.zip

Flop_12240k_(255t,2h,48s)_NOBOOT.zip

Flop_3840k_(80t,2h,48s)_BCGRUB.zip

Flop_3840k_(80t,2h,48s)_NOBOOT.zip

 

Edited January 8, 2025 by deomsh
Alignment of print-screens; MORE corrections and additions

[deomsh]

Part 8½ B: Full installation of Windows 98se on a Rloew non-XMS Ramdrive

This project is a variation of Part 8½ A: Full installation of Windows 98se on a Grub4Dos Memdrive, but this time the Grub4dos memdrive is only used to obtain a small C-drive to install and run Windows 98se on a Rloew non-XMS Ramdrive.

Tested on following systems: 

1) Asrock 960GM-GS3 with 2GB, 4GB and 8GB RAM, AMD-Bulldozer and Geforce 7800 GTX v2

2) Asus P8H61E with 8GB RAM, Intel i-3 and NVIDIA GeForce 6700 XL

3) Acer VERITON M2610G with 2GB, 4GB and 8GB RAM

Apart from the content of the Windows 98se CD-ROM, only eight additional files are needed:

Files HIMEMEX.SYS, RAMDSK32.COM and RAMDSK64.COM are needed to create the non-XMS Ramdrive(s). PROTHOOK.VXD is needed to give Windows' access to the Ramdrive(s) - https://rloewelectronics.com/distribute/RAMDISK/RAMDISK2.0/

File LCOPY.EXE from LFNTOOLS is used to copy Long File Names to the Ramdrive, while still in MS-DOS. LDEL.EXE is used for special purposes. Inside lfn-1.79-en.zip - https://sourceforge.net/projects/lfntools/files/lfntools/1.79/

Files GRUB.EXE and grubutil FAT are needed for phases using Grub4dos - latest grub4dos-0.4.6a-2024-02-26.7z - https://github.com/chenall/grub4dos/releases/tag/0.4.6a

The attached zip contains only my own MS-DOS batch-files, a couple of my own Grub4dos-scripts, a few modified INF-files, some PIF- and LNK-files and documentation.

Highlights

• minimal user-intervention needed, two small image-files auto-added during Setup
• script INSTALL.BAT will check for presence of obligatory files and will extract all other needed files from the Windows 98se-CAB's
• includes a new script to patch RUNONCE.EXE during Setup (from Grub4dos).
• auto-adjustment of Ramdrive(s) to 1GB 32-bits ramdrive (2GB RAM), 2GB 32-bits ramdrive (less than 5GB RAM) and 2GB-swapfile 32-bits ramdrive and a 64-bits ramdrive (from 5GB of RAM)
• setup can be run again re-using all files, images re-used if desired too
• predefined drivers available during installation by copying files to their respective directories
  • Bearwindows VBE graphics driver
  • Tihiy's Safe mode SVGA-patch
  • BHDD31
  • NUSB33
  • Rloew's PATCHMEM, HCDP, SATA patch, AHCI-driver and USB1-storage driver
  • Sweetlow's RMMFLRM.VXD to delete phantom floppy drive letters
  • Update Windows files placed in directory WINDIR or inside sub-direcories INF, COMMAND, SYSTEM, SYSTEM\IOSUBSYS or SYSTEM\VMM32
• Bootmenu after installation, with choices Normal, Logged (\BOOTLOG.TXT), Safe mode, Command prompt only and Safe mode command prompt only (if defined MS-DOS CD-drivers are added, choice Command prompt only with CD/DVD too)

• Injection of changed CONFIG.SYS and AUTOEXEC.BAT and driver-files on small C-memdrive possible (directory INJECT.ONC)

• Everything is documented in the directory README in the Project-zip below

Some print-screens made during installation:

Content of README.TXT

REQUIREMENTS:

1) USB-flashdrive formatted with FAT or FAT32 (depending on size) including MS-DOS 7.1 system files
2) HDD-style is most universal, but FDD-style is possible (probably no Safe mode)
3) Content of Windows 98SE CD-ROM
4) Prod-key to install Windows 98SE
5) Minimum of eight additional files: HIMEMEX.SYS, RAMDSK32.COM, RAMDSK64.COM, PROTHOOK.VXD,
    LCOPY.EXE, LDEL.EXE, GRUB.EXE and FAT

HARDWARE:
1) Minimum 2GB memory, preferred 8GB
2) Best is a PS/2-Keyboard, otherwise NUSB33-files must be included in Setup, needs USB1(.1)
3) Mouse is not needed during Setup

PREPARATION:
1) Copy contents of WINONR8.5.USB.EMPTY.ZIP to USB-flashdrive
2) Copy files of Windows 98SE CD-ROM to directory WIN982CD
3) Copy minimum of needed files to directory SETUP982\ADDFILES (see ADDFILES.TXT for specifications)
4) Copy desired files to various directories to run during Setup (see files-lists with specifications)
5) Copy desired drivers to directory SETUP982\DRIVERS (the content of this directory is copied to
    R:\SETUP982\DRIVERS, including sub-directories)
6) Copy desired programs to directory SETUP982\PROGRAMS (the content of this directory is copied to
    R:\SETUP982\PROGRAMS, including sub-directories)

INSTALLATION:
Boot from USB-flashdrive and run INSTALL.BAT

AFTER INSTALLATION:
1) Use MSCONFIG to disable SCANREG and Schedules - do not reboot!
2) Disable Recycle Bin
3) Enable DMA in Device Manager on Hard drives/ CD-ROM - do not reboot!
4) Installation of USB-drivers if still needed - do not reboot!
5) Installation of other drivers of choice - do not reboot!
6) Boot to MS-DOS and Exit to Windows (automated with pre-installed Shortcut on Desktop)
7) Copy content of R: to directory ONR on USB-flashdrive (best with function Directory Synchronization of  
    Total Commander)

RUNNING WINDOWS 98SE ON RLOEW'S NON-XMS RAMDRIVE:
Boot USB-flashdrive and use Menu-item of choice
After choosing item Command-prompt only, Windows can be still started with WIN, even in Safe mode with WIN /D:M
After choosing item Safe mode command-prompt only, Windows can be still started with WIN, but NOT in Safe mode

MAINTENANCE:
1) Safe mode can be used for maintenance, rather slow (not working on all hardware - needs USB1.1)
2) Windows can be used for maintenance, needed for certain drivers.
   Before reboot synchronize R: with directory ONR on USB-flashdrive
   Afterwards again to delete installation files in directory ONR\WINDOWS.ONR

From command-promt there is access to the Windows-directory WINDOWS.ONR
(is using SUBST.EXE R: C:\ONR)

TROUBLESHOOTING:
1) USB2-drivers: if drivers from NUSB33 are not working, use U98SEUSB.EXE from Unofficial Service pack 3xx
    After installation reboot Boot to MS-DOS and Exit to Windows (automated with pre-installed Shortcut on
    Desktop)
    Finish installation with Device Manager
2) NDIS-2 driver needs an entry in AUTOEXEC.BAT, install from Windows
    Before reboot check AUTOEXEC.BAT on small C-drive and move entry AFTER file-coping entries
    Copy modified AUTOEXEC.BAT to directory INJECT.ONC on on USB-flashdrive
3) DirectX can be installed in Safe mode, but after reboot to Windows installation files must be removed
    from directory
    ONR\WINDOWS.ONR on USB-flashdrive
4) HDA2 driver needs an entry in AUTOEXEC.BAT, add HDATSR.EXE manualy from Windows to
    AUTOEXEC.BAT and HDA2.DLL to SYSTEM.INI
    Use AUTOEXEC.BAT on small C-drive and set entry AFTER file-coping entries
    Copy modified AUTOEXEC.BAT to directory INJECT.ONC on on USB-flashdrive
5) Localization of MS-DOS can be added to CONFIG.SYS and AUTOEXEC.BAT on small C-drive
    Copy modified CONFIG.SYS and AUTOEXEC.BAT to directory INJECT.ONC on on USB-flashdrive
6) Copying small C-drive back to image-file 16WINONC.IMG with help of hex-tools like HxD
    Copy content of Physical drive back to image-file (NOT logical drive)
    BTW file 16WINONC.IMG is set to System and Read-only, so temporarily remove Read-only attribute
7) Instabilities while using non-XMS Ramdrive:
    Adjust Buffers in CONFIG.SYS on small C-drive and copy to INJECT.ONC
    Disable Read-ahead buffers on HDD and CD-ROM in Device Manager

 

 

Edited October 11, 2025 by deomsh
Better alignment/ text, zip removed: later a 'better' one will be inserted

[deomsh]

Motherboard Asrock N68C-S UCC is also compatible with Part 8½ B: Full installation of Windows 98se on a Rloew non-XMS Ramdrive.

But this was not that easy, so maybe of general interest.

This board has a Nforce 630a chipset (max 8GB). In a conversation between @ragnarok and @LoneCrusader the problem was mentioned of endless waiting before Windows 98SE started, should have to do something with 'Gate A20 line': https://msfn.org/board/topic/174701-w9x-on-geforce-7025-nforce-630a-chipset/

I fixed my waiting-problem during setup with SweetLow's HIMEM.SYS: http://sweetlow.orgfree.com/download/ and then file a20alwon.zip

The 'preferred' version is fully compatible with my 'WINONR 8.5 USB' setup - only manually copying HIMEM.SYS to directory SETUP982\DOSFILES is needed.

But after last part of Windows Setup: still only a blinking cursor - while I was using 'Setup /p i'.

In the end following workaround gave the desired result: installation with setup-switch /p i;s=detectbus,detectfloppy. This time there was no problem to start the GUI of Windows 98SE. I used my NUSB33 setup-choice already, after Wizard New Hardware to install the PCI-bus all USB-devices were recognized - without reboot!

After copying to the USB-pendrive, running Windows 98SE was no longer a problem. No waiting either. IDE- and SATA-Controllers are working too with RLOEW's patches. Only the onboard LAN (RTL8201EL) was not recognized (also no driver available).

The onboard-graphics Geforce 7025 can only be used with Bearwindows' VBEMP driver, but this was a known fact already.

Even Watler's HDA-driver is working with the chipset's HDA-controller (10DE:03F0). The VIA HDA-codec VT1705 is working out of the box, to use WAVEOUT.EXE only VolumeWidget=$10 has to be set in HDACFG.INI.

But there was one persistant problem: exit to MS-DOS was no longer possible, and shutdown or reboot only while using the pysical buttons. I tried the Shutdown Supplement and other updates/ registry-hacks, but to no avail.

In the end overwriting the NUSB33-stack with the one in U98SEUSB.EXE from @PROBLEMCHYLD Unofficial 3xx-Servicepack solved all these problems (do not forget to disable SystemTray in MSCONFIG and renaming NTMAPHLP.PDR). 

With addition of an old RTL8139 PCI Ethernet card everything is GOOD, even Safe mode is working.

BTW: if an ACPI-bios was installed manually, almost everything seems okay (except one instance of Motherboard Resources with yellow exclamation mark), but no ACPI functions - same functionality as with PCI-bus only. But Wizard New Hardware didn't find a BIOS in auto-mode.

Edited February 22, 2025 by deomsh
Correction

[deomsh]

I made a new version of Part 8½ B: Full installation of Windows 98se on a Rloew non-XMS Ramdrive

Highlights:

• Minimum memory requirement lowered from 2GB to 512 MB, of available memory 7/8 part is used for a RLoew 32-bits non-XMS ram-drive (2,118 MB memory gives the max of 2 GB). Minimum memory is tested on my old PCChips M811-board, fully stable with 12 Internet Explorer windows together with 12 MS-DOS-windows (with http://www.proxycrime.com Google is still usable with Internet Explorer 4, even search-settings can be changed);
• I skipped making the 27MB setup-image, files still copied to (rd,0), but now directly mapped to memory as a Grub4dos mem-drive;
• Because of the CHS-limitation of floppies in MS-DOS I changed the Grub4dos mapping of boot-USB drives in hard-drive emulation to D: - boot-USB drives in floppie emulation still mapped to B: (with CHS-limit of 1024/255/63, so about 8GB);
• Choice to run JHRobotics' PATCH9X during Setup if files PATCH9X.EXE and CWSDPMI.EXE are added to the folder SETUP982\PATCH9X, simply extract them from JHRobotics' Freedos image (even possible with 7z). See next two print-screens:

• Choice of three Setup options (no detection of PCI-bus, no detection of Floppy, no ACPI), with their combinations. Default is still Setup /P I;S=detectfloppy. See next print-screen:

• I wrote a new Grub4dos-script to localize CONFIG.SYS/ AUTOEXEC.BAT during first boot of Windows. Windows' Setup will add and localize DISPLAY.SYS and COUNTRY.SYS to CONFIG.SYS and MODE.COM and KEYB.COM to AUTOEXEC.BAT. My script LOCALIZE.G4B will read-out these localizations during first start of Windows from directory ONR, and write them to CONFIG.SYS/ AUTOEXEC.BAT inside the 16MB C:-image and to CONFIG.SYS/ AUTOEXEC.BAT on the boot-USB drive.
  During Setup the whole C-drive was copied to the 27WINONC.982 folder on ram-drive R: - so all is needed is to copy the 27WINONC.982 folder to directory ONR on the USB boot-drive;
• If accidental deleted re-generation of the 16MB C:-image, including new localization (file LOCALIZE.TAG is deleted while building the image);
• File WINONRCD.BAT is copied during Setup to the root of the boot-USB drive. Running WINONRCD will prepare all files needed to make a Windows 98 SE 'Live CD/DVD' (running in memory only, so full write-access).
  Only GRLDR has to be added to SETUP982\WINONRCD (or to Root).
  If XDVD2.SYS and/ or SHCDX33F.COM are not found in the installation-phase, OAKCDROM.SYS and/ or MSCDEX.EXE have already been extracted from the Windows 98 SE cab's as a fallback.
  Be aware OAKCDROM.SYS is not compatible with SATA-drives (in IDE-mode). Further last two files are using together about 64 KB conventional memory, first two files only about 4KB! But XDVD2.SYS and/ or SHCDX33F.COM can be added to folder SETUP982\WINONRCD for use with the 'Live CD/DVD'.
  After running WINONRCD: files 4032KONC.HDD (C:-image), GRLDR, MENU.LST, FAT and FATCOPY.G4B and a few directories are added to directory ONR. Directory GRUB contains same MENU.LST as directory ONR, as fallback. Files added to directory INJECT.CDC before burning are copied to the C-drive while booting from CD/ DVD.
  ImgBurn is working 'out-of-the-box', no other ASPI-layers needed. Be aware 'El Torito'-boot is in no-emulation mode, and needs four sectors. For instance WINONCD has one sector as default, but ImgBurn has four. Important is to choose ISO9660+Joliet in case of CD-R/ CD-RW and ALWAYS ISO9660+Joliet+UDF is case of DVD+/-R / DVD+/-RW. See next print-screen:

The 'empty' version has been growing from 85 files to 120 files, and all-included from 314 files to 385 files. See FILELIST.TXT and ALLFILES.TXT in the README folder.

 

BTW an USB-drive is not absolutely needed, possible too is running Windows 98 SE from a RLoew non-XMS ramdrive using a hard-disk image inside Virtual Box or VMware.

Edited October 11, 2025 by deomsh
Correction, zip removed: later a 'better' one will be inserted

[deomsh]

I made some changes to MKFATIMG.G4B, a Grub4dos script to make FAT-image files.

New/ Changes:

• partition/ volume --size=n/ --sectors=n leading to more than 1024 cylinders allowed (partition type auto 0E/0C);
• switch /SPC:n now max 128 sectors per cluster (max was 64);
• new alignment switches:
  • partition alignment 32k-8m (mainly based on 224 Heads and 56 Sectors per Track);
  • FAT12 alignment 1k-2k, FAT16 alignment 1k-256k; FAT32 alignment 1k-8m;
• new switch /RDSIZE:4m-4g to make partial images in RAM (rd) possible, can be easily copied to (USB-) disk with dd (max full size 2048g, rounded down);
• switch /HIDDSEC:n to set (fake) number of hidden sectors on Floppy, max full size 2048g, on (partial) Ram-Disk only (size rounded down);
• fresh PBR boot codes, all full NASM code (ealier taken from Linux' ms-sys appeared not to be legit):
  • MSDOS20/30/40/50 (based on Microsoft's MS-DOS 4.0 MASM source code - MIT). MSDOS40 has been made binary identical;
  • MSDOS5070 FAT12/ FAT16 only, universal boot of IO.SYS (V4/)V5/V6/V7 and showing dot's during loading (based on Microsoft's MS-DOS 4.0 MASM source code - MIT);
  • MSDOS60 FAT12/ FAT16 only, will boot using INT13 AH=42h extensions too during boot (although further not used by IO.SYS V4/V5/V6).  Showing dot's during loading and with Key2reboot function too (based on Tinybit's GRLDR-FAT GAS source code - GPL);
  • MSDOS70 FAT12/ FAT16 only, will boot using INT13 AH=42h extensions too. Also supports booting WINBOOT.SYS apart from IO.SYS,  showing dot's during loading and with Key2reboot function too (based on Tinybit's GRLDR-FAT GAS source code - GPL);
  • MSDOS71 FAT32 only to boot IO.SYS, showing dot's during loading and with Key2reboot function too (based on Tinybit's GRLDR-FAT32 GAS source code - GPL);
  • GRLDR FAT12 /FAT16/ FAT32, ported to NASM from Tinybit's GRLDR-FAT/FAT32 GAS source codes (GPL). With mods like: showing dot's during loading, Key2reboot, AH-output if INT13-error and identification of FAT12/FAT16 based on calculation of total number of clusters;
  • Reactos FAT32 boot code, newest version. Unchanged but fully ported to NASM (GPL);
  • OEMDOS40/70 FAT12/ FAT16 only, slightly changed Freedos' NASM OEMBOOT boot code to solve some problems booting IO.SYS (GPL);
• fresh MBR boot codes, all full NASM code (ealier taken from Linux' ms-sys appeared not to be legit):
  • SYSLINUX to boot most PBR boot codes (unchanged - GPL);
  • FDBOOT from Microsoft's MS-DOS 4.0 MASM source code (MIT), full NASM code - but has been made binary identical;
  • FDBOOT40 based on Microsoft's MS-DOS 4.0 MASM source code (MIT), full NASM code (not binary identical), with F2 => F3 change.

More info, full changelog's, NASM boot code (including all original sources) and how to compile yourself using MrExodia's Github-container on: https://github.com/deomsh/MKFATIMG.G4B

BTW all MS-DOSv4-v6/v7 IO.SYS loaders follow LDOS load protocol's. More info on Peter Szabo's site: https://github.com/pts/bakefat?tab=readme-ov-file#compatibility-and-limitations 

No known load protocol in case of MS-DOSv2/v3: handshake like v6, but al sectors of IBMBIO.COM/ IO.SYS loaded (experimental, and with some 'hack' made compatible with Grubutil 'fat').

I did some tests with use of various alignment-switches to 'pimp' two USB flash-drives on behalf of my legacy USB-project. All USB-drives where partitioned/ formatted with help of VMWare Workstation 17 (very good USB-as-Physical-disk passthrough support!), but total sectors must be known beforehand (use some partition manager to obtain).

Print-screen of some production, MKFATIMG.G4B with use of switch /RDSIZE:16m to produce a partial partition in RAM (rd), add System Files with COPYSYS.G4B and copy with dd the partial partition from grub4dos ram-drive to disk:

Further better alignment of a small no-name USB 2.0 flash-drive with FAT16 (Floppy-emulation). In my project all-important is the USB-Legacy read-speed while copying content of directory ONR to a non-XMS Ramdrive (RLoew). As can be seen on the stopwatch, total time decreased from 7m45s to 4m32s. Most influential seems to be the clustersize here:

Alignment-tests on a (quite bad) Philips 2.0 flash-disk sold as 64GB gave less conclusive results: 64KB clustersize resulted in no real read-speed difference on this drive, all about 2m5s-2m15s. But alignment is still important here to gain more write-speed (even quite bad on Windows 10):

BTW it's funny the benchmarks with Crystal DiskMark and atto-disk-benchmark do not provide the same information as measurable differences on USB Legacy boot. But of course they use the (hopefully) highly optimized Windows 10 USB-drivers. 

Edited April 8 by deomsh
Corrections, additions

[jaclaz]

Well, you did a lot of work, very good .

 

There is something else that may be of use to the old tinkerers, the makebootfat approach to have a disk that is at the same time a floppy and a partitioned disk:

https://www.advancemame.it/doc-makebootfat.html

Also (JFYI) check this:

http://reboot.pro/topic/12436-usbzipls120-booting-with-minimalist-mbr-code-and-grldr/

it may contain something useful.

 

[deomsh]

Hello @jaclaz nice to see you on msfn.

Thanks for taking interest in my project. These legit open-source boot codes are quite a challenging project. I started without any real knowledge of assembly, it took me about six month's to port existing boot codes to NASM and adapt them to my needs.

Thanks for the links.

When I downloaded MINI-MBR.ZIP I got version(1) in my download folder. The original version was from 2018, so maybe you attended me earlier. But I think I can now do more with this approach.

I didn't really go 'into' USB-ZIP so far, although I have one board with Award Bios and USB-ZIP option. My testboards are mainly Asrock, so not the best USB-legacy.

Below 512 MB I am forced to use some Superfloppy format, which is luckily possible with my USB-projects in this thread. But maybe I can check if this MBR/PBR and/ or USB-ZIP approach will have any advantages.

BTW I couldn't incorporate CALEB144 in my presets - I found no exact geometry information. So all I could do was adding a more or less guessed Superfloppy example to the help of MKFATIMG.G4B:

'Example: MKFATIMG.G4B --CHS=144/64/32 /CALEB144.IMG /FDD /V:TRYCALEB144'

Do you have any idea about the 'real geometry' of CALEB144? I did a lot of searching, but without any result!

This is how my example looks like in Virtual Box before booting with Grub4dos:

Edited April 10 by deomsh

[jaclaz]

As I see it 144/64/32 is a good guess, though I don't think that we will ever know if accurate.

I believe the Caleb UHD 144 was never adopted in meaningful numbers, so it is only for completeness.

But then you should add also the previous Insite 20.8 Mb "floptical":

https://wiki.preterhuman.net/Floptical

755/2/27   with sector size selectable between 256, 512 and 1024 bytes.

[deomsh]

Thanks for commenting on Caleb UHD 144.

I supposed Caleb UHD 144 was in MiB with my TRYCALEB144 example, but is it possible it should be read as 144MB, so 144,000,000 bytes?

Thanks for the Floptical-idea, I will add it to my current (rather scarce) superfloppy presets (with floppy-preset switch /F:xxxx). My help mentions currently only two:

'> 2 heads (FAT16): 120m, 240m', with C/H/S=963/8/32 respective 262/32/56.

This weekend I worked on a 'would-be' USBZIP drive with H/S 64/32 and the partition table moved to the fourth slot. But sadly I was mistaken about having a board with an Award BIOS. That one is AMI too, only older: 2005. So still no USBZIP option to test. My two 2011 AMI boards are booting everything below 512 MB as superfloppy to A: - without or even with MBR.  Also doesn't care if first or fourth partition entry is used in case of MBR. Both 32 and 63 Sectors Per Track where taken.

Impossible to get access to the MBR again: after booting Grub4Dos only (fd0) found and hidden sectors all nulled in the BPB (fake - probably - reported by these BIOS's). My AMI 2005 board was doing the same in Auto mode or forced Floppy mode. As an experiment I removed al boot code from the MBR: still forced Floppy boot, unless the Magic Bytes where removed too. In that case no boot at all, which makes sense I suppose.

I also worked with the two boot codes you mentioned earlier, but I am unsure however how my AMI BIOS's 'took' these boot codes on my 'USBZIP'-drive. These where my findings:

1) the Makebootfat MBR I found on Github didn't boot at first my USB-drive with my ealier 128k alignment, but it came out just two bytes had to be changed. After aplying the changes to the binary the EB3C90-MBR booted without problems. It seems the shifting of Peter Alvin's SYSLINUX boot code didn't work out wel, at least not for me. Sources I used from Github where mbrfat.bin and mbrfat.asm (22 years old!): https://github.com/amadvance/makebootfat/blob/master/ BTW No Issues raised on this Github account.

2) the MINI-MBR is a nice idea: if BIOS reports floppy the partition table isn't read out and cylinder 1 (with 64h, 32s) assumed as start of bootcode. Worked in my case as such. BTW link can be found on archive.org only and luckily the files too; reboot.pro is gone (forever??).