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

Reply via email to