Virtual Superfloppy Configurations

Original work by Micho Durdevich

Introduction
The aim of this fifth article is present the design of a new interesting class of diskless Win95/98/Me workstations, that remote boot from OS/2 Warp Server.

The basic idea is to boot Windows directly from a virtual superfloppy! The construction of such superfloppy images has been explained in the previous article. As we saw, the basic design of OS/2 Warp Server RIPL system for DOS requesters limits the size of a superfloppy image to approx 16MB (because in this context the maximal number of cylinders is 256, and a floppy-like device should have maximum two heads-add to this the fact that the maximal # of sectors per track is 63).

Hence, a very interesting and challenging problem appears: Build a micro-Windows version (the nucleus) that has full GUI and 32-bit networking and fits into 16MB!

As in our previous nucleus-type configurations, the (non-essential) extensions of the operating system, together with the corresponding applications, are all stored on the OS/2 server and become available to the RIPL client, after making the appropriate network drive connections in 32-bit mode. The main problem here is to separate the nucleus (the part that must stay on the superfloppy) from the rest of the operating system. However there are several simple methods of doing this...

The configurations that we are going to describe have the following basic properties: In the next section we shall discuss basic techniques to split Windows into the nucleus (to be installed on the virtual superfloppy) and the extension (to be installed on the OS/2 server). In particular, we shall see which Registry entries control the form of the nucleus.
 * There is no any 16-bit networking running, except the basic connections initiated during the initial RIPL processing.
 * The virtual boot drive [A:] remains 16-bit all the time.
 * Simplicity: No nucleus transfers, unzipping, 16-bit logins, VFAT adjustments...
 * Better memory usage (no big RAM drives).
 * Comparing with the previous nucleus-type configurations, they boot faster.
 * Long filenames support (even on the virtual floppy).
 * Full 32-bit networking support.
 * Easier installation and RIPL client management.

We shall then consider some variations of the basic theme, presenting RIPL configurations that are automatically "client-oriented". This can be done using a powerful filtering mechanism built into OS/2 Warp Server RIPL subsystem. In the first appendix we present listings of CONFIG.SYS, AUTOEXEC.BAT, MSDOS.SYS and 16START.BAT files for such clients.

Finally, a detailed file-by-file specification of a Win95 nucleus (suitable for IBM Network Station 2800) is given in the second appendix. Similar considerations apply to Win98 workstations. On the other hand, Windows Millennium Edition systems require some very special steps, that will be discussed in the next article.

Minimising Procedure
Perhaps the most direct method is the safest and the most instructive one: Construct the nucleus from scratch! We can start from a standard HD install, containing all the features we need (including networking). Make a backup copy of the entire WINDOWS folder. In order to remove unnecessary Windows parts, open a DOS Window and proceed with deleting (using DEL *) all files in WINDOWS directory and SYSTEM directory. This will actually delete all files, except those that are locked by the system. Such a procedure would give us a 0-approximation of the nucleus, we will have to put some files back. In particular some or all CPL-files (representing Control Panel object) should be copied back.

Reboot the system. Because of the missing files, the system will not boot, ha-ha-hahaha :) But hopefully, error messages will tell us which files are missing! Put them back from the backup copy. In such a way we should be able to get the standard GUI showing up.

Get a beautiful FILEMON program from SysInternals. This utility monitors in real time all the files the access to which is requested by various processes in the system. It is worth noting that there is a nice companion program REGMON, which monitors the Registry functions. With the help of FILEMON, figure out which files are needed for the basic system components (trying to open the objects, and inspecting the FILEMON log) to work.

In some cases FILEMON will not show all files there are really needed. Binary-read the initial files and find out which DLLs/VXDs are needed.

After having a lot of fun, you should end up with a clean smoothly working Windows. You can remove some files from the COMMAND subfolder, some or all *.INF files from INF subfolder, and also files from the HELP subfolder. Optionally, you can put back some background bitmaps, screen saver files and so on, but the entire Windows nucleus should not exceed 14MB. This is because it is a good idea to leave some space on the 16MB-superfloppy (approx 2MB) for the appropriate extra stuff, like some important diagnostic tools.

Registry Editing/Recompile
At first, simplify the system Registry, by removing unnecessary stuff. Export the registry into a text-file, change all occurrences of the Windows boot drive (normally its the C-drive) into references to the A-drive. Compile the new file (from DOS) creating a new Registry (don't overwrite the initial registry)! The syntax for the recompilation procedure has been explained in the third article.

Furthermore, we have to remove some entries from the lists of 16-bit/32-bit known DLLs. If a DLL is "known" to Windows, the operating system looks only into the system subfolder when a corresponding access request is made. In contrary, if a DLL is "not known" Windows will look in all directories listed in the path statement of AUTOEXEC.BAT file. Hence, a simple removal from the corresponding known DLLs list, allows us to move a DLL to a different folder. Of course, in our case such non-essential Windows DLLs will be stored on the OS/2 Warp Server.

The corresponding Registry entries are: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs for important 32-bit DLLs and similarly HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\Known16DLLs for important 16-bit DLLs. For example, the entire Object Linking and Embedding stuff (the files OLE*.DLL) can be safely removed from the nucleus and stored on the OS/2 server.

Creating Superfloppy Images
The structure of the superfloppy image file has been explained in our previous article. Let us recall here that the most subtle part of this game consists in editing the BIOS Parameter Block of the image file, and adding the appropriate 4-byte string at the beginning of the image (necessary for RPLLOADR.COM to start booting the client properly).

Here we shall focus on what to put into the image. The simplest way to put files on the image is to create a RAM-drive of the same size as the superfloppy (using for example SRDISK). This should be done within a standard Windows workstation. Later on, we should linearly map this drive to an image file (using HDCOPY for example) and finally we should edit the BPB and add the corresponding 4-byte string, to make the disk RIPL-deployable.

Copy the entire Windows folder of the previously created nucleus, except the files SHELLICONCACHE, TTFCACHE, SYSTEM.DAT/0, USER.DAT/0, WIN.INI, SYSTEM.INI to the RAM-drive representing the superfloppy. Note that in order to preserve long filenames, copying of the Windows nucleus should be performed within a Windows system.

Create a special folder (say C_INIT) in the RAM-drive, and put there WIN.COM, WIN.INI and SYSTEM.INI, as well as recompiled SYSTEM.DAT and USER.DAT (with all attributes stripped off). Edit SYSTEM.INI and make sure that something like PagingFile=C:\WIN386.SWP is included in the [386Enh] section.

Furthermore, include the appropriate RAM-drive software. Create the appropriate CONFIG.SYS and AUTOEXEC.BAT files. Make elementary adjustments to MSDOS.SYS. During DOS-mode booting, the RIPL client should create a small RAM-drive [C:], together with a WINDOWS folder where all the files from C_INIT should be copied.

Windows Extensions on the OS/2 Server
As we emphasized several times, non-essential extensions of Windows should be stored on the OS/2 server, in a normal form. There are several very simple ways to tell Windows where to look for these extra files.

As the first solution, we could configure the client to make an automatic redirection in 32-bit mode, so that after Windows boots, it sees a redirected drive [D:] with a subfolder say WIN95, containing the extensions. In AUTOEXEC.BAT we should append D:\WIN95 at the end od the path statement.

There is a second method which is perhaps conceptually clearer: Copy the entire Windows tree (a full-blown version, without client-specific files including Registry) to the appropriate folder in the OS/2 server. Construct a full-blown client-specific registry (starting from a client with a HD, say) edit it to point to the new drive location, and configure the RIPL client to merge this Registry into the Nucleus Registry, as a part of the StartUp folder processing (see below about the clientization procedures).

Controlling Boot Drive Letter
There is a simple way to control the main Windows drive letter of our RIPL requesters. Standardly, they would boot from [A:]. But if we execute SUBST F: A:\ then we get a new drive [F:], which is a mirror of [A:]. We can adjust the system Registry, as well as MSDOS.SYS and AUTOEXEC.BAT so that the system will boot off [F:].

The advantage of doing this is that we can use the same drive letter for Windows boot drive of a RIPL workstation, and for an auxiliary RAM-drive used to prepare the superfloppy image (on Windows development machine). This is particularly useful when creating the Desktop folder, and various shortcuts from the Start Menu, as we can do it directly from the Windows development machine, without having to binary-edit shortcut files.

Interestingly, various experiments in my computer lab have indicated that the performance of RIPL clients with substituted boot drive letters has been slightly improved! Probably, Windows uses different routines to access drives with a non-floppy drive letter (even if they operate in 16-bit mode).

Enabling Client-Specific Configurations
The superfloppy image we described so far contains one fixed burned-in registry, so it is not suitable for user customizations and different clients. This can be fixed by transferring a client-specific registry from the server, during the boot phase.

We can take advantage of a filtering mechanism built into the OS/2 server RIPL service. The server interprets (for RIPL clients) certain strings on the superfloppy image file in a very special way.

The critical strings are of the form 01:18, 23 April 2006 (CEST)m where the hexadecimal digit m refers to the workstation record in the RPL.MAP file (which is the main configuration file for the OS/2 Warp Server RIPL subsystem). In addition, if the replacement string has more than 6 characters, we should add the appropriate amount of tilde characters in the string. The minimum number of tilde characters is 5, in order to invoke the filtering mechanism.

For example, a line of the following form is standardly present in AUTOEXEC.BAT of all DOS requesters: LOADHIGH CONNECT Now, suppose that the server name is AURORA, the domain name IMATH and the workstation name DOS98, then the above line will appear to the client simply as LOADHIGH CONNECT Z AURORA DOS98 IMATH Using this, it is easy to set up a RIPL client that connects to the OS/2 Warp server, and copies the registry from the principal client-specific directory IBMLAN\RPLUSER\MACHINENAME. The simplest 16-bit solution involves starting IBM 16-bit networking and making automatic redirections [Y:]=\\SERVERNAME\WRKFILES=RPLUSER_Folder, [Z:]=\\SERVERNAME\IBMLAN$=IBMLAN_Folder. The registry is copied during DOS boot processing.

It is also possible, although a bit trickier, to set up the superfloppy so the system connects to the OS/2 server in 32-bit mode (using M$ networking), automatically makes the appropriate redirections, and merges the client-specific portion of the registry, during StartUp folder processing (the last part of Windows boot process). However, this requires recompiling the burned-in registry with appropriate special strings introduced.

Appendix A: Basic Configuration Files

 * msdos.sys file

We shall define here 2 start-up configurations: The internal one (loading a predefined registry burned into the superfloppy) and the standard one (requiring the IBM 16-bit networking stuff, a part of which is the driver DLSHELP.SYS).
 * config.sys file

The echo-messages are visible only if we turn off the animated Win95 Logo. For simplicity, we have not included conditional error-checking commands, assuming everything works perfectly. The system automatically loads Windows GUI (because of WIN at the end of the file). Alternatively, we can put BootGUI=1 in MSDOS.SYS, however such configurations show a slight instability. This is probably because Windows pre-assumes some standard properties of its boot drive, in case it thinks that GUI should be loaded. Indeed, with BootGUI=1 and without BootWarn=0, Windows will present a weird error message!
 * autoexec.bat file

This file starts the 16-bit networking in order to copy the client-specific files to the RAM-drive [C:].
 * 16start.bat file

Appendix B: Windows Nucleus Listing
This listing corresponds to Win95 superfloppy nucleus running on IBM Network Station 2800 with a built-in IBM EtherJet adapter.

Windows Folder
COMMAND.COM    CONTROL.EXE     REGEDIT.EXE     PROTMAN.EXE    EXPLORER.EXE WIN.COM                                    PROTMAN.DOS     TASKMAN.EXE WINPOPUP.EXE                                        NET.EXE      RUNDLL.EXE WINSOCK.DLL                                        NET.MSG MORICONS.DLL                                       NETH.MSG    RUNDLL32.EXE
 * Executables & Related

TRIANGLES.BMP    CIRCLES.BMP      IFSHLP.SYS       LOGOW.SYS WAVES.BMP      SETUP.BMP       HIMEM.SYS       LOGOS.SYS BUBBLES.BMP                RAINFORREST.BMP     OS2WARP.SCR
 * Miscellaneous

[Start Menu]      [COMMAND]        [SYSTEM]           [INF]         [FONTS] In total, about 1600 Kbytes!
 * Relevant Subfolders

The Command Subfolder
DISPLAY.SYS    XCOPY32.EXE      ATTRIB.EXE    SCANDISK.EXE CHOICE.COM    COUNTRY.SYS       DEBUG.EXE      CHKDSK.EXE    DISKCOPY.COM XCOPY.EXE     DOSKEY.COM        EDIT.COM        EDIT.HLP     EXTRACT.EXE FC.EXE       FIND.EXE        ANSY.SYS        KEYB.COM       LABEL.EXE MEM.EXE        SYS.COM        MOVE.EXE       SUBST.EXE        SORT.EXE START.EXE       MORE.COM      FORMAT.COM     DELTREE.EXE Many of these files are really not mandatory... but anyway all this takes only about 720 Kbytes of disk space!

The System Subfolder
KERNEL32.DLL    KRNL386.DLL     MSMOUSE.VXD      SETUPX.DLL SHELL32.DLL      SHELL.EXE       MFC30.DLL      SETUP4.DLL USER32.DLL       USER.EXE    MSVCRT20.DLL       VMM32.VXD GDI32.DLL        GDI.EXE                         VFD.VXD ADVAPI32.DLL    COMMDLG.DLL                     SPOOL32.EXE COMDLG32.DLL   IOSCLASS.DLL                     SPOOLSS.DLL COMCTL32.DLL   COMMCTRL.DLL                     SYSTRAY.EXE MSGSRV32.DLL
 * Critical System Files

LZEXPAND.DLL   DESKCP16.DLL    LINKINFO.DLL    SYSCLASS.DLL     SYNCENG.DLL LZ32.DLL   TOOLHELP.DLL         VER.DLL       WINMM.DLL      SYNCUI.DLL PIFMGR.DLL     DIBENG.DLL     VERSION.DLL         URL.DLL     SHLWAPI.DLL TOOLHELP.DLL   MMSYSTEM.DLL    SYSTHUNK.DLL       DDEML.DLL    CONAGENT.EXE
 * Extra DLLs

The following listing corresponds to a simple configuration, consisting of M$ networking, NETBIOS protocol and the network adapter files. Some of the network files are located in the main Windows folder. The last column contains the files associated to the IBM EtherJet adapter... NETAPI32.DLL     NETAPI.DLL     NETBIOS.DLL     NETBEUI.VXD    IBMFENT5.SYS MSNET32.DLL      NETDI.DLL     NETMGMT.VXD      VREDIR.VXD       IBMDD.VXD MSNP32.DLL      NETOS.DLL      SVRAPI.DLL        NDIS.VXD       IBMFE.SYS MAPI32.DLL        MPR.DLL       WSOCK.VXD     VNETSUP.VXD     IBMKDDP.VXD MSAB32.DLL       MSSP.VXD       PMSPL.DLL    NDIS2SUP.VXD     IBMSETP.CNT MSPP32.DLL     MPREXE.EXE      WSASRV.EXE MSPWL32.DLL    MPRSERV.DLL     MSSHRUI.DLL SECUR32.DLL   CHOOSUSR.DLL                    VNETBIOS.VXD    8255XNDI.DLL
 * Network-Oriented Stuff

VGA.DRV      MOUSE.DRV     MMSOUND.DRV    KEYBOARD.DRV COMM.DRV   SUPERVGA.DRV    WINSPOOL.DRV      SYSTEM.DRV       POWER.DRV
 * DRV-files

SYSDM.CPL       DESK.CPL        INTL.CPL        MAIN.CPL      NETCPL.CPL TIMEDATE.CPL      MODEM.CPL      APPWIZ.CPL    PASSWORD.CPL     INETCPL.CPL
 * Control Panel

CP_437.NLS     LOCALE.NLS     UNICODE.NLS     CP_1252.NLS     VGAFULL.3GR WINOA386.MOD In total, about 10 MBytes of superfloppy space!
 * Miscellaneous

IFSMGR.VXD        IOS.VXD About 250 Kbytes :)
 * Subfolder system\vmm32

BIGMEM.DRV    AIC78XX.MPD     DISKTSD.VXD CDTSD.VXD      CDVSD.VXD      AMSINT.MPD     DISKVSD.VXD    VOLTRACK.VXD NECATAPI.VXD       APIX.VXD 	     CDFS.VXD     NCRC710.MPD     NCRC810.MPD ESDI_506.PDR     HSFLOP.PDR  	      RMM.PDR    SCSIPORT.PDR    ATAPCHNG.VXD SCSI1HLP.VXD	 SMARTVSD.VXD	 TORISAN3.VXD In total, about 400 Kbytes!
 * Subfolder system\iosubsys