Numhandles switch for himem.sys in DOS 6.22
Ryan Cabanas
I'm wondering how the numhandles switch for himem.sys in DOS 6.22
affects the environment for DOS applications, generally speaking. I
read the help file for himem.sys in DOS, but I don't really know much
about extended memory blocks or handles.
I have DOS 6.22 installed on a hard drive all by itself, on a Pentium
4 1.8GHz w/ 512MB RAM. I've been trying to get a DOS application to
run, but was having a heck of a time. I finally got it to run, but
the only way I could get it to start up was by setting the numhandles
switch equal to 2 in the config.sys. The instructions for this
program do not call for a change in the numhandles switch and when I
had this program running on our last machine (a 386 running Win 3.11)
I did not have to add this switch to get the program to run.
I was wondering if anyone could please tell me how they think this
could possibly affect my program and maybe just a quick blurp about
handles?
I was also wondering if anyone would have anticipated that a change in
the numhandles like this would have been necessary because of newer
hardware like the kind I'm running DOS 6.22 on.
Thank you so much for the help.
Ryan Cabanas
Herman Dullink
>affects the environment for DOS applications
table size, taking less RAM.
>I've been trying to get a DOS application to run,
>the only way I could get it to start up was by setting the numhandles
>switch equal to 2 in the config.sys.
I guess the DOS application needs a lot of base RAM.
With the MEM /C or MEM /D command you can see how much RAM
is used for what. There are many things that take RAM, such as buffers,
stacks, file handles. In my config.sys I have:
FCBSHigh=1
FilesHigh=20
StacksHigh=0,0
To minimize memory requirements to my needs.
I also have
DOS=High,UMB
DeviceHigh=Himem.sys /testmem:off
DeviceHigh=mouse.sys
InstallHigh=doskey.com /insert
To move resident programs out of base RAM.
This requires a driver or emulator that provides
'Upper' memory.
H
Norm Dresner
he was running on the ragged edge of not-quite-enough memory for the
application, I can't see that a few dozen handles would make all that
difference, but it's possible.
To the OP, when you're running Windows -- any windows -- it uses a
different amount of low (i.e. 1st megabyte) of memory that dos does and you
generally have more room for programs that way.
Norm
Herman Dullink <dul...@hetnet.nl> wrote in message
news:apg8t7$mla$1...@reader12.wxs.nl...
Ryan Cabanas
Thank you for replying.
So a smaller /numhandles setting decreases the handles table, thereby
making more RAM available to my DOS application. Lots of RAM is good.
But by having a smaller handles table, is it possible that this will
negatively affect my application (anything in general that you can
think of)? Thanks for the help Herman.
Ryan Cabanas
"Herman Dullink" <dul...@hetnet.nl> wrote in message news:<apg8t7$mla$1...@reader12.wxs.nl>...
Ryan Cabanas
Thanks for posting.
I was wondering if you could tell me what the downside may be of
having too low of a /numhandles setting. The instructions for my DOS
application say that I only need 640KB of expanded memory for the
program. After setting /numhandles=2 I checked the memory and I had
32MB of expanded; yeah, more than enough. But from reading the
himem.sys help file and the way it talked about "simultaneously"
accessing memory, is there still a downside to having /numhandles this
low, even though I have 32MB of expanded memory? Thanks for the help.
Ryan Cabanas
"Norm Dresner" <nd...@worldnet.att.net> wrote in message news:<DMTu9.8489$VJ5.4...@bgtnsc05-news.ops.worldnet.att.net>...
Norm Dresner
news:8e1a0594.02102...@posting.google.com...
> Norm,
>
> Thanks for posting.
>
> I was wondering if you could tell me what the downside may be of
> having too low of a /numhandles setting. The instructions for my DOS
> application say that I only need 640KB of expanded memory for the
> program. After setting /numhandles=2 I checked the memory and I had
> 32MB of expanded; yeah, more than enough. But from reading the
> himem.sys help file and the way it talked about "simultaneously"
> accessing memory, is there still a downside to having /numhandles this
> low, even though I have 32MB of expanded memory? Thanks for the help.
>
>
> Ryan Cabanas
>
While the /numhandles setting of 2 may be okay for the (IIRC) game
you're trying to run, it may be woefully inadequate for other programs. As
long as you're willing to have several boot options you can reboot before
and after running this game. You can create a boot-menu in CONFIG.SYS
which will give you the ability to choose which of several boot sets you
want to use for a given bootup.
One thing you might try to do to see exactly how much difference this
makes is to boot "normally" and run the command "mem" to determine the size
of the largest executable program, and then to do the same thing with the
restricted numhandles setting, If the difference isn't too great, there my
be other techniques you can use to free up some memory that would be less
intrusive.
Norm
Herman Dullink
>making more RAM available to my DOS application.
> But by having a smaller handles table, is it possible that this will
>negatively affect my application
It won't affect your appliction that much. These handles are for XMS
extended memory allocations. If an application uses XMS, it'll only
allocate once (all memory it needs). If you're using resident tools
which use XMS (such as RAMDRIVE and SMARTDRV), it will
affect your application as these two resident tools will use all
available handles.
Again, check with MEM /C and MEM /D how much is used by
what. Fiddling with some switches in config.sys can max out
memory use.
E.g the reason I use the odd nummer of 23 for buffers is because
DOS tries to use 'high' memory first. When DOS loads the main
resident portion of DOS up (using the DOS=HIGH switch in
config.sys), there isn't space for 24 buffers anymore.
My optimum configuration has 631KB free of 640KB. Could be
636KB if I try harder... :-)
H
Matthias Paul
>> I'm wondering how the numhandles switch for himem.sys in
>> DOS 6.22 affects the environment for DOS applications
> It sets the size of the handles table. A low number will
> have a smaller table size, taking less RAM.
Yes, but is the EMB handle table actually stored in DOS memory?
I haven't tried right now, if playing with HIMEM.SYS /NUMHANDLES=n
changes the DOS memory layout...
Anyway, if one handle consumes 6 bytes (as per doc) the difference
between the default 32 and 2 would sum up to just 180 bytes or ca.
12 paragraphs. Even the maximum difference (128 handles) would
still account to just 756 bytes or 48 paragraphs.
>> I've been trying to get a DOS application to run, the only way
>> I could get it to start up was by setting the numhandles
>> switch equal to 2 in the config.sys.
> I guess the DOS application needs a lot of base RAM.
I am a bit sceptical this little difference would have such an
impact on the free conventional memory, that it could cause the
application to run or not to run. So, without knowing better
details (does the program make use of XMS memory at all?),
I assume the problem is elsewhere.
Another possible explanation is that the application can take
advantage of XMS memory, but needs /more/ than two XMS handles
to make any good use of it at all. And since there are less
handles available (maybe the two are already used up by other
programs?), the program reverts to other types of memory, like,
for example, EMS or disk swapping.
Assuming that something fishy might be going on inside of
MS-DOS HIMEM.SYS 3.10 (from 1993) on a 512 Mb (!) system,
not having enough handles might keep the application from
using XMS and therefore from running into a possible problem
in the XMS implementation. Do all other XMS clients run
fine on this system?
Without knowing the program (name? version?) and the exact
behaviour of the program and/or the system when the problem
occurs (Does it hang? Does it give an error message? Does
it run wild?), it will all remain speculation, I'm afraid.
How much of your 512 Mb are detected by MS-DOS 6.22 HIMEM.SYS,
actually? Does your program work without /NUMHANDLES=2, when
you strip this down to 256 Mb or even to 64 Mb (if possible) -
either physically or with XMSSIZE?
Also, it might be interesting to run a few cross-checks with other,
more modern memory managers, for example with the MS-DOS 7.10
HIMEM.SYS, the PC DOS 2000 HIMEM.SYS, or the DR-DOS 7.03 EMM386.EXE.
Hope it helps,
Matthias
--
<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
Marco van de Voort
> On 2002-10-27, Herman Dullink wrote:
>
>>> I've been trying to get a DOS application to run, the only way
>>> I could get it to start up was by setting the numhandles
>>> switch equal to 2 in the config.sys.
>> I guess the DOS application needs a lot of base RAM.
>
> I am a bit sceptical this little difference would have such an
> impact on the free conventional memory, that it could cause the
> application to run or not to run. So, without knowing better
> details (does the program make use of XMS memory at all?),
> I assume the problem is elsewhere.
Those memmanagers get loaded quite early. Maybe it simply makes an UMB
block to small to load a certain TSR -> it is loaded low.
Ryan Cabanas
Thanks for posting. I put my replies below yours.
"Matthias Paul" <Matthi...@post.rwth-aachen.de> wrote in message news:<apm4vl$ejr$1...@nets3.rz.RWTH-Aachen.DE>...
> On 2002-10-27, Herman Dullink wrote:
>
> >> I'm wondering how the numhandles switch for himem.sys in
> >> DOS 6.22 affects the environment for DOS applications
> > It sets the size of the handles table. A low number will
> > have a smaller table size, taking less RAM.
>
> Yes, but is the EMB handle table actually stored in DOS memory?
> I haven't tried right now, if playing with HIMEM.SYS /NUMHANDLES=n
> changes the DOS memory layout...
>
> Anyway, if one handle consumes 6 bytes (as per doc) the difference
> between the default 32 and 2 would sum up to just 180 bytes or ca.
> 12 paragraphs. Even the maximum difference (128 handles) would
> still account to just 756 bytes or 48 paragraphs.
>
> >> I've been trying to get a DOS application to run, the only way
> >> I could get it to start up was by setting the numhandles
> >> switch equal to 2 in the config.sys.
> > I guess the DOS application needs a lot of base RAM.
>
> I am a bit sceptical this little difference would have such an
> impact on the free conventional memory, that it could cause the
> application to run or not to run. So, without knowing better
> details (does the program make use of XMS memory at all?),
> I assume the problem is elsewhere.
No. With the /numhandles=2 I'm not having a problem starting the
program. With this switch I have something like 596KB of conventional
and the program only requires 512KB. It starts up fine.
No, the program only needs Expanded memory (at least that's what the
very underqualified technical support staff for this program said). I
have no idea whether or not it really does use Extended memory as
well.
The problem was that I could not get my DOS application to run when I
had himem.sys in the config.sys file, without making any changes to
the /numhandles switch. The program would give me a Cobol error when
trying to start. I found that by using the /numhandles switch and
setting it to 2, the program would run. And with this setting, when I
looked at the memory available, it states that I have 32MB of Expanded
memory. Since the program only requires a minimum of 640KB of
Expanded memory, I figured I was okay there. But I do not know what
will happen with the /numhandles setting so low, since I do not know
for absolute certain if the program does use Extended memory as well
and it was my understanding that the /numhandles switch affects the
usage of Extended memory.
>
> Another possible explanation is that the application can take
> advantage of XMS memory, but needs /more/ than two XMS handles
> to make any good use of it at all. And since there are less
> handles available (maybe the two are already used up by other
> programs?), the program reverts to other types of memory, like,
> for example, EMS or disk swapping.
> Assuming that something fishy might be going on inside of
> MS-DOS HIMEM.SYS 3.10 (from 1993) on a 512 Mb (!) system,
> not having enough handles might keep the application from
> using XMS and therefore from running into a possible problem
> in the XMS implementation. Do all other XMS clients run
> fine on this system?
>
I do not have any other DOS programs running, other than WordPerfect
5.1, and to tell you the truth I have not tried running that program
with these config.sys settings yet.
The DOS application in question will start just fine with the
/numhandles switch set to 2. My main concern is whether or not having
this setting so low will affect my program once I start using it. I
know that this is probably not possible to answer since I can't give
you a definite answer as to whether or not it makes us of Extended
memory at all. Then if that statement is correct, does that imply
that only programs that make use of Extended memory would be affected
by this change, or would all programs? If only programs that make use
of Extended memory, then I would have to speculate that this program
does make use of Extended memory in some way because in order to get
the program to run I had to add this /numhandles switch and change it
to 2. Therefore, this program was affected by a change that only
programs that use Extended memory are affected by.
> Without knowing the program (name? version?) and the exact
> behaviour of the program and/or the system when the problem
> occurs (Does it hang? Does it give an error message? Does
> it run wild?), it will all remain speculation, I'm afraid.
>
The program is an accounting software program for farming called
"Famous" and the version is 5.8c. I doubt anyone has heard of it and
they would be wise to keep it that way.
So far, with the /numhandles setting set to 2, I've been able to start
the program without any problems. I've not had a chance to get into
it deeply and see if any errors occur once I start using the program
fully.
The reason for this initial post was to see if there was any general
speculation that DOS-knowledgeable people would be able to make as to
the possible negative results I might experience from setting the
/numhandles switch so low. Not that I have a choice in what to set
the /numhandles swith at because the program will only run when it's
set to 1 or 2, but I was just curious as to the possible side-effects
I might expect due to the /numhandles switch being set so low.
> How much of your 512 Mb are detected by MS-DOS 6.22 HIMEM.SYS,
> actually? Does your program work without /NUMHANDLES=2, when
> you strip this down to 256 Mb or even to 64 Mb (if possible) -
> either physically or with XMSSIZE?
The actual amount of memory that is detected by himem.sys is 64MB.
32MB of that is made to be Expanded memory, which is what I want,
because the program (according to the program's technical support
staff) uses Expanded memory.
>
> Also, it might be interesting to run a few cross-checks with other,
> more modern memory managers, for example with the MS-DOS 7.10
> HIMEM.SYS, the PC DOS 2000 HIMEM.SYS, or the DR-DOS 7.03 EMM386.EXE.
I tried using the himem.sys file from Win95 and Win98 (this was before
I found out the /numhandles setting had to be changed, so these files
were used without any switches), but the program still gave me a Cobol
error when I tried to run it.
Thanks for your posts Matthias. I look forward to your reply.
Ryan Cabanas
>
> Hope it helps,
>
> Matthias
Matthias Paul
> The problem was that I could not get my DOS application to run when
> I had himem.sys in the config.sys file, without making any changes
> to the /numhandles switch. The program would give me a Cobol error
> when trying to start.
I'm no Cobol expert, but other's might be. What's the exact error
message, please - if for nothing else, then at least for the records?
It could become important to know, since the problem may be very
well down to a bug or shortcoming in a memory management library
used by your application. Do you know, which version of Cobol was
used to develop your application?
> I found that by using the /numhandles switch and setting it to 2,
> the program would run. And with this setting, when I looked at
> the memory available, it states that I have 32MB of Expanded memory.
When you remove the /NUMHANDLES switch, how much free conventional
memory and EMS memory does MEM report?
> But I do not know what will happen with the /numhandles setting so
> low, since I do not know for absolute certain if the program does
> use Extended memory as well and it was my understanding that the
> /numhandles switch affects the usage of Extended memory.
If you can, please try to find a version of Quarterdeck's QEMM,
which includes a nice system-info tool named Manifest (MFT.EXE).
Besides a lot of other useful info, this utility will tell you
the number of currently available XMS and EMS handles.
You can use it to find out if there are still any XMS handles
available when you are about to start your application. It will
also tell you, if there are actually any free EMS handles to
use for your application (see below).
You can also run MFT.EXE in TSR mode and pop it up while your
application is up and running, so you can see the changes
in the amount of available handles anytime at runtime.
This will definitely tell you what kind of memory is
used by your farming software.
> The DOS application in question will start just fine with the
> /numhandles switch set to 2. My main concern is whether or not having
> this setting so low will affect my program once I start using it.
Most applications only need one EMS or XMS handle at a time, but
only the developers of your application will know if this applies
to your particular program, too. MFT.EXE may give you a good hint
as well, but the memory utilization may change under more heavy
use, of course.
> Then if that statement is correct, does that imply that only programs
> that make use of Extended memory would be affected by this change,
> or would all programs?
In theory, yes. HIMEM.SYS is an XMS provider, that is, it will
make Extended Memory available through the XMS API.
/All/ XMS clients are affected by a change in the amount of XMS
handles, but programs not using XMS should not normally be affected
by this (other than a slight possible change in the DOS memory
footprint for the XMS driver itself, in case the handle table
is actually stored in DOS memory.)
However, depending on circumstances there may be more XMS clients
in your system then you expect. A disk cache might be, or a RAM disk.
You mentioned that your program uses Expanded Memory. This tells us
that an EMS driver must be present as well. If you don't use some
hardware EMS (rare these days, in particular EMS 4.0 boards with
32 Mb), you will most probably also have loaded an 386 EMS emulator
like EMM386 in addition to HIMEM.SYS.
An EMM386 style driver will use XMS to emulate EMS, so it will use
up at least some of the available XMS handles as well. So, changing
/NUMHANDLES may indirectly also affect your programs using EMS.
A (maybe not so) hypothetical scenario could be that EMM386 provides
32 Mb of EMS memory, but then there are no free EMS handles left to
use it when your application queries the EMS API, since through
indirect means using EMS memory will also use up XMS memory.
Since I use the much advanced DR-DOS EMM386, which manages all this
dynamically from the same shared pool of memory, I am not completely
familiar how less advanced memory managers like the MS-DOS EMM386
work in this situation (that's why I suggested to also try the
DR-DOS EMM386). As far as I know, MS-DOS EMM386 allocates EMS memory
statically, so it will probably need one XMS handle to provide
EMS memory. Does someone know?
>> Without knowing the program (name? version?) and the exact
>> behaviour of the program and/or the system when the problem
>> occurs (Does it hang? Does it give an error message? Does
>> it run wild?), it will all remain speculation, I'm afraid.
>>
> The program is an accounting software program for farming called
> "Famous" and the version is 5.8c. I doubt anyone has heard of it
> and they would be wise to keep it that way.
;-) Thanks. It's still useful for the records. Please mind, that
all newsgroup posts get archived and are searchable with Google.
If someone in ten or twenty years time will run into the same
problem, he might need this very info, and cannot ask the
original posters any more... So, to make a thread useful for
others beyond just solving one's individual problems, it is
important to give as much complete background info as possible
for references purposes.
> The reason for this initial post was to see if there was any general
> speculation that DOS-knowledgeable people would be able to make as to
> the possible negative results I might experience from setting the
> /numhandles switch so low. Not that I have a choice in what to set
> the /numhandles swith at because the program will only run when it's
> set to 1 or 2, but I was just curious as to the possible side-effects
> I might expect due to the /numhandles switch being set so low.
For most other programs, it is just the opposite. They won't run
unless there is at least a minimum amount of handles.
That's why I think, that your program /stops/ (not /starts/)
using one memory resource when you change the amount of handles
to be so low.
If this would be the case, this would indicate, that there is
something fishy in the interaction of your program with this
resource, when it is available.
Two possible scenarios:
- Your program was designed to support both, XMS and EMS, but XMS
is buggy, for what reasons ever. So the developers/supports tell
you, it will need EMS, but forget to tell you that you /must/
not have XMS memory at the same time.
Maybe the program is so old (XT and early AT times), that having
(hardware) EMS, but no XMS, was a common scenario.
- Your program uses only EMS, but bails out because it does not
expect so much EMS memory to be available. EMS 2 - 3.2 maxed
out at 8 Mb, EMS 4.0 at 32 Mb (although some EMS emulators can
provide more). If your program was designed with EMS 2, 3.0, or
3.2 in mind, the programmers might have take the size query
function reporting 32 Mb of free EMS memory to be an error.
Unless your programs makes special use of EMS 4.0 features,
the EMS memory could just as well be provided by a harddisk
swapping. Slow, but it would work. So, it would not be unthinkable
that your program reverts to use harddisk swapping in case it does
not find EMS at all.
(And the supporters tell you it needs EMS, because they consider
hard disk swapping to be too slow - unless swapping to a RAM disk).
>> How much of your 512 Mb are detected by MS-DOS 6.22 HIMEM.SYS,
>> actually? Does your program work without /NUMHANDLES=2, when
>> you strip this down to 256 Mb or even to 64 Mb (if possible) -
>> either physically or with XMSSIZE?
>
> The actual amount of memory that is detected by himem.sys is 64MB.
> 32MB of that is made to be Expanded memory, which is what I want,
> because the program (according to the program's technical support
> staff) uses Expanded memory.
Ok, let's try a few things:
Reduce the amount of EMS memory available to 7 Mb (to be well below
the EMS 3.2 limit of 8 Mb). If your program still works, try if
it still works if you increase or remove /NUMHANDLES again.
Get Marko Kohtala's SRDISK resizeable RAM disk driver 2.xx from the
net and use the XMSSIZE utility in his distribution to change the
reported amount of XMS memory in your system to be 15 Mb (to be
below 16 Mb). Change /NUMHANDLES as above and see if it works.
Alternatively, you can use the EMS.COM and XMS.COM utilities shipping
with Quarterdeck's QEMM and make a few pseudo-allocations and see
if this changes the behaviour of your program.
>> Also, it might be interesting to run a few cross-checks with other,
>> more modern memory managers, for example with the MS-DOS 7.10
>> HIMEM.SYS, the PC DOS 2000 HIMEM.SYS, or the DR-DOS 7.03 EMM386.EXE.
>
> I tried using the himem.sys file from Win95 and Win98 (this was before
> I found out the /numhandles setting had to be changed, so these files
> were used without any switches), but the program still gave me a Cobol
> error when I tried to run it.
Try them again, this time with /NUMHANDLES. Also try the DR-DOS EMM386
(http://www.drdos.org), this works without an external HIMEM.SYS.
Ryan Cabanas
Thank you so much for posting back. I'm sorry that I haven't
responded sooner. I won't be able to test my software thoroughly
until this weekend (11/09/02) and I will post as soon as I see how it
goes. Thank you for helping me and helping to get this information
out there for others who may run into the same problems that I am. I
look forward to hearing from you again.
Ryan Cabanas
"Matthias Paul" <Matthi...@post.rwth-aachen.de> wrote in message news:<aq354q$kqq$1...@nets3.rz.RWTH-Aachen.DE>...
Ryan Cabanas
Well, the program will run with /numhandles=2 (although it does act a
little slow), but now I've run into another problem that is not
related to memory. I will have to start a new thread in a new group
for this now.
The problem is that the program makes diskette backups of the
pertinent company data and it looks for BACKUP.EXE to do this. Well,
in DOS 6.22 the program is called MSBACKUP.EXE. I renamed it to
BACKUP.EXE, but when it goes to do the backup it says that the command
line in the *.set file is not recognized and asks if I want to use the
default.set file. If I say 'yes', it will get to the backup screen,
but it will not specify the files that need to be backed up anymore
because I'm using just the default.set file.
I tried copying the BACKUP.EXE file from the DOS version that comes
with Windows 3.11 (because that's what system we had this program on
before and are running it on right now until we can get this to work),
but I got a message saying that it was the wrong DOS version (when
trying to use the diskette backup feature in the program).
I don't know what to do anymore. I'm so frustrated with this program.
It just wasn't meant to run on machines like this. It's been nothing
but a nightmare. Thank you for your help.
Ryan Cabanas
Matthias Paul
> The problem is that the program makes diskette backups of the
> pertinent company data and it looks for BACKUP.EXE to do this.
> Well, in DOS 6.22 the program is called MSBACKUP.EXE. I renamed
> it to BACKUP.EXE,
It won't work, because MSBACKUP is not the same as BACKUP.
Despite its name, MSBACKUP is essentially a modified version
of Central Point's PC Tools PCBACKUP, which is a good program
in itself, but not compatible with the traditional BACKUP.
> I tried copying the BACKUP.EXE file from the DOS version that comes
> with Windows 3.11 (because that's what system we had this program on
> before and are running it on right now until we can get this to work),
> but I got a message saying that it was the wrong DOS version (when
> trying to use the diskette backup feature in the program).
>
> I don't know what to do anymore. I'm so frustrated with this program.
Don't worry, that's just Microsoft at its best. ;-) Provide a program
to restore backups which only works under a particular version of DOS,
which - in any real world use - is is very likely not the same version
of DOS, which was once used to create the original backup. Now, combine
this scenario with the fact that the corresponding SYS utility only
works
under the version of DOS it is about to SYS, you can easily lock ourself
out of the system, if you don't have the original installation disks at
hands all the time, or start playing tricks... (All these problems are
totally unknown under any issue of DR-DOS.)
You have two options:
- Either use the SETVER device driver to fake a different DOS version
(the original DOS version this particular BACKUP was written for).
- Use the BACKUP file from DR-DOS, which is option and data compatible
with the MS-DOS/PC DOS BACKUP, provides a number of extra options,
and works under any DOS issue without restrictions.
(You might also consider to switch over to DR-DOS completely,
which should give you long list of smaller and larger advantages
over MS-DOS. Using the DR-DOS LOADER utility, you can even install
it in parallel to MS-DOS, so you switch back and forth between both
systems for easier migration. There's only one potential problem,
using the DR-DOS EMM386.EXE driver on a very modern machine often
requires quite some tweaking or won't work at all. But the MS-DOS
EMM386 also works under DR-DOS, of course.)
> It just wasn't meant to run on machines like this. It's been
> nothing but a nightmare.
Na, don't give up so soon.
It is a bit difficult to guess from here, since there are still
many of my questions left unanswered and you do not seem to have
the right test tools at hands to find out easily. Otherwise, it
should be easy to isolate the cause of the memory problems and
treak the system to your requirements.
I suggest you try to let a local DOS expert investigate the problem.
For an experienced person, it should be easy to isolate the cause
There's no magic about it, it just needs knowledge about the possible
implications and where to look for problems. Advanced Windows
users won't be of much help here.
If all else fails, just get a used second hand machine, something
of the 200 - 400 MHz era 1997 - 1999. If you have the choice,
my personal recommendation would be an ASUS P/I-P55T2P4 Rev 3.1
mainboard with the Intel 430HX chipset. They are cheap, well-
designed, and rock-solid, fast enough for "anything DOS", and
support all essential peripherals. Latest BIOS versions even support
the AMD K6-2 and K6-III CPUs up to 450 MHz (requires an extra power
adapter), if you can still get ahold of them somewhere, otherwise
an Intel Pentium 230 MMX or even a Pentium Classic would probably
be fast enough for your application as well.