Virtual Superfloppy Configurations
Original work by Micho Durdevich
Contents
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!