[Freedos-user] command.com (Freecom) main environment location

2013-07-04 Thread Bertho Grandpied
Hi List ! 

I've seemed to notice Command.com locates its master environment block at the 
top of conventional memory, just under the video (and under a BIOS defined 
extended bios data aka EBDA, if any). 

Is this behaviour user-controllable with some switch while loading FreeCOM ? Or 
otherwise, depending on the global FDConfig ? I could not find a way to change 
this - which is not a good design decision overall IMHO, at least not if it 
can't be overridden  :-(

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


Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-04 Thread Chris Evans
That's funny, because I thought that the master environment was controlled
by the kernel.sys?
Maybe they can add a switch that forces the environment be loaded in
upper ram instead of conventional?


-Chris
Http://digitalatoll.com/
Http://tawhakisoft.com/nxdos.html


On Thursday, July 4, 2013, Bertho Grandpied wrote:

 Hi List !

 I've seemed to notice Command.com locates its master environment block at
 the top of conventional memory, just under the video (and under a BIOS
 defined extended bios data aka EBDA, if any).

 Is this behaviour user-controllable with some switch while loading FreeCOM
 ? Or otherwise, depending on the global FDConfig ? I could not find a way
 to change this - which is not a good design decision overall IMHO, at least
 not if it can't be overridden  :-(

 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 javascript:;
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
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


Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-04 Thread Tom Ehlert

 That's funny, because I thought that the master environment was
 controlled by the kernel.sys? 
obviously not as it's size is controlled by '/E:512'

 Maybe they can add a switch that
 forces the environment be loaded in upper ram instead of conventional? 

'they' could do nearly everything
at the time the environment was put to ~9f00:0 there simply didn't
exist upper memory in FreeDOS  (and having a switch to move ~512 byte
to upper memory is not s exiting ;)

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


Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-04 Thread Tom Ehlert
Hi Bertho,


 I've seemed to notice Command.com locates its master environment
 block at the top of conventional memory, just under the video (and
 under a BIOS defined extended bios data aka EBDA, if any). 

 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 ?
where would you put it and why ?


 overall IMHO, at least not if it can't be overridden  :-(

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


Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-04 Thread Bertho Grandpied

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 UMBs 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


Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-04 Thread dmccunney
On Thu, Jul 4, 2013 at 4:17 PM, Bertho Grandpied y31415926...@yahoo.fr wrote:
 On Thu, 4 Jul 2013 21:08:12 +0200 Tom Ehlert t...@drivesnapshot.de wrote :

 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.

Placing the environment at the top of conventional memory is what
MS-DOS COMMAND.COM did, and FreeDOS tries to be DOS compatible.

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.  With a CGA card you could get
96K of additional RAM.  With my Hercules card, I could get 64K. so I
booted to a system that had 704K of conventional memory.  COMMAND.COM
putting the master environment at the top of conventional memory did
not cause a problem.

While it might be nice to relocate the master environment block
elsewhere, like upper memory, it's hardly necessary.  People lived
without being able to do so for decades without problems.  I don't
ever recall hearing about the sort of problems you raise as
possibilities, and I'd call the chances of them happening rare enough
to not be worth worrying about.

If you insist on this behavior, feel free to submit a patch that adds it.
__
Dennis
https://plus.google.com/u/0/105128793974319004519

--
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


Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-04 Thread Chris Evans
So command.com controller the allocating of dos env ?
I still always thought it was a kernel level thing , as the way I coded
it in nxbio.sys
That reminds me that I need to make a dosenv.asm

-Chris
Http://digitalatoll.com
Http://tawhakisoft.com/nxdos.html




On Thursday, July 4, 2013, Tom Ehlert wrote:


  That's funny, because I thought that the master environment was
  controlled by the kernel.sys?
 obviously not as it's size is controlled by '/E:512'

  Maybe they can add a switch that
  forces the environment be loaded in upper ram instead of conventional?

 'they' could do nearly everything
 at the time the environment was put to ~9f00:0 there simply didn't
 exist upper memory in FreeDOS  (and having a switch to move ~512 byte
 to upper memory is not s exiting ;)

 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 javascript:;
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
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


Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-04 Thread dmccunney
On Thu, Jul 4, 2013 at 5:55 PM, Chris Evans aaxiomfin...@gmail.com wrote:
 So command.com controller the allocating of dos env ?
 I still always thought it was a kernel level thing , as the way I coded it
 in nxbio.sys

I misspoke.  It's more correct to say that placing it at the top of
conventional memory is what MS-DOS did, and where COMMAND.COM expected
to see it.

Same difference - it's what MS-DOS did, and what FreeDOS does to be
compatible.  I never saw it cause a problem in MS-DOS, and I don't see
it's a problem that needs to be fixed.

 -Chris
__
Dennis
https://plus.google.com/u/0/105128793974319004519

--
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


Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-04 Thread Chris Evans
I just wrote a dosenv.asm for nxbio I'll write it up to a int21 call so
user app and resize dos environment at will.


On Thursday, July 4, 2013, dmccunney wrote:

 On Thu, Jul 4, 2013 at 5:55 PM, Chris Evans 
 aaxiomfin...@gmail.comjavascript:;
 wrote:
  So command.com controller the allocating of dos env ?
  I still always thought it was a kernel level thing , as the way I coded
 it
  in nxbio.sys

 I misspoke.  It's more correct to say that placing it at the top of
 conventional memory is what MS-DOS did, and where COMMAND.COM expected
 to see it.

 Same difference - it's what MS-DOS did, and what FreeDOS does to be
 compatible.  I never saw it cause a problem in MS-DOS, and I don't see
 it's a problem that needs to be fixed.

  -Chris
 __
 Dennis
 https://plus.google.com/u/0/105128793974319004519


 --
 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 javascript:;
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
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