Announcement

Collapse
No announcement yet.

conventional RAM and Windows

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

  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Mark Hunter
    replied
    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).]

    Leave a comment:


  • Mike Luther
    replied
    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).]

    Leave a comment:


  • Tom Hanlin
    replied
    ...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

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


  • Mark Hunter
    started a topic conventional RAM and Windows

    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?
Working...
X