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=4721alloc_id=10040op=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=4721alloc_id=10040op=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=4721alloc_id=10040op=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_idG21alloc_id040op=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_idG21alloc_id040op=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_idG21alloc_id040op=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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
