🚀 go-pugleaf

In article <789@dinl.mmc.UUCP> schwartz@dinl.uucp (Michael Schwartz) writes:
>
>Is the "slow boot" version applicable to version 2.1?  Is it the same as
>the "Debug" version?  How does one replace drivers "easily?"  Who will
>untie Pauline from the railroad tracks?
>

The slow boot version is created by directly copying the files that windows
needs from the SDK diskettes.  You can create either a regular slow boot or a
debug slow boot.

The required files are:

    windowing layer
        kernel.exe
        gdi.exe
        user.exe
    driver layer
        keyboard.drv
        comm.drv
        sound.drv
        display.drv
        mouse.drv
        system.drv
    boot application
        msdos.exe

I believe that this is all of the files that you need, but I have not actually
done this yet so I am not sure.

Of course the driver files that you use depend on your hardware setup.  One
way to find out what files you need is to copy the debug version of the 3
.exe files, hook up a dumb terminal for debugging, and then type "kernel".
The start up should abort because of a missing file, and the name of the
missing file should be displayed on the debug terminal.  You then copy this
file from the SDK diskettes.

To run windows you enter "kernel".  The slow boot version always begins
by executing msdos.exe.  If you want windows to come up and execute your
application you copy or rename your application to msdos.exe in the slow
boot directory.

The install program creates 3 files from the above list for the fast boot
version, WIN.COM (this is a memory resident stub used to reload windows if
you run a DOS application that requires lots of memory), WIN200.OBL (contains
load on call code and other parts of windows that can be descarded during
normal windows operation), and WIN200.BIN (this remains resident while
windows is running unless a DOS application needs the memory then it gets
tossed out and WIN.COM is used to reload it when the DOS application
terminates).  It is called the fast boot version because it takes less time
to initially load Windows into memory.  This is the only performance
difference.


Here's another interesting tid bit.  If you are using a second monitor instead
of a dumb terminal windows will still attempt to display RIP codes and stack
traces to the dumb terminal.  In order to have RIP codes and stack traces
displayed on your second monitor you need to add the following line to your
config.sys file:

    DEVICE = C:\DOS\OX.SYS

you also need to copy ox.sys from the SDK diskettes into the appropriate
directory (dos in this case).

                                          I hope this helps,
                                               Marc
----
              "All my life I always wanted to BE somebody.
               I see now I should have been more specific."
                             Jane Wagner
Marc Guyott                                         mguyott@mirror.TMC.COM
{mit-eddie, pyramid, harvard!wjh12, xait, datacube}!mirror!mguyott
Mirror Systems	Cambridge, MA  02140                617/661-0777