Jump to content

Some features of MS-DOS 8.0: Difference between revisions

From EDM2
← Older editNewer edit →
Cbmibm (talk | contribs)
21 edits
Cbmibm (talk | contribs)
21 edits
redirect, my content is not allowed here by Serg, see http://www.edm2.com/index.php?title=Windows_Me_boot_and_Windows_2000_boot&diff=5215&oldid=5212
Line 1: Line 1:
Original work by [[Micho Durdevich]]
#REDIRECT[[RIPLing Windows Millennium Edition]]
 
<h2>1. Introduction</h2>
 
<p>In this article we shall talk about diskless Windows workstations
that remote-boot Windows Millennium Edition from OS/2 Warp Server.</p>
 
<p> Configurations we are going to present are the most complex, yet the most powerful
Windows RIPLing solutions. We achieve this by combining diverse ideas presented
in the previous articles, with a new structural element: Dynamical transition from real-mode to protected mode networking, during the boot process. </p>
 
<p> Our RIPL clients start as normal DOS requesters from a virtual
superfloppy [A:]. During the real-mode boot phase, they create a small RAM-drive [C:]
that holds Registry and some critical Windows files. These files form
what we shall call the <i>sub-nucleus</i> (in contrast to the <i>nucleus</i>
configurations considered previously, the sub-nucleus alone is not enough
to boot GUI).</p>
 
<p> Using ideas of this article, it is possible to set up RIPL clients that have
<i>absolutely the same functionality, and the same look and feel</i> as
the standard Windows machines. In particular, we can set up a diskless
workstation that runs a standard, full-blown version of Windows Millennium from
OS/2 Warp Server.</p>
 
<p> More specifically, basic characteristics of our RIPL-clients are:
 
<ul>
<li>Dynamical switch from real-mode to protected mode networking during
the boot process. Full 32-bit networking working.
<li>Full long file-name support.
<li>At least as stable as standard Windows Millenium Edition systems. Actually, we have an increased
security and stability, because of the RIPL-context.
<li>Ability to play video clips, advanced audio support, games :) Virtually all applications are supported.
<li>The whole HTML-engine working, including the extensive help
subsystem, wizards and IE.
<li>High flexibility in configuring. Possibility to
introduce a local HDD for swapping. A local HDD can also hold
the sub-nucleus files.
<li>Universality: Ideas of this article apply also to Windows 95/98/98SE.
This RIPLing method works for all types of lite Windows versions, too.
</ul>
 
Diskless Windows 95/98/98SE configurations require much less work.
Various WinME-specific steps described here are not necessary, while
some other steps require trivial modifications. Therefore, I
decided to illustrate everything on the most challenging case-Windows
Millennium.</p>
 
<p>The article is organized as follows. The next section contains
a couple of simple, but important remarks, about the server setup. The main
part of the article is Section 3, that describes the boot process and the
design of our RIPL requesters. In particular, it contains the sub-nucleus
listing for Windows Millennium. We also explain how to get dynamical networking
transition working, with the help of SNAPSHOT.EXE and SNAPSHOT.VXD. </p>
 
<p>Section 4 discusses two sample configurations (that use NETBIOS and IPX as real-mode
protocols, respectively). In particular, it contains
PROTOCOL.INI and mini-Registry descriptions for these configurations.</p>
 
<p>In Section 5, concluding remarks and observations are made.
This includes modifying original fully diskless setup,
in order to include configurations that have a local hard drive. As
we already mentioned, a local HDD
can be very useful as a swapping media. It can also hold
the subnucleus package. It is also possible to install more Windows files
locally, which enables us to fine-tune the performance of network clients. </p>
 
<p>The article ends with two appendices. The first appendix (having an
independent interest) describes a very elegant procedure to enable
real-mode DOS support in Windows Millennium Edition. The second appendix
discusses a couple of strange properties of Windows 98SE/ME. I do not
see any other purpose of these "new features" except to make
it exceedingly difficult to run Windows in any non-standard
environment, including our RIPL context. </p>
 
<p>After all, there is something good in the fact that Windows designers
decided to introduce such puzzling obstacles. One of the best
ways to learn any subject is, perhaps, by solving non-trivial
problems appearing in the game.</p>
 
<p>In the spirit of this, the paper features a variety
of <i>exercises.</i> Some of them are easy, some of them are tricky. And
the solution is not always unique! Anyway, I hope that solving
exercises, or just thinking about possible solutions, can help
you understand better a very subtle and exciting theory of RIPLing
diskless Windows workstations from OS/2 Warp Server. </p>
 
<h2>2. Notes on Servers Involved</h2>
 
<p>It is important to distinguish between three different possible roles
that a server system could play in a RIPL game:</p>
 
<p><b>The RIPL Server:</b> Enables a diskless system to start over a network,
loading a DOS kernel and initiating the 16-bit networking.</p>
 
<p><b>The Operating System Server:</b> It is where Windows
files are stored. This server enables the
RIPL workstation to boot into a full 32-bit Windows
client.</p>
 
<p><b>The Applications Server:</b> It is where all application
files are stored.</p>
 
<p>The simplest setup is that a single OS/2 Warp Server
machine plays all these roles. In more complex networks however, it might
be a better idea to designate different server machines to
perform different remote-boot-related tasks. And of course, it is possible
to have several server machines, within the same
group (for example, a couple of RIPL servers). This
could be interesting in the situations where the network is heavily
loaded by RIPL requests. </p>
 
<p>I strongly recommend that all these three principal
tasks be performed by OS/2 machines (strictly speaking,
you need an OS/2 server only for RIPL service, while
OS/2 clients can be used to provide Windows operating system and
applications). I consider OS/2 as by far the most reliable
remote-boot solution.</p>
 
<p>It should be noted however, that you can easily set
up things in order to use different operating
systems on server machines (as Windows or UNIX).  </p>
 
<h2>3. Description of the Boot Process</h2>
 
<h3>Initial Real-Mode Boot</h3>
 
<p>In this first phase, we RIPL-start a DOS requester
from a virtual superfloppy of at least 8MB (the
creation of such superfloppy images was described in
articles 4/5).</p>
 
<p>I recommend installing <i>two network adapters</i> per diskless
workstation, during the testing and building of the RIPL clients.
The first network adapter should be dedicated to <i>initial
RIPL-processing</i> and the second adapter should be used for
 
<i>M$ networking</i> (in both real and protected modes). Once
our RIPL client is working properly, we can fine-tune it and
switch to a single-adapter setup easily. </p>
 
<p>The superfloppy contains the following software components:</p>
 
<h4>Real-Mode System</h4> <p>It consists of IO.SYS, MSDOS.SYS
(in the root directory) with IFSHLP.SYS (in WINDOWS folder)
and VMM32.VXD=COMMAND.COM (as explained in Appendix A).
Here is a possible listing of the [Paths] section of MSDOS.SYS file:</p>
 
<pre>WinDir=F:\WINDOWS
WinBootDir=A:\WINDOWS
HostWinBootDrv=F
</pre>
 
<h4>Real-Mode M$ Networking</h4>
 
<p>It is composed from the following files:</p>
 
<pre>NET.EXE    NET.MSG    NETH.MSG    PROTMAN.DOS  PROTMAN.EXE  SUBST.EXE
  PROTOCOL.INI    SYSTEM.2    &lt;16nicdrv&gt;.DOS  SNAPSHOT.EXE NDISHLP.SYS
</pre>
 
<p>Here, SYSTEM.2 is the mini-registry containing
necessary information for the 16-bit networking to start. A blueprint of
the mini-registry is listed in WiRIPL3. Protocol-related entries are
discussed within the next section. Here, this file has a <i>weird extension</i>. This is
because IO.SYS of WinME examines the Registry (if it finds it!)
from the very beginning, and the system somehow
<i>remembers</i> something of it. This can totally confuse the system
during the GUI boot (where we switch to the full Registry). The
mini-Registry is renamed to SYSTEM.DAT later, just before
starting the real-mode network client. </p>
 
<p>Observe also that we do not have any CONFIG.SYS
file! Actually, IO.SYS of WinME is <i>unable to
load</i> any real-mode device drivers listed in CONFIG.SYS
(except IFSHLP.SYS that is loaded automatically and HIMEM.SYS
that is pre-built into IO.SYS). It simply ignores
the CONFIG.SYS file. </p>
 
<p>A workaround is to use the appropriate command-line
utility for loading device drivers (as LDEVICE by Adlersparre &amp;
Associates, for example).</p>
 
<p>The only driver here that we would normally load
from CONFIG.SYS is RAMDRIVE.SYS. The network
adapter driver and NDISHLP.SYS are loaded by
NET.EXE, when starting the network protocol (which
by the way enables SNAPSHOT.EXE to properly capture
the whole contents of the real-mode networking).  </p>
 
<h4>Ramdrive Software</h4>
<p>A possible solution is given by LDEVICE.EXE and RAMDRIVE.SYS!</p>
 
<h4>Sub-Nucleus Files</h4>
<p>The WINDOWS folder contains all the above mentioned network &amp;
 
ramdrive-related files. The most important files are in subfolders
SYSTEM and SYSTEM32.</p>
<p><b>System Subfolder</b></p>
<p><b>CriticalFiles={ </b>kernel32.dll, user32.dll, vmm32.com,
krnl386.exe, systray.exe<b> }</b></p>
 
<p><b>Network-related={</b> vredir.vxd, netbeui.vxd, nwlink.vxd,
vnetbios.vxd<b> }</b> </p>
 
<p>At the protected mode level, our RIPL clients use both NETBIOS
and IPX protocols, and the primary network logon is given by client
for M$ networks. </p>
 
<p><b>KnownDLLs={ </b>nt1003.sys, advapi32.dll, netapi32.dll, msgsrv32.dll, netbios.dll, lz32.dll, lzexpand.dll,
linkinfo.dll, ntdll.dll, svrapi.dll, wmi.dll, wmiexe.exe, mpr.dll, mprexe.exe, version.dll, ver.dll<b> }</b></p>
 
<p><b>Miscellaneous={ </b>locale.nls, unicode.nls, cp_1252.nls, cp_437.nls<b> }</b></p>
 
<p><b>System::Iosubsys={ </b>Basically, all vxd/pdr/drv files that are
present in standard configurations<b> }</b></p>
 
<p><b>System::VMM32={}</b></p>
 
<p><b>System32-subfolder={</b>
This subfolder should contain all device drivers
that are associated to the loader NTKERN.VXD, which by default is an
integral part of the monolithic VMM32.COM. In particular,
the corresponding 32-bit network adapter driver &lt;drv32nic&gt.SYS
should be in SYSTEM32<b>. }</b></p>
 
<h3>Real-Mode Game and VMM32-Initialization</h3>
 
<p>At first, we have to create the approptiate RAM-disk.
For example, one solution is given by executing
 
<font color=#660000>
<center>LDEVICE RAMDRIVE.SYS /E 10000</center></font></p><p>
Next, it is necessary to copy the entire
WINDOWS folder (with subfolders) into the newly
created RAM-disk [C:]. Rename SYSTEM.2 into SYSTEM.DAT.</p>
 
<p>Furthermore, we execute from [C:] the following
<center><font color=#660000>RPLTERM, SUBST A: C:\</font></center><div>
which will terminate the connection with the virtual
superfloppy, and create a new [A:]-drive, as a
<i>substitution</i> by [C:].</div></p>
 
<p><b>Exercise:</b> Explain reasons why do we need the
SUBST step at all? What could be an alternative? </p>
 
<p>The 16-bit networking is started by the following
sequence of commands:
<font color=#660000><center>SNAPSHOT /M:&lt;xyz&gt;<br>
              net start &lt;protocol&gt;&nbsp;<br>
              net start workstation<br>   
              net use F: \\OS2Server\WinME<br>
              SET path=F:\windows;F:\windows\SYSTEM</center></font></p><p>
 
where &lt;protocol&gt; is IPX or NETBEUI and &lt;xyz&gt; is the amount of memory
in Kilobytes, that should be reserved for real-mode networking.</p>
 
<p>After establishing a network connection, we should
copy the full
<center><b>Registry={ </b>SYSTEM.DAT, USER.DAT, CLASSES.DAT<b> }</b></center></p><p>
from a client-specific location into C:\WINDOWS. </p>
 
<p><b>Exercise:</b> Explain how to take advantage of the
powerful OS/2 Warp Server <i>filtering mechanism</i>
that is built into its DOS-RIPL subsystem, in order to
be able to automatically transfer the appropriate
requester-specific Registry files. </p>
 
<p>Before going further, let us emphasize that <i>all Windows
Millennium files/folders</i> are stored on a redirected drive [F:].
Consequently <i>all Registry entries</i> should point
to [F:], <i>except the entry</i>  </p>
 
<pre>[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup]
"WinBootDir"="A:\\WINDOWS"
</pre>
 
<p>Technically, in preparing a diskless RIPL client, we would
normally start from a "blueprint" machine equipped with a local
hard disk, and install Windows in a standard way on this machine.
We would then copy all Windows stuff on the server, and change
configuration files, in order to point to a new drive letter
(in case local Windows drive letter differs from F). In particular,
we would have to export, edit and re-compile the Registry. </p>
 
<p><b>Exercise:</b> What is the correct command-line syntaxt for creating
the Registry from a text file, in the case of Windows ME?</p>
 
<p>Finally, we are ready to launch VMM32.COM from
[C:], which starts a "true" Windows ME boot. </p>
 
<h3>Dynamical Networking Transition</h3>
 
<p>This part of the boot process is played by a
small but extremely powerful static VXD driver
SNAPSHOT.VXD. It is responsible for <i>dynamical
transition</i> from real-mode to protected mode networking during
the boot process, so that we end up with a clean
32-bit network client. It is loaded from the
Registry, with the corresponding entry block:</p>
 
<pre>[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\SNAPSHOT]
"Start"=hex:00
"NetClean"=hex:01
"StaticVxd"="snapshot.vxd"
</pre>
 
<p>The driver SNAPSHOT.VXD uses the information
gathered by SNAPSHOT.EXE, to transform the initial 16-bit into
a 32-bit connection to [F:]. Both files SNAPSHOT.VXD/EXE are
available from any Win95 distribution.</p>
 
<p><b>Exercise:</b> What do you think could happen, and why, if
we excluded the network files NWLINK.VXD, NETBEUI.VXD ,
VREDIR.VXD and &lt;32nicdrv&gt;.SYS from the Sub-nucleus
on the local RAM-drive (but leaving them intact on the main Windows
drive [F:])?</p>
 
<p><b>Exercise:</b> What is the best that we could expect to
happen if we <i>eliminated</i> SNAPSHOT.VXD from this game,
leaving everything else untouched? Similarly, is it possible to
get rid of SNAPSHOT.EXE?</p>
 
<p><b>Exercise:</b> As we know, Windows 95/98/98SE all have the ability to
process CONFIG.SYS, and thus to naturally
load real-mode device drivers. Why it is not
a good idea, in this context, to load the 16-bit
protocol manager and the DOS adapter driver from
the CONFIG.SYS file?</p>
 
 
<h3>Protected Mode Boot Phase</h3>
 
<p>This is the final part of the boot process, and there is nothing
RIPL-specific here. After initializing the Configuration Manager and
Windows core components such as KRNL386.EXE, KERNEL32.DLL, GDI32.EXE
and USER32.DLL, a control is given to CMDNINST.EXE, which in its turn
initiates M$ logon. After logon processing, the graphical interface is
presented by EXPLORER.EXE.</p>
 
<h2>4. Sample Configurations</h2>
 
<p>Now, we are going to talk about two sample WinME diskless configurations:
The first one is based on a single OS/2 Warp Server (Aurora) machine
and the client uses NETBIOS as the main network
protocol. The second one is using an auxiliary
Win95 machine as an Operating System
Server, while RIPL service and applications are provided
by the Aurora server (much less reliable of course,
but its a fun to boot WinME from Win95). The Win95 "server" machine
uses IPX protocol and has peer-to-peer networking installed.</p>
 
<p>We assume here that the RIPL client is using a Fast EtherLink 905X
adapter. At the 32-bit level, the client machine has both IPX and
NETBIOS installed. </p>
 
<p>In my lab, I constructed both these configurations using various
types of machines. In particular, the following hardware gives one solution:
RIPL clients are IBM Netvista (Network Station 2800) with 128MB of RAM.
The built-in IBM EtherJet adapter was used during boot-block processing.
A second network adapter (3Com Fast Etherlink 905C) was used for
the main network connections (M$ 16-bit and 32-bit networking). </p>
 
<p>As server systems, I used two IBM ThinkPads 765D (P166MMX with 32MB)
running Aurora and Win95 respectively. I also worked with two more
powerful OS/2 servers (running both OS/2 Warp Server Advanced 4 and
Aurora). The first one is AMD K6-II 300Mhz with 256MB of RAM, 6GB Maxtor EIDE
HDD, Tyan/Via Apollo. The file system used is HPFS386. The second server
is Athlon 700Mhz, AOpen/Via Apollo, 256MB RAM and 6GB Maxtor
EIDE HDD. The file systems used are HPFS for the main operating systems
and JFS for the RIPL stuff. Both servers use 3Com Fast EtherLink
905C-TX adapters. </p>
 
<h3>NETBIOS Configuration</h3>
 
<p>The network starts by invoking
<font color=#660000><center>NET START NETBEUI</center></font></p><p>
and the Real Mode Network Registry section looks like</p>
 
<pre>[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Network\Real Mode Net]
"transport"="ndishlp.sys,*netbeui"
"netcard"="el90x.dos"
"LoadRMDrivers"=hex:00,00,00,00
"PreferredRedir"="VREDIR"
"Transition"=hex:01
"StaticDrive"="F"
</pre>
 
<h3>IPX Configuration</h3>
 
<p>The network starts by
<font color=#660000><center>NET START IPX</center></font></p><p>
and the corresponding mini-Registry section is:</p>
 
<pre>[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Network\Real Mode Net]
"transport"="ndishlp.sys,*nwlink"
"netcard"="el90x.dos"
"LoadRMDrivers"=hex:00,00,00,00
"PreferredRedir"="VREDIR"
"Transition"=hex:01
"StaticDrive"="F"
</pre>
 
<p>Here are the listings of PROTOCOL.INI for both configurations:</p>
 
<pre>                           
    [protman$]                                [protman$]
    DriverName=protman$              DriverName=protman$
    priority=NDISHLP$                  priority=NDISHLP$
 
    [ndishlp$]                                [ndishlp$]
    DriverName=ndishlp$              DriverName=ndishlp$
    Bindings=EL90X$                      Bindings=EL90X$
 
    [Data]                                        [Data]
    netcards=EL90X$                      netcards=EL90X$
                                 
    [netbeui$]                                  [nwlink$]
    DriverName=netbeui$                DriverName=nwlink$
    Lanabase=0                              Frame_Type=4
    sessions=10                              cachesize=0
    ncbs=12                                           
    Bindings=EL90X$                      Bindings=EL90X$
 
    [EL90X$]                                    [EL90X$]
    DriverName=EL90X$                  DriverName=EL90X$
</pre>
<p><b>Exercise:</b> Explain why it might be easier to set up RIPL
clients using two network adapters for different boot tasks? Discuss
problems that could occur if we straightforwardly used a single adapter in
building a RIP  L client? Discuss additional technical steps that are
recommendable in case of single-adapter clients?</p>
 
<h2>5. Concluding Remarks and Observations</h2>
 
<p>In this study, we have focused ourselves to diskless WinME systems.
However, there is nothing in our considerations that is incompatible
with the existence of a local HDD. A local
swapping media can be very useful, decreasing the network load. In adition,
a local HDD can be used to hold the subnucleus package, thus avoiding
the transfering the whole subnucleus over network, each time the
client boots.</p>
 
<p>For security reasons, it is better to use RIPL as the boot method,
instead of booting directly from a HDD (which should not be bootable).
The system Registry should be almost always stored on a server, so that it
is transferred into the appropriate RAM-drive before VMM32.COM starts. 
Initialization scripts should be modified accordingly. </p>
 
<p>Of course, if security is not an issue, we can further simplify our
configurations and have a local bootable HDD, installing the subnucleus
and full Registry locally. </p>
 
<p>Another simple variation is to use a standard floppy to boot the
workstation.</p>
 
<p><b>Exercise:</b> Explain in detail all the steps/changes necessary to perform
in order to:
<ul><li> Start a diskless workstation from a real bootable floppy;
 
<li> Start the system from a bootable local HDD, and optionally have
the Registry transferred from a server.
</ul></p><p>
In both cases we do not need any RIPL server.</p>
 
<p>All diskless systems should be configured to start with Active Desktop
turned off (Active Desktop works fine, and can be turned on after the
system has booted). </p>
 
<h2>Appendix A: Enabling Real-Mode DOS Support in Windows Millennium Edition</h2>
 
<p>We shall describe here a very simple and elegant method of enabling real-mode DOS in WinME.
It requires changing <i>only one byte</i> of the standard command interpreter COMMAND.COM.
Alternatively, it is possible to incorporate non-standard command interpreters in
this procedure. </p>
 
<p>The problem is that for some strange reasons WinME designers decided to completely
disable real-mode DOS. The kernel IO.SYS of WinME was rewritten following this idea. </p>
 
<p>According to Microsoft, the elimination of the real mode support substantially improved
the system stability and decreased the system boot time.</p>
 
<p>Roughly speaking, the boot process of WinME looks like as follows:</p>
 
<p>After reading the boot sector of the WinME partition, the system loads the DOS-kernel
IO.SYS. The kernel IO.SYS reads the file MSDOS.SYS (located in the root directory) in order
to figure out where is the main Windows folder. The kernel loads its internal
HIMEM.SYS and also VFAT support driver IFSHLP.SYS (located in the main Windows
folder). Furthermore, IO.SYS gives control to VMM32.VXD (which is located
in the SYSTEM subfolder of the main Windows folder). The monolithic VMM32.VXD creates virtual machines,
loads all static VxDs, and switches the processor to protected mode. Finally,
protected mode components are loaded, including critical files such as
KERNEL32.DLL, KRNL386.EXE, GDI32.DLL and USER32.DLL. </p>
 
<p>In particular, WinME does not need any command interpreter to
boot. Moreover, its default incarnation does not need the file WIN.COM!</p>
 
<p>Our main idea is to <i>replace the file</i> VMM32.VXD by the appropriate
command interpreter. The simplest solution would be to use the standard COMMAND.COM.
However, a slight technical problem appears here, because of a funny mistake
in the standard command interpreter COMMAND.COM. Fortunately, this error is only
one-byte long... </p>
 
<p>The original Windows loader VMM32.VXD can be started from the command line, which
would then initiate the protected-mode boot, as usual.  </p>
 
<p>More precisely: </p>
 
<h3>Step 1: Binary Editing of COMMAND.COM</h3>
 
<p>At the hexadecimal offset 00006510, replace 75 by EB :) This will correct the
above mentioned error. More precisely, we are here replacing a conditional jump
instruction (75 10) with an unconditional jump (EB 10). I recommend error-correcting
both copies of COMMAND.COM (in the root of the boot drive and in the main
Windows folder, however Windows will work fine without both of these copies). I
assume you are using release 4.90.3000 of WinME (English version).</p>
 
<h3>Step 2: Adjusting The Loader</h3>
 
<p>Rename the file VMM32.VXD into VMM32.COM. Copy the improved COMMAND.COM into the
SYSTEM subfolder, as a new "loader" file VMM32.VXD.</p>
 
 
<h3>Step 3: Getting rid of WIN.COM</h3>
 
<p>Rename the file WIN.COM into WINME.COM!</p>
 
<p>Now, when we start WinME it will stop at the command prompt, displaying
an error message that it can not find WIN.COM. At this point, we have
WinME running in real DOS-mode :)</p>
 
<h3>Step 4: Final adjustments</h3>
 
<p>This error message is harmless. Optionally, it gives us a nice opportunity to
replace it by another, personalized message. Simply binary-edit the file
COMMAND.COM (but of course, replace the message-do not change the size of
the file!)...</p> 
 
<h3>Loading WinME Graphical Interface</h3>
 
<p>To load full GUI, simply launch VMM32.COM from the command prompt!</p>
 
<h3>Interesting Variations</h3>
 
<p>Instead of using the error-corrected COMMAND.COM, we can put another
program in place of VMM32.VXD. For example, we can use another command
interpreter, or custom-build a nice DOS-program, giving us something like
a startup meny, and so on.</p>
 
<p>For example, we can use a simple (and very old!) unix-like command shell
csh4 (by Kent Williams). The package includes the full source code. In this
case, we have to copy the shell program SHELL.COM over VMM32.VXD.</p>
 
<p>Another illustrative example is to use 4DOS from JP Software: After
installing the files into a separate directory (say C:\4DOS) all
we have to do is to copy 4DOS.COM over VMM32.VXD and create
the appropriate 4DOS.INI file (which should stay in the SYSTEM
subfolder). Note that this solution does not depend of COMMAND.COM
and in particular it is not necessary to binary-edit anything. </p>
 
<p>As a third example--it possible to use Orchard House (very nice and compact
DOS shell, by Gleason Pace). The package consists of a single executable OH.EXE and a
configuration file (managed within the program). In this case, we copy OH.EXE
over VMM32.VXD.</p>
 
<p>Since the full WinME is loaded by VMM32.COM, we do not need the file WIN.COM,
as we already mentioned. The same trick is applicable with
earlier versions of Windows, however <i>assuming that we use IO.SYS from Windows
Millennium.</i> Interestingly, in all my experiments non-ME DOS kernels were
causing Win95/98-based VMM32.COM to crash. Anyway, it looks like that Win95/98
workstations run a little smoother with a WinME kernel IO.SYS. In order to make a
standard DOS command Window fully usable (for launching various Windows programs
for example), it is also necessary to replace CONAGENT.EXE and files in
COMMAND subfolder, with their WinME counterparts... </p>
 
<p>A more conservative method of booting WinME from DOS is to binary-edit
WINME.COM (the renamed WIN.COM) and change it so it will load VMM32.COM instead of
VMM32.VXD. Of course, in this case Windows starts by invoking WINME at the
command prompt. </p>
 
<p>We can use the above ideas to create a bootable WinME floppy, using the same
kernel IO.SYS as for the hard disk boot. Unfortunately, it seems that SYS.COM
supplied with WinME is unable to transfer the system files to a floppy (by default,
Windows Millennium is using a special DOS kernel IO.SYS to boot from a floppy). Perhaps
the cleanest method would be to start from a blank floppy, overwritting the boot
sector by the appropriate code (the boot sector is the same as for a Win95/98
bootable floppy, the fourth article contains a boot sector explanation/listing). Next, we
have to copy IO.SYS and IFSHLP.SYS to the root directory of the floppy.
Finally, we have to create SYSTEM subfolder and copy the standard COMMAND.COM
as VMM32.VXD in SYSTEM. </p>
 
<p>********<br>Interestingly, in the case of such bootable floppies, the file COMMAND.COM works
fine and it is not necessary to perform any error-corrections. The same property
applies for <i>virtual floppies and superfloppies</i> used for RIPLing
diskless workstations from OS/2 Warp Server. </p>
 
<h2>Appendix B: Weird Changes in Design of Windows Millennium</h2>
 
<h3>Problems with big RAM-drives</h3>
<p>This problem affects both Win98SE and WinME. It seems that
the system gets confused by real-mode RAM-drives that are bigger
than 10MB. Trying to load such a real-mode RAM-drive results in a
dramatically increased instability. In addition,
such a RAM-disk would not support long filenames&nbsp;(?!?)</p>
 
<p>The file that is responsible for this hostile behavior is the
Input-Output Supervisor IOS.VXD. Normally, it is an integral part
of VMM32.COM.</p>
 
<p>On the other hand, Windows 95 works fine with all sorts of
RAM-drives, of any sizes. </p>
 
<h3>Unflexibility with locations of device drivers</h3>
 
<p>It seems that all drivers that are loaded by NTKERN.VXD
<i>must stay</i> in one of the subfolders
{SYSTEM32, SYSTEM, SYSTEM32\DRIVERS} of the folder pointed
by winbootdir from MSDOS.SYS.</p>
 
 
<p>In our case, winbootdir=C:\WINDOWS and this means
that all NTKERN-related drivers must be a part of the
subnucleus and stay on the RAM-drive [C:].</p>
 
<p>Together with the IOS-related obstacle, this gives us a very
interesting problem: To see which NTKERN drivers are really used (Windows
installation puts a lot of files into SYSTEM32\DRIVERS, only a
fraction of them are really needed) in order to make the subnucleus fit
into 10MB limitation.</p>
 
<p>In case there are too many NTKERN drivers, there are several possible
workarounds:
 
<ul><li>Use a local media to store the subnucleus, as discussed in
Section 5.
<li>Change the system Registry so that some drivers are not loaded by
NTKERN :)
<li>Use a compressed RAM-drive [C:], in a way similar to our nucleus
configurations of WiRIPL4.</ul></p>
 
<p><b>Exercise:</b> Explain in detail the steps/changes necessary to perform
in order to: [1] Avoid loading selected drivers via NTKERN;
[2] Get compressed RAM-drive [C:] configurations working.</p>
 
<h3>Inability to process CONFIG.SYS</h3>
 
<p>This is related with so-called "removal" of real-mode DOS support
from Windows Millennium. As explained in the previous appendix,
in reality there is no any DOS removal, just the kernel IO.SYS was
redesigned in order to start loading Windows immediately, and to
ignore CONFIG.SYS.</p>
 
<p>With very little efforts, it is possible to incorporate into
IO.SYS the ability to present something like a menu at start-up,
with different options (this can be done very easily by writting
a customized VMM32.VXD). </p>
 
<h3>IO.SYS-Registry Coupling</h3> <p>The real-mode kernel IO.SYS
examines the system Registry, before it gives control to
VMM32.VXD. This can cause all sorts of weird phenomena if we
change the registry during the real-mode boot. As explained,
the solution is to start with a <i>renamed</i> mini-Registry.</p>
 
<h3>Strange Instructions Built Into COMMAND.COM</h3>
 
<p>If you copy any normal DOS executable over VMM32.VXD, it should
start without problems, as a part of WinME "boot". The
only ME-runnable program I know that does not start properly is
the command interpreter COMMAND.COM&nbsp;(?!?) As explained in Appendix A,
there is a hostile conditional jump instruction that prevents us
from loading COMMAND.COM as VMM32.VXD, in the case of a normal
HDD boot.</p>

Revision as of 18:27, 15 November 2010

Redirect to:

Retrieved from "https://www.edm2.com/index.php?title=Some_features_of_MS-DOS_8.0&oldid=5471"