[Freedos-kernel] Strange bug in kernel 2035
Hello all, I've found what seems an odd bug in the kernel (version 2035) while testing a first alpha version of nlsfunc and it is driving me mad: In nls.c:muxLoadPkg(), the value of cp becomes 0 right after the first call to muxGo() (the one that does the installation check). It seems as if the stack is trashed somewhere, but I'm not able to see where or how. I have observed the same results with OpenWatcom 1.2 and Turbo C++ 1.01. I've also tested with two different versions of nasm (precompiled 16bit binaries of versions 0.98.38 and 0.98.36) with no luck. Adding traces affects the bug itself (trashes a different variable), so I've made a simple TSR (nlsfoo.com) that implements a couple of nlsfunc calls (installation check and set code page) The first one prints the value of the BP register and, the second, the contents of BX. With an unmodified kernel, install nlsfoo.com and execute testchcp.exe (link below, does the same that CHCP 850, but chcp was broken in freecom until very recently) and you'll see: The first is correct (the kernel passes 0 in BP), but the second is wrong (BX should contain the codepage, i.e. 0352h). Apply the patch below to the kernel (nls.c), which passes the codepage in BP to the nlsfunc installation check and the result is 0352 0352 As you see, in this case the correct value is shown in both cases :-O My setup: Kernel 2035, compiled with any combination of OpenWatcom 1.2, Turbo C++ 1.01 and NASM versions 0.98.36 and 0.98.38. Tested in dosemu 1.2.1. Links to test programs: http://perso.wanadoo.es/samelborp/testchcp.exe http://perso.wanadoo.es/samelborp/testchcp.c http://perso.wanadoo.es/samelborp/nlsfoo.com http://perso.wanadoo.es/samelborp/nlsfoo.asm Kernel patch (for testing purposes): -- ke2035.orig/kernel/nls.c 2004-06-24 13:41:18.0 +0200 +++ ke2035/kernel/nls.c 2004-07-22 10:37:37.0 +0200 @@ -122,7 +122,7 @@ COUNT muxLoadPkg(UWORD cp, UWORD cntry) /* make sure the NLSFUNC ID is updated */ #error "NLS_FREEDOS_NLSFUNC_VERSION == NLS_FREEDOS_NLSFUNC_ID" #endif - if (muxGo(0, 0, NLS_FREEDOS_NLSFUNC_VERSION, 0, NLS_FREEDOS_NLSFUNC_ID, 0, + if (muxGo(0, cp, NLS_FREEDOS_NLSFUNC_VERSION, 0, NLS_FREEDOS_NLSFUNC_ID, 0, (UWORD *)&id) != 0x14ff) return DE_FILENOTFND; /* No NLSFUNC --> no load */ if (id != NLS_FREEDOS_NLSFUNC_ID) /* FreeDOS NLSFUNC will return */ TIA and sorry for the long post. Eduardo. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Hello Eduardo,
> I've found what seems an odd bug in the kernel (version 2035) while
> testing a first alpha version of nlsfunc and it is driving me mad:
> In nls.c:muxLoadPkg(), the value of cp becomes 0 right after the first
> call to muxGo() (the one that does the installation check).
solved:
*** nls.c, 98:
STATIC COUNT muxGo(int subfct, UWORD bp, UWORD cp, UWORD cntry, UWORD bufsize,
void FAR *buf, UWORD *id)
{
int ret;
iregs r;
log(("NLS: muxGo(): subfct=%x, cntry=%u, cp=%u, ES:DI=%p\n",
subfct, cntry, cp, buf));
/* ret = call_nls(subfct, &nlsInfo, bp, cp, cntry, bufsize, buf, id);
mov al, [bp + 4]; subfct
mov ah, 0x14
mov si, [bp + 6]; nlsinfo
mov bx, [bp + 10] ; cp
mov dx, [bp + 12] ; cntry
mov cx, [bp + 14] ; bufsize
les di, [bp + 16] ; buf
pushbp
mov bp, [bp + 8]; bp
int 0x2f
pop bp
mov bp, [bp + 20] ; store id (in
SS:) unless it's NULL
or bp, bp
jz nostore
mov [bp], bx
*/
r.a.b.h = 0x14;
r.a.b.l = subfct;
r.si = (short)&nlsInfo;
r.bp = bp;
r.b.x = cp;
r.d.x = cntry;
r.c.x = bufsize;
r.di = FP_OFF(bp);
r.es = FP_SEG(bp);
intr(0x2f,&r);
if (*id)
*id = r.b.x;
ret = r.a.x;
log(("NLS: muxGo(): return value = %d\n", ret));
return ret;
}
int2f,406
+%if 0
; moved into intr() style by tom
; extern UWORD ASMCFUNC call_nls(UWORD subfct, struct nlsInfoBlock *nlsinfo,
; UWORD bp, UWORD cp, UWORD cntry, UWORD bufsize, UWORD FAR *buf, UWORD *id);
global _call_nls
_call_nls:
int2f, 439:
ret
+%endif
additionally, you need my recent patch, that makes intr available again.
tom
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Hi Eduardo, the fix below fixes your problem as well. To Tom: I appreciate the fact that you find intr() easier to use and less bug prone, but there is a minor and a major problem with it in resident code (as opposed to init code where there is only a very minor problem). Minor: - not using intr() saves ~100 bytes of code Major: - not using intr() saves almost 30 bytes of stack. You can work around that by making iregs r static but then the 24 bytes go into low memory. Saving stack space is very important when calling potentially foreign TSRs as you know (and it may make it possible for friendly TSRs to reenter DOS after all). Bart --- int2f.asm.~1.34.~ 2004-05-04 22:16:45.0 +1200 +++ int2f.asm 2004-07-24 12:20:10.0 +1200 @@ -412,6 +412,7 @@ pushbp mov bp, sp pushsi + pushdi mov al, [bp + 4]; subfct mov ah, 0x14 mov si, [bp + 6]; nlsinfo @@ -428,6 +429,7 @@ jz nostore mov [bp], bx nostore: + pop di pop si pop bp ret --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Hello Tom, apart from the drawbacks there is another problem: --- mov bp, [bp + 20] ; store id (in SS:) unless it's NULL or bp, bp jz nostore mov [bp], bx nostore: --- > > if (*id) > *id = r.b.x; The first * in this part is wrong, and also id lives on the stack, but SS!=DS here (!), see the comments elsewhere in nls.c. it would need to be if (id != NULL) /* or if (id) */ poke(_SS, id, r.b.x); returning a "long" (or a struct with two ints, but I'm not sure if all compilers we use put that in dx:ax) would be another way to avoid this, and save a bit of stack space too. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Bart Oldeman wrote: > the fix below fixes your problem as well. Bart, Tom, thanks to both. Bart, this works perfectly. Tom, your patch seems to cause some problems (now the wrong DS is passed to some nlsfunc calls. It happens with a modified nls.c, I can send you the code and the details if you are interested) Now, guys, if you could only give me a hint on how to implement this: http://sourceforge.net/mailarchive/message.php?msg_id=8809361 In return, I promise you a tour through the best tapas bars in Madrid next time you come. I'll pay the bill, of course! ;-) Eduardo. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Hi!
24-Июл-2004 14:37 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO> apart from the drawbacks there is another problem:
BO> mov bp, [bp + 20] ; store id (in SS:) unless it's NULL
BO> or bp, bp
BO> jz nostore
BO> mov [bp], bx
BO> nostore:
>> if (*id)
>> *id = r.b.x;
[above code from tom's patch, where he tries to replace asm by C code]
BO> The first * in this part is wrong, and also id lives on the stack, but
BO> SS!=DS here (!), see the comments elsewhere in nls.c.
Line 114:
COUNT muxLoadPkg(UWORD cp, UWORD cntry)
{
UWORD id; /* on stack, call_nls in int2f.asm takes care of this
* if DS != SS */
BO> it would need to be
BO> if (id != NULL) /* or if (id) */
BO> poke(_SS, id, r.b.x);
Yes. Very ugly. :(
BO> returning a "long" (or a struct with two ints, but I'm not sure if all
BO> compilers we use put that in dx:ax)
BC does, TC does, OW does. Don't know about MSVC, but I doubt that it
doesn't.
BO> would be another way to avoid this, and save a bit of stack space too.
Hm. You mean, return in DX value of BX instead storing it at *id?
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
On Sat, 24 Jul 2004, Eduardo Casino wrote: > Tom, your patch seems to cause some problems (now the wrong DS is passed > to some nlsfunc calls. It happens with a modified nls.c, I can send you > the code and the details if you are interested) If you don't initialize r.ds in a call to intr there is garbage in there. r.ds = FP_SEG(&nlsInfo) is also necessary if you go that route. Using direct assembly DS will just stay that. > Now, guys, if you could only give me a hint on how to implement this: > > http://sourceforge.net/mailarchive/message.php?msg_id=8809361 It's a difficult question. Essentially there are two ways we can go: 1. if the kernel very carefully minimizes stack usage on the code path taken and NLSFUNC itself only uses a couple bytes of stack in between it's possible to just do it. or 2. nlsfunc would have to copy anything in between ss:sp and ss:920 (_disk_api_tos, that's the top of the stack used here in any DOS >= 4.0) to a temp area (max 384 bytes), set sp to 920, and with that call DOS. Then after the call adjust the stack pointer, then swap it back, then return. 2. is probably easiest unless we also like to experiment with 3rd party NSLFUNCs. There may be funny problems I didn't think of but can't think of any though. > In return, I promise you a tour through the best tapas bars in Madrid > next time you come. I'll pay the bill, of course! ;-) Madrid is a long way and a lot warmer than here from what I heard :) Although 40 C is too hot. Greetings from Auckland NZ (10 C, but clear skies). Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
El sáb, 24-07-2004 a las 13:50, Bart Oldeman escribió: > It's a difficult question. Essentially there are two ways we can go: > 1. if the kernel very carefully minimizes stack usage on the code path >taken and NLSFUNC itself only uses a couple bytes of stack in between >it's possible to just do it. > or > 2. nlsfunc would have to copy anything in between ss:sp and ss:920 >(_disk_api_tos, that's the top of the stack used here in any DOS >= > 4.0) to a temp area (max 384 bytes), set sp to 920, and with that call > DOS. Then after the call adjust the stack pointer, then swap it back, > then return. Just curious, what about a 3rd possibility: implement the 2f12xx calls as documented in RBIL? For example, 2f1228: "sets user stack frame pointer to dummy buffer, moves BP to AX, performs LSEEK, and restores frame pointer". (This is the "what", my problem is "how" :) > 2. is probably easiest unless we also like to experiment with 3rd party > NSLFUNCs. There may be funny problems I didn't think of but can't > think of any though. NLSFUNC is very specific of each DOS variant. The internal nls structures are different. Regards, Eduardo. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
On Sat, 24 Jul 2004, Eduardo Casino wrote: > El sáb, 24-07-2004 a las 13:50, Bart Oldeman escribió: > > > It's a difficult question. Essentially there are two ways we can go: > > 1. if the kernel very carefully minimizes stack usage on the code path > >taken and NLSFUNC itself only uses a couple bytes of stack in between > >it's possible to just do it. > > or > > 2. nlsfunc would have to copy anything in between ss:sp and ss:920 > >(_disk_api_tos, that's the top of the stack used here in any DOS >= > > 4.0) to a temp area (max 384 bytes), set sp to 920, and with that call > > DOS. Then after the call adjust the stack pointer, then swap it back, > > then return. > > Just curious, what about a 3rd possibility: implement the 2f12xx calls > as documented in RBIL? For example, 2f1228: "sets user stack frame > pointer to dummy buffer, moves BP to AX, performs LSEEK, and restores > frame pointer". (This is the "what", my problem is "how" :) The user stack frame pointer is poined to by a global variable "user_r" in the FreeDOS kernel. It points to the user stack which is yet another stack. It sits in the SDA at 264hDWORD pointer to stack frame containing user registers on INT 21 What normally happens is that: 1. user calls int21/ah=42 2. registers are pushed on the stack (entry.asm) 3. ss:sp stored in user_r 4. ss:sp moves to DOS stack 5. DOS does the lseek using the values pushed in 2. 6. DOS updates the registers on the user stack Essentially the RBIL comments says that, in MSDOS, 2f1228 changes user_r to point to a dummy place, moves the value of BP to the "AX"-slot in the dummy user_r stack, calls steps 4-6, restores user_r, and returns. In FreeDOS that would mean something like this: case 0x28: old_user_r = user_r; user_r = &tempplace; user_r->AX = r.BP; int21_service(user_r); user_r = old_user_r; break; This has nothing to do with switching kernel stacks, in fact if FreeDOS would do things this way (instead of calling DosSeek directly) it would use even more stack space. This all goes to say that RBIL is a strange place, sometimes it doesn't report much at all (about error codes for instance), and sometimes it reports about such obscure implementation details. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Hi Bart, > This has nothing to do with switching kernel stacks, in fact if FreeDOS > would do things this way (instead of calling DosSeek directly) it would > use even more stack space. Excuse me if I'm a bit thick in the head. Do you mean that it makes no sense to implement the int 2f122[6-9b] functions in FreeDOS and it is better to do what you suggested in your previous post? (http://sourceforge.net/mailarchive/message.php?msg_id=9050842) Eduardo. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Hello again, > 2. nlsfunc would have to copy anything in between ss:sp and ss:920 >(_disk_api_tos, that's the top of the stack used here in any DOS >= > 4.0) to a temp area (max 384 bytes), set sp to 920, and with that call > DOS. Then after the call adjust the stack pointer, then swap it back, > then return. > > 2. is probably easiest unless we also like to experiment with 3rd party > NSLFUNCs. There may be funny problems I didn't think of but can't > think of any though. There are. If I understand it correctly, when calling DOS with ss:920, the flags and return address are trashed because DOS sets ss:920 on entry, again. The one that has worked for me is: - Switch to a local stack - copy anything in between the original ss:sp and ss:920 to a temp area - call DOS ints - restore from temp area - switch to original stack - return Does anybody see any additional problem with this? Eduardo. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
On Mon, 26 Jul 2004, Eduardo Casino wrote: > There are. If I understand it correctly, when calling DOS with ss:920, > the flags and return address are trashed because DOS sets ss:920 on > entry, again. No. The whole point of calling int2f/ax=12xx is that this stack setup is bypassed. i.e. *without* any swapping in NLSFUNC you'd have int21/ah=38 => DOS switches to internal stack => NLSFUNC (still uses DOS stack) => int2f/ax=12xx => back in DOS at a lower place on the same stack. Now it's just very easy to use too much stack in this setup and that's the whole problem. > - Switch to a local stack > - copy anything in between the original ss:sp and ss:920 to a temp area > - call DOS ints > - restore from temp area > - switch to original stack > - return > > Does anybody see any additional problem with this? you should not use a local stack when you call int2f/ax=12xx. As RBIL states: SS = DOS DS (must be using a DOS internal stack) Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
> > This has nothing to do with switching kernel stacks, in fact if FreeDOS > > would do things this way (instead of calling DosSeek directly) it would > > use even more stack space. > > Excuse me if I'm a bit thick in the head. Do you mean that it makes no > sense to implement the int 2f122[6-9b] functions in FreeDOS and it is > better to do what you suggested in your previous post? No, it makes sense to implement them, but you're understanding of RBIL apparently was wrong -- it isn't talking about switching stacks but about pointing to a different stack frame. The only thing RBIL does here is to point out a fairly obscure implementation detail of these functions in MSDOS. None of the int2f/12 functions switch stacks. They all work on the user stack, and for quite a few this has to be equal to a kernel stack too. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
El lun, 26-07-2004 a las 14:09, Bart Oldeman escribió: > No. The whole point of calling int2f/ax=12xx is that this stack setup is > bypassed. > > i.e. *without* any swapping in NLSFUNC you'd have > int21/ah=38 => DOS switches to internal stack => > NLSFUNC (still uses DOS stack) => int2f/ax=12xx => back in DOS at a lower > place on the same stack. > > Now it's just very easy to use too much stack in this setup and that's the > whole problem. > > > - Switch to a local stack > > - copy anything in between the original ss:sp and ss:920 to a temp area > > - call DOS ints > > - restore from temp area > > - switch to original stack > > - return > > > > Does anybody see any additional problem with this? > > you should not use a local stack when you call int2f/ax=12xx. > As RBIL states: SS = DOS DS (must be using a DOS internal stack) I understood all of this the wrong way. I thought that you were saying to call _int21_, that's the reason for the local stack. > > Excuse me if I'm a bit thick in the head. Do you mean that it makes no > > sense to implement the int 2f122[6-9b] functions in FreeDOS and it is > > better to do what you suggested in your previous post? > > No, it makes sense to implement them, but you're understanding of RBIL > apparently was wrong -- it isn't talking about switching stacks but about > pointing to a different stack frame. So, now that I know how to solve the stack problem, is my implementation of int2f/ax122[6-9] correct? (http://sourceforge.net/mailarchive/message.php?msg_id=8802703) Eduardo. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
NLSFUNC and callbacks into kernal (was Re: [Freedos-kernel] Strange bug in kernel 2035)
On Sat, 24 Jul 2004, Bart Oldeman wrote: Hello Bart, DOS has three internal stacks, how about switching to the Critical Error stack and defer any calls when the stack is in use? Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: NLSFUNC and callbacks into kernal (was Re: [Freedos-kernel] Strange bug in kernel 2035)
On Mon, 26 Jul 2004, Steffen Kaiser wrote: > DOS has three internal stacks, how about switching to the Critical Error > stack and defer any calls when the stack is in use? You'd automatically overflow into the Critical Error stack anyway. I wonder about "defer" though -- how do you defer a critical error handler, when say, you try to find a:COUNTRY.SYS without a floppy in the drive? At first sight a delayed critical error handler seems more difficult than switching stacks Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: NLSFUNC and callbacks into kernal (was Re: [Freedos-kernel] Strange bug in kernel 2035)
On Tue, 27 Jul 2004, Bart Oldeman wrote: On Mon, 26 Jul 2004, Steffen Kaiser wrote: DOS has three internal stacks, how about switching to the Critical Error stack and defer any calls when the stack is in use? You'd automatically overflow into the Critical Error stack anyway. I So you can set DOS's Critical Error flag and be happy? wonder about "defer" though -- how do you defer a critical error handler, when say, you try to find a:COUNTRY.SYS without a floppy in the drive? At first sight a delayed critical error handler seems more difficult than switching stacks OK, "defer" is not the right word, how about "autofail". Or, re-enter DOS as like in case of a Critical Error. I never tested (or used) NLSFUNC in conjunction with floppies and I certainly never considered this an option. Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
