free time at last... On Wed, Apr 29, 2009 at 8:49 PM, Eric Auer <e.a...@jpberlin.de> wrote: > > Hi Bart, admins, others, > >>> Would you like to have access again? Should be no problem :-) > >> Sure! > > Apparently only Aitor, Jim and Pat can give you SVN write > access but I think that would be a *very* nice idea... ;-). > > I noticed Pat already uploaded your SYS OW 1.8 fix :-).
:-) > > If you plan to patch things overlapping those things listed > below, please announce so we can coordinate. You may also want Please consider the 2037 [dev] kernel for review only (not that I'm abandoning it, just moving my work outside of the scope of official FreeDOS kernel). > to read the "state of kernel 2037" and "state of kernel 2038" > threads on the freedos-user in Feb 2009. High on the wishlist will do, I have been trying to read through my archives, unfortunately my gmail account only goes back a year (search and access from multiple computers really is nice). > for 2037 would be extending that SVN changelog wiki page and interesting read, but don't expect updates from me, for now at least > a backport of country sys support to 2038 stable. Eduardo may > be considering to work on that backport... =A0For SYS, I would > suggest an option to enforce either LBA or CHS style boot, in I plan to work on porting the country (or ensuring Eduardo's patches are committed and tested) and win patches (the win specific parts are minimal) from dev to trunk after we get 2038 released (with the plan to release 2039 shortly after with these patches). sys work can wait for a little while questions though, are all the outstanding patches for country in the unstable branch or are there any emails/patches/whatever still floating out there? > particular for FAT32, via the command line. The wishlist for > the stable 2038 kernel is quite short: Insert patches listed > below, update changelog file and make a SF file release :-). > I'm working on the patches, been reading through and refamilarizing myself with the code, and think I can figure out the SF release process again, but those darn changelogs (ever so useful from the outside ...) > > > Patches waiting here for review, comments, uploading: > > - *Bart*: SYS compileability with OpenWatcom C 1.8 and newer (in SVN) I need to check latest sys version and probably commit something similar as well, but that can wait until after 2038 is released > > - Eric: dosfns.c / fatfs.c / proto.h SHARE tuning (safe afair) > > - Christian: entry.asm revamp to fix the CP/M call (review!) > http://sf.net/tracker/?func=3Ddetail&aid=3D2421577&group_id=3D5109&atid= =3D105109 anyone know of any CP/M like programs or applications to test these with? > > - Any: (?) update changelog, update my email addr in the docs > http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/?view=3Dlo= g > > - RayeR: init-mod.h always say BSS_INIT(x)=3Dx (workaround OW bug?) I want to look into this one more, I know there is some interesting logic in startup because of the code relocation; need to verify what the entry code is doing > > - Tom: inthndlr.c bugfix for int 21.1c no-FAT case I don't remember seeing this one, will have to search for it > > - RayeR: initdisk.c CHS cyl off-by-one and total_sectors overflow > =A0and DebugPrintf drive param format string fixes > > - Any: If DSSI points to partn (00 or 80) in FAT16/32 boot sector > =A0then take partn offset from DSSI+x (I *had* a patch but where??) > > - Eric: re-enable drive access flag handling to make unformatted > =A0drives more properly unformatted, disk tools should be fine now? > > - Christian: patch related to exit/resident if self-owned PSP > =A0(he pasted the patch in a recent thread on the mailing list) > > - Any: (Eric?) support 4 GB file size by changing sft_size, sft_posit > =A0to unsigned (dir_size, f_offset already are) and changing lseek > =A0error reporting (no longer treat "negative as fail") - seems you > =A0can let SftSeek accept ANY dos_lseek retval as errors are already > =A0checked by SftSeek itself before calling dos_lseek? DosSeek just > =A0calls SftSeek, needs no changes. The sft_size / sft_posit change > =A0might require adjustments to that at some places in the code. > > - Any: (?) support that extended open flag which allows sizes above > =A02 GB: DosRWSft should throw error 5 access denied if you try to > =A0write beyond that file offset if that flag is not set (shrug ;-)) all >2GB work should wait until 2038 and possibly 2039 are released, this should be done along with work towards FAT+ support (backword compatible with support for files > 4GB, requires addition of one extended seek API function - see EDR for RBIL type spec and some internal changes to ensure sequential access works correctly) > > - Any: implement int 2f.1228?? Apparently exists but commented out?? > will look into it, don't recall and too lazy while typing this email to see what this function does/is :-) > > > Thanks for the explanation of OW 1.8 / 1280 get/setftime un- > DOS-ification of headers to gain MS VC / DJGPP compat ;-). > > Eric > Yes thank you for both the explanation and patch. And thanks Eric for making my life easier with this TODO list. Offtopic: fdos.org was down temp because I forgot to update my credit card info when my bank issued me a new one a few months back (possible leak of info or something) and I'm still working getting my registar information corrected so I can insure the domain name doesn't expire... agh Eric, is it my connection or have your sites moved/down? I am back working on the kernel; my plan is to leave all the distribution work to others and concentrate on more fun/hobby stuff of programming. :-) Thanks, Jeremy ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel