>>> I've seemed to notice Command.com locates its master environment >>> block at the top of conventional memory >>> Is this behaviour user-controllable with some switch while loading >>> FreeCOM ?
>> what would be the purpose to change this ? whee would you >> like to have it ? >>> Or otherwise, depending on the global FDConfig ? I could >>> not find a way to change this - which is not a good design decision >> why is this not a good design decision ? > I'm surprised you have to question this! after ~12 years without anybody complaining, I'm surprised about you complaining. > Tis bad because the block > in question exceedingly ill-placed, 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. Of course the default > placement of an XBDA (in case there is one, that is, almost always > nowadays) 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. *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. it looks like you have a particular strange setup thaqt you are disturbed by command's environment. maybe you are mapping memory in/out dynamically ? > The "why" has been explained. In addition, 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 > 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 ;) > for that reason the end of the > 'transient program area' should as far as possible coincide with the > end of conventional (int 12) memory. > To where : by default, or absent DOS-managed UMBs, put it on top of > the main FreeDCOM code (this is how MS does it). it was easier to do it the way it is, and so far nobody complained. that's a pretty good design decision. > Optionally relocate to an available UMB. already done (in 2001). Tom ------------------------------------------------------------------------------ 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
