[Freedos-kernel] exeflat (2035a) start segment must be variable
exeflat.c of build 2035a (not 2035) has a problem. The start segment is an argument so it's a variable and its value - 2 must be loaded into DI instead of the constant 0x5E. Here's a fix: --- cvs\kernel\utils\exeflat.c 2004-07-09 04:16:30.0 +0200 +++ src\kernel\utils\exeflat.c 2004-08-07 13:16:38.0 +0200 @@ -303,6 +303,7 @@ 0x33,0xFF, /* 27 xor di,di */ 0xFF,0xE7, /* 29 jmp di; jmp 0 */ }; +*(short *)trailer[3] = start_seg - 2; *(short *)trailer[15] = (short)size + 0x20; *(short *)trailer[20] = start_seg + header.exInitSS; *(short *)trailer[25] = header.exInitSP; --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035a) start segment must be variable
On Sat, 7 Aug 2004, Luchezar Georgiev wrote: exeflat.c of build 2035a (not 2035) has a problem. The start segment is an argument so it's a variable and its value - 2 must be loaded into DI instead of the constant 0x5E. Here's a fix: --- cvs\kernel\utils\exeflat.c2004-07-09 04:16:30.0 +0200 +++ src\kernel\utils\exeflat.c2004-08-07 13:16:38.0 +0200 @@ -303,6 +303,7 @@ 0x33,0xFF,/* 27 xor di,di */ 0xFF,0xE7,/* 29 jmp di; jmp 0 */ }; +*(short *)trailer[3] = start_seg - 2; *(short *)trailer[15] = (short)size + 0x20; *(short *)trailer[20] = start_seg + header.exInitSS; *(short *)trailer[25] = header.exInitSP; Hi Lucho, This is against exeflat.c of 2035a-UNSTABLE. Neither 2035a (i.e. CVS HEAD) nor 2035 have this problem. Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035-Arkady) start segment must be variable
Hallo Bart, This is against exeflat.c of 2035a-UNSTABLE. Neither 2035a (i.e. CVS HEAD) nor 2035 have this problem. I didn't know that there are TWO kernel builds called 2035a... Perhaps you should call yours 2035b where b = Bart (a = Arkady ;-) Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035-Arkady) start segment must be variable
On Sat, 7 Aug 2004, Luchezar Georgiev wrote: This is against exeflat.c of 2035a-UNSTABLE. Neither 2035a (i.e. CVS HEAD) nor 2035 have this problem. I didn't know that there are TWO kernel builds called 2035a... Perhaps you should call yours 2035b where b = Bart (a = Arkady ;-) I was just reflecting what it reports from version.h -- that's the info Jeremy put in, neither Arkady nor myself. In CVS HEAD I see: #define BUILD 2035 #define SUB_BUILD a #define KERNEL_VERSION_STRING 1.1.35 /*#REVISION_MAJOR . #REVISION_MINOR . #REVISION_SEQ */ #define KERNEL_BUILD_STRING 2035a /*#BUILD SUB_BUILD */ but in CVS UNSTABLE I see #define BUILD 2035a #define SUB_BUILD -UNSTABLE #define KERNEL_VERSION_STRING 1.1.35a /*#REVISION_MAJOR . #REVISION_MINOR . #REVISION_SEQ */ #define KERNEL_BUILD_STRING 2035a-UNSTABLE /*#BUILD SUB_BUILD */ I don't know why some people started calling 2035a-UNSTABLE plain 2035a... perhaps just too lazy to type -UNSTABLE. But it reports that on the screen right? Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hallo Bart, #define BUILD 2035 #define SUB_BUILD a #define KERNEL_VERSION_STRING 1.1.35 /*#REVISION_MAJOR . #REVISION_MINOR . #REVISION_SEQ */ #define KERNEL_BUILD_STRING 2035a /*#BUILD SUB_BUILD */ #define BUILD 2035a #define SUB_BUILD -UNSTABLE #define KERNEL_VERSION_STRING 1.1.35a /*#REVISION_MAJOR . #REVISION_MINOR . #REVISION_SEQ */ #define KERNEL_BUILD_STRING 2035a-UNSTABLE /*#BUILD SUB_BUILD */ I don't know why some people started calling 2035a-UNSTABLE plain 2035a... perhaps just too lazy to type -UNSTABLE. But it reports that on the screen right? Sure. It reports quite a lot of things. But if BUILD is defined as 2035 (Bart) and 2035a (Arkady),it may be used for identification too. I hate the build version dualism (e. g. version should be 2.0.35), but I know that neither this, nor removal of phrases like All Rights Reserved. that are useless now, nor removal of the f-nodes that prevent programs which modify SFTs from working, will ever happen. OK, long live the holy conservatism that saves the FreeDOS world from the Arkadifying hell ;-G By the way, how is Arkady? Has anybody heard of him recently? I begin to worry about him! Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hello Bart, Actually a couple of years ago it was build 1937 for version 1.0.2 ;) Wow! Well, I hope that it can be 2.0.60 for build 2060 in just a couple of years ;-) nor removal of phrases like All Rights Reserved. that are useless now Pat sent an email to this list -- here's your chance if you really care about this! The Buenos Aires Convention (1911) that required this was superseded by the Universal Copyright and Berne conventions. More on this at http://www.cni.org/Hforums/cni-copyright/1999-01/0196.html It's more difficult than a simple removal. If you'd simply replace all fnode references with SFT's you'll see a substantial increase in code size (because SFT's are FAR). Also fnodes are used in situations where SFTs can't do the job (dir operations). You're right - there are for example cluster fields that must be 32 bit and not 16 bit for FAT32. However -- replacing the use of the persistent fnodes that are now in the HMA by SFTs is a good idea IMHO. This is just a question of time, it may never happen but it can happen if somebody does it and it works well. I see. What about including the SFT in the F-node structure and removing all duplicating fields? As all SFTs are pointed to by a linked list, I think that this is possible. What do you think? An altogether different subject, and you know very well why. You've made plenty of patches yourself and most of them went in. For which I thank you, and I hope that in time, more Arkady's patches will be accepted too. No idea. A bit silent here indeed. Arkady, please respond if you read this. How are you? Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hello Luchezar, OK, long live the holy conservatism that saves the FreeDOS world from the Arkadifying hell ;-G By 100% agreed tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035-Arkady) start segment must be variable
Hello Luchezar, I didn't know that there are TWO kernel builds called 2035a... Perhaps you should call yours 2035b where b = Bart (a = Arkady ;-) or call the 'optimized' kernel keUNSTABLExxx or keARxxx, as the main stream kernel should concentrate on FIXING bugs, rather then introducing new ones. tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Bart Oldeman escribió: By the way, how is Arkady? Has anybody heard of him recently? I begin to worry about him! No idea. A bit silent here indeed. True. Maybe he is on a vacation? Aitor --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hello Tom et al, or call the 'optimized' kernel keUNSTABLExxx or keARxxx, as the main stream kernel should concentrate on FIXING bugs, rather then introducing new ones. 100% agreed. Since I use unstable kernel every day in practice, I think it has no more bugs than the stable one. But during the last few weeks I noticed several more bugs and incompatibilities present in both stable and unstable branches, most of them extremely difficult to fix, namely: 1. While copying a directory tree containing many LFNs *without* DOSLFN loaded and *with* delayed write of SMARTDRV in a FAT32 directory, many invalid directory entries are created, which consist of parts of the contents of the copied files. Turning delayed write off makes the bug vanish. If FreeDOS ir replaced by MS-DOS or if copying to a FAT16 directory under FreeDOS, there is no bug. 2. The same test above, but *with* DOSLFN loaded, if done with the COPY /S command of 4DOS, which supports LFNs, causes only lost clusters and all the target files are in zero length. If done by another program which supports LFNs, for example FM, there is no bug. (FM is a Bulgarian all-in-one file manager / file editor / disk editor / CD player / calculator / Tetris / etc.etc.). Again, if FreeDOS is replaced by MS-DOS or if copying to a FAT16 directory under FreeDOS - no bug. 3. If load segment (/L option) was different than 60h, bootstrap causes a read error during the loading of the kernel if it's longer than about 62 KB. The exact value of the load segment doesn't matter, and the bug reveals for *any* value other than 60h. 4. SYS hangs up or causes an invalid opcode at the time of reading the boot sector of my ATA flash cards, if compiled by anything than Watcom. Non-Watcom versions of SYS work on all other drives. 5. DOSLFN 0.33, run off a XMSDSK RAM-disk, doesn't show the files there with dir in FreeDOS, but works in MS-DOS 7.10. DOSLFN 0.32 works everywhere. DOSLFN 0.33 works on any other disk in FreeDOS Needless to say that these bugs and incompatibilities are only a small part of the whole picture. You already know the DOS extender compatibility problems I've reported earlier. Perhaps it's also worth mentioning that writing files under DOSLFN is significantly slower than under MS-DOS. So, as a prospective user of the kernel, after contributing to it for more than an year, I can conclude than it's good enough for simpler tasks not involving writing a lot of long named files on a FAT32 partition. For more complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more suitable. You can find a good comparison betweent the different DOS versions on the page of Wengier Wu (, China DOS Union) http://newdos.yginfo.net/dosfat32.htm (page is in English). Thank you for your attention. It's time for me to concentrate on other tasks. It's been a pleasure for me to work with you guys. I hope that FreeDOS will be THE DOS one day. But hardly real soon now... Regards, Lucho () --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
At 09:19 PM 8/7/2004 +0300, Luchezar Georgiev wrote: Needless to say that these bugs and incompatibilities are only a small part of the whole picture. You already know the DOS extender compatibility problems I've reported earlier. Perhaps it's also worth mentioning that writing files under DOSLFN is significantly slower than under MS-DOS. I'd like to know of any DOS extender compatibility problems as I have looked carefully for them. All the big name extenders and several 2nd or 3rd tier ones, work fine for all the applications tested. Eric Auer remarks that DOS/4GW still has compatibility problems in Bugzilla, but he has failed to demonstrate any of them to me. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hi Lucho, Luchezar Georgiev escribi: 100% agreed. Since I use unstable kernel every day in practice, I think it has no more bugs than the stable one. But during the last few weeks I noticed several more bugs and incompatibilities present in both stable and unstable branches, most of them extremely difficult to fix, namely: Could you please fill bugzilla entries with these please? So, as a prospective user of the kernel, after contributing to it for more than an year, I can conclude than it's good enough for simpler tasks not involving writing a lot of long named files on a FAT32 partition. For more complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more suitable. You can find a good comparison betweent the different DOS versions on the page of Wengier Wu (, China DOS Union) http://newdos.yginfo.net/dosfat32.htm (page is in English). It gives to me a 404... (though the link seems interesting enough). Thank you for your attention. It's time for me to concentrate on other tasks. It's been a pleasure for me to work with you guys. I hope that FreeDOS will be THE DOS one day. But hardly real soon now... A pitty to hear you go, or am I misinterpretating your words? Aitor --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
So, as a prospective user of the kernel, after contributing to it for more than an year, I can conclude than it's good enough for simpler tasks not involving writing a lot of long named files on a FAT32 partition. For more complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more suitable. You can find a good comparison betweent the different DOS versions on the page of Wengier Wu (, China DOS Union) http://newdos.yginfo.net/dosfat32.htm (page is in English). It gives to me a 404... (though the link seems interesting enough). http://www.google.com.br/search?q=cache:PIFhy-PkmJ0J:newdos.yginfo.net/dosfat32.htm+dosfat32hl=pt Alain --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
nor removal of phrases like All Rights Reserved. that are useless now Pat sent an email to this list -- here's your chance if you really care about this! The Buenos Aires Convention (1911) that required this was superseded by the Universal Copyright and Berne conventions. More on this at http://www.cni.org/Hforums/cni-copyright/1999-01/0196.html Honestly I believe you're right here -- the issue is that changing copyright messages without agreement of the original author is a bit shaky IMHO. If you just get Pat's go ahead for the change then I'm all for it. Note that the GPL doesn't use all rights reserved, it gives an example like Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. FreeDOS could, say, show the full message if you press a certain F key(as it waits for F5/F8 anyway), like this FreeDOS kernel build 2035a-WHATEVER. Copyright... This kernel comes with ABSOLUTELY NO WARRANTY and you are welcome to redistribute it under certain conditions; press F1 for details. It's more difficult than a simple removal. If you'd simply replace all fnode references with SFT's you'll see a substantial increase in code size (because SFT's are FAR). Also fnodes are used in situations where SFTs can't do the job (dir operations). You're right - there are for example cluster fields that must be 32 bit and not 16 bit for FAT32. Well those can be dealt with, a bit awkward though. IIRC Win98 stores these clusters in the various SHARE related fields. Not sure how many DOS programs (if any) depend on these on FAT32 though. Maybe SMARTDRV and DOSLFN or LFNDOS? However -- replacing the use of the persistent fnodes that are now in the HMA by SFTs is a good idea IMHO. This is just a question of time, it may never happen but it can happen if somebody does it and it works well. I see. What about including the SFT in the F-node structure and removing all duplicating fields? As all SFTs are pointed to by a linked list, I think that this is possible. What do you think? IMHO easiest to copy those fields across that matter, and then then delete them from the persistent fnodes. i.e. the far fnodes would be able to become different from the near ones, and xlt_fd() and save_far_fnode() would no longer use fmemcpy but copy individual fields. Another difference is the way that directory entries are addressed: SFT's use (sector number, entry in sector), where fnodes use (starting cluster number of dir, entry in directory). And if you don't keep the whole directory entry in memory then dir_write would have to become read/modify/write instead of simply write. Takes a fair bit of time of course, it just depends how motivated one is. Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
On Sat, 7 Aug 2004, Luchezar Georgiev wrote: [problems with DOSLFN and SMARTDRV and some obscure problems for nonstandard configurations] So, as a prospective user of the kernel, after contributing to it for more than an year, I can conclude than it's good enough for simpler tasks not involving writing a lot of long named files on a FAT32 partition. For more complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more suitable. You can find a good comparison betweent the different DOS versions on the page of Wengier Wu (, China DOS Union) http://newdos.yginfo.net/dosfat32.htm (page is in English). Of course this is since the DOSLFN author apparently isn't interested in running it on FreeDOS and most FreeDOS developers aren't interested enough in DOSLFN (it's useless on networked drives for instance, which makes it almost useless in DOSEMU!). Same for SMARTDRV, anyway why SMARTDRV if we have LBACACHE? In any case these China DOS Union guys seem to think they can freely redistribute MSDOS 7.10 so if they think that's all fine and it works for what they want then I wish them good luck. PC-DOS 7.1 never seems to have been officially released but just appears to be what's used on Norton Ghost's boot disks. Remember that Steve Gibson went round trip back to FreeDOS after evaluating several other DOSes so this means that FreeDOS can't be that bad :) I just hope that if I ever need spinrite myself Steve can pay back by giving me a free copy ;) Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
