Date: Sun, 14 Feb 93 15:03:22 -0700
From: jan kok <kok AT CS DOT ColoState DOT EDU>
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: another HyperDisk problem

I too have not had any luck using HyperDisk (4.32) with djgcc on my
present computer, an Intel 486DX with a UM82C480 chip set and an AMI
BIOS.  I have been using smartdrv which comes with Windows 3.1 for
many months without problems.  HyperDrive, when I try it, works fine
with everything except djgcc.  djgcc will even link .o files together
properly, but when it tries to compile a .c file, it just hangs.  ^C
will get it back after a few seconds.  HyperDisk DID work with djgcc
on another 486 with an Award (?) BIOS and unknown chipset.

I have a mild interest in seeing this resolved since I have read that
HyperDisk is substantially faster than smartdrv (but I think that was
back in Windows 3.0 days, does anyone have more recent info?).  On the
other hand, since smartdrv works, there is also a disk cache utility
in DRDOS 6.0, (many of the DRDOS utilities work in MS-DOS), and there
are probably some free disk cache programs around, it's not urgent.

I just noticed something odd, which may or may not have anything to do
with the problem: With smartdrv, if I start up Windows, then exit by
double clicking on the exit icon (the WinExit utility, which I got
from the disk accompanying the book Windows 3.1 Secrets), then when
Windows exits I am back in the same directory that I was in when I
started Windows.  But if I use HyperDisk instead and do the same
thing, then I am left in the directory where WinExit lives!  It seems
bizarre that the disk cache should affect the current directory.

Below are my current startup files.  I have had the same problem
(between HyperDisk and djgcc, don't know about the directory anomaly)
even without vdisk, ansi and mouse drivers loaded.  The problem occurs
whether of not qemm\loadhi is used to load HyperDisk.  The hyperdisk
options used below were suggested by HyperWare support (I talked with
them a couple of times without resolving anything).  vi:- is an
undocumented option which disables something to get around bugs in
other people's code, I don't remember the specifics.  Note that "or"
means Override Report, it doesn't mean "one or the other".

Thanks for any suggestions...

- Jan
kok AT cs DOT colostate DOT edu

CONFIG.SYS
----------
DEVICE=C:\QEMM\QEMM386.SYS RAM 
DEVICE=c:\qemm\loadhi.sys /r:1 c:\drd\vdisk.sys 1536 /E
DEVICE=c:\qemm\loadhi.sys /r:1 c:\dos\ansi.sys
DOS=HIGH
files=30
BUFFERS=20
rem STACKS=9,256
shell=c:\command.com /p /e:1024
rem DEVICE=c:\qemm\loadhi.sys /r:2 c:\bin\hyperdkx.exe s or vi:-
rem device=c:\bin\hyperdkx.exe s or xs vi:-

AUTOEXEC.BAT
------------
@ECHO OFF
C:\QEMM\LOADHI /R:2 C:\WINDOWS\SMARTDRV.EXE > NUL
c:\qemm\loadhi /r:2 c:\bin\mouse.com > nul
PROMPT $p$g

md d:\bin
md d:\tmp
copy \gcc\bin\go32.exe d:\bin\go32
copy /b \gcc\bin\stub.exe+\gnu\demacs\bin\demacs d:\bin\em.exe
copy \bin\e.bat d:\bin\e.bat

PATH d:\bin;C:\BIN;C:\WINDOWS;C:\WINWORD;C:\DOS;c:\gcc\contrib\gcc16;c:\gcc\bin
SET TEMP=c:\tmp
call gccsetup
call demsetup
set infopath=.;c:/gnu/demacs/info

GCCSETUP.BAT
------------
set COMPILER_PATH=c:/gcc/bin
set C_INCLUDE_PATH=c:/gcc/include
set CPLUS_INCLUDE_PATH=c:/gcc/cplusinc;c:/gcc/include
set OBJC_INCLUDE_PATH=c:/gcc/include
set OBJCPLUS_INCLUDE_PATH=c:/gcc/include
set LIBRARY_PATH=c:/gcc/lib
set GO32=ansi 2r1 driver c:/gcc/drivers/tseng4k.grd gw 1024 gh 768

DEMSETUP.BAT
------------
set TERM=ibmpc
set TERMCAP=c:\gnu\demacs\termcap
set HOME=c:\gnu\demacs
set TZ=MST
set USER=kok
set EMACSLOADPATH=c:\gnu\demacs\lisp
set EMACSEXECPATH=c:\gnu\demacs\etc
set DEMACS_KEEP=1024
set SHELL=c:\command.com