Hi Jeremy, > Currently I am working on the 2038 release. That is, going through > reviewing, modifying (usually comments), and committing the set of > patches/bugfixes outstanding. This weekend I am going to tag and > release 2038 - I lost most of my access to SF and all to ibiblio so I > will tag, build, upload to fdos.org and announce, hopefully someone > with access will put on SF and ibiblio.
I suggest that you email for example me the SEPARATE patches (diff -u) in a zip so I can upload them to SVN and (!) add nice/helpful SVN commit logs comments while doing so... :-). > 2038 contains a lot of work done over the last couple years (and > perhaps long overdue, my fault I suppose). Right now I am > reacquainting myself with the code as it has been a few years myself > since I really had time to do work. The changes should be relatively small and well-logged, but if you have any questions, please mention the SVN revision number so I can give some explanations. Can be on-list :-). > The dev branch is frozen - I ask (everyone is free to do as they > please) bug reports be only against the current release (SVN or > releases, but not against -UNSTABLE branch). Note that the work is > not abandoned, the dev branch was originally meant... Blatant ad: Please help filling in the second half of the UNSTABLE branch list-of-changes (technical view) - that would make it easier to cherry-pick patches that are 1. SIMPLE (low risk for porting) and 2. USEFUL and 3. STABLE and CAREFULLY port them to that stable branch in this year. I agree that we should not put much effort in the unstable / devel branch itself at this moment, too experimental and contains too many too complex patches given our group size. http://apps.sourceforge.net/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch > Anyway, my future work on the dev branch is now done as a separate > project (I call it the DOS-C kernel as opposed to the kernel discussed > on this list, the FreeDOS kernel). Why another fork? You can just tag the current unstable state and start new experiments in the unstable branch right away... ;-). > intent is to only support OW so I can simplify some of the code and > work towards support for more filesystems (well that new tech one :-) Whoa... > and oddly enough some of the stuff Jim had mentioned on his page - > however this will be 386+ and may break some backward compatibility, > hence the spin off. I THINK you could make some components "compile time omitable" but I also think that "support only OW" is a risky idea as you will still need drivers and drivers typically are what forces you to include and keep all sorts of compatible cruft. Talking about filesystems: See my other mail, the compile time enable-able built-in read-only support for for example ISO9660 might be a fun idea. I can send you some docs if you want ;-). Yet again - this is only for the dev / unstable branch imho. > Once 2038 is released I plan to continue reviewing any outstanding > patches and apply as appropriate. My top priority is bug fixes - > repeatable bugs will probably be fixed first :-) In no particular True. One bug: MSCLIENT, but only in BASIC (without REDIR loaded) produces 1-1-1980 timestamps on the server only with FreeDOS as client. It does not happen with FULL config of MSCLIENT though. > order my additional work will be merging work from the dev branch, Only after careful discussion on the list please. > specifically sys, country, & the perhaps some of the win hooks. The Eduardo may have already started having a look at porting the country sys support. Note that it would be good to keep the ability to have country-specific built-in things like date and number formats even without installing a country sys file :-). About SYS: Please have a look at the current stable version, it contains some compatibility and performance fixes. The dev SYS is a bit bloated now, more universal boot loader than FreeDOS ;-). Win hooks: Sounds okay if you can keep the patches SMALL. I would recommend NOT to pour some heavy f-node-versus-sft sauce over the nice stable stable branch of the kernel, for example... > main bug/feature that I plan to work on is FAT+ support, the working > with 4GB files goes along with this since it adds support for 4+GB > files. EDR already supports this. Beyond that, a lot of it depends > on what others discuss. See the thread with Tom - Supporting that ad-hoc EDR-DOS-file-system called FAT+ is asking for trouble with anything that is compatible with NORMAL FAT systems. Only in the unstable / devel branch please! Eric ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
