Text 33, 113 rader
Skriven 2007-03-31 08:42:28 av Mike Luther (1:117/3001.0)
     Kommentar till text 32 av Andrew Clarke (3:633/267.0)
Ärende: DOSBOX/2 question.
==========================
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 @ 1:117/3001



--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)