You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
...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.
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
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.
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).]
Algorithms - interesting mathematical techniques with program code included.
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.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Tweet
Comment