On Sun, Jun 13, 2021, 4:07 PM Eric Auer <[email protected]> wrote: > > Hi Jeremy, Jim and remaining kernel and shell experts, > > While I have not seen it discussed here yet, > > > https://sourceforge.net/p/freedos/news/2021/06/freedos-kernel-2043-and-freecom-085/ > > writes: > > > FreeDOS kernel 2043 and FreeCOM 0.85 > > > > Jeremy Davis has been working to update the FreeDOS kernel and > > FreeCOM, the FreeDOS command shell. Jeremy has shared new versions on > > GitHub. Thanks Jeremy! >
The changes are mostly the work of others and they deserve most of the credit with the continued development. > > > For the kernel, some changes include now support building with > > GCC-ia16, CHAIN command in config.sys, various fixes, new setver > > capabilities. Source and 8086 compatible builds provided, f16 only > > supports FAT12/FAT16, while f32 also supports FAT32 formatted disks > > (both 8086). kernel.zip provides a FreeDOS package, 8086 version with > > FAT12/FAT16 and 386 version with FAT12/FAT16/FAT32. ke2043_rufus is a > > 386 compiled version with FAT12/16/32 support and FORCELBA enabled. > > Why is it necessary to have a special FORCELBA edition? > Should that not be accessible via SYS CONFIG, without > the need for a separate compile? Also, not all 386/486 > have proper LBA support in the BIOS, so users of those > would have to revert to the slower and larger f32 file? > No it is not needed. Any future releases won't include it. The original purpose was part of an attempt to make it easier on the author of Rufus. It is a great tool for creating bootable USB disks. > > Also see the git history for the full change log. You can find the > > updated kernel at kernel.freedos.org and via GitHub in the version > > 2043 release. We've also mirrored the updated kernel in the FreeDOS > > Files Archive at Ibiblio, in the /files/dos/kernel directory. > > > > The FreeCOM release provides multiple variants - the recommended is > > one of the Open Watcom xms-swap versions. The files with ow are built > > with Open Watcom and the files with bc are built with Borland C/C++. > > > Currently only English xms-swap GCC (ia16) built version is provided, > > please see automatic builds for latest builds with GCC. The files > > with -intl use English language for critical errors and provide > > strings. for all supported languages. The xmsswap. files are > > recommended for computers with XMS memory, as XMS memory is used for > > swapping. The command.* files use standard swapping and swap to disk. > > Please give more details about this. For 8086, people will want the > KSSF editions, while the rest will usually go for the XMS-SWAP ones > in combination with HIMEM, XMGR or, on 286 computers, FDXMS286. Which > downloads correspond to those use cases? > Yes, if you have xms then xms swap versions are recommended. If you don't have xms, then the swapping to xms will do no good, so the standard version without xms swapping support is the better choice. The versions are separated into xmsswap and command directories accordingly or the files themselves named xmsswap.com or command.com. I included both variants in all archives except gcc one. > > The language specific versions are compiled for the specific language > > so the critical errors will also be translated if available. These > > are only provided in Open Watcom builds. You can find the updated > > version in the FreeCOM GitHub, and in the FreeCOM 0.85 release > > directory on GitHub. We've also mirrored this version in the FreeDOS > > Files Archive on Ibiblio, under /files/dos/command. > > I would like to bring up two long-standing problems again. Maybe you > can give an estimate when those might be addressed. Thank you :-) > > Problem one: The HMA cannot be used before the end of config sys, so > drivers cannot make use of this extra space unless you "devload" them. > I have no specific plans regarding this issue, but will look into it. > Problem two: One cannot have several UMB drivers. Otherwise, people > could load UMBPCI first to get UMB and then load EMM386 (into UMB!) > to get some more, to have even MORE of their 640 kB DOS RAM free :-) > This is one of the main issues I am addressing in next couple months. > I notice that the history.txt for the updated kernel ends at 2042, > so I assume the current 2043 downloads are release candidates which > are waiting for us to test before the changelog gets fully updated? > The URL in the bugs.txt and index.md etc. also seems outdated, still > pointing to the barely useable The documentation needs to be cleaned up. That said, the sourceforge site is still valid for bugs, though I can't make any changes there, only add comments. I do read them. I do not like duplicating source control information into another file. The information is there. I understand it is a place to make it easier for people to see what changed and if it's worth their time to look further and it shows a project is maintained. sourceforge tracker instead of the new > https://github.com/FDOS/kernel/issues > > and a description of the relevant changes from > > https://github.com/FDOS/freecom/commits/master > > which seem to include long CMDLINE support improvements :-) > > Unfortunately, ALL files in the kernel source download have the same > timestamp, making it impossible to see what was last changed when :-o Unfortunately that is a side effect of git, it doesn't set time stamps. I find it very annoying but haven't found a good solution. I have no desire to manually set timestamps. If anyone has suggestions for how to get git to set timestamps on files, I would be greatful. I currently use diffs and git history to see changes. > In freecom, the link in file_id.diz is outdated, to sourceforge, now > redirecting to the wiki start page. The same happens with the link > mentioned in download.txt ... > > https://github.com/FDOS/freecom/blob/master/todo got last changed in > 2006, I guess those to do items are no longer matching reality? > > I guess the HTML docs may no longer match the implementation: > https://github.com/FDOS/freecom/tree/master/docs/html/commands > > Other possibly outdated documentation: > > How to contribute: > https://github.com/FDOS/freecom/blob/master/docs/upload.txt > > How is DOS=HIGH relevant to command.com? Multiplexor ==> Multiplexer > https://github.com/FDOS/freecom/blob/master/docs/todo.txt > > Outdated web links in: > https://github.com/FDOS/freecom/blob/master/docs/readme.txt > https://github.com/FDOS/freecom/blob/master/docs/download.txt > > No updates since 2003, version 0.83 beta something: > https://github.com/FDOS/freecom/blob/master/docs/history.txt > > Reaches 0.84 pre 7, but not 0.85 yet either: > https://github.com/FDOS/freecom/blob/master/CHANGED > > Describes 0.83 beta 48, not 0.85 yet: > https://github.com/FDOS/freecom/blob/master/docs/html/build48.html > > Thanks for your updates and feedback! Regards, Eric > > I haven't worked on FreeCom in years, but am working on reacquainting myself with it. There have been too many pre releases. The 0.85 number is really because Bart has done a lot of work that FreeCom deserves a full release and to set a base point for bug tracking. Bart does a lot still and so I was both trying to help him get an updated build out hopefully for inclusion in upcoming FreeDOS official release and to get back to developing it. I like 4dos, but it's license causes issues so I want to spend some time improving FreeCom. I don't generally discuss much on list as I don't know how much time I will get to devote to what I want to do. Unfortunately I have done a lot of work, but it is scattered across various laptops and virtual machines, with months and years before I get back to them. That means I usually have to figure out not only what I did but more importantly what was still todo. My kids are getting older and I have more time, so at least for a while I am working on tackling various bugs and maybe making some of my changes public. I really appreciate the work others have done and the help to get automated builds working on GitHub. One of my goals is to improve the tests that get ran. Jeremy
_______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
