Thanks for the reply Andrew ..
I'm not ignoring you .. just horribly busy with my own programming work at the moment ..
The default configuration provides around 634K of free conventional memory (type 'mem' at the command prompt). You might
be able to get more somehow, but I didn't see an
obvious way of doing it.
What do you need more conventional memory for?
See below..
You can enable/disable XMS and EMS from the DOSBox
configuration file. Up to 64 Mb XMS and 64 Mb EMS.
You should get around 634K free conventional memory
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 @ 1:117/3001
--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)