Jump to content

RIPLing Windows: Further Variations: Difference between revisions

From EDM2
No edit summary
 
Ak120 (talk | contribs)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Original work by [[Micho Durdevich]]
Original work by [[Micho Durdevich]]


<h2>1. Introduction</h2>
==Introduction==
 
We continue with the study of RIPLing Windows from OS/2 Warp Server. The aim of this note is to present a couple of more sophisticated constructions.
<p>We continue with the study of RIPLing Windows from OS/2 Warp Server. The aim of  
this note is to present a couple of more sophisticated constructions.</p>
   
   
<p>We shall start by considering diskless Win95 workstations with a  
We shall start by considering diskless Win95 workstations with a RAM-drive [C:], that remote boot Win95 from a network drive, say [F:].
RAM-drive [C:], that remote boot Win95 from a network drive, say [F:].</p>
 
<p>We shall then discuss, very briefly, some technical details of
the RIPL setup for Windows 98. Interestingly Win98 (without IE shell integration)
RIPLes better than Win95 (after all, Win98 comes with many subtle improvements,
updated drivers, and so on). In spite of this fact, there is not any official
support for remote-boot configurations from Microsoft.</p>
 
<h2>2. Playing With a RAM Drive</h2>
 
<h3>Motivations</h3>
 
<p>Our RIPL context gives a very specific computing environment. Some of the
benefits of introducing a RAM drive on client workstations are:
 
<ul>
<li>This drive can hold important frequently accessed files,
including the swap file, temporary files etc,
minimalizing the network load. Of course, putting the swap file
on the RAM drive implies that effectively there will be no virtual memory...</li>
<li>We can put the system Registry on the RAM drive (being
copied from the server during the workstation startup). This means that
all the changes on the Registry will not be saved, until we manually
copy SYSTEM.DAT and USER.DAT back to their fixed locations on the
server. By doing this, we increase the system integrity in several
ways.</li>
 
<li>It helps to solve some network disk-access problems for certain
irregularly behaving files. It also plays an important role in setting
up 32-bit networking on RIPL clients (32-bit networking on RIPL clients will
be discussed in our next articles).</li>
</ul></p>
 
<h3>Registry Recompile</h3>
 
<p>The main problem here is how to change the host Windows drive letter
from C (as it was in our first&nbsp;construction) to F. The following simple
procedure solves this:
 
<ol>
<li>Export the whole Registry of the RIPL workstation (built in accordance
with the instructions of the previous&nbsp;article) to a
text file, say X.REG.</li>
<li>Using a text editor, replace all the references to drive C in X.REG,
with the references to drive F.</li>
<li>Re-build, using the DOS-mode regedit, the SYSTEM.DAT and USER.DAT
files from this new X.REG file.</li>
</ol></p>
 
<p><i>As a bonus, the recompiled Registry will be (probably considerably) smaller!</i></p>
 
<p>Furthermore, change (if necessary) C-&gt;F in SYSTEM.INI and WIN.INI. </p>
 
<h3>Setting Up the RAM-disk</h3>
 
<p>This is achieved by copying RAMDRIVE.SYS to (virtual) boot disk [A:] and loading it
during the boot process. For example, a CONFIG.SYS statement
<center><font color=#660000>DEVICEHIGH=A:\RAMDRIVE.SYS 16384 512 128 /E
</font></center><div>would create a RAM-disk [C:] of 16MB, with 512 bytes sector size and 128
root directory entries (here we have assumed that there is not any local
hard disk on the workstation!).</div></p>
 
<h3>Setting Up MSDOS.SYS</h3>
 
<p>We can replace the micro MSDOS.SYS on the boot disk with a "real" Win95
MSDOS.SYS. Make sure that it contains the following line<center>
<font color=#660000>WinBootDir=C:\</font></center>


<div>within the [Paths] section. Also, make sure that LoadGUI=0 and Logo=0 in [Options].</div></p>
We shall then discuss, very briefly, some technical details of the RIPL setup for Windows 98. Interestingly Win98 (without IE shell integration) RIPLes better than Win95 (after all, Win98 comes with many subtle improvements, updated drivers, and so on). In spite of this fact, there is not any official support for remote-boot configurations from Microsoft.


<h3>Setting Up The Initialization Image of [C:]</h3>
==Playing With a RAM Drive==
===Motivations===
Our RIPL context gives a very specific computing environment. Some of the benefits of introducing a RAM drive on client workstations are:
*This drive can hold important frequently accessed files, including the swap file, temporary files etc, minimalizing the network load. Of course, putting the swap file on the RAM drive implies that effectively there will be no virtual memory...
*We can put the system Registry on the RAM drive (being copied from the server during the workstation startup). This means that all the changes on the Registry will not be saved, until we manually copy SYSTEM.DAT and USER.DAT back to their fixed locations on the server. By doing this, we increase the system integrity in several ways.
*It helps to solve some network disk-access problems for certain irregularly behaving files. It also plays an important role in setting up 32-bit networking on RIPL clients (32-bit networking on RIPL clients will be discussed in our next articles).


<p>Create a directory in \\SERVERNAME\W95 to hold the initial files that
===Registry Recompile===
will be copied to the workstation. Let it be say C_INIT. Put the new Registry  
The main problem here is how to change the host Windows drive letter from C (as it was in our first construction) to F. The following simple procedure solves this:
files SYSTEM.DAT and USER.DAT in this directory, together with COMMAND.COM
#Export the whole Registry of the RIPL workstation (built in accordance with the instructions of the previous article) to a text file, say X.REG.
and files you like to go to [C:] before Win95 loads. Ensure all HSR attributes are
#Using a text editor, replace all the references to drive C in X.REG, with the references to drive F.
removed from SYSTEM.DAT and USER.DAT in C_INIT.</p>
#Re-build, using the DOS-mode regedit, the SYSTEM.DAT and USER.DAT files from this new X.REG file.


<h3>Preparing to Load Win95</h3>
''As a bonus, the recompiled Registry will be (probably considerably) smaller!''


<p>Before loading the graphical interface (and after establishing a network
Furthermore, change (if necessary) C→F in SYSTEM.INI and WIN.INI.
identification F &lt;-&gt; \\SERVERNAME\W95) we should execute the
following commands (putting them in the appropriate batch file/AUTOEXEC):</p>


<p>set&nbsp;path=C:\;F:\WINDOWS;F:\WINDOWS\COMMAND<br>
===Setting Up the RAM-disk===
copy&nbsp;F:\C_INIT\*.*&nbsp;C:\<br>
This is achieved by copying RAMDRIVE.SYS to (virtual) boot disk [A:] and loading it during the boot process. For example, a CONFIG.SYS statement
attrib&nbsp;+R&nbsp;+H&nbsp;+S&nbsp;C:\SYSTEM.DAT<br>
DEVICEHIGH=A:\RAMDRIVE.SYS 16384 512 128 /E
attrib&nbsp;+R&nbsp;+H&nbsp;+S&nbsp;C:\USER.DAT<br>
would create a RAM-disk [C:] of 16 MB, with 512 bytes sector size and 128 root directory entries (here we have assumed that there is not any local hard disk on the workstation!).


set&nbsp;comspec=C:\COMMAND.COM<br></p>
===Setting Up MSDOS.SYS===
We can replace the micro MSDOS.SYS on the boot disk with a "real" Win95 MSDOS.SYS. Make sure that it contains the following line
WinBootDir=C:\
within the [Paths] section. Also, make sure that LoadGUI=0 and Logo=0 in [Options].


<p>Re-allocate the swap file, by including the line
===Setting Up The Initialization Image of [C:]===
<center><font color=#660000>pagingfile=C:\WIN386.SWP</font></center>
Create a directory in \\SERVERNAME\W95 to hold the initial files that will be copied to the workstation. Let it be saying C_INIT. Put the new Registry files SYSTEM.DAT and USER.DAT in this directory, together with COMMAND.COM and files you like to go to [C:] before Win95 loads. Ensure all HSR attributes are removed from SYSTEM.DAT and USER.DAT in C_INIT.
<div>in the [386Enh] section of SYSTEM.INI.</div></p>


<h3>Load Win95 GUI</h3>
===Preparing to Load Win95===
Before loading the graphical interface (and after establishing a network identification F ↔ \\SERVERNAME\W95) we should execute the following commands (putting them in the appropriate batch file/AUTOEXEC):
set path=C:\;F:\WINDOWS;F:\WINDOWS\COMMAND
copy F:\C_INIT\*.* C:\
attrib +R +H +S C:\SYSTEM.DAT
attrib +R +H +S C:\USER.DAT
set comspec=C:\COMMAND.COM


<p>Execute WIN. After the GUI comes up, you will probably have a couple
Re-allocate the swap file, by including the line
of broken shortcut links. Manually change the program references from C
pagingfile=C:\WIN386.SWP
(left from the previous RIPL setup) to F.</p>
in the [386Enh] section of SYSTEM.INI.


<p>Note that we have not used the program SETMDIR to define
===Load Win95 GUI===
the Registry location, in contrast to the solution described in
Execute WIN. After the GUI comes up, you will probably have a couple of broken shortcut links. Manually change the program references from C (left from the previous RIPL setup) to F.
the previous article. Instead, the Registry location has been defined in the
MSDOS.SYS file.</p>


Note that we have not used the program SETMDIR to define the Registry location, in contrast to the solution described in the previous article. Instead, the Registry location has been defined in the MSDOS.SYS file.


<p>The problems with long filenames, 32-bit disk access and icons are still
The problems with long filenames, 32-bit disk access and icons are still present in this setup. The icons' problem is solved in the same way as in the previous article.
present in this setup. The icons problem is solved in the same way
as in the previous article.</p>


<p>It is interesting to mention that the RAM-drive setup allows us to avoid changing
It is interesting to mention that the RAM-drive setup allows us to avoid changing the file reference (from EXPLORER.EXE to SHELL32.DLL) for My Computer icon (necessarily changing the standard icon). However, in order to avoid My Computer icon being replaced with a generic Windows icon, it is necessary to include EXPLORER.EXE in C_INIT, in order to ''copy'' it to C before GUI loads, and change the icon path in Registry. We can also re-define the shell pointer in SYSTEM.INI accordingly.
the file reference (from EXPLORER.EXE to SHELL32.DLL) for My Computer icon
(necessarily changing the standard icon). However, in order to avoid My Computer  
icon being replaced with a generic Windows icon, it is necessary to include EXPLORER.EXE  
in C_INIT, in order to <i>copy</i> it to C before GUI loads, and change the icon path  
in Registry. We can also re-define the shell pointer in SYSTEM.INI accordingly.</p>


<h2>3. RIPLing Windows 98-Basic Observations</h2>
==RIPLing Windows 98 - Basic Observations==
Here the principal ideas are the same as for Win95 RIPL (that is, install first on a local hard drive, then copy to server and perform the appropriate manual adjustments) however, there are some subtle differences.


<p>Here the principal ideas are the same as for Win95 RIPL (that is, install first
First of all, it seems that SETMDIR utility (available with Win95 only) does not work correctly with Win98. Hence, it is necessary to apply the above-mentioned alternative method, by defining WinBootDir in the [Paths] section of MSDOS.SYS.
on a local hard drive, then copy to server and perform the appropriate manual adjustments)
however, there are some subtle differences.</p>


<p>First of all, it seems that SETMDIR utility (available with Win95 only) does not
Secondly, Win98 has problems in disconnecting automatically from its virtual boot floppy (unlike Win95). Therefore, it is necessary to execute the IBM RPLTERM utility prior to loading GUI.
work correctly with Win98. Hence, it is necessary to apply the above mentioned
alternative method, by defining WinBootDir in the [Paths] section of MSDOS.SYS.</p>


<p>Secondly, Win98 has problems in disconnecting automatically from its virtual boot  
The standard configuration of Windows 98 (with IE integrated) generates much more network traffic during the boot process and various operations (as expected, because of all this IE extra load). Hence it is very important to re-configure IE stuff properly, replacing the long filenames Registry references (like "Temporary Internet Files") with short counterparts.
floppy (unlike Win95). Therefore, it is necessary to execute the IBM RPLTERM utility
prior to loading GUI.</p>


<p>The standard configuration of Windows 98 (with IE integrated) generates much
In order to speed up the client workstation, it is highly recommendable to remove the IE shell integration from the OS. We refer to [http://www.98lite.net 98LITE] website for more information on IE removal, various "lite" configurations of Win98 and accompanying installation software.
more network traffic during the boot process and various operations (as expected,  
because of all this IE extra load). Hence it is very important to re-configure IE  
stuff properly, replacing the long filenames Registry references (like "Temporary
Internet Files") with short counterparts.</p>


<p>In order to speed up the client workstation, it is highly recommendable to remove the  
Basically, the construction consists in replacing the files EXPLORER.EXE (in WINDOWS directory) as well as SHELL32.DLL and COMDLG32.DLL (in WINDOWS\SYSTEM) with their Win95 counterparts, and some elementary manual adjustments.
IE shell integration from the OS. We refer to <a href="http://www.98lite.net" target="warpnew">98LITE</a> website
In such a way we end up with a considerably faster, cleaner and smoother system, generating much less network load. Furthermore, it would be necessary to replace the NotePad and WordPad, with Win95 versions. In order to save the server disk space, we can completely remove the IE files and clean up the Registry, by removing unnecessary entries and recompiling (remember, workstations starting from their RAM drive [C:] transfer the Registry from the server).
for more informations on IE removal, various "lite" configurations of Win98 and  
accompanying installation software.</p>


<p>Basically, the construction consists in replacing the files EXPLORER.EXE
The problem with a delayed shutdown and reboot ''completely disappeared'' when RIPLing Win98. My diskless workstation smoothly shuts down and reboots, in all possible configurations (with/out IE integration, and with/out the RAM drive [C:]).
(in WINDOWS directory) as well as SHELL32.DLL and COMDLG32.DLL (in WINDOWS\SYSTEM)
with their Win95 counterparts, and some elementary manual adjustments.
In such a way we end up with a considerably faster, cleaner
and smoother system, generating much less network load. Furthermore, it would be necessary
to replace the NotePad and WordPad, with Win95 versions. In order to save the server
disk space, we can completely remove the IE files and clean up the Registry, by removing
unnecessary entries and recompiling (remember, workstations starting from their
RAM drive [C:] transfer the Registry from the server).</p>


<p>The problem with a delayed shutdown and reboot <i>completely disappeared</i>
[[Category:Networking Articles]]
when RIPLing Win98. My diskless workstation smoothly shuts down and reboots, in
all possible configurations (with/out IE integration, and with/out the RAM drive [C:]).</p>

Latest revision as of 10:40, 11 January 2023

Original work by Micho Durdevich

Introduction

We continue with the study of RIPLing Windows from OS/2 Warp Server. The aim of this note is to present a couple of more sophisticated constructions.

We shall start by considering diskless Win95 workstations with a RAM-drive [C:], that remote boot Win95 from a network drive, say [F:].

We shall then discuss, very briefly, some technical details of the RIPL setup for Windows 98. Interestingly Win98 (without IE shell integration) RIPLes better than Win95 (after all, Win98 comes with many subtle improvements, updated drivers, and so on). In spite of this fact, there is not any official support for remote-boot configurations from Microsoft.

Playing With a RAM Drive

Motivations

Our RIPL context gives a very specific computing environment. Some of the benefits of introducing a RAM drive on client workstations are:

  • This drive can hold important frequently accessed files, including the swap file, temporary files etc, minimalizing the network load. Of course, putting the swap file on the RAM drive implies that effectively there will be no virtual memory...
  • We can put the system Registry on the RAM drive (being copied from the server during the workstation startup). This means that all the changes on the Registry will not be saved, until we manually copy SYSTEM.DAT and USER.DAT back to their fixed locations on the server. By doing this, we increase the system integrity in several ways.
  • It helps to solve some network disk-access problems for certain irregularly behaving files. It also plays an important role in setting up 32-bit networking on RIPL clients (32-bit networking on RIPL clients will be discussed in our next articles).

Registry Recompile

The main problem here is how to change the host Windows drive letter from C (as it was in our first construction) to F. The following simple procedure solves this:

  1. Export the whole Registry of the RIPL workstation (built in accordance with the instructions of the previous article) to a text file, say X.REG.
  2. Using a text editor, replace all the references to drive C in X.REG, with the references to drive F.
  3. Re-build, using the DOS-mode regedit, the SYSTEM.DAT and USER.DAT files from this new X.REG file.

As a bonus, the recompiled Registry will be (probably considerably) smaller!

Furthermore, change (if necessary) C→F in SYSTEM.INI and WIN.INI.

Setting Up the RAM-disk

This is achieved by copying RAMDRIVE.SYS to (virtual) boot disk [A:] and loading it during the boot process. For example, a CONFIG.SYS statement

DEVICEHIGH=A:\RAMDRIVE.SYS 16384 512 128 /E

would create a RAM-disk [C:] of 16 MB, with 512 bytes sector size and 128 root directory entries (here we have assumed that there is not any local hard disk on the workstation!).

Setting Up MSDOS.SYS

We can replace the micro MSDOS.SYS on the boot disk with a "real" Win95 MSDOS.SYS. Make sure that it contains the following line

WinBootDir=C:\

within the [Paths] section. Also, make sure that LoadGUI=0 and Logo=0 in [Options].

Setting Up The Initialization Image of [C:]

Create a directory in \\SERVERNAME\W95 to hold the initial files that will be copied to the workstation. Let it be saying C_INIT. Put the new Registry files SYSTEM.DAT and USER.DAT in this directory, together with COMMAND.COM and files you like to go to [C:] before Win95 loads. Ensure all HSR attributes are removed from SYSTEM.DAT and USER.DAT in C_INIT.

Preparing to Load Win95

Before loading the graphical interface (and after establishing a network identification F ↔ \\SERVERNAME\W95) we should execute the following commands (putting them in the appropriate batch file/AUTOEXEC):

set path=C:\;F:\WINDOWS;F:\WINDOWS\COMMAND
copy F:\C_INIT\*.* C:\
attrib +R +H +S C:\SYSTEM.DAT
attrib +R +H +S C:\USER.DAT
set comspec=C:\COMMAND.COM

Re-allocate the swap file, by including the line

pagingfile=C:\WIN386.SWP

in the [386Enh] section of SYSTEM.INI.

Load Win95 GUI

Execute WIN. After the GUI comes up, you will probably have a couple of broken shortcut links. Manually change the program references from C (left from the previous RIPL setup) to F.

Note that we have not used the program SETMDIR to define the Registry location, in contrast to the solution described in the previous article. Instead, the Registry location has been defined in the MSDOS.SYS file.

The problems with long filenames, 32-bit disk access and icons are still present in this setup. The icons' problem is solved in the same way as in the previous article.

It is interesting to mention that the RAM-drive setup allows us to avoid changing the file reference (from EXPLORER.EXE to SHELL32.DLL) for My Computer icon (necessarily changing the standard icon). However, in order to avoid My Computer icon being replaced with a generic Windows icon, it is necessary to include EXPLORER.EXE in C_INIT, in order to copy it to C before GUI loads, and change the icon path in Registry. We can also re-define the shell pointer in SYSTEM.INI accordingly.

RIPLing Windows 98 - Basic Observations

Here the principal ideas are the same as for Win95 RIPL (that is, install first on a local hard drive, then copy to server and perform the appropriate manual adjustments) however, there are some subtle differences.

First of all, it seems that SETMDIR utility (available with Win95 only) does not work correctly with Win98. Hence, it is necessary to apply the above-mentioned alternative method, by defining WinBootDir in the [Paths] section of MSDOS.SYS.

Secondly, Win98 has problems in disconnecting automatically from its virtual boot floppy (unlike Win95). Therefore, it is necessary to execute the IBM RPLTERM utility prior to loading GUI.

The standard configuration of Windows 98 (with IE integrated) generates much more network traffic during the boot process and various operations (as expected, because of all this IE extra load). Hence it is very important to re-configure IE stuff properly, replacing the long filenames Registry references (like "Temporary Internet Files") with short counterparts.

In order to speed up the client workstation, it is highly recommendable to remove the IE shell integration from the OS. We refer to 98LITE website for more information on IE removal, various "lite" configurations of Win98 and accompanying installation software.

Basically, the construction consists in replacing the files EXPLORER.EXE (in WINDOWS directory) as well as SHELL32.DLL and COMDLG32.DLL (in WINDOWS\SYSTEM) with their Win95 counterparts, and some elementary manual adjustments. In such a way we end up with a considerably faster, cleaner and smoother system, generating much less network load. Furthermore, it would be necessary to replace the NotePad and WordPad, with Win95 versions. In order to save the server disk space, we can completely remove the IE files and clean up the Registry, by removing unnecessary entries and recompiling (remember, workstations starting from their RAM drive [C:] transfer the Registry from the server).

The problem with a delayed shutdown and reboot completely disappeared when RIPLing Win98. My diskless workstation smoothly shuts down and reboots, in all possible configurations (with/out IE integration, and with/out the RAM drive [C:]).