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


This SF.net email is sponsored by Windows:

Build for Windows Store.

Freedos-user mailing list

Reply via email to