Hi Pat, kernel gurus Jeremy and Bart, > You can release it [an updated kernel], but I want to put > it together with other updates and finally generate v1.1.
You mean a FreeDOS 1.1 BASE ISO image? That would be nice, but you can of course use many already pre-packaged updated packages from the fdupdate repository and also the updated installer from Jim for that... There is another problem, though: People why try to download a current kernel end up e.g. on fdos.org which is long dead, but used to contain an automated regular build of the kernel and a minimalistic boot floppy image containing that. Maybe the tradition of having "daily builds" somewhere could be resurrected, for those who cannot or do not want to compile kernels from the subversion repository manually. This would also be nice for tasks like binary search for when things in a regression bug broke and/or got fixed, etc :-) >> An SVN source tarball can be obtained at: >> http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/?view=tar >> >> An 8086/FAT32 OW1.9 compiled kernel.sys binary for testing at: >> http://dosemu.org/bart/kernel.sys I am impressed how many changes from 2039 to 2040 have already accumulated, but to be honest I am also a bit disappointed that none of them was mentioned on this mailing list before. Yes I know that there are ways to automatically follow SVN commits, but I mean more something like a low traffic announcement and occasionally discussion list about kernel changes... >> * r1567 ... add explicit byte >> overrides for older versions of NASM for more compact code, It is good to hear that things were perfect apart from the size even with older NASM already before that improvement :-) >> * r1565 sys/sys.c: Change // to /* comments for Turbo C Thanks. >> * r1564 kernel/dosfns.c: If handle valid, close file in PSP >> table before the low-level close + (perhaps) critical error. >> Avoids closing the file twice (and hitting the critical >> error twice) on abort/program termination. Sounds like a good catch. >> Also, close can only return error 6 (DE_INVLDHNDL), >> not 5 (DE_ACCESS), see RBIL. Just wondering, maybe it was 5 to mimick a particular DOS? >> * r1563 kernel/task.c: From Christian Masloch: >> set flags to 0x200 (IF set) when transferring to int22 >> termination address. Interesting, I assume that fixes a hang in a specific situation? >> * r1562 kernel/fatfs.c: Check errors for callers of dir_write >> and shrink_file. Fixes: Bug: File creation does not check >> whether buffers are written correctly [also r1561] Good to know that this is fixed - since when it was broken? >> * r1560 kernel/kernel.asm: >> Enlarge clock and block driver stacks... Were the old stack sizes to be the same as some other DOS or were they just picked to be "a bit more than minimally needed"? I am asking because I wonder whether side effects could exist. >> * r1559 kernel/fatfs.c: Fix value that is used before being >> initialised. >> This lead to a drive to not be considered as FAT32 despite it is >> (or vice-versa). That sounds like a very important fix, thanks! >> * r1499 kernel/makefile: >> With the stack changes the DOS segment has moved to 0x79. Any side effects expected? >> * r1498 kernel/irqstack.asm: >> New irqstack.asm: irq 2, 3, 4, 5, 6, 10, 11, 12, 14, 15 >> now use the IBM interrupt sharing protocol for STACKS... Nice. Did other DOSes also do this? I assume RAM and CPU cost is tiny? Thanks again for all those recent updates. Regards, Eric ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
