Re: [Freedos-user] Re : Freedos-user Digest, Vol 808, Issue 1

[Tom Ehlert]

> Thanks. It would work indeed because - as I was checking a few minutes
> before reading your mail - FreeCOM does maintain the master environment
> pointer (its segment) in its PSP:3Ch slot, additionally FreeCOM seems
> to use the contents of that 'slot', not some copy it made, whenever
> it needs to access the ENV.

that's how 'edit the parent/master environment' utilities work(ed),
it's 'documented undocumented' behaviour, and FreeCOM behaves and has
to behave) the same way.
> At least a search (using debug!) did not
> find the environment segment, as data, inside FreeCOM's live memory.

> Of course it could be keeping the live ENV's segment in 
> registers, but since that is "C" it's dubious registers are used for 
> long time storage (contrary to what ASM code does profusely, at least mine).

if the master environment would be simply
'data' with some internal variable pointing to it, the master
environment would be obviously swapped out (or located at :)

but of course you knew that

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] Re : Freedos-user Digest, Vol 808, Issue 1

[Matej Horvat]

> My bet would be on JEMM as the one which messes with memory control  
> blocks.

You're right. It is JEMM.

> Yup. TSRs which are never unloaded would not be a problem, otherwise
> they could leave holes, but that's life... One could even re-run your
> program and try to relocate the ENV again into such a hole, if it's big
> enough :=)

Sure, you can run it any number of times.

> FreeCOM does maintain the master environment
> pointer (its segment) in its PSP:3Ch slot, additionally FreeCOM seems
> to use the contents of that 'slot', not some copy it made, whenever
> it needs to access the ENV.

3Ch is reserved as far as I know. Do you mean 2Ch? That's what my program  
modifies.

--
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] Re : Freedos-user Digest, Vol 808, Issue 1

[Bertho Grandpied]

Hi, Matej Horvat: 

> I've spent the last three hours writing a tiny COM program that moves
> COMMAND.COM's environment block to the lowest address possible (using
> DOS's "low memory first fit" strategy). 

Nice !

> Unfortunately, it does not seem to  
> be able to find the environment block if used in AUTOEXEC.BAT after 
> HIMEMX and JEMM386 were loaded in FDCONFIG.SYS (I only tested both at the 
> same  
> time, so I don't know which one causes the problem), 

My bet would be on JEMM as the one which messes with memory control blocks. 

> but it works if run  
> after AUTOEXEC.BAT has been processed (for some reason - but by then
> you may have TSRs loaded between COMMAND.COM and its environment,
> which may or may not be OK for your needs) or if those two drivers are not 
> loaded.

Yup. TSRs which are never unloaded would not be a problem, otherwise 
they could leave holes, but that's life... One could even re-run your 
program and try to relocate the ENV again into such a hole, if it's big
enough :=)

> So for example, without HIMEMX and JEMM386, FreeCOM will allocate its
> environment block at e. g. segment 9F7F, but after running the program,
> the environment block will reside at segment 23B4, almost immediately
>after COMMAND.COM (it depends on the order in which you load TSRs).

Thanks. It would work indeed because - as I was checking a few minutes
before reading your mail - FreeCOM does maintain the master environment
pointer (its segment) in its PSP:3Ch slot, additionally FreeCOM seems
to use the contents of that 'slot', not some copy it made, whenever
it needs to access the ENV. At least a search (using debug!) did not
find the environment segment, as data, inside FreeCOM's live memory.

Of course it could be keeping the live ENV's segment in 
registers, but since that is "C" it's dubious registers are used for 
long time storage (contrary to what ASM code does profusely, at least mine).

Of course, I presume your program does care to adjust the PSP:3C pointer.

> Please contact me off-list if you want to try it out.

Well, thank you. A fully satisfactory solution ought to come from
FreeCOM's initialisation itself, though.

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

[Matej Horvat]

Hi Bertho,

I've spent the last three hours writing a tiny COM program that moves  
COMMAND.COM's environment block to the lowest address possible (using  
DOS's "low memory first fit" strategy). Unfortunately, it does not seem to  
be able to find the environment block if used in AUTOEXEC.BAT after HIMEMX  
and JEMM386 were loaded in FDCONFIG.SYS (I only tested both at the same  
time, so I don't know which one causes the problem), but it works if run  
after AUTOEXEC.BAT has been processed (for some reason - but by then you  
may have TSRs loaded between COMMAND.COM and its environment, which may or  
may not be OK for your needs) or if those two drivers are not loaded.

So for example, without HIMEMX and JEMM386, FreeCOM will allocate its  
environment block at e. g. segment 9F7F, but after running the program,  
the environment block will reside at segment 23B4, almost immediately  
after COMMAND.COM (it depends on the order in which you load TSRs).

Please contact me off-list if you want to try it out.

Matej Horvat
http://matejhorvat.si/

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

[Rugxulo]

Hi,

On Mon, Jul 8, 2013 at 10:06 AM, Bertho Grandpied  wrote:
>
> Should OTOH you (and the FreeDOS project at large) wish to offer the
> free XBDA mover as a supplement/alternative to FreeDOS's internal, I'll
> contact you for arranging the mirroring. It's a simple, robust and
> tiny DOS device driver coded in ASM, a few hundred bytes altogether.

A nice readme.txt telling how to use it would be most helpful.  :-)
But yes, of course, anything free/libre (four freedoms) can be
mirrored.

>> 4DOS is ambiguously licensed. I don't really recommend it
>
> I /love/ 4DOS - been using it for 20 years - used to be NDOS.
> For internal use, it must be OK, right ?

I don't know, I'm no lawyer. I don't even want to think about it. It's
out of my hands anyways. (And now I remember that Bernd put it in FD
1.1 anyways, maybe as default!)

> The question wrt to licensing was rather whether 4DOS.COM could be legally 
> envisaged to become FreeCOM as FreeDOS official, or "alternate
> official?" shell.

It's not as easy as it sounds to be compatible between shells with
.BAT scripts. Personally, I stick to plain .BAT (usually FreeCOM) and
third-party tools (or external scripting languages) rather than rely
on 4DOS.

Though there's nothing technically horrible about 4DOS, but it's not
really worth using exclusively, IMO. (Though, again, it's not my
decision what FreeDOS proper does.) I do have it as an optional shell
in my CONFIG.SYS menu, but I rarely use it.

> Rebuilding is one thing, patching and debugging properly is another.
> This task takes a motivated, seasoned C programmer, who preferably were
> familiar already with FreeCOM. All I can do is try to argue it, knowing
> well it's a possibility that no one will be convinced and undertake it.

Bart Oldeman is the dude to contact. He was the last one officially
working on it (circa late 2011). You may have to email him directly,
but again, he may be too busy these days (educated guess).

http://sourceforge.net/p/freedos/svn/1709/tree/

"freecom  2011-07-29  bartoldeman  [r1696] Merged fcompl1 and
fcompl2.c to filecomp.c"

> On the other hand, if FreeCOM hasn't been revised since 2001, maybe it's
> not to early for 'someone' to give the old code a look and some fresh
> thought.

Not sure where you got 2001 from. It's hard to tell from (very) quick
glance, but it seems 2003 (0.82) and 2006 (0.84). I know, not much
better, but still ...!  :-)

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

[Tom Ehlert]

Hi,

> Should OTOH you (and the FreeDOS project at large) wish to offer the
> free XBDA mover as a supplement/alternative to FreeDOS's internal, I'll
> contact you for arranging the mirroring. It's a simple, robust and
> tiny DOS device driver coded in ASM, a few hundred bytes altogether.
it probably should be merged into the kernel, or actually used as a
blue print to fix the bug (?) in the current kernel that prevents the
XBDA move.

> On the other hand, if FreeCOM hasn't been revised since 2001,
nobody said that.

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

[Bertho Grandpied]

Att: Rugxulo 

Hi,

> Patience, young padawan. 

I had to look that padawan up on wOOkipedia (not a typo!)  :=)
 

> Things like this take time and thought (and
research and testing).

Accepted. I've passed the message, now letting things ripen (and tone down) as 
appropriate.

> If you draw up a patch and it isn't accepted upstream into SVN, I can
still mirror it somewhere (e.g. iBiblio) for you.

I'm afraid no patch to FreeCOM is likely will be coming from me, for reasons 
already stated and rehashed. 

Should OTOH you (and the FreeDOS project at large) wish to offer the 
free XBDA mover as a supplement/alternative to FreeDOS's internal, I'll 
contact you for arranging the mirroring. It's a simple, robust and
tiny DOS device driver coded in ASM, a few hundred bytes altogether. 


>> maybe Tom does not have the patience to explain you
>> why there are good reasons why FreeDOS does things
>> the way they are done, but you can trust him :-)
(...)
>> Give him the benefit of the doubt, as he is one of the resident
experts around here who has contributed a lot. 

I think I did give the, whatever, benefit - but maybe it was not apparent ? 

> But even the smartest
> person in the world gets tired, too busy with "real life", or just
> forgets some minor details from years ago.

Sure. but the smartest person in the world won't convince me s/he 
cannot discard 100 K of temporary code/data and do some memory resizing,
move part of itself out of the way if need be - before allocating memory.

It's not exactly a beginning programmer's task, nor is it rocket science either.

[...]

>> want a command shell during project building. I'll be recommending 4DOS
>> for internal use - license allowing.

> 4DOS is ambiguously licensed. I don't really recommend it, though
> there aren't a lot of "full" shell replacements available. If you can
> avoid some (most?) .BAT internal stuff, you may find it easier to
> replace:

I /love/ 4DOS - been using it for 20 years - used to be NDOS. 
For internal use, it must be OK, right ? 
The question wrt to licensing was rather whether 4DOS.COM could be legally 
envisaged to become FreeCOM as FreeDOS official, or "alternate 
official?" shell. 

> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/contrib/

> Again, I take this to mean that (admittedly) FreeCOM is too hard to
> rebuild (preferably with TurboC). If you need help with this, feel
> free to try and ask specifically for assistance. 

Having never written a line in C makes it a no-no for myself, and no programmer 
on their small team will take  an interest in what is outside 
the realm of the project.

> (It's definitely what
> I would call slightly annoying, but it's definitely not impossible to
> rebuild either.)

Rebuilding is one thing, patching and debugging properly is another. 
This task takes a motivated, seasoned C programmer, who preferably were 
familiar already with FreeCOM. All I can do is try to argue it, knowing 
well it's a possibility that no one will be convinced and undertake it.

On the other hand, if FreeCOM hasn't been revised since 2001, maybe it's 
not to early for 'someone' to give the old code a look and some fresh 
thought.

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

[Tom Ehlert]

>> you would end up with
>>    3   K COMMAND.COM, (resident part)
>>    100 K FREE         (remainders of freecom before resizing)
>>    1   K   command.com environment (at ~1800:0)

> How lame ! Of course, your Freecom shall have to play a minimum game of
> releasing its own initialisation code and data, resizing and
> possibly moving things along. Basic DOS system coding skills, not rocket 
> science.

> This is/the/ official shell we are talking of, not some half baked
> throwable transient proggy, it deserves having a minimum of /intelligent
> design/ applied :=)

it looks like a real experienced programmer (you) has to show us
confused youngsters how it should be done!

> There are even other enhancements that could be made in the same domain,
> an easy one is to give back the /initial/ environment (if any) received by
> your Command from its caller (or from Sysinit). It is of no use after the
> Master ENV is built. Freeing it would give FreeDOS an edge over MS 
> Command. But the important is the above.
I'm deep impressed. we have a black belt grandmaster on visit. unfortunately too
busy to work, but we are so happy to receive good advice ;)


> You (or was it Eric) repeated
> that FreeCOM had to follow MS-Command,
it was dennis

> but in this respect it doesn't
> even start to try, I am /sorry/ to observe.


>>> How do you say "arrogance" in German, Herr /Doktor/ Ehlert ?
>> Arroganz.

> Itself ! I may sound harsh, but being accused of ignorance by 
> more ignorant is the only word of excuse I will utter.
this 'more' makes me think that you should prove your competence first

> Let's forget /name calling/ ? If you agree, I'm your man

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

[Rugxulo]

Hi,

On Mon, Jul 8, 2013 at 8:57 AM, Bertho Grandpied  wrote:
>
> What is the legal status of 4DOS in relation to FreeDOS ? There's a fully 
> baked
> product, could it become /the/ main FD shell ?

Unlikely to become the main shell (though that's not my decision
anyways). I'm honestly not sure how free/libre it is. IIRC, the
original license (when sources were released) was quite contradictory,
so I'm not sure if "commercial use" is allowed, which is indeed a big
restriction that OSI and FSF rally against. (Not to mention requiring
non-free tools. I don't think the partial patch to use OpenWatcom was
ever very successful, but I never tried, and certainly Lucho only used
old official MS tools.)

I don't know the details, I'm no lawyer. It's unlikely to ever change.
Feel free to contact the copyright holder (Rex Conn? JPsoft?) for
clarification, but then again, they may not respond (in any useful
manner), so don't get your hopes up.

http://jpsoft.com/company/contact-jp-software.html

Sorry to be so pessimistic.

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

[Bertho Grandpied]

>> You may call me Czerno, Herr Ehlert
> your email signature reads "Bertho Grandpied "
> that translates to Bob Bigfoot, right ?

Ask Yahoo!... Then if you insist on calling me Bertho, be my guest.

>> And EVEN if for some reason HMA was not available or not given to
>> the DOS kernel, what makes you deem an environment at ~1800:0  not
>>such a good idea ?

> you would end up with
>    3   K COMMAND.COM, (resident part)
>    100 K FREE         (remainders of freecom before resizing)
>    1   K   command.com environment (at ~1800:0)

How lame ! Of course, your Freecom shall have to play a minimum game of 
releasing its own initialisation code and data, resizing and possibly moving 
things along. Basic DOS system coding skills, not rocket science.  

This is/the/ official shell we are talking of, not some half baked 
throwable transient proggy, it deserves having a minimum of /intelligent
design/ applied :=) 

There are even other enhancements that could be made in the same domain,
an easy one is to give back the /initial/ environment (if any) received by 
your Command from its caller (or from Sysinit). It is of no use after the 
Master ENV is built. Freeing it would give FreeDOS an edge over MS 
Command. But the important is the above. You (or was it Eric) repeated
that FreeCOM had to follow MS-Command, but in this respect it doesn't 
even start to try, I am /sorry/ to observe. 

What is the legal status of 4DOS in relation to FreeDOS ? There's a fully baked 
product, could it become /the/ main FD shell ? 

>> How do you say "arrogance" in German, Herr /Doktor/ Ehlert ?
> Arroganz.

Itself ! I may sound harsh, but being accused of ignorance by 
more ignorant is the only word of excuse I will utter.

Let's forget /name calling/ ? If you agree, I'm your man


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

[Rugxulo]

Hi,

On Mon, Jul 8, 2013 at 5:30 AM, Bertho Grandpied  wrote:
>
> I must say, though, the reception which I got from Herr Ehlert on this list 
> is making me wonder whether spontaneous contributions made in
> good faith are welcome and / or opportune.

Patience, young padawan. Things like this take time and thought (and
research and testing).

If you draw up a patch and it isn't accepted upstream into SVN, I can
still mirror it somewhere (e.g. iBiblio) for you.

Or you can do almost anything with it anyways, it's free/libre. There
can be no one stopping you from contributing (somewhere, somehow).

>> maybe Tom does not have the patience to explain you
>> why there are good reasons why FreeDOS does things
>> the way they are done, but you can trust him :-)
>
> As in, I should /trust/ someone blindly who /starts/ interacting by affirming
> that I /do not understand/ the point ?

Give him the benefit of the doubt, as he is one of the resident
experts around here who has contributed a lot. But even the smartest
person in the world gets tired, too busy with "real life", or just
forgets some minor details from years ago.

> Further to stating that I Czerno "do not understand", and that he Tom
> "does not care" about your users, I have yet to read Herr Ehlert's
> statement of why it would be (dangerous? unwelcome?) for Freecom
> to allocate the master environment block in low memory using "first fit".
>
> I'm open and ready to accept sound reasons, which must be FreeCOM specific 
> then,
> just not the "you wouldn't be happy" stance ! Am I bizarre ?

Yes, of course, technical explanations (or how to test for
correctness) would be ideal, but he may not have time for that nor
remember the details.

> Well... the project which I keep mentionning won't include a "COMMAND"
> processor in the final distribution as self sufficient bootable images for a 
> floppy or USB key. The final user may want to add one and we certainly
> want a command shell during project building. I'll be recommending 4DOS
> for internal use - license allowing.

4DOS is ambiguously licensed. I don't really recommend it, though
there aren't a lot of "full" shell replacements available. If you can
avoid some (most?) .BAT internal stuff, you may find it easier to
replace:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/contrib/

> In case a future version of FreeCOM finally can be persuaded to locate
> the ENV low, like MS and all other Command.com flavours rightly do,
> shall we reconsider.

Again, I take this to mean that (admittedly) FreeCOM is too hard to
rebuild (preferably with TurboC). If you need help with this, feel
free to try and ask specifically for assistance. (It's definitely what
I would call slightly annoying, but it's definitely not impossible to
rebuild either.)

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

[Tom Ehlert]

>> Bertho ???,

> You may call me Czerno, Herr Ehlert
your email signature reads "Bertho Grandpied "
that translates to Bob Bigfoot, right ?

>>> You can't escape having to explain what "adverse effects" you were evoking, 
>>> now anyway.

>> command.com is a 'normal' program. just allocating DOS memory will
>> give you an environment at ~1800:0. not such a good idea.

> You are joking, Herr Ehlert, richtig ?
> Launching a basic FreeDOS+FreeCOM virtual machine while I'm typing...
> No upper memory. Using (Jack Ellis's, I think ) XMGR.SYS.
> MEM /D indicates the ENV would be at *526:0*, /not/ such a /bad idea/.
> And this is /with/ VMware's BIOS 5 kilobytes EBDA relocated low, mind you.

I recommend to apply your 'allocate low' change to FreeCOM yourself.
you will see what happens.


> Of course the kernel is in HMA, which may be what your reply eluded !
no.

> And EVEN if for some reason HMA was not available or not given to
> the DOS kernel, what makes you deem an environment at ~1800:0  not such a 
> good idea ?
you would end up with
3   K COMMAND.COM, (resident part)
100 K FREE (remainders of freecom before resizing)
1   K   command.com environment (at ~1800:0)

> I this all your deep reason for forcing the master ENV up at 9 ?
> In which way other than your respectable personal preference is it better?


> This is highly ridiculous. At least provide a choice. Leave it to 
> power /users/ to determine for themselves what memory layout is 
> best in /their/ situation.

> Ah, but - sorry, I was forgetting - you /don't care/ much about your users.
your are making things up - again.

you asked
  > How many users do you have ?
I answered
  I have no idea - and don't care.

> How do you say "arrogance" in German, Herr /Doktor/ Ehlert ?
Arroganz.

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

[Bertho Grandpied]

> Bertho ???,

You may call me Czerno, Herr Ehlert  

>> You can't escape having to explain what "adverse effects" you were evoking, 
>> now anyway.

> command.com is a 'normal' program. just allocating DOS memory will
> give you an environment at ~1800:0. not such a good idea.

You are joking, Herr Ehlert, richtig ?
Launching a basic FreeDOS+FreeCOM virtual machine while I'm typing...
No upper memory. Using (Jack Ellis's, I think ) XMGR.SYS.
MEM /D indicates the ENV would be at *526:0*, /not/ such a /bad idea/.
And this is /with/ VMware's BIOS 5 kilobytes EBDA relocated low, mind you.

Of course the kernel is in HMA, which may be what your reply eluded !

And EVEN if for some reason HMA was not available or not given to the DOS 
kernel, what makes you deem an environment at ~1800:0  not such a good idea ? 

I this all your deep reason for forcing the master ENV up at 9 ?
In which way other than your respectable personal preference is it better? 

This is highly ridiculous. At least provide a choice. Leave it to 
power /users/ to determine for themselves what memory layout is 
best in /their/ situation.

Ah, but - sorry, I was forgetting - you /don't care/ much about your users.

No wonder you don't have many.

> usually ~9f00:0 is a much better place.
> and juggling memory around (beyond what is already done) was so far
never necessary  (and still isn't)

How do you say "arrogance" in German, Herr /Doktor/ Ehlert ?

Wiedersehen

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

[Bertho Grandpied]

Hi, Eric Auer !
 
> PS: XBDA and moving it is not necessarily trivial.

Our EBDA mover is working flawlessly AFAICT.Old code of mine actually, 
written for MSDOS 5+ before MS introduced the switches=/E option (or
before I was aware of the switch?). Last week when I had discovered 
that the respective FreeDOS kernel's "switches" doesn't work (see below),
we merged in new code to deal with it. 

My and the project's intention as a way to somehow repay in part what
FreeDOS is giving us was to offer this generic MSDOS+FreeDOS EBDA mover
for inclusion at the FD repositories as soon as all the project's people
has had a chance to field tested the release candidate on as many DOS 
machines and configurations as they can.

I must say, though, the reception which I got from Herr Ehlert on this list is 
making me wonder whether spontaneous contributions made in 
good faith are welcome and / or opportune. 

> maybe Tom does not have the patience to explain you
> why there are good reasons why FreeDOS does things
> the way they are done, but you can trust him :-) 

As in, I should /trust/ someone blindly who /starts/ interacting by affirming
that I /do not understand/ the point ? Which is funny because, as much
as I claim I /do not/ grasp the C language, I will claim having a /good/
understanding of DOS's memory management, the API and the 'innards' as 
well, and even the implementation quirks (Microsoft's). So I /might/ take
offence of what you call, mildly, Tom's lack of patience.

Further to stating that I Czerno "do not understand", and that he Tom 
"does not care" about your users, I have yet to read Herr Ehlert's
statement of why it would be (dangerous? unwelcome?) for Freecom 
to allocate the master environment block in low memory using "first fit".

I'm open and ready to accept sound reasons, which must be FreeCOM specific 
then, 
just not the "you wouldn't be happy" stance ! Am I bizarre ?

> XMS swapping is done by FreeCOM, not the kernel...

Indeed, my typo.
 
>> " SWITCHES = /E " directive in Config.sys is ignored silently
> CfgSwitches says:
...
>   /* allowed values: [48..1024] bytes, multiples of 16
> ...

> You also want to read some of the related code. You are
> right that there is no feedback telling you step by step
> what happens with the EBDA, but making the kernel that
> verbose would also make it unnecessarily large.

Well, I won't enter into that code in detail - I don't do *C*, remember ! 

but the FreeDOS kernel mover /does not work/ on *real* machines, ours /does/ 
work ;=) 

At first sight, FreeDOS makes assumptions which are much 
too restrictive (in present days, XBDAs are over 1 k byte in length, 
6 kilobytes aren't rare.)

>> Is there a FreeCOM 'blueprint' or design document for FreeCOM 
>> other than the code comments ?
 
> There are some text files, wiki / homepage documents...
> But generally speaking: If it is not part of the source
> download, it is probably not included.
 
This is a problem with many projects of course. 

Well... the project which I keep mentionning won't include a "COMMAND" 
processor in the final distribution as self sufficient bootable images for a 
floppy or USB key. The final user may want to add one and we certainly
want a command shell during project building. I'll be recommending 4DOS 
for internal use - license allowing.

In case a future version of FreeCOM finally can be persuaded to locate 
the ENV low, like MS and all other Command.com flavours rightly do, 
shall we reconsider.

Kind 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