how to increased conventional memory and use ems?

[Paul Purvis]

the conclusion i have come up with is, the line in the config.sys for emm386.exe to use ems and umbs should be
DEVICE=EMM386.EXE 16384 RAM
or a number higher than 16384 should be use in my systems or even
DEVICE=EMM386.EXE RAM
to get as much as 32mb of ems and umb area in my system that has 128mb memory install.
lotus version 4 was stubborn about a lesser amount used for ems memory below 12mb.
on about 10 other systems with 12mb of memory up to 24mb of memory i just used the line
DEVICE=EMM386.EXE RAM
to achieve ems memory and umb area
all systems are pentium based processors if that would make a difference
also to note, i also have the line in the config.sys
DEVICE=HIMEM.SYS
DOS=HIGH,UMB
i am using the versions of himem.sys and emm386.exe that where distributed with win98se
wordperf 6.0 never had a problem with any settings of particular amounts used for ems.
i hope this information was not covered before on a powerbasic forums, booting several configurations
of config.sys is never popular, with me or anybody else i know, it seems to be an unwanted pain.
i hope this saves somebody some time as lotus 123 and wordperf are two popular programs found on
many machines using pure dos(msdos,pcdos,etc).
it seems that now i will be able to use powerbasic programs that use ems, so now i can move on to
the benefits achieved with programs written that use ems(tsr,hugh arrays,etc.)



[This message has been edited by paul d purvis (edited June 12, 2003).]

[Paul Purvis]

thank you individuals for your answers, and i am sure a lot of others considered the problem as well.
i have learned how to have ems and umbs using emm386.exe, but i have aslo run into some trouble.
i added the key work RAM in the command tail on the line device=emm386.exe, and sure enough i gained
umb space for loading some programs, and i use lotus 123 version 4 which did not load when i did that.
we(our company) use two large memory hogs, lotus 123 and wordperf verson 6, with wordperf being the biggest hog.
wordperf loaded up fine. i also have several other programs that can benefit from ems. i have used quarterdeck
products in the past, matter of fact the version i found under the dust was version 2.??. i learned a long time ago,
try to keep a standard if possible and keep it simple. ems for the most point is needed in pb/dos 3.5 in my use, as i want
to write some programs with the compiler. i personally have had good use of the xms todate and i know ems was popular during
the beginning years when extra memory beyond the 640mb conventional was being created. powerbasic set that using ems to be their
standard of using memory above 640mb like some many other companies, and the why is not important and i know that if
msdos was the number 1 operating system today they would have a some way using xms, but msdos is not the standard so
if i were them, i would not worry about using xms either. QEMM it seems is free now for the downloading and it maybe a great
program, but as some have already pointed out, it could also make my life miserable.
Smartdrv, windows 3.11, lantastic, and other programs (matter of fact i am using a cpm emulation software call unidos),
seem to have little problems with himem.sys and emm386.exe, but i want my cake and eat it too in this situation. the way i feel
is that all programs have their downsides and memory managers do too, but i really do not want to go from the frying pan into the
fire. i saw an nice article on a website the other day trying to solve my ems and umb problem, if you lookup the key word, UMBINFO,
you can find this site, it is about setting up your operation system.
once again the many thanks for the great answers and i will never say never, i might be advocating qemm next week.
paul

example of emm386.exe that gives 2048mb ems
device=emm386.exe 2048 ram
as i have read on a website, there is a quirk on using the key word RAM on the emm386.exe line.
when i am successful on my journey, i will write back with the results.
also if anybody is having problems with either qemm or emm386.exe, i am very interested as i know probably
many others are also. i do understand there is a bug in the version that came with win95 version b.
if anybody out there wants a version of the emm386.exe and himem.sys i am using, you should be able to find
the newest versions from microsoft and if not i will post it on my ftp site.


------------------




[This message has been edited by paul d purvis (edited June 08, 2003).]

[Michael Mattias]

FWIW, PB/DOS v 3.5 "VIRTUAL" arrays use EMS rather than conventional memory.

MCM

[Mike Luther]

Lance is VERY correct about trying to avoid STEALTH MODE with QEMM for
generalized use or programs which are distributed to others that are
expected to work without problems.

As well, once you get to working with this utility, and have lots of boxes
to watch, you will find that all kinds of different motherboard BIOS work
is done which uses memory managment techniques that are far from any
standard, one would think. The average person gets to see very little
about this I think.

I think you will find that Lance is also quite correct about the reference
to QEMM version 8 series code. Two upgrades to that are still on the system
here for reference purposes:

1-27-01 10:28p 863661 0 QEMM803D.EXE
1-27-01 10:29p 886572 0 QEMM803W.EXE

My handbooks for both are at a remote site many miles from here. But these
are not conventional .ZIP file self unpacking executables that I can read for
checking things with PKUNZIP. Memory says that the "D" version is for a
'conventional' DOS box upgrade. The "W" version is for the WIndows upgrade
path. I have installed this level on a WIN box or two with, I think, exactly
the effects he notes.

Of other interest, QuarterDeck's Manifest analysis program will run and offer
memory debugging help for IBM's DOS-VDM sessions under OS/2! It is particularly
useful in examining such things as other than the conventional lower interrupt
number uses for hooks for TSR's, as well as complete mapping of the use of memory
which often can tell you very oblique reasons for failures. In this tool is, for
example, a handle list for files for both handle and file name. You might think,
"so what?", but odd things can be found. For example, a TSR which uses a handle
in the system that may be spoofed across to a hidden crypt name for networked use
instead of the "real" name will show both handles! Used for some techniques of
shared file work on networks, it's up to the programmer to close BOTH file handles
when you are done.

Perhaps the worst reccurant system damage I ever had to find in DOS to prove that
PB was *NOT* the source of the problem, involved a third party TSR in which the
encrypted file handle and name was closed, but *NOT* the real name one. In fact,
every time a FAX was sent from inside the PB encoded application, the TSR was
leaving a same name buffer file open with another and another and another handle
used. At one point, when the handles ran into the FAT tables, and corrupted them,
and overwrote them, it might take weeks to go back and hand de-code thousands of
data files alleged to be PB corruption ... that was *NOT* the case.

It may well be that conventional WINDOWS tools exist to figure out all this stuff
as well, and we have a far more sophisticated tool for OS/2 called THESEUS which
covers this stuff as well. There simply has to be such a tool for later WIN as
well and I'd like to know what it is if someone would post it here for future
reference, please.



------------------
Mike Luther
[email protected]

[Lance Edmonds]

EMS drivers typically allocate a 64K "page frame buffer" which normally resides somewhere between segment &H0A000 and &H0FFFF, hence EMS will reduce the UMB area by 64Kb. All access to EMS is then performed through this page frame buffer. The driver then maps the actual EMS memory (located above the 1Mb address) in and out of that buffer, typically using 16K pages.

If this 64K buffer does not leave enough UMB memory available for drivers, then they will probably load into the conventional memory area. MemMaker might be able to reorganize and optimize memory, or you could use QEMM -- it can help with this problem by using its Stealth mode to dynamically move drivers around, BUT...

QEMMs "Stealth" mode was particularly problematic on many PCs though... at least, that has been my experience, and those of quite a few other DOS programmers... I'd recommend disabling that option if any stability problems are encountered.

The bottom line is that there are limited UMB resources available, and at some point, you'll run out and you will be forces to sacrifice something -- be it conventional memory or a driver, etc.

As an aside, at least one version of QEMM (8.x?) could provide up to 64Mb of EMS too, which effectively doubles or quadruples the amount of VIRTUAL array storage PB/DOS can use over the original EMM386 drivers supplied with MS-DOS (VIRTUAL arrays can be up to 32Mb each, so 64Mb of EMS allows 2x 32Mb arrays, or 4x 16Mb arrays, or 1x 32Mb + 32x 1Mb arrays, etc).


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Joe Byrne]

I can't agree more with Mike. I don't use DOS any longer, but when I did, I had a copy of QEMM with every PC. IMHO they need to go hand-in-hand <IMG SRC="http://www.powerbasic.com/support/forums/smile.gif" ALT="smile">

------------------
Joe Byrne
mailto:[email protected]
[email protected]
</A>

[Mike Luther]

Depending on your needs, other user needs, and success at putting it all
together, you might stabilize all this on Quarterdeck's QEMM memory management
toolset. It has a couple things going for it that may be helpful.

It is, in my opinion, very well documented and the docs are clear enough
so that even if you are not a guru you can learn pretty much what to do to
get things set up and OPTIMIZE'd. Notice I capitalized that! The tool
they distribute which is used to do this is .. OPTIMZE.EXE, grin.

Secondly, another tool they distribute with the package is called Manifest,
which is MFT.EXE, as such. Manifest is, in my opinion, one of the nicest
troubleshooting tools for all this you could ask for. It pretty quicly will
spot conflicts, better ways to do things, and show you an awful lot about
what is really going on in a box!

Versions of updates for QEMM exist all the way into compatible tools for
even early WIN-95 and maybe later. Of course the argument may arise
that support is only given for MS management tools, but then finding out
exactly what tool(s) that means, versions and so on, so that what you
see is seen by everyone else is a separate hurdle, if you stumble on
the track over a loose shoelace!

<IMG SRC="http://www.powerbasic.com/support/forums/wink.gif" ALT="wink">

For what this may be worth ...


------------------
Mike Luther
[email protected]

[Mel Bishop]

Originally posted by paul d purvis:
...as i have been warned, there are bugs in the msdos 6.22...

What bugs have you been warned of? I have been using DOS 6.x for
years and haven't had any troubles with these files.

by the way mel, have you tryed the newer versions?

Not really. Haven't had a need to try mix-n-match.


------------------

[Paul Purvis]

thanks for the reply mel

as i have been warned, there are bugs in the msdos 6.22 version of emm386
i have ran the versions of emm386.exe and himem.sys also from win95 and win98 previous to win98se.
these drivers(from win98se) have solved some of the problems i was having with other versions of himem.sys and emm386.exe
but i will try and run the old versions to see if i get some umbs with ems loaded.
however, i can only try that, i will not run those versions because i have seen my problems reduce to almost nill on the newer versions
also the newer himem.sys and emm386.exe load faster for some reason also, but speed in loading is only a nice goody.

by the way mel, have you tryed the newer versions?

paul


------------------




[This message has been edited by paul d purvis (edited June 02, 2003).]

[Mel Bishop]

Originally posted by paul d purvis:
i am using himem.sys and emm386.exe programs from the os win98se on the msdos os.

If you are using pure DOS 6.22, I don't see how you can use
win98se HiMem & Emm386; But if you are, I would recommend
switching back to using the DOS 6.x files instead. That should
releast your umb back for your use.




------------------

[Paul Purvis]

hello everybody,
i have been using xms exclusively for years in a pure msdos 6.22 os.
i would like to use EMS and also keep from losing valuable conventional memory.
i am using himem.sys and emm386.exe programs from the os win98se on the msdos os.
whenever i use ems, i loss umbs for other programs that must be loaded as tsrs;
such as drivers for ansi, lan connections, smartdrv, and other programs that must be running for my
system to operate.
any helpful suggestions on increasing my conventional memory while using ems would be very much appreciated.
paul

------------------




[This message has been edited by paul d purvis (edited June 02, 2003).]