RIPLing Windows: Some Technical Issues

From EDM2
Jump to: navigation, search

Original Work by Micho Durdevich


This article builds on the material presented in the previous notes. Here, our aim is to address certain important technical issues, naturally appearing in the study of diskless Windows workstations remote booting from OS/2 Warp Server.

We shall see:

  • How to uniformize the client architecture, using only Microsoft redirection software (both 16-bit and 32-bit). This plays an important role in considerations involving various network protocols. In particular, it will be explained how to create a mini-registry file, suitable for DOS-mode networking. We also provide a "blueprint" mini-registry, suitable for editing and compiling...
  • How to enable long filenames for RIPL workstations (the simplest method);
  • A couple of tips and tricks, having an independent interest.

This article is organized as follows.

At first, we shall consider workstations starting from a local floppy disk, and explain how to set up the DOS-mode Microsoft networking. The most subtle part of this procedure consists in creating a mini-registry file which contains the appropriate network information. As we shall see, there is a funny way to trick the Setup program, to do the main job for us.

Next, we consider "true RIPL" workstations, booting from a virtual floppy disk image on the OS/2 Warp server. This requires a small modification of the "real boot floppy" configuration.

We shall then pass to issues involving networking and long filenames. Finally, in the last section some additional remarks and tricks are collected.

All considerations are applicable to both Win95 and Win98 RIPL configurations, except the method of tricking the Setup, which works only with Win95. The installation Setup of Win98 is designed from the ground up NOT to recognize remote-boot installations, as the whole Win98 is officially non-RIPLable at all!?!

Using Microsoft 16-bit Redirection Software

Workstations Starting From a Local Floppy

Our main objective here is to make a bootable floppy disk, suitable for RIPL, containing the purely Microsoft redirection software. In other words, this software should be used to connect to the server and map network drives during the DOS boot phase.

The Microsoft version of NET.EXE requires a registry file to read the corresponding network information. Consequently, it is necessary to include a Registry file on the boot floppy. Having in mind that NET.EXE actually needs only a small part of the real Registry, we may create a special mini-registry file, just for this purpose. Of course, we could try to put the full system Registry on the boot flopy, but it is often too big to fit on a single floppy disk (together with other critical files).

In order to create the registry file, we can use the Win95 installation Setup.

(i) Copy the files (from Win95 CD for example)


into an appropriate directory on the server. These files are necessary for the server-based Setup of Win95 to perform the client-specific operations.

(ii) Set up a diskless RIPL DOS-requester (using IBM redirection software provided with Aurora) possessing a real floppy drive. More precisely, the machine should run Win95 in DOS mode. The client should also have a RAM-drive [C:] of say at least 8MB.

(iii) Enable a sharing alias for the above mentioned server directory.

(iv) From the client side, connect to the OS/2 Warp server, make the appropriate network drive identifications, then RPLTERM (to enable the real floppy drive) and execute

SETUP /T:TempFilesPath

This will initiate the Windows installation Setup.

(v) Go through the "Installation Process" and choose minimal components without any special hardware selection (this is just to make the Setup happy, otherwise it could easily crash on any nonstandard point, as discussed in [2]).

If everything goes fine, at the end of the procedure you will be asked to insert a blank floppy in the client floppy disk drive. At this point, if you decide to proceed, you should make sure that a full Win95 installation media is available to the client. The setup will create a bootable floppy, containing Microsoft network software, other critical files, and - most important for us - a raw mini-registry SYSTEM.DAT!!!

Better yet, we can exit the Setup just before the step of creating the boot floppy (at the "Start Copying Files" screen). The mini-registry files will be in C:\WINDOWS directory (under names SYSTEM.NEW and USER.NEW, note that these files will be SHR). Using this, we can easily manually make the boot floppy. Before exiting the Setup, it is not a bad idea to make a backup copy of the temporary files folder. It contains various valuable files that could be useful in other experiments...

An interesting variation of this theme is to use workstations with a hard disk which will hold all client-related files (later on, we can easily move these files to a client location on the server). Client files will go to the C:\WINDOWS directory, and a copy of the boot floppy files would be saved in the SUBOOT subdirectory.

For this to work correctly, we should compose a MSBATCH.INF file containing the following instructions: HDBoot=0, RPLSetup=0, WorkstationSetup=1 and SaveSuBOOT=1 in [Network] section. The last instruction ensures that the boot floppy files are saved in the SUBOOT subdirectory of the main machine directory (C:\WINDOWS in our case).

In principle, we could have defined InstallDir (this [Setup] variable points to the machine-specific directory) as a network directory, however such configurations have problems with OS/2 Warp Server: in all my experiments the setup was crashing! A sample MSBATCH.INF is given in [2] and a detailed documentation on its structure can be found in [1]-Appendix D. The correct setup call remains the same

SETUP /T:TempFilesPath

We should make several subtle adjustments to the boot floppy. At first, we should include the appropriate NIC-driver. Secondly, we should manually edit the PROTOCOL.INI file and introduce the appropriate lines in CONFIG.SYS, AUTOEXEC.BAT and MSDOS.SYS (as explained below).

The raw mini-registry should be further edited (in order to be usable with your NIC-driver and NET.EXE). In order to do this, export it to a text file

REGEDIT /L:system.dat+location /R:user.dat+location /E minireg.reg

edit the corresponding network sections, and then compile to create the new mini-registry:

REGEDIT /L:new-system.dat /R:new-user.dat /C minireg.reg

Interestingly, the mini-registry created by the Setup contains mostly completely unnecessary entries. Funny enough, many of such entries deal with graphical interface... You can safely remove all of them, and keep only DOS/16-bit networking related stuff!

Alternatively, you can have a look at the following sample mini-registry file (suitable for machines with an IBM EtherJet PCI adapter). Before compiling, the file should be appropriately changed to reflect your configuration.










[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Network\Real Mode Net]







This registry file is intended for workstations having a RAM-drive [C:]. After creating the mini-registry, you should carefuly adjust the boot floppy. Make sure it contains the following files:


Furthermore, make sure that CONFIG.SYS contains the line


where the parameter /I: points to the location of PROTOCOL.INI. It is crucial that PROTOCOL.INI contains the correct information.

The program SMARTDRV.EXE greatly reduces the floppy disk activity, and the time necessary to perform necessary DOS-mode tasks.

An interesting technical problem here is that Windows figures out if its own redirection software is loaded prior to GUI (NET.EXE works 16-bit in DOS, and 32-bit in Windows) and then refuses to load: (This is where the program SNAPSHOT.EXE enters the game. It tricks Windows not to recognize when its 16-bit networking is running. Normally, this should be executed before using any DOS redirection:


where XYZ is the amount of memory in kilobytes that should be reserved for the real mode (=DOS) networking.

The second role of SNAPSHOT.EXE is to prepare the system to a dynamical transition from 16-bit to 32-bit networking, that occurs during the GUI initialization. This transition is ashieved by loading a VXD-version of SNAPSHOT from the main Registry (see [1]-Chapter 4). Both SNAPSHOT.EXE and SNAPSHOT.VXD can be found in Windows installation cabs.

Workstations Starting from a Virtual Disk Image

These RIPL configurations are obtained by a simple modification of the previous setup. There is one subtle point here: a possible conflict between the network software on the (virtual) floppy and the software loaded during the boot-block execution phase (loaded from the corresponding CNF-file).

Perhaps the simplest solution here is to:

(i) Create a RAM-drive [C:], and copy NET.EXE, NETH.MSG, NET.MSG, SYSTEM.DAT, PROTMAN.EXE, RPLTERM.EXE, COMMAND.COM and perhaps SNAPSHOT.EXE and SMARTDRV.EXE to it (from AUTOEXEC.BAT, for example). Re-set the variable COMSPEC to C:\COMMAND.COM.

(ii) Execute RPLTERM from [C:] and then connect to the server using NET.EXE.

32-bit Redirection and Long Filenames

As we have already observed, Windows RIPL workstations normally would not recognize long filenames. The explanation of this phenomenon is simple: Our RIPL clients make their drive-mapping connections to the server in a 16-bit DOS mode, and DOS does not know anything about long filenames. The connections stay active all the time, including after the full GUI comes up. So Windows will see the same DOS-picture...

In order to get long filenames, we should use a redirection software supporting long filenames, working within the 32-bit Windows shell. There exist two natural ways to make this work:

(i) Dynamically switch from DOS to Windows (16-bit to 32-bit) mode with the help of SNAPSHOT.VXD.

(ii) Install the Client for Microsoft Networks.

The second approach is much simpler. The basic philosophy is to keep the initial DOS-mode connection for the minimal Windows with networking, and create new network drives using the 32-bit redirection (NET.EXE from a DOS window). Of course in order to do this we should install the Client for Microsoft Networks (this should be done from the RIPL workstation, once it is up and running).

It is important to mention that this method works for RIPL workstations using both Microsoft and IBM (coming with Aurora) 16-bit redirection software.

Concluding Remarks

Sometimes the Windows fails to load, after installing the networking. I have found that loading EMM386.EXE from CONFIG.SYS would always solve the problem. There are many possible parameters, but the following basic variation must be present:


We have assumed here that our workstation starts from a RAM-drive [C:]. The switch /Y tells Windows where to find the copy of EMM386.EXE to be used during GUI initialization (the copy from [A:] would obviously not work, if we executed RPLTERM prior to WIN).

Interestingly, the "confusing Windows" effect (non-figuring out if its redirection software has been loaded) can be ashieved by executing SNAPSHOT, or even SNAPSHOT /M:0 just before WIN (and after making network connections). Of course, this is not at all compatible with configurations loading SNAPSHOT.VXD...

From the practical viewpoint, the most interesting topic is to see which Windows applications can be installed within the RIPL environment. In principle, every normal application should be RIPL-deployable (perhaps after some non-essential modifications).

As an illustration, let us discuss what should be done to make Mathematica V3 from Wolfram Research RIPL-friendly. Mathematica is a highly professional software package designed for almost all kinds of symbolic calculations in modern mathematics.

The first problem is that Mathematica makes an extensive use of long filenames. Thus we should access Mathematica using the 32-bit networking. To install the software on the OS/2 Warp Server, it is sufficient to copy Mathematica tree from an appropriate Windows machine (with a HD).

The second problem is that Mathematica will immediately try, upon execution, to write something in "Progam Files" directory, requiring a lot of long subdirectories/filenames. Normally, this will fail because the principal Windows folders are under the 8.3-filesystem. A simple solution here is to introduce a special undocumented environment variable MATHEMATICA_PREFERENCES and assign to it the appropriate network drive/directory name. For example, we can put


in the client AUTOEXEC.BAT file. Here [X:] is the network drive realized using the 32-bit redirection and RIPLCLIENT is the ID of our RIPL workstation.

Finally, we should change Mathematica kernel parameters (to reflect the new location). In such a way we can share one copy of Mathematica among many users.

Basic Literature

  1. Microsoft Windows 95 Resource Kit, Microsoft Professional Editions.
  2. Joe R Doupnik, Installing Win95 on Netware Servers (read-only) for Diskless Clients, Utah State University, June 1996.