Thanks for the reply Andrew ..

I'm not ignoring you .. just horribly busy with my own programming work at
the moment ..

 ac> The default configuration provides around 634K of free conventional 
 ac> memory (type 'mem' at the command prompt).  You might 
 ac> be able to get more somehow, but I didn't see an 
 ac> obvious way of doing it.

 ac> What do you need more conventional memory for?

See below..

 ac> You can enable/disable XMS and EMS from the DOSBox 
 ac> configuration file.  Up to 64 Mb XMS and 64 Mb EMS.

 ac> You should get around 634K free conventional memory 
 ac> using the same version of DOSBox on any host platform.

Well, I can live with 634K free memory, if my (personal) memory is right, grin.

I have a number of PowerBasic 3.5 programs which are HUGE in size. There
was a comment a while back in their forums pushing out the question as to
who has the largest programs in PowerBasic for DOS.  As far as I know from
the discusson there is no question as to who that is...   Me.

Long, long ago I licensed the Btrieve product for development.  And the
Btrieve 6.1.5 mission critical file system has been an absolute treasure
for what I do.  The OS/2 DOS-VDM sessions can also be set up to yield even
more than 624K of DOS free memory if you set up the parameters for either
16 color or monochrome video driver emulation.  I've actually done that for
test purposes.  And with the up to 724K total memory you can actually
compile and use even bigger executables which use the Btrieve 6.1.5 code on
up into that extra memory area.  Though as best I recall, I've avoilded
going over the 624K mark.

However, the extra memory is needed for my work in the development work
where the programs are all right at the top of available memory and can't
be debugged without a bit more, sigh.

That extra memory, combined with up to my chosed limit of 8MB of EME/XMS
high memory is where I get what I need for my roughly 620 absolutely
necessary PUBLIC variables in my suite, together with close to the maximum
limit of 2,500 private variables that is the upper limit for the PB
compiler tools.  Source lines in my programs typically run up well over the
35,000 line mark, and the only external tool I use, even for video, menuing
.. which I personally have written, is the PMSHELL program which allows for
slushing the entire DOS process into upper memory so as to make the entire
normal lower memory available for CHILD SHELL processes, complete with
passing the ENTIRE variable set to the SHELL CHILD program as needed and
restoring it on collapse.

I actually do have an official release of the Btrieve 6.1.5 code the
Pervasive crew released for OS/2 as well.  And moved to PowerBasic because
I was promised personally by Bob Zale that he was releasing PB for OS/2.
The rest of the story is interesting.  Per what was told me by an
ex-internal assembly language specialist for Bob, he finished the OS/2
version.  He printed all the CD-ROM's and material for it.  He took it all
to Las Vegas to COMDEX to release it.  At COMDEX, IBM walked up to him as
he prepared the table and told him, that if he released it for OS/2 they
would give away Visual Basic for OS/2 for FREE and break him!

He walked away from the show, destroyed the whole project, then switch to
Windows and released the entire PB line for Windows instead. It was his
only hope for financial survival and I don't blame him one bit for what he
did over this.  Again, I have no personal knowledge from Bob over this. 
This is what ws told to me and I can sure believe it from the huge fight
between IBM and Gates back at that time.  I have the official VB for OS/2
versions of things as well.  I've tried it.  It's horrible and takes
forever because VB isn't a true compiler for OS/3 as released by IBM.  It
is an interpreter product.  As part of the as-told me threat IBM made to
Bob, they told him they would change the whole VB product ot a native
compiler product as well and that the OS/2 native executables they would
produce would totally wipe him out of the speed and efficiency edge he has
had for years with his very beautiful and creative work for the PowerBasic
toolset.

However for official reasons, I cannot use Windows for any of my code. And
Bob has been promising that there will be a release of PowerBasic for LINUX
for almost six years now if my memory is correct.  After the PB OS/2 mess
and so on .. he absolutely will give no date related comments about ANY
future changes in the code and I don't blame him one bit for that vaporware
policy.  Apparently somebody else may have gone after him for the OS/2
version that was never released,  I did not.

At this time I've got upwards of 88,000 hours of server time in the OS/2
DOS-VDM game with what I've done and less than two hours of un-planned down
time at some of this.  When Bob releases PB for LINUX I'll gladly see what
the changes of that vector will produce.  But as to holding on to the
platform in the mid-stream process, if what I have will run in DOSBOX cross
platform, it might be a stabilzer mode for me to use that in the middle of
the road.  Thus the question about DOSBOX for OS/2 for research purposes.

I have over 1,300,000 lines of source covering over 124 total executables
and library modules in my code.  Somewhat a busy body maker,sigh ..  I've
got about three-fourths of it ported to Watcom C++ as a bail out.  But at
this point the projected source lines for the project will go over
6,000,000 lines from what I have as autoconversion from PB 3.5 to VAC++
done now.  In addition to one very specific string related cross compatible
issue with that I've not been able to solve personally due to C's character
based non-string cooperative array issues, there are some other functions I
just don't have time to solve yet in my auto translator executables as well
I've developed.

Maybe this explains my interest in DOSBOX and why the larger memory is
either a do or die deal for me.


--> Sleep well; OS/2's still awake! ;)

Mike {at} 1:117/3001



--- Maximus/2 3.01