Announcement

Collapse
No announcement yet.

conventional RAM and Windows

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • conventional RAM and Windows

    A certain DOS program runs fine under Windows in a DOS
    window. Under pure DOS it aborts at start with:
    "Program too big."

    Does Windows leave more conventional RAM free than
    pure DOS does?
    Politically incorrect signatures about immigration patriots are forbidden. Googling “immigration patriots” is forbidden. Thinking about Googling ... well, don’t even think about it.

  • #2
    Just a little.

    MS-DOS allows a program to use up to 640 Kb RAM, if it is physically installed.

    Windows allows each program running to use up to 2,000,000 Kb RAM, as long as there is that much RAM+hard disk installed.

    MCM
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      ...but, that only applies to Windows programs. DOS programs are still
      limited to roughly 640K. The exact amount available depends a great
      deal on the operating system, and what device drivers and/or TSRs are
      running (usually, more of an issue for pure DOS systems).

      You might start with the DOS command, MEM, which will tell you where
      the memory is going. Run MEM /C from the command prompt. You may be
      able to reclaim some base memory by removing unnecessary drivers or
      by loading them into upper memory (via LH or LOADHIGH, if I remember
      correctly, on reasonably current DOS versions; this was introduced in
      DOS 5.0 or so).

      My Windows 2000 machine at work provides a maximum DOS program size
      of 630,336 bytes, FWIW.

      ------------------
      Tom Hanlin
      PowerBASIC Staff

      Comment


      • #4
        And as a DOS-VDM, even after the Btrieve Engine is loaded along with
        two other TSR's here's what I see in OS/2 from a MEM run at the prompt:

        DOS Ctrl+Esc = Window List
        (C) Copyright 1982-1995, Btrieve Technologies, Inc.
        All Rights Reserved.

        MicroKernel Database Engine v6.15.430
        Copyright (c) 1982-1996, Pervasive Software, Inc.
        All Rights Reserved.

        DOSLOGAC uses Int# 96


        752640 bytes total memory
        752640 bytes available for DOS
        671840 largest executable program size

        8781824 bytes total EMS memory
        8388608 bytes free EMS memory

        2031616 bytes total XMS memory
        2031616 bytes available XMS memory
        ------0 bytes available contiguous extended memory
        DOS resident in High Memory Area
        High Memory Area in use

        As well, the little utility MAPMEM shows:

        MAPMEM 3.5, Copyright 1993 TurboPower Software

        Psp Cnt Size Name Command Line Hooked Vectors
        ---- --- ------ ---------- ------------------- ---------------------
        ---- 3 20,672 DOS
        0510 2 5,232 COMMAND 22 23 24 2E
        ---- 1 192 ---free---
        0666 1 2,336 TAME n/a 10 14 15 16 17 21 28
        ---- 1 44,576 ---free---
        0719 2 679,456 ---free---
        ---- 752,624 ---total--


        But that noted, exactly in line with lots of other threads on what is there
        and what is no vs. memory managers and so on, please note.

        Just because I see this, can use this, even can use even more in certain
        ways if I don't use TSR's and so on, can manipulate the whole page frame
        operation, high memory, where the excludes are for video and so on, just like
        in QEMM ...

        That does *NOT* mean everyone to which I distribute an executable I create
        with PBC, will be able to run it, and/or run it without some form of run-time
        problems.

        Upper memory management and utilization are really quite different even from
        one hardware box to another, especially as to how page frames and the use of
        the FF00 to FFFF segment is used by the BIOS for the motherboard, as I have
        tried hard to understand all this.

        For a long time now I have tried to get a statement of what the exact defacto
        standard for upper menory managent is for PB for DOS, and that comes back
        keyed to a specific spec. But that's not a clear simple table of requirements
        which most folks can be furnished which tells them step by step exactly what
        size this and that and tuning tips must be to optimize DOS for PB work, I think.

        Also important is the amount of upper memory that is present when you run DOS
        applications under more modern operating systems. For example, you create a
        DOS program with PB which does use upper memory management, and you create it
        such that it needs, say 8MB under some conditions. Your user runs it as a DOS
        program in a more modern operating system which the USER only sets the session
        up so it has, say 7MB of the required memory! The error in the program, as I
        think most of us write code, romps along until it runs out of memory, doesn't
        check to see if the required memory isn't really there. From long experience at
        all this I can tell you that out of memory issues are not black and white as to
        the errors that get thrown. It may really take work and time to figure out that
        the user simply has a session in which memory is an issue.

        Thus guidelines are really somewhat in order based on whom will be your clientele
        and how much control you can exert to make sure the session has the needed memory
        and environment for you distributed program.

        In a sort of a kind of a way, I try to keep my MAIN memory limit in the programs
        I let loose to about 450K or less than 500K needed for execution. In my case, the
        needed upper memory can routinely reach toward the 8MB values much of the time.
        So the standard OS/2 Session Settings folder for the applicable DOS-VDM session in
        the OS/2 Warp4 or Merlin Convenience Pack 4.52 is told to use an 8MB maximum EMS
        memory size, and a 2MB XMS memory allowance. As well, specifications here for some
        of the rest of the critical issues are:

        DOS_HIGH = ON
        DOS RMSIZE = 640K
        DOS_UMB = ON
        DMPI_DOS_API = AUTO
        DMPI_MEMORY_LIMIT = 16MB
        DMPI_NETWORK_BUFF_SIZE = 8K
        EMS_FRAME_LOCATION = AUTO
        EMS_HIGH_OS_MAP_REGION = 0
        EMS_LOW_OS_MAP_REGION = 384K
        EMS_MEMORY_LIMIT = 8192K
        XMS_HANDLES = 32
        XMS_MEMORY_LIMIT = 2048K
        XMS_MINIMUM_HMA = 0

        And for those folks using CGA level colors only in the DOS-VDM world of
        OS/2 you can set:

        VIDEO_MODE_RESTRICTION = CGA.

        As you can see, once the operating system lets you begin to see and set
        all this stuff really important to DOS, things get complicated! As well
        every single DOS-VDM program operation can have completely a completely
        different setup, and as well every single DOS-VDM program operation can
        have its own complete different 'AUTOEXEC.BAT' with a completely unique
        environment, path definitions, TSR's - the works!

        I'm sure these same issues are present in WIN-whatever, too, but are very
        different in some respects. For example in the OS/2 DOS-VDM or native
        world, I can as an optional choice, still have direct access to the hardware
        and communications ports! I don't do this, but if I did, that would create
        yet other problems if I wanted to run the code on other platforms. Back to
        the memory issues and conclusion.

        Plan carefully what you encode as to memory choices. Try hard not to fall
        into the pit of creating something which will be very difficult to use
        for a person who may not have your specific operating system platform.


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

        [This message has been edited by Mike Luther (edited June 20, 2003).]
        Mike Luther
        [email protected]

        Comment


        • #5
          Michael --

          I doubled the size of all the arrays in the program
          (thus using more RAM but well under 2 KKK) just
          to see if it would still run in a DOS window under
          Windows.

          It compiled, but when run it gave the "Program
          too big" message, just as the original (smaller)
          version had under pure DOS.

          Tom --

          I'd forgotten about that mem/c command. When
          I tried it in Windows there are only three processes
          using conventional RAM, leaving 614 K free, whereas
          in pure DOS there were five, leaving only 561 K free.

          What suprises me is that Windows leaves more
          RAM than pure DOS -- I expected the other way
          around.

          Anyway, as Mike says, one should be conservative
          in either case. Or make all the array's dynamic
          and dimension them only after a fre(-1).


          [This message has been edited by Mark Hunter (edited June 20, 2003).]
          Politically incorrect signatures about immigration patriots are forbidden. Googling “immigration patriots” is forbidden. Thinking about Googling ... well, don’t even think about it.

          Comment


          • #6
            In pure DOS, all programs have to share that base 640K (or so). In
            32-bit Windows, there is no "base" memory-- hardware drivers and
            other Windows programs have access to whatever RAM is available,
            plus virtual memory that's paged to/from disk. When Windows creates
            a "DOS box", it's actually putting together a fake "base memory"
            block so that DOS programs will feel at home. To the extent that it
            can replace DOS drivers with Windows drivers, the former DOS drivers
            no longer take up any "base memory" space. So, there may well be more
            "base memory" available to a DOS program running under Windows.


            ------------------
            Tom Hanlin
            PowerBASIC Staff

            Comment

            Working...
            X