If anyone doesn't have a PXE image for their network card and is interested in trying network booting/imaging, the ipxe project (https://www.ipxe.org) has support for a load of PCI (and ISA!) cards which you can use to build a version of ipxe which you can flash to a ROM image:

https://ipxe.org/appnote/hardware_drivers

Usually add-in network cards didn't come with a PXE image, as it cost extra. Modern integrated motherboards of course have it as standard.

(Subtly wonders if he should do a 'diskless win9x machine' writeup or not. Decides to do so.)

It's possible to use a network deployed dos floppy image and a minimal networking stack (like mtcp) to fully netboot a win9x instance.

The boot process more or less goes:

RPL / PXE pulls a 1.44mb floppy image from the fileserver, which is a boot disk for that version of win9x.

The system boots this image. The image contains himem.sys, emm386.exe, xmsdsk, smartdrv.bin, scandisk, attrib, any dos drivers you need, then finally a packet driver for the nic and mtcp. It has a 'full install' version of msdos.sys.

(If you use pxe, then you can use the universal pxe packet driver, which is quite small.)

XMSDSK gets set up to host the OS, and to load at the top of ram with the /t switch. Must be loaded from autoexec.bat to stop windows complaining.

C needs to be ~512mb to 1gb in size.

MTCP is used to pull a smartdrv3 compressed volume file which gets written to the ramdisk. Attrib is used to set the file system and hidden.

Scandisk is called on the volume file with the undocumented /mount syntax.

[Scandisk C: /mount]

after that, you'll have a mounted compressed C drive with a full windows deploy inside, and you just need to start it by calling win.

davidrg wrote on 2025-11-02, 05:48:

Could be PXE, and if so is probably usable to boot something. I think by the time PXE came around, PCs were mostly just being network booted to install an operating system - not to run one. So options are probably a bit more limited than with RPL.

the PC 2001 system design guide (chapter 3) actually makes PXE 2.1 mandatory for machines that are supposed to run windows 2000.

megatron-uk wrote on 2025-11-02, 09:26:

If anyone doesn't have a PXE image for their network card and is interested in trying network booting/imaging, the ipxe project (https://www.ipxe.org) has support for a load of PCI (and ISA!) cards which you can use to build a version of ipxe which you can flash to a ROM image:

https://ipxe.org/appnote/hardware_drivers

Usually add-in network cards didn't come with a PXE image, as it cost extra. Modern integrated motherboards of course have it as standard.

very interesting, although a shame i don't see the common intel 82557 (pro/100b)/82558 (pro/100+) in there. some 82558 cards even look to have soldered EEPROMs instead of a socket, so if those are hotflashable via some software, you wouldn't even need a programmer. i suppose one could hotflash a socketed EEPROM as well, though am not sure if the software would be able to work with every type of EEPROM that one could put in that socket.

of what's listed there i have a 3c509b, so hopefully the 509 listing extends to that. how to know what type of EEPROM will be compatible with the resulting ROM file? guess i could try one of the options mentioned here: XT-IDE BIOS with 3com 3c509B

i'll note that it's not really my preferred card due to the need to set 10mbit HD on the other side - never got 10mbit FD to work for some reason. so with that being said i should clarify that i was really only talking about a OS install via network to a local HDD - assuming C: in the method from the previous post is a network drive i doubt win9x performance will be all that, especially on said 1ombit HD link.

wierd_w wrote on 2025-11-02, 15:28:

(Subtly wonders if he should do a 'diskless win9x machine' writeup or not. Decides to do so.)

Windows 95 actually has built-in support for being network booted and Windows Setup will even generate the boot floppy image for you. You end up with a shared copy of the windows files on the server, with per-machine copies of the registry and a few other bits. The first post in the thread gives some details and has links to a full description of the process.

auron wrote on 2025-11-02, 18:59:

davidrg wrote on 2025-11-02, 05:48:

Could be PXE, and if so is probably usable to boot something. I think by the time PXE came around, PCs were mostly just being network booted to install an operating system - not to run one. So options are probably a bit more limited than with RPL.

the PC 2001 system design guide (chapter 3) actually makes PXE 2.1 mandatory for machines that are supposed to run windows 2000.

Indeed, but the Retail release of Windows 95 was the last version of Windows to actually support being network booted, and it doesn't support doing it from a PCI NIC so that probably rules out PXE. AFAIK in all newer versions of Windows (and any version of Windows NT) PXE is only useful for installing windows from the network to a local hard disk without requiring a CD or floppy to get the process started.

davidrg wrote on 2025-11-02, 05:48:

I think by the time PXE came around, PCs were mostly just being network booted to install an operating system - not to run one. So options are probably a bit more limited than with RPL.

For what it's worth, I've used PXE and NFS to run (not just install) Fedora Core 1 and CentOS 7. It's something Linux has been able to handle for a long time: https://tldp.org/HOWTO/text/NFS-Root Different distributions would have different levels of support for this though, and I think it's always a bit of a hack.

megatron-uk wrote on 2025-11-02, 09:26:

If anyone doesn't have a PXE image for their network card and is interested in trying network booting/imaging, the ipxe project (https://www.ipxe.org) has support for a load of PCI (and ISA!) cards which you can use to build a version of ipxe which you can flash to a ROM image:

There's also Etherboot, which later evolved to become gPXE if I understand correctly. I tend to use Etherboot, and boot it from a floppy. It's not as convenient as having it in ROM, but it only has to load a few dozen kilobytes from the floppy.

wierd_w wrote on 2025-11-02, 15:28:

MTCP is used to pull a smartdrv3 compressed volume file which gets written to the ramdisk. Attrib is used to set the file system and hidden.

Scandisk is called on the volume file with the undocumented /mount syntax.

Thanks for the info! I remember reading about doing this kind of thing before, and always got hung up on the compressed volume part sounding inconvenient to work with. Maybe I'll be more inclined to do this if I actually manage to make it more convenient to work with compressed volume images on Linux eventually! (FYI wierd_w that link is to my post which you've already read)

initially creating the compressed volume file is inconvenient, because you have to work with either a real hard disk initially, or muss about with a virtual machine.

There are no real good tools for messing with a drivespace3 compressed volume file, other than the tools that came with win9x. (95 with plus!, or win98)

It does get around 2:1 compression ratio though, so win95 can fit very comfortably inside 384mb of ramdisk, and win98 can fit quite comfortable inside 512mb of ramdisk. Both will have sufficient freespace left to actually be usable for things. (a 512mb ramdisk can hold a full win98 deploy, IE 5.5 / IE6, and a handful of useful tools, along with the win98 installer files, with about 100mb of reported disk free after turning on superpak and squeezing the bejeebus out of it. Be sure to defragment the drive and the compressed image for maximal economy, before copying the DRVSPACE.000 file to the fileserver. The "you need 2mb of diskspace free on the host volume!!" thing is not actually true. Scandisk will mount the .000 file with 0bytes free on the host after the copy operation. You can be very miserly with the ram.)

The magic things that NEED to be done are:

MSDOS.SYS needs to be the full install version, not the version found on the EBD. (1)
XMSDSK needs to be loaded from the top of memory with the /T switch, and needs to be loaded from AUTOEXEC.BAT(2)
DRVSPACE.000 needs to be marked SYSTEM and HIDDEN with attrib(3)

Things that are very handy to do, include using DRVSPACE.SYS /MOVE to move the drvspace.bin handler from upper memory (where it gobbles down 64k of it! YEUCH!) into the XMS memory instead, and generally having a well considered upper memory layout/load order.

Windows runs absurdly fast from a ramdisk, even with compression turned on.

(1) If you compare these, you will find that they are quite different, and that the full install version contains data for what drive windows should be found on, among other things. These need to be configured correctly for your setup.

(2) Windows will have a hard time setting up the VMM if it cannot get enough actual RAM below 2gb address space. Ideally, you want a machine that has 2gb of physical RAM, where the top 1gb is used for this ramdisk, the bottom 1gb is used for win9x, and the address space above 2gb is free for use by the VMM subsystem. Windows gets "Uppity" about disk devices using drivers loaded from config.sys, and will throw up a very ugly "DRIVE %FOO% IS USING MS-DOS COMPATIBILITY MODE" warning on every boot if this is the case. This is avoided by loading XMSDSK from Autoexec.bat instead, per XMSDSK's literature. I have tested this myself, and yes-- this is indeed the case.

(3) Scandisk will *NOT* mount the DRVSPACE.000 file if it is NOT SYSTEM and HIDDEN. Copying the file from the share is hard if those are already set, so its better to just copy it, then set the flags programmatically with attrib first.