On Thu, 4 Jul 2013 21:08:12 +0200 Tom Ehlert <t...@drivesnapshot.de> wrote :
>> 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! 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. We could have a separate utility for relocating Freecom's primary env, but, frankly, the command processor shoud be able take care of it itself. > where would you put it and why ? 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. 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. 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). Optionally relocate to an available UMB. >> overall IMHO, at least not if it can't be overridden :-( Re-iterating ! -- 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
