On Fri, 5 Jul 2013 15:45:34 GMT
"Bret Johnson" <bretj...@juno.com>
Hi Bret ! (long time, no see...)
>> ... a user who is able, one way or another, to have usable RAM
>> mapped above the 640 k so-called limit into the "video memory'
>> segments, up to 736 k (B7FFF), will be forced to use the added
>> memory as "UMB"s instead of an extension of *contiguous* so-called
>> conventional mem.
> Is this what you're trying to do (get more than 640k without
> using UMB's), and why you don't like the XBDA / master
> environment being at the top of conventional memory?
I was giving this as one example of why FreeDOS having
relegated the master environment copy to the top of conventional
mem /can/ break things. I could have given quite different examples,
nor exaples I could name old programs still available which were written
as early as the times of MS DOS 2 (!) with the implied assumption that
Command's env block follows immediately above its PSP's block.
The exact reason which made me stumble on this non-conformity of FreeCOM's does
not need to be discussed in detail, it is complex and
would derail the discussion. Fact is, some project someone else is building has
elected to use a FreeDOS boot disk for a basis, and this
bizarre, unmotivated, design of FreeCOM definitely interferes
negatively with some aspects of the project. It isn't ruining all,
and we could well use another shell than FreeCOM - in fact, I think
the project will be its own shell for a self-contained diskette or
USB-stick of sorts.
Now see! you've driven me into digressing from my initial purpose here again
Back to FreeCOM : of course we, app programmers, could devise a utility
for the purpose of moving that darned environment back to where it
belongs, i.e., low contiguous DOS-managed memory.
Leaving apart the fact that doing so from a transient DOS program and
without leaving holes is not absolutely a trivial programming task, we
would be still faced with the problem that, how are we supposed to
reliably /find/ and adjust the pointer(s) that of necessity FreeCOM internally
keeps to the environment !
Clearly IMHO it is Freecom's responsibility (i.e., of whoever is tasked with
debugging, maintaining and enhancing FreeCOM) to provide the solution,
be it a command line option, a permanent fix, or even an API.
Hoping this could be at least some food for thought, and
Taking the leave for now
This SF.net email is sponsored by Windows:
Build for Windows Store.
Freedos-user mailing list