Stacker 3.0 + Smartdrv.exe = confusion...
Stefan Frick
Ok, so I tried to combine these two, with confusing results...
First:
During boot-up it complained that 'double-buffered device-drivers should
not be started with DEVICEHIGH=' etc, etc. So I changed this to
INSTALL=C:\WINDOWS\SMARTDRV.EXE C- D+ 2048 1024 and, at least, Smartdrive starts
in high memory.
Second:
While starting, Smartdrive complains that it cannot create the cache on the
selected disk (D: logical, C: physical). Huh? Smardrive is started *after* the
SSWAP routines that swaps the C: and D: drive.
Even more confusing is the output from smartdrv /? which actually says it's
caching the D: drive!
I've looked in the manuals and in the 'last-minute-notes' that came with Windows 3.1
but can't find any clues.
Hard facts:
386sx/25 w AMI BIOS (dated june-91)
8Mb ram
DOS 5.0 with himem and emm386 activated (no ems)
Windows 3.1
40Mb disk with Stacker 3.0
Thanx in advance!
-Stefan
fred j mccall 575-3539
>Ok, so I tried to combine these two, with confusing results...
>First:
>During boot-up it complained that 'double-buffered device-drivers should
>not be started with DEVICEHIGH=' etc, etc. So I changed this to
>INSTALL=C:\WINDOWS\SMARTDRV.EXE C- D+ 2048 1024 and, at least, Smartdrive starts
>in high memory.
Don't do it this way. Start it in your AUTOEXEC.BAT, instead, and it
will load whatever part of itself high as will fit without your
telling it to do so.
>Second:
>While starting, Smartdrive complains that it cannot create the cache on the
>selected disk (D: logical, C: physical). Huh? Smardrive is started *after* the
>SSWAP routines that swaps the C: and D: drive.
>Even more confusing is the output from smartdrv /? which actually says it's
>caching the D: drive!
See why I say not to use SSWAP? Just by the by, there is no quarantee
(I don't believe) that CONFIG.SYS statements will be executed
sequentially, so don't be too sure which is happening first.
--
"Insisting on perfect safety is for people who don't have the balls to live
in the real world." -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred....@dseg.ti.com - I don't speak for others and they don't speak for me.
Brian Martin
I use Stacker 3.0 with a 200MB disk stacked to "400MB", as a single C: partition,
in DOS 5.0, with Windows 3.1, & Smartdrive.
I have databases of 10 or 20 MB files, & often do sorts with 20MB input,
20MB output & 20MB work files, on a 486/33 clone.
I get no Stacker problems, despite programs under development crashing the PC.
Occassionally I need to run CHKDSK & Stackers verification tools,
but CHKDSK would be normal even without Stacker.
Earlier versions of Stacker had bugs with disks which after stacking were > 256MB,
but V3.0 is great (so far).
Brian Martin bri...@cssc-syd.tansu.com.au
Mike Dunnagan
> I use Stacker 3.0 with a 200MB disk stacked to "400MB", as a single C:
> partition
You do realize, that a partition larger than 127 Mbytes, uses a 4k cluster
size? This can be a tremendous waste of disk space.
Mike Dunnagan ---
--
The opinions expressed are not necessarily those of the University of
North Carolina at Chapel Hill, the Campus Office for Information
Technology, or the Experimental Bulletin Board Service.
internet: laUNChpad.unc.edu or 152.2.22.80
Jen Kilmer
>In <1993Mar10....@ericsson.se> etx...@helix.ericsson.se (Stefan Frick) writes:
>>Ok, so I tried to combine these two, with confusing results...
>
>>First:
>
>>During boot-up it complained that 'double-buffered device-drivers should
>>not be started with DEVICEHIGH=' etc, etc. So I changed this to
>>INSTALL=C:\WINDOWS\SMARTDRV.EXE C- D+ 2048 1024 and, at least,
>>Smartdrive starts in high memory.
>
>Don't do it this way. Start it in your AUTOEXEC.BAT, instead, and it
>will load whatever part of itself high as will fit without your
>telling it to do so.
You're right, smartdrv (the TSR disk cache) will loadhigh on its own.
Part of the problem is that smartdrv is a two-headed beast, mostly for
historical reasons. It's a device driver that does "double buffering",
that is, it buffers all BIOS-level hd i/o in conventional memory.
This is nec when using the 386/486 paging features with a controller that
assumes no paging will occur. It also slows the system down. Since the UMBs
created by emm386, qemm386, etc are extended memory paged into the UMA,
loading the device driver high won't work.
The disk cache is a TSR, best loaded from autoexec (tho can be loaded
with install=, it's just not tested very much). Originally smartdrv.sys
was a BIOS-level cache, so combining them into one animal made some sense.
Now the command-line interface to smartdrv hooks you into both the cache
and the double-buffering driver.
>>Second:
>
>>While starting, Smartdrive complains that it cannot create the cache on the
>>selected disk (D: logical, C: physical). Huh? Smardrive is started *after* the
>>SSWAP routines that swaps the C: and D: drive.
Doesn't matter. There a data-corrupting case which can occur if smartdrv is
caching the compressed drive. Both the smartdrv developers and Stac's
development folks agreed that smartdrv should refuse to load on Stacker
drives. Smartdrv is detecting the Stacker drive using a detection method
recommended by Stac. [This was all Windows 3.1 timeframe]
>>Even more confusing is the output from smartdrv /? which actually says it's
>>caching the D: drive!
Remember, the C (stacked) drive is physically located on D (normal MSDOS
drive). So your stacked drive _is_ being cached - and your cache is a
little more efficient since it's caching compressed data.
>See why I say not to use SSWAP? Just by the by, there is no quarantee
>(I don't believe) that CONFIG.SYS statements will be executed
>sequentially, so don't be too sure which is happening first.
YES YES YES YES YES.
BTW, in 5:
DOS= are read first.
Then all commands except install=s are read in sequential order.
FILES=, BUFFERS=, etc are put into a data structure and processed later.
If you have dupes (say, two SHELL= lines) the last one is used.
DEVICE= are processed when read, if DOS=HIGH or DOS=UMB and it hasn't
found an XMS driver yet, then after each driver is initialized, it
checks to see if there's an XMS driver. If there is, MSDOS asks the XMS
driver for the HMA (if dos=high) and if there's any UMBs [if dos=umb;
it's himem, the answer is no]. When/if UMBs are found, msdos allocates
all of them and adds them to its memory pool.
DEVICEHIGH= are processed just like DEVICE=, except that when allocating
memory for the device driver it will set up the int 21h to request UMBs.
Note this only works if UMBs are in the memory pool, otherwise the int
21h returns a conventional memory block. [Command.com implements lh the
same way, I would think 4DOS would too.]
INSTALL= commands are processed next, in sequential order.
Finally, whatever program is designated by SHELL= is loaded and executed
with any parameters listed on the SHELL= line (default is
shell=\command.com \ /e:256 /p).
4.0 was sorta the same, no DOS= stuff, no /e: default on shell=.
3.x had no INSTALL=.
And, of course, this may all change in the future.
-jen
--
#include <stdisclaimer> // je...@microsoft.com // ...just testing...