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 
> >
> 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
>
--
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  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
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 
> 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 4:17 PM, Bertho Grandpied  wrote:
> On Thu, 4 Jul 2013 21:08:12 +0200 Tom Ehlert  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 Bertho Grandpied

On Thu, 4 Jul 2013 21:08:12 +0200
Tom Ehlert  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


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


[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