>>> - handling of floppy before disk is inserted / unformatted partitions
>
>>> - initdisk CHS geometry fix and BSS init fix from RayeR
>
>>> - int 21.1c non-FAT / non-existing drive handling fix from Tom
>
>> If anyone wants to contribute to discussions about this patches
>> he can do that now.
>
> I guess I should first re-send the patches somewhere for discussion?
You might as well do that, yes.
>>>> - Terminating self-owning PSPs (parent PSP field set to the PSP)
>
> Okay okay so paste your diff -u for inthndlr.c and task.c again and
> we can discuss it... As usual, minimal patches are preferred :-).
I created them with the GUI diff tool of TortoiseSVN, apparently you have
to modify the source and destination filename. I added a small comment to
the new condition in task.c for clarification.
task.dif:
==== CUT HERE ====
--- D:\WINDOWS\TEMP\task.c-revBASE.svn000.tmp.c So Apr 26 11:45:13 2009
+++ D:\Coding\Projects\FDKERN\kernel\task.c So Apr 26 11:39:32 2009
@@ -542,7 +542,9 @@
/* might be a good idea to do that after closing
but doesn't help NET either TE */
- if (!tsr)
+ /* corrected self-owning PSP handling - just don't free */
+ /* the allocated resources as for TSRs. cm */
+ if (!tsr && !(p->ps_parent == cu_psp) )
{
network_redirector(REM_CLOSEALL);
for (i = 0; i < p->ps_maxfiles; i++)
==== CUT HERE ====
inthndlr.dif:
==== CUT HERE ====
--- D:\WINDOWS\TEMP\inthndlr.c-revBASE.svn000.tmp.c So Apr 26 11:46:25 2009
+++ D:\Coding\Projects\FDKERN\kernel\inthndlr.c So Apr 26 11:40:40 2009
@@ -1049,8 +1049,6 @@
/* End Program */
case 0x4c:
- if (((psp FAR *)MK_FP(cu_psp, 0))->ps_parent == cu_psp)
- break;
tsr = FALSE;
rc = 0;
if (ErrorMode)
==== CUT HERE ====
>>>> - CALL 5 interface is broken, and probably crashes the system.
> Same as above - paste a diff for that one, too. Be aware that the
> entry.asm stack layout is sort of critical so I would prefer to get
> any type of comment from any of the old experts before sticking the
> CP/M-ish call 5 fix into the stable branch. Maybe it could also be
> added only to the unstable branch first?
As mentioned in my previous bug report, I compiled a modified DOS-C
version with my replacement code inserted. I used DEBUG to verify that
CALL 5 succeeds and returns with the correct stack.
> I think one of the problems
> with your original patch was that it made the stack footprint bigger
> so if you can modify your patch to avoid/reduce that side-effect...?
Ignoring that the previous one did immediately CRASH the system, no, my
replacement's stack usage is not even bigger. Besides, if the CALL 5
function input is a valid one (i.e. below 25h) the handler chains to the
Int21 handler anyway. For most function (I think all below 25h too) the
Int21 handler requires 9 additional words of the caller's stack to save
all 16-bit registers anyway.
This is the original diff file I created some time ago. As mentioned, you
might remove the excessive comments or the license notifier since it's
just a patch and the licenses would match anyway.
entry.dif:
==== CUT HERE ====
--- entry.old 2008-06-10 19:57:46.173326100 +0200
+++ entry.asm 2008-07-07 13:41:55.289280900 +0200
@@ -70,49 +70,58 @@
; fudge the stack to look like an int 21h call.
;
reloc_call_cpm_entry:
- ; Stack is:
- ; return offset
- ; psp seg
- ; 000ah
- ;
- push bp ; trash old return address
- mov bp,sp
- xchg bp,[2+bp]
- pop bp
- pushf ; start setting up int 21h stack
- ;
- ; now stack is
- ; return offset
- ; psp seg
- ; flags
- ;
- push bp
- mov bp,sp ; set up reference frame
- ;
- ; reference frame stack is
- ; return offset bp + 6
- ; psp seg bp + 4
- ; flags bp + 2
- ; bp <--- bp
- ;
- push ax
- mov ax,[2+bp] ; get the flags
- xchg ax,[6+bp] ; swap with return address
- mov [2+bp],ax
- pop ax ; restore working registers
- pop bp
- ;
- ; Done. Stack is
- ; flags
- ; psp seg (alias .COM cs)
- ; return offset
- ;
- cmp cl,024h
- jbe cpm_error
- mov ah,cl ; get the call # from cl to ah
- jmp reloc_call_int21_handler ; do the system call
-cpm_error: mov al,0
- iret
+
+; The following code is from RxDOS version 7.20N.
+; (C) Copyright 2008 Christian Masloch. Licensed under the GNU GPL.
+;
+; The original DOS-C code knew about "CALL 5"'s special behaviour but
failed
+; to adjust the stack correctly. It also had another bug so that functions
+; 00h-24h were rejected but all functions above passed to Int21. (The CP/M
+; handler should only allow functions 00h-24h.)
+; ----
+ ; RxDOS 7.20N: Actually the CALL 5 interface isn't just a far
call to
this address.
+ ; Rather it's a near call (inside the program's
PSP) to address 5,
which
+ ; then calls far to this address. Doing a retf
here will screw anything
+ ; up and return into the PSP data instead of into
the actual caller
code.
+ pushf
+ push bp
+ mov bp, sp
+ ; [ bp ] = bp
+ ; [ bp + 2 ] = flags (that we just pushed)
+ ; [ bp + 4 ] = call far's ip (will point into PSP so it's
garbage)
+ ; [ bp + 6 ] = call far's cs
+ ; [ bp + 8 ] = "CALL 5"'s ip
+
+ push ax
+ xchg ax, word [ byte bp + 2] ; ax = flags
+ xchg ax, word [ byte bp + 8] ; [ bp + 8 ] = flags
+ ; ax = "CALL
5"'s ip
+ xchg ax, word [ byte bp + 4] ; [ bp + 4 ] = "CALL
5"'s ip
+ pop ax
+ pop bp
+ add sp, byte 2 ; were the flags we
just pushed
+
+ ; [ sp ] = "CALL 5"'s IP
+ ; [ sp + 2 ] = call far's cs
+ ; [ sp + 4 ] = flags
+ ; Surprisingly this really looks like the stack for an
interrupt!
+ cli ; Real interrupt
entries do the same
+
+
+ cmp cl,24h ; CP/M function number
+ ja .nocpmfunc ; is it above 24h?
Really no CP/M function -->
+ ; (I found this
behaviour while debugging MS-DOS)
+
+ mov ah,cl ; CP/M compatibility
interface uses cl as function
+ jmp reloc_call_int21_handler ; Pass it through to
our normal Int21
entry
+ ; (adjusted for DOS-C)
+
+.nocpmfunc:
+cpm_error: ; (DOS-C. just in case any code
uses it)
+ xor al,al ; Report "Unused"
function
+ iret ; (don't need to care
about CY/NC)
+
+; ----
;
; interrupt zero divide handler:
==== CUT HERE ====
>>>> - The seek position (and various other fields) of the SFT isn't
>>>> declared
>>>> as unsigned. Eric reported that the seek function reports errors using
>>>> negative return values. This has to be changed so that it can work
>>>> with
>>>> files up to 4 GiB...
>
> Indeed - several functions will have to pass a pointer to an extra
> return status argument to work around this complication, but on the
> other hand, the patch will still not be very complex, I hope. Maybe
> it can also be an alternative to support files up to 3.999 GB and
> leave a small range of values reserved for error codes? Also depends
> on which of the methods has which impact on kernel size and speed?
>
>>>> since the actual seek operation never returns errors in MS-DOS
>
> I seem to remember this point from an earlier discussion yes...
Rather implement it that way, letting the Int21 handler take care of
invalid al values or handles, if the alternative is some random maximal
file size.
Regards,
Christian
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
