Hi Tom ! 

>> I'm surprised you have to question this!
>after ~12 years without anybody complaining, I'm surprised about you

How many users do you have ? Of these, how many understands this level of 
detail, /and/ in addition, will care ? 

Methinks you were p.ssed off by my remarks, but there is nothing 
personal to them. Who is , or are, the 'appointed maintainer(s)' for
FreeCOM ? Are you one of them ?

>> Tis bad because the block
>> in question exceedingly ill-placed
>>  Of course the default
>> placement of an XBDA (...)
>> deserves the same blame but either the kernel or some
>> utility will routinely relocate it down during Config.sys
>> processing.

> the FreeDOS kernel relocates the XBDA.

Really ? Will it ? The kernel I'm using will /not/ do it, certainly not by 

Pray tell how, if there is a way, you tell the kernel to do the down 
move; despite what some doc says on the FreeDOS site, the "switches=/E" 
command does not work (but it does in MS-DOS). Not that I need it, we've
written our own EBDA mover.

> *then* config.sys processing happens; possibly some driver maps a000-
> b7ff as conventional memory

> *then* comes command.com, and maps it's environment as high as
> possible. if b7ff is available, it will load it's environment there.
>if  ef00 is available, it's loaded there.

Why these latter limits would be thus hard-coded is beyond me. 
But never mind for the moment

In these posts I am NOT meaning to consider UMBs.
I should not have mentioned upper memory even tangentialy.
Let's limit ourselves to a DOS on an AT-compatible system which 
is not capable of supporting UMBs - or that we do not want to configure
for UMBs anyway.

That is, basic DOS system with 640 k conventional memory. 

>> it looks like you have a particular strange setup that you are 
>> disturbed by command's environment. maybe you are mapping memory
>> in/out dynamically ?

Let the setup be as defined above, a compativle with no 'upper' RAM.

>> under /some but not all/
>> BIOSes, it seems the presence of a DOS MCB-covered zone under the
>> 'video' area may perturb conventional memory reporting by the API of
>> int 15/E820. Not confirmed.

> don't make things up

I'm not making thins up, you needn't make derogatory comments. 
Then, that was off-topic and as I did write, unconfirmed.

>> Want more ? OK, additionally, some
>> (admittedly very rude, maybe very old) DOS programs will neglect to
>> check where the memory 'above' them ends, and use any and all "BIOS
>> int 12" mem without reservation.

> sure. execute such programs, and you deserve no better. CtrlAltDelete
> will clean up ;)

LOL. Admittedly the argument was far fetched. None the less,

>> this is how MS does it).

>it was easier to do it the way it is, and so far nobody

HA ! Sincerity itself, at last! Now this I /can/ understand, and even
sympathise with :=)  Not in line with what Dennis wrote, though...

> that's a pretty good design decision.

Only for so long as no one disputes it :=)... FreeCOM can't claim 
MS-Command.com compatibility until time it has an option, and 
I would suggest, the /default/, to allocate the master env block from 
the bottom, instead of the top of conventional mem.

Besides, I hardly see how it was "easier", your word, for FreeCOM to do 
it in the current way. I'd rather suspect whoever made the decision, 
back when, was confused, similar to how DM Cunney remained somehow
apparently confused to this day.

>> Optionally relocate to an available UMB.
> already done (in 2001).

I know, a good thing - but not the question.



This SF.net email is sponsored by Windows:

Build for Windows Store.

Freedos-user mailing list

Reply via email to