Re: [Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
On 5/22/07, Eric Auer <[EMAIL PROTECTED]> wrote: > > - what was the reason for 21.3301 modifying DL again? Tom already answered that. > - why is 2f.1228 "seek" disabled? I don't know. CVS logs indicate it is waiting for another unstable kernel merge. > - do you want to explain the "something else" in nls.c? Check it out in CVS! > Bart, what was the dosfns.c spc=rg[0] rg[0] comes from the network redirector. It is copied to spc which is returned by DosGetFree. rg[0] comes from int2f/110c in AX in int2f.asm. > And what was the JPP story > about deltree in fatfs.c, do you remember the background? no, John Price was involved before me. > I think the fatdir.c "i=3" change from "if volid is set but > dir is not" to "if, ignoring rdonly and archive, only volid > is set" was to make Zeliard findfirst happy. You said it was > only in the copy on my homepage but not in cvs... It is in cvs now... > Did you already throw in the other changes from my homepage, > with some useful cvs logs, or did you wait for me to do that? well you can find out yourself :) Bart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
Hi Bart, here my reply to your reply to my list :-) Few "part 2" reactions first: - what was the reason for 21.3301 modifying DL again? - why is 2f.1228 "seek" disabled? - do you want to explain the "something else" in nls.c? Reactions to this first part: Any volunteers for SYS.TXT / CONFIG.TXT / INTFNS.TXT updates? Todo items: check if sys.txt is up to date, add "" to the IF example and mention that FCBS setting is basically irrelevant because FreeDOS simulates FCBS (both config.txt). Check which int 2f DOS kernel functions are not yet implemented and add a list of them to intfns.txt; Fix the drive vs driver typo. Plus there is that "secondard" typo in fatfs.c ;-). Any volunteers for the int 21.5d01 ... 5d05 implementation? Various "close all handles with property X" functions, so this should be a reasonably tame task. Bart, what was the dosfns.c spc=rg[0] and "padding can be with spaces and 0 bytes" purpose again? And what was the JPP story about deltree in fatfs.c, do you remember the background? I think the fatdir.c "i=3" change from "if volid is set but dir is not" to "if, ignoring rdonly and archive, only volid is set" was to make Zeliard findfirst happy. You said it was only in the copy on my homepage but not in cvs... Did you already throw in the other changes from my homepage, with some useful cvs logs, or did you wait for me to do that? I will try to update the cvs a bit in the next time, but may take a while. So of course it would be nice if somebody could help out with the .txt file updates in the meantime :-). Thanks! Eric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
>>NOTE that both versions have a typo: "... the any key ..." > It's not a typo! Damnit! Still haven't found the any key? see http://www.computergear.com/pressanykey4.html and http://www.gadgetizer.com/2006/04/03/any-key-mistery-solved/ or just google for "the any key" ;) Tom - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
Hi, here is the point by point reply to Eric's list... CN means: a new change in CVS independent of Tom (not present in the 2035-Tom diff) TA means: Tom's change, applied TNA means: Tom's change, not applied TO means: Tom's change, other, see explanation. On 12/31/06, Eric Auer <[EMAIL PROTECTED]> wrote: > - Tom has a build2 bat file, which does a SYS CONFIG >on the kernel, copies the kernel to A:, and sorts the >map file. We could add that to the cvs. TNA He's had that for a long time, I always saw that as something Tom specific. You certainly don't want to put it as is... as strange things will happen, I'd get Error reading from drive A: DOS area: sector not found (A)bort, (I)gnore, (R)etry, (F)ail? without a floppy drive... > - buildall, build, default: more comments in cvs, >plus cvs has set dos4g=quiet CN > - bugs / build / lfnapi / mkboot / nls / sys / readme.txt: >at most differs in linebreak style? WHAT is "2." in mkboot?? There hasn't been a 2. in mkboot since at least May 2000. >Is the zip naming scheme still up to date in readme? >Does sys.txt describe all current stable SYS options? CN (I don't know) > - config.txt: cvs has a newer extended version >NOTE: I think there should be a FCBS note telling that >FreeDOS can provide FCBS without FCBS=... line? >The IF %config%==... example should use "". CN (Perhaps) > - contrib.txt: cvs is newer, updates Bernd / Aitor CN > - fdkernel.lsm / version.h / globals.h differ, of course >NOTE that we no longer have REVISION_MAJOR nor >REVISION_MINOR as those were incompatible to 32RTM! CN. Well you can still (sort of) derive them from the string via int21/ax=33ff > - intfns.txt CVS version better describes the current state >QUESTION: Which int 2f functions are still missing? >Any volunteers for int 21.5d01 ... 21.5d05? >Typo in CVS: "drive" instead of "driver" for LFN CN > - readme.cvs CVS version is better, more up to date CN > - floppy.asm CVS version is slightly better, improved >comments. The FL_DISKCHANGED implementation is a bit >different but in the end seems to do the same thing. >Could anybody CHECK THAT? TNA Tom and Arkady (in CVS) both fixed the same bug with ret 8 but in different ways: Arkady jumps backwards to ret_AH whereas Tom jumps forwards. > - filelist, makefile: CVS version provides more FreeDOS >style directory / zip file structure and no longer >includes autoexec / config / install bat files. IF we >had somewhat more useful SAMPLE CONFIG / autoexec, it >would make sense to include them, but for now, I prefer >the CVS style :-). CN > - device.h CVS version provides r_si and r_di but those >do not seem to be used yet? CN should be in ioctl.c (see UNSTABLE branch). I'll do that later. > - hdr.h CVS version makes intr() void, Tom uses unsigned >WHICH is better? CVS probably? TO... Tom changed intr() in pcb.h (which was unused) to match up with the one prototyped for init code, when he started using it for NLS and floppy change notification. I have instead, removed the intr() prototype. I thought, and still think, that intr() is a bit too expensive (too many bytes) to use in the resident code. Tom disagrees, but we've been through that :) > - portab.h CVS version has some extra Watcom pragmas with >the comment "min.unpacked size" (default parm / modify) >I assume CVS is better? >The CVS version also has MK_SEG_PTR and MK_UWORD and >MK_ULONG, probably by Arkady, but I think those are not >yet actually used for much? CN. I don't like those macros much, so I like it that they are hardly used but we've been through that too :) > - asmsupt.asm CVS version uses some FSTRCMP / _fstrcmp / >pascal_setup in Watcom, while Tom has that commented >out as still untested. WHICH IS BETTER? CN. Now used in fatfs.c to prevent removal of current directory so tested. > - config.c timeout is "time > timeout" in Tom version and >"time >= timeout" in CVS version, the latter is maybe >better for 0 timeouts / hanging timers?? TNA as explained by Tom just now. > - dosfns.c CVS DosGetFree returns UWORD (-1 for false) >instead of BOOL, so it no longer has a UWORD * spc >argument >NOTE: What is the purpose of "spc = rg[0]" in cvs? it was just moved up a bit, getting redirector data. >IsDevice has different handling of "padding can be >with spaces or 00 bytes", probably having the same >effect in the end. Could somebody COMPARE both versions? >The CVS version also skips something for block devices. CN. All those changes were on purpose, no changes in Tom's kernel. > - dsk.c the TOM VERSION provides an call to int 2f.4a00 >to ask a potential GUI whether it is okay to display >the "insert disk a:/b:..." "DJ" message as text. A GUI >can trap this and show a dialog box instead. VERY NICE. TO. I have applied this but using a special purpose asm function to avoid intr to sav e about
Re: [Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
Part 2...
On 1/1/07, Eric Auer <[EMAIL PROTECTED]> wrote:
> inthndlr.c: Toms version modifies DL on return from int 21.3301
>(set ctrl c flag), while the CVS does not - CVS is better.
TA -- discussed earlier
>The CVS version uses the new dpb16to32 function for shorter code.
CN
>TOMS version has some interesting extra error handling, maybe
>this can be added to the CVS version: Around line 430, Tom does
>"if ErrorMode && AH>=0c && AH neither 30 nor 59 then { ErrorMode=0;
>fnode[0].f_count = 0; fnode[1].f_count = 0; }" - in other words,
>for the non-reentrant DOS functions, make sure to mark all near
>fnodes as unused on entrance to int 21.
>Later, around line 1550, if not both fnode counts are 0, force
>them to be 0, but display a warning if ErrorMode was 0. Explanation:
>An int24, for example in FindFirst, is handled by an app by NOT
>returning to the kernel (possible). That way, resources are never
>freed and ErrorMode is never reset...
>Note that Tom only forces fnode freeing, not ErrorMode reset.
TA. This is also in the UNSTABLE kernel, to be exact I ported it from there.
>FatGetDrvData modifies AX in Toms version and AL in CVS, which of
>the two is better? See fcbfns.c
>The FcbParseFname call of int 21.29 modifies AL directly in CVS,
>while Toms version also updates rc. WHICH OF THE TWO IS BETTER?
CN (both)
>Tom re-orders some register writes, which looks as if he tried
>to set lr.ES / lr.DI as late as possible. Why? Optimizes better?
TA. Probably to allow the compiler to do common tail optimization. It
saves a few bytes.
>The CVS version returns CX = 0 on int 21.30, while Tom returns
>the REVISION numbers. A comment in CVS tells that CX must be 0
>for 32RTM compatibility - found by Michael.
>The int 21.36 implementation follows the different DosGetFree
>parameter / return value structure in both versions.
>The function int 21.??0a, set extended error, looks more optimized
>in the CVS version. Both seem to have the same effect. COMMENTS?
>In the CVS version, int 21.5f checks if cdsp->cdsDpb has a zero
>offset, according to comments this checks if a drive is physical.
>Sounds good...? This affects the handling of the AL==7 case.
>The CVS version provides a more extended stub for the DBCS API
>int 21.63xx ;-).
CN
>The int2F_12_handler of the CVS version supports several new
>functions: 26 (open), 27 (close), 29 (read). HOWEVER, the new
>code for function 28 (seek) is disabled. WHY?
>There is also a SET DOS VERSION DX interface at function 2f.
CN
> - intr.asm: Toms version has the following additional code:
>global INTR / INTR: INTR (between the no_read_error: ret and
>the segment INIT_TEXT around line 125). What is that used for?
>Where is INTR defined?
TNA
right at the beginning: %macro INTR 0
called by Tom in two places.
> - ioctl.c looks BETTER IN TOMS version: r_command of the request
>header is set based on al, using a table with the entries
>0,0,C_IOCTLIN,C_IOCTLOUT,C_IOCTLIN,C_IOCTLOUT,C_ISTAT,C_OSTAT,
>C_REMMEDIA,0,0,0,C_GENIOCTL,C_GENIOCTL,C_GETLDEV,C_SETLDEV,
>C_IOCTLQRY,C_IOCTLQRY at slots 0..11 (hex). The CVS code, on
>the other hand, spreads this information over two switch / case
>areas which first set a nMode variable and later set r_command.
TA: This is a little optimization that is also present in the UNSTABLE
ioctl.c (which takes things a bit further). The table saves doing
everything seperately in switch cases. Actually ioctl can be made a
lot simpler with that table. Done in UNSTABLE, but I could do better
myself (saving ~200 bytes in the process), not applied yet.
> - main.c has an updated copyright string year in the CVS version.
>Other differences seem to be whitespace-only around line 570 and
>correcting a typo: TOM has the corrected "boot from" string around
>line 735, while the CVS version writes "booot from". One more diff
>is around line 690: Is EmulatedDriveStatus "nothing/void" (Toms
>version) or is it "STATIC int" (CVS version)...?
TA (for booot), the rest is CN.
> - memmgr.c: The CVS version allows double free of memory blocks,
>which is necessary to be compatible with a flaw in QBasic 4...
CN
> - nls.c: TOMS version quotes quite some ASM code and sets many
>registers before calling intr(0x2f,&r): BH=0x14 BL=subfct CX=bufsize
>SI=(short)&nlsinfo BP=bp BX=cp DX=cntry ES:DI = pointer bp.
>The CVS version, on the other hand, uses call_nls(subfct,
>&nlsInfo, bp, cp, cntry, bufsize, buf, id). WHICH OF THEM IS BETTER?
TO (none :) I applied something else that puts "id" in the high part
of a long, and no intr. It's a tricky variable because SS!=DS in that
code.
> - proto.h: The parameters / return types differ for DosGetFree,
>FcbParseFname and FatGetDrvData. The CVS also has dpb16to32...
CN
> - serial.asm: The CVS version has ComInStat, which a
Re: [Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
Hi! 31-Дек-2006 18:46 [EMAIL PROTECTED] (Eric Auer) wrote to freedos-kernel@lists.sourceforge.net: EA> In the end, I would like to have 2036 "extra stabilized" EA> so that Tom no longer needs a separate kernel version. Let remain alone 2036, which already released in FD 1.0 - time to start new version. EA> Here we go, big list of diffs :-) . To check the 2036 EA> sources, get a source zip or use the cvs web browser: EA> http://freedos.cvs.sourceforge.net/freedos/kernel/ EA> The Tom sources are available from Tom, but I can also EA> provide a (not very well cleaned up) unified diff file. Better if it will be available for direct download. EA> - Tom has a build2 bat file, which does a SYS CONFIG EA>on the kernel, copies the kernel to A:, and sorts the EA>map file. We could add that to the cvs. Why not? EA> - buildall, build, default: more comments in cvs, EA>plus cvs has set dos4g=quiet default.bat should be defaults.bat, else there be troubles under 3DOS. EA> - config.txt: cvs has a newer extended version EA>NOTE: I think there should be a FCBS note telling that EA>FreeDOS can provide FCBS without FCBS=... line? ? EA>The IF %config%==... example should use "". Of course. EA> - hdr.h CVS version makes intr() void, Tom uses unsigned EA>WHICH is better? CVS probably? I think, better to use own function with own interface (see callint() in Blair's CLIB), which provides better handling for registers and their parts. Blair, the more I think, the more me looks, that returning CF instead AX in callint() is better. EA> - portab.h CVS version has some extra Watcom pragmas with EA>the comment "min.unpacked size" (default parm / modify) EA>I assume CVS is better? EA>The CVS version also has MK_SEG_PTR This is mine. EA>and MK_UWORD and EA>MK_ULONG, probably by Arkady, but I think those are not EA>yet actually used for much? But they should be, because they more readable and more safe. EA> - config.c timeout is "time > timeout" in Tom version and EA>"time >= timeout" in CVS version, the latter is maybe EA>better for 0 timeouts / hanging timers?? Where? EA> - dsk.c the TOM VERSION provides an call to int 2f.4a00 EA>to ask a potential GUI whether it is okay to display EA>the "insert disk a:/b:..." "DJ" message as text. A GUI EA>can trap this and show a dialog box instead. VERY NICE. Let me remind you about tom's letter in freedos-kernel @ 2006/09/19. EA> - fatdir.c WHICH VERSION IS BETTER HERE? Tom uses EA>"if ((attr & D_VOLID|D_DIR)==D_VOLID) i=3" while CVS uses EA>"if ((attr & ~(D_RDONLY|D_ARCHIVE))==D_VOLID) i=3 else EA>attr &= ~D_VOLID" ... (this is in findfirst afair) First is old behavior, second was introduced later. I don't remember reasons for this change (I remember there was something about this from Jeremy), but kernel, which I download from CVS at end of December, does contain first code: COUNT dos_findfirst(UCOUNT attr, BYTE * name) if ((attr & (D_VOLID|D_DIR))==D_VOLID) i = 3; [...] if ((attr & (D_VOLID|D_DIR))==D_VOLID) [...] if ((fnp->f_dir.dir_attrib & ~(D_RDONLY | D_ARCHIVE)) == D_VOLID && fnp->f_dir.dir_name[0] != DELETED) COUNT dos_findnext(void) if (fnp->f_dir.dir_name[0] != '\0' && fnp->f_dir.dir_name[0] != DELETED && !(fnp->f_dir.dir_attrib & D_VOLID)) [...] /* MSD Command.com uses FCB FN 11 & 12 with attrib set to 0x16. Bits 0x21 seem to get set some where in MSD so Rd and Arc files are returned. RdOnly + Archive bits are ignored */ /* Test the attribute as the final step */ if (!(fnp->f_dir.dir_attrib & D_VOLID) && !(~dmp->dm_attr_srch & (D_DIR | D_SYSTEM | D_HIDDEN) & fnp->f_dir.dir_attrib)) EA> - int2f.asm has different comments: CVS "INT2F/11xx" while EA>Tom has "INT2F/12xx and INT2F/4A01,4A02"... which is right? Second comment is mine correction for original wrong comment. As usually, most my changes was lost in void. EA> main.c what is better, STATIC int or nothing for EmulatedDriveStatus? "Nothing" is old K&R style and will be diagnosed by current compilers. STATIC (read: LOCAL) marks functions, which are internal and should/need not be exported. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
Welcome in 2007 :-)
Here part 2 of my mail from last year ;-), comparing Toms
extra stable 2035c kernel to the CVS stable HEAD 2036 kernel.
inthndlr.c: Toms version modifies DL on return from int 21.3301
(set ctrl c flag), while the CVS does not - CVS is better.
The CVS version uses the new dpb16to32 function for shorter code.
TOMS version has some interesting extra error handling, maybe
this can be added to the CVS version: Around line 430, Tom does
"if ErrorMode && AH>=0c && AH neither 30 nor 59 then { ErrorMode=0;
fnode[0].f_count = 0; fnode[1].f_count = 0; }" - in other words,
for the non-reentrant DOS functions, make sure to mark all near
fnodes as unused on entrance to int 21.
Later, around line 1550, if not both fnode counts are 0, force
them to be 0, but display a warning if ErrorMode was 0. Explanation:
An int24, for example in FindFirst, is handled by an app by NOT
returning to the kernel (possible). That way, resources are never
freed and ErrorMode is never reset...
Note that Tom only forces fnode freeing, not ErrorMode reset.
FatGetDrvData modifies AX in Toms version and AL in CVS, which of
the two is better? See fcbfns.c
The FcbParseFname call of int 21.29 modifies AL directly in CVS,
while Toms version also updates rc. WHICH OF THE TWO IS BETTER?
Tom re-orders some register writes, which looks as if he tried
to set lr.ES / lr.DI as late as possible. Why? Optimizes better?
The CVS version returns CX = 0 on int 21.30, while Tom returns
the REVISION numbers. A comment in CVS tells that CX must be 0
for 32RTM compatibility - found by Michael.
The int 21.36 implementation follows the different DosGetFree
parameter / return value structure in both versions.
The function int 21.??0a, set extended error, looks more optimized
in the CVS version. Both seem to have the same effect. COMMENTS?
In the CVS version, int 21.5f checks if cdsp->cdsDpb has a zero
offset, according to comments this checks if a drive is physical.
Sounds good...? This affects the handling of the AL==7 case.
The CVS version provides a more extended stub for the DBCS API
int 21.63xx ;-).
The int2F_12_handler of the CVS version supports several new
functions: 26 (open), 27 (close), 29 (read). HOWEVER, the new
code for function 28 (seek) is disabled. WHY?
There is also a SET DOS VERSION DX interface at function 2f.
- intr.asm: Toms version has the following additional code:
global INTR / INTR: INTR (between the no_read_error: ret and
the segment INIT_TEXT around line 125). What is that used for?
Where is INTR defined?
- ioctl.c looks BETTER IN TOMS version: r_command of the request
header is set based on al, using a table with the entries
0,0,C_IOCTLIN,C_IOCTLOUT,C_IOCTLIN,C_IOCTLOUT,C_ISTAT,C_OSTAT,
C_REMMEDIA,0,0,0,C_GENIOCTL,C_GENIOCTL,C_GETLDEV,C_SETLDEV,
C_IOCTLQRY,C_IOCTLQRY at slots 0..11 (hex). The CVS code, on
the other hand, spreads this information over two switch / case
areas which first set a nMode variable and later set r_command.
- main.c has an updated copyright string year in the CVS version.
Other differences seem to be whitespace-only around line 570 and
correcting a typo: TOM has the corrected "boot from" string around
line 735, while the CVS version writes "booot from". One more diff
is around line 690: Is EmulatedDriveStatus "nothing/void" (Toms
version) or is it "STATIC int" (CVS version)...?
- memmgr.c: The CVS version allows double free of memory blocks,
which is necessary to be compatible with a flaw in QBasic 4...
- nls.c: TOMS version quotes quite some ASM code and sets many
registers before calling intr(0x2f,&r): BH=0x14 BL=subfct CX=bufsize
SI=(short)&nlsinfo BP=bp BX=cp DX=cntry ES:DI = pointer bp.
The CVS version, on the other hand, uses call_nls(subfct,
&nlsInfo, bp, cp, cntry, bufsize, buf, id). WHICH OF THEM IS BETTER?
- proto.h: The parameters / return types differ for DosGetFree,
FcbParseFname and FatGetDrvData. The CVS also has dpb16to32...
- serial.asm: The CVS version has ComInStat, which allows polling
the serial port status. Implemented based on a feature request
from our SourceForge trackers. The tests for DSR / al,20h of the
GetComStat output are commented out in the CVS version, better?
- sys.c: Tom uses fat32readwrite... as prototype, CVS uses
int fat32readwrite - WHICH return type is better? TOM uses
the OEMID string "FRDOS5.1" which matches MS style better
than "FreeDOS ": The string should be 5 uppercase letters,
1 digit, dot, another digit.
I hope somebody will find the time to answer the questions
embedded in those two mails and merge the good patches from
TOMS kernel into the CVS kernel :-). Thanks!
Eric
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get t
[Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
Hi all ... and happy new year :-) I took some time to compare the current CVS stable / HEAD kernel FreeDOS 2036 to the "extra stable 2035c" kernel which is used by Tom. The latter is generally a bit older, but also features some patches which have not yet found their way into 2036. There are also places where it is unclear which variant is better, so I hope you can give some feedback on this mail - in particular Tom, Arkady, Bart and Jeremy can hopefully help to get a clearer "big picture" of the differences... In the end, I would like to have 2036 "extra stabilized" so that Tom no longer needs a separate kernel version. Here we go, big list of diffs :-). To check the 2036 sources, get a source zip or use the cvs web browser: http://freedos.cvs.sourceforge.net/freedos/kernel/ The Tom sources are available from Tom, but I can also provide a (not very well cleaned up) unified diff file. - Tom has a build2 bat file, which does a SYS CONFIG on the kernel, copies the kernel to A:, and sorts the map file. We could add that to the cvs. - buildall, build, default: more comments in cvs, plus cvs has set dos4g=quiet - bugs / build / lfnapi / mkboot / nls / sys / readme.txt: at most differs in linebreak style? WHAT is "2." in mkboot?? Is the zip naming scheme still up to date in readme? Does sys.txt describe all current stable SYS options? - config.txt: cvs has a newer extended version NOTE: I think there should be a FCBS note telling that FreeDOS can provide FCBS without FCBS=... line? The IF %config%==... example should use "". - contrib.txt: cvs is newer, updates Bernd / Aitor - fdkernel.lsm / version.h / globals.h differ, of course NOTE that we no longer have REVISION_MAJOR nor REVISION_MINOR as those were incompatible to 32RTM! - intfns.txt CVS version better describes the current state QUESTION: Which int 2f functions are still missing? Any volunteers for int 21.5d01 ... 21.5d05? Typo in CVS: "drive" instead of "driver" for LFN - readme.cvs CVS version is better, more up to date - floppy.asm CVS version is slightly better, improved comments. The FL_DISKCHANGED implementation is a bit different but in the end seems to do the same thing. Could anybody CHECK THAT? There are also some whitespace changes and stuff. - filelist, makefile: CVS version provides more FreeDOS style directory / zip file structure and no longer includes autoexec / config / install bat files. IF we had somewhat more useful SAMPLE CONFIG / autoexec, it would make sense to include them, but for now, I prefer the CVS style :-). - device.h CVS version provides r_si and r_di but those do not seem to be used yet? - hdr.h CVS version makes intr() void, Tom uses unsigned WHICH is better? CVS probably? - portab.h CVS version has some extra Watcom pragmas with the comment "min.unpacked size" (default parm / modify) I assume CVS is better? The CVS version also has MK_SEG_PTR and MK_UWORD and MK_ULONG, probably by Arkady, but I think those are not yet actually used for much? - asmsupt.asm CVS version uses some FSTRCMP / _fstrcmp / pascal_setup in Watcom, while Tom has that commented out as still untested. WHICH IS BETTER? - config.c timeout is "time > timeout" in Tom version and "time >= timeout" in CVS version, the latter is maybe better for 0 timeouts / hanging timers?? - dosfns.c CVS DosGetFree returns UWORD (-1 for false) instead of BOOL, so it no longer has a UWORD * spc argument NOTE: What is the purpose of "spc = rg[0]" in cvs? IsDevice has different handling of "padding can be with spaces or 00 bytes", probably having the same effect in the end. Could somebody COMPARE both versions? The CVS version also skips something for block devices. - dsk.c the TOM VERSION provides an call to int 2f.4a00 to ask a potential GUI whether it is okay to display the "insert disk a:/b:..." "DJ" message as text. A GUI can trap this and show a dialog box instead. VERY NICE. NOTE that both versions have a typo: "... the any key ..." - fatdir.c WHICH VERSION IS BETTER HERE? Tom uses "if ((attr & D_VOLID|D_DIR)==D_VOLID) i=3" while CVS uses "if ((attr & ~(D_RDONLY|D_ARCHIVE))==D_VOLID) i=3 else attr &= ~D_VOLID" ... (this is in findfirst afair) - fatfs.c adds a parameter char * name to init_direntry in the CVS version, which produces more compact code... The CVS version also prevents "removal of the current directory". There are also differences in handling directories with further attributes: Tom commented out all extra checks, and the CVS version does "if (!(attr & D_DIR) || (attr & ~(D_DIR|D_ARCHIVE))) then abort" (so system/hidden/readonly directories cannot be deleted) The CVS version also has more exact tests whether the first two entries are . and .. (and a typo, "secondard") The CVS version also blocks renaming of the current directory and does "init fnode for ne
