View source for Remote Boot of Win95 from OS/2 Warp Server

Original work by [[Micho Durdevich]]

== Introduction ==
This is the first of a series of articles devoted to the integration of Microsoft Windows operating systems within OS/2 Warp Server/Client working environments.

In this article we shall explain in detail how to set up a remote boot diskless workstation to load Windows 95 (together with the appropriate applications) directly from an OS/2 Warp Server. The results that will be presented here open an exciting new possibility to extend IBM's and Serenity Systems' OS/2-oriented managed client philosophy to Windows platforms.

In other words, we are going to set up RIPL (Remote Initialization and Program Load) for Windows clients. In this article, we shall describe the simplest and perhaps the most straightforward procedure. The first real-mode phase of Win95 boot process is essentially a plain DOS. The transition to a protected-mode regime occurs during the second boot phase, when GUI is loaded. Accordingly, our Win95 clients will be understood, from the Warp-Server-RIPL viewpoint, as DOS clients. Such DOS clients will be configured appropriately, so they will be able to RIPL a full-blown version of Windows 95.

It should be noted however, that this is not a documented feature of Windows nor OS/2 Server. And it is not free of problems (but all the problems I know about are really not serious). Windows 95 Resource Kit contains detailed instructions how to enable remote boot of Win95 clients, but for specific non-OS/2 servers (as Novell Netware or NT). Some of these ideas are used here in a modified form.

Our solutions essentially differ from IBM's WorkSpace On-Demand Feature for Windows, which also extensively uses the Warp Server RIPL subsystem. 
The main difference is that in our case the whole Windows operating system resides on the server, and so the client workstations can be diskless.

In contrast, the WorkSpace On-Demand solution requires that the client Windows operating system (Win9x/ME or WinNT/2000) be installed locally, on the client workstation (which obviously must have a hard disk for this purpose!).
The mentioned installation process (which is server-driven and unattended) is relatively lengthy, and requires several reboots of the client. If the client fails, it is necessary to repeat the whole lengthy procedure again...
In this environment the RIPL is used:
#During the client installation process, to load the operating system install image and other basic software from the server, and locally initiate the OS installation process.  
#Subsequently (during normal operations) only to load from the server a small "hybrid boot image" program which will read the first sector of the local hard disk and enable local booting of the corresponding Windows OS.

The article is organized as follows:

In the next section we shall present the main procedure for setting up a Win95 client and Win95 image on the server. After this we shall talk about problems with such Win95 installations, and it will be explained how to solve (some of) them.

==Windows 95 RIPL Setup==
To simplify considerations, we shall consider only one Windows 95 RIPL-client.

The procedure has 8 important steps!

'''Step 1.''' Set up an OS/2 Warp Server machine (I used Aurora-beta), and enable RIPL support (for DOS and OS/2). This is a relatively complex procedure but it is a standard OS/2 Warp Server stuff.

'''Step 2.''' Physically build a client workstation. You will need a network adapter that supports RIPL (I used 3Com EtherLink 905C-TX-M) and the system BIOS should support booting from networks. For the moment, install a hard disk on the client!

'''Step 3.''' Install Windows 95 on the client. Do a normal install, without networking. I used the very first upgrade version, 3.5-inch floppy disks. I have also played with Win95B, with very similar results...

'''Step 4.''' On the server side, set up a DOS remote boot requester, which will boot from a special floppy disk image. This is a standard procedure, well documented in Warp Server online books. The boot disk image should be created from a bootable Windows 95 floppy. Make sure the disk contains the following files:

'''Win_95Set ={'''IO.SYS, MSDOS.SYS, COMMAND.COM, IFSHLP.SYS, HIMEM.SYS'''}'''

'''Aurora_Set ={'''DLSHELP.SYS, NETWORK.INI, NET.EXE, NET.MSG, NETH.MSG, CONNECT.EXE, CONFIG.SYS AUTOEXEC.BAT'''}'''

Add the line 
 DEVICE=IFSHLP.SYS
in the CONFIG.SYS file.

Make sure that the system smoothly remote-boots to DOS. After some initial RIPL processing messages you should see the "Starting Windows 95" message, following by processing config.sys and autoexec.bat files. You should end up with a DOS prompt (pointing to the disk image) and the system should make the following standard network identifications:
 [Z:] = \\SERVERNAME\IBMLAN$
 [Y:] = \\SERVERNAME\WRKFILES

'''Step 5.''' Choose a directory on the server (on a JFS, HPFS or HPFS368 partition) that will serve as the Windows 95 remote [C:] drive.
Copy the entire client's Windows 95 tree from the client to this directory. Do the same with the client's Program Files directory. For example, you can use WinZip on the client and Info-ZIP unzip on the server. Make sure you copied all files, including read-only, system and hidden. On the server side, define and enable a sharing alias for the above-mentioned directory (for example \\SERVERNAME\W95).

'''Step 6.''' This is crucial. Find and copy the program setmdir.exe, from Windows 95 
installation cabs to the remote-[C:] directory. This program allows us to manually set up Registry path for Windows 95, before GUI loads.

'''Step 7.''' Remote boot Windows 95 :) When the client boots to DOS95, go to Z:\DOSLAN\NET
and execute
 NET USE C: \\SERVERNAME\W95
This will disconnect the physical drive [C:] and reinterpret [C:] as the desired network drive. Now, from the new [C:] execute
 SETMDIR /R:C:\WINDOWS
If everything is OK, you should get a confirmation that the Registry pointer has been set up to C:\WINDOWS\SYSTEM.DAT.

Keep your fingers crossed. Repeat in your mind 6 times something appropriate that OS/2 will like for sure (remember, there exist exactly 6 Platonic polyhedra in the 4-dimensional Euclidean space, in all higher dimensions there are only 3!).

Then execute WIN.

'''Step 8.''' Check how your system works and do some manual adjustments. At this point (during the first boot) you could get an error message saying that the master boot record has been modified (check also in Control Panel→System→Performance) and that the drives use MS-DOS compatibility mode (after all, this is expected!). Your new system will not recognize/see VFAT long filenames, so you will need to change (from the server side) the long filenames to something standard (for example, change the files/directories including "Program Files" and screen saver filenames).
Also, it will be necessary to edit Registry settings, to reflect the new file/directory names (this can be also done before copying the windows/program file trees). In such a way, you should get more or less the same Win95 system as initially, with a difference that some icons may not display properly, being converted to generic Windows icons. More about solving this interesting problem in the next section.

Finally, you can physically disconnect the hard disk from the client workstation. 
My system boots a little faster in this case. Interestingly, it takes a very long time to shutdown or restart (the "Please Wait While Your Computer Shuts Down" screen remains for about 6 minutes on my machine).
Of course, the whole Win95 RIPL could be automated, putting the appropriate instructions into AUTOEXEC.BAT.
Overall, I think that described Windows 95 RIPL clients show reasonably good performance...

==Problems and Solutions==
The fact that the system does not recognize long filenames is not surprising. 
We have used a real-mode DOS-compatible software to map the system drives. Therefore, the filesystem is DOS-compatible, from the very beginning. One solution for long filenames is to use the Microsoft protected-mode network client, when re/connecting to the relevant drives. However, this requires setting up a protected-mode networking.
Such configurations are possible and will be discussed in a separate article.

It is worth noticing that some of the programs "demanding" long file names can be made very friendly by simple binary edit of the executable/dlls and/or renaming the offending files.

The Performance Tab of System Properties shows (besides above mentioned boot sector change and real-mode disk access notifications) that the virtual memory is using the DOS-compatibility mode. This is actually not a problem, it appears to be normal for RIPL workstations (the same happens with workstations RIPLed from NT-servers).

Note that the system initially boots to its "virtual disk" [A:] represented by the above mentioned floppy disk image. However, after the Windows GUI loads, Windows will forget about it, and point to its standard floppy drive (assuming there is a floppy controller installed and enabled)! On the other hand, this does not happen when Windows is RIPLed in a safe mode. In other words, we have assumed here that the standard RPLTERM.EXE utility (to disconnect from the virtual boot floppy disk, found in Z:\DOSLAN\NET) has not been used at all! 
It does not hurt to execute RPLTERM before WIN, and in this way Windows will boot properly in the safe mode too.

Sometimes the client freezes when an application is launched from a DOS window. 
It seems that this does not happen when the same programs are launched from "Run" window or Windows Explorer.

To solve the icons problem: At first, define the maximal icon cache by introducing a new string value "Max Cached Icons" (include the quotations!) and setting it to 2048.
The value should be within
 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer.

Next remove (from DOS) the hidden SHELLICONCACHE file from the WINDOWS folder (in our case it will be truncated to SHELLICO).

If the above two steps do not cure the problem, manually edit the Registry and find icon references. They are mostly related to SHELL32.DLL file and icons are referenced as "C:\WINDOWS\SYSTEM\SHELL32.DLL,n" where "n" is the icon number within the SHELL32 library. In many cases, it is the "DefaultIcon" key.
Make sure the icons are NOT referenced as "C:\WINDOWS\SYSTEM\SHELL32.DLL,-m". If yes, change the referencing model to the first format. Also, if you have a problem with the icons stored in EXPLORER.EXE change the Registry references to the similar icons in SHELL32.DLL. For example, "My Computer" icon originally comes from EXPLORER.EXE. This particular icon is referenced within
 HKEY_CLASSES_ROOT\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}
and you can change it to any other icon.

After all these adjustments, delete again (from DOS) the SHELLICO file. If the icons are still not showing up properly, force the system to re-read the icons info by changing the icon size by few points and then going back (Desktop->Properties->Appearance->Item=Icon).

Our next article presents a couple of more complex RIPL configurations...

[[Category:Networking Articles]]