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
