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
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 allows polling
the serial port status. Implemented based on a feature request
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 the chance to share
