Hi Tom ! >> I'm surprised you have to question this! >after ~12 years without anybody complaining, I'm surprised about you complaining.
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 default. 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 >complained. 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. Regards -- Czerno ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
