In composing this reply from the terrible Yahoo! web mail, I'll be trying to /force/ hard end-of-lines, not "flowed" lines, at long last! fingers crossed.
On Thu, 4 Jul 2013 dmccunney <dennis.mccun...@gmail.com> wrote: > Placing the environment at the top of conventional memory is what > MS-DOS COMMAND.COM did, and FreeDOS tries to be DOS compatible. With all due respect, you must be mistaken :-( I've used almost all versions of Microsoft from 3.2 to 8 (and assorted DRDOS versions also). They - or rather their 'command.com' always have asked for the /lowest available/ DOS memory block for their master environment, which is to say practically always the env has been immediately above the program itself. I've /never/ seen a compatible command.com, including 4DOS, use that alternate "allocation strategy" which you claim, incorrectly, was DOS's default ! Maybe, just maybe, your confusion arises from the Microsoft Command interpreter's internal use of the top of the TPA for its data (but /without/ any MCB reservation! When control is returned from a transient, they *check* for possible memory corruption in the unprotected are by way of a control sum). This is nothing to do with the environment anyway. > I never had a problem because of it. One thing I used to run on my > old PC XT clone under MS-DOS 3.3 and 5.0 was a freeware utility form > Chris (CED) Dunford. It could map unused video memory in the segment > above 640K to DOS conventional memory. Yep this is the kind of things you could do, although VGA memory was exceedingly /slow/ for executing programs from, nowadays we would map the memory in better ways - using EMM 4.0 for instance, or (with some chipsets) remapped physical memory even in CPU /real mode/. You "never had a problem"... precisely because you were using "MS-DOS 3.3 and 5.0" at the time, giving you an uninterrupted 640+96=736 k bytes of '(un)conventional' memory ! With FreeCom's environment (and/or an XBDA) in the way, you'd have been much less happy. Although you'd still got that extra memory, it would've been fragmented hence much less appealing. > COMMAND.COM putting the master environment at the top of conventional > memory It didn't ! > While it might be nice to relocate the master environment > block elsewhere, like upper memory, it's hardly necessary. This is not what I'm requesting. I'm strongly suggesting that FreeDOS should locate the master environment it creates in a way compatible to MSDOS and thanks to your kind reply I do understand the reason it is not compatible, currently, is rather a misunderstanding than any legitimate design decision. Apologies if this sounds rude, it's not meant to be ! Kind regards -- Ninho ------------------------------------------------------------------------------ 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
