In article <35168@adm.brl.mil> lee@cpu.us.dynix.com (Lee Crites) writes:
>
>On 21 Jan 1993, jindrich liska wrote:
>> whenever I try Options|Open I get a message "... not enough memory..." and system stucks. Actually, there is no reason for this message (still lots of memory avail.).
>
>I am getting this message a LOT with BP7. Is there a bug here? I have
>4meg of RAM, and set up my computer so that the only TSR's kicking around
>are the mouse driver and SSTOR (SuperStore disk compression utility).....
>.... I ran the utility that cam with BP7 to test the EMS, and it
>worked fine. I also have the IDE set up to use EMS (something I had to do
>quite early just to get some of my other programs to compile).
> lee@us.dynix.com | If it ain't broke yet,
I run BP on a Toshiba 386SX portable with 4 Megs RAM.......so 4 Megs is
not the problem (I compile 50,000 lines in about 20 Units).....so I think
is reasonable to ask you (both) to show us you CONFIG.SYS and
AUTOEXEC.BAT files.
BTW, running EMS memory with BP makes no sense at all *unless* you are
specifically using EMS in the target application.
I can say that running DOS 5 and EMM386.SYS is *poison* to the TD386
stand along debugger (which already has stability problems).
Additionally, I'd strongly recommend that if you are using DOS 5, you
substitute the WINDOWS versions of MOUSE.sys and HIMEM.SYS, since they
were written with DPMI server function in mind (hell, even MicroSoft
reccommends what I just suggested).
In reality, you are not whole-heartedly debugging this problem until you
start with no-TSRs (does the SSTOR TSR obey the same memory allocation
rules as HIMEM.SYS? Does it respect the needs of the DPMI server that
gets launched (silently) before BP starts up?).
To debug rour respective problems requires that you strip AUTOEXEC.BAT
and CONFIG.SYS down to absolute bare minimum and add in things....and not
