Virtual Superfloppy Configurations

Original work by Micho Durdevich

Introduction

The aim of this fifth article is to 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 16 MB (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 16 MB!

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:

• 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.

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.

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.

Constructing Windows Nucleus

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 14 MB. This is because it is a good idea to leave some space on the 16MB-superfloppy (approx 2 MB) 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 it's 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 of 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 an 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).

Interesting Variations

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

[Paths]
WinBootDir=C:\WINDOWS
WinDir=F:\WINDOWS
HostWinBootDrv=F

[Options]
BootGUI=0
Network=1
Logo=1
Autoscan=0
;BootWarn=0

config.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).

[Menu]
menuitem=1, Local Maintenance Mode
menuitem=2, IBM 16-bit Networking+RIPL
menucolor=15,1
menudefault=2, 8

[1]
DEVICE=A:\WINDOWS\HIMEM.SYS
DOS=HIGH,UMB
DEVICEHIGH=A:\WINDOWS\IFSHLP.SYS

[2]
DEVICE=A:\WINDOWS\HIMEM.SYS
DOS=HIGH,UMB
DEVICEHIGH=A:\WINDOWS\IFSHLP.SYS
DEVICEHIGH=A:\16IBM\DLSHELP.SYS
LASTDRIVE=Z

autoexec.bat 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!

@echo off
echo * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
echo *            Netvista 2800 Diskless Win95 Client            *
echo *              Superfloppy Configuration V0.8A              *
echo *                                                           * 
echo *                    by Micho Durdevich                     *
echo *                 Institute of Mathematics                  *
echo *          National Autonomous University of Mexico         *
echo *   http://www.matem.unam.mx/~micho, micho@matem.unam.mx    *
echo *                                                           *
echo *  All this is based on OS/2 Warp Server RIPL Subsystem!!!  *
echo * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

echo Constructing a RAM-drive [C:]...
xmsdsk 8192 c: /Y
mkdir c:\windows
mkdir c:\junk
copy a:\windows\explorer.exe c:\windows >nul
copy a:\windows\command.com  c:\windows >nul

goto %config%

:1
echo Internal Configuration Files...
copy c_init\*.* c:\windows >nul
echo Final Adjustments...
set comspec=c:\windows\command.com
subst f: a:\
set path=c:\windows;f:\windows;f:\windows\command
set temp=c:\junk
set tmp=c:\junk
attrib +h +r +s c:\windows\*.dat
goto end

:2
cd 16ibm
call 16start.bat
cd\
echo Configuration Files and Final Adjustments...
copy Y:*.* c:\windows >nul
set comspec=c:\windows\command.com
subst f: a:\
set path=c:\windows;f:\windows;f:\windows\command;d:\win95
set temp=c:\junk
set tmp=c:\junk
set mathematica_preferences=d:
attrib +h +r +s c:\windows\*.dat
goto end

:end
echo OK!!! I think I am now ready to load Windows :)
win

16start.bat file

@echo Starting IBM 16-bit Networking...
LOADHIGH NET START

@echo Connecting to the RIPL Server...
LOADHIGH connect

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

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

Executables & Related

  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

Miscellaneous

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

Relevant Subfolders

[Start Menu]       [COMMAND]        [SYSTEM]           [INF]         [FONTS]

In total, about 1600 Kbytes!

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

Critical System Files

  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

Extra DLLs

 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 

Network-Oriented Stuff

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

DRV-files

     VGA.DRV       MOUSE.DRV     MMSOUND.DRV    KEYBOARD.DRV
    COMM.DRV    SUPERVGA.DRV    WINSPOOL.DRV      SYSTEM.DRV       POWER.DRV

Control Panel

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

Miscellaneous

  CP_437.NLS      LOCALE.NLS     UNICODE.NLS     CP_1252.NLS     VGAFULL.3GR
WINOA386.MOD

In total, about 10 MBytes of superfloppy space!

Subfolder system\vmm32

IFSMGR.VXD         IOS.VXD

About 250 Kbytes :)

Subfolder system\iosubsys

   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!