No announcement yet.

how to increased conventional memory and use ems?

  • Filter
  • Time
  • Show
Clear All
new posts

  • how to increased conventional memory and use ems?

    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.


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

  • #2
    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.

    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.


    • #3
      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?



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


      • #4
        Originally posted by paul d purvis: 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.

        There are no atheists in a fox hole or the morning of a math test.
        If my flag offends you, I'll help you pack.


        • #5
          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="" ALT="wink">

          For what this may be worth ...

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


          • #6
            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="" ALT="smile">

            Joe Byrne
            mailto:[email protected]
            [email protected]
            Software makes Hardware Happen


            • #7
              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).

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


              • #8
                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]
                Mike Luther
                [email protected]


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

                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]


                  • #10
                    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.

                    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).]
                    p purvis


                    • #11
                      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
                      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).]
                      p purvis