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
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:
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 in
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)
>
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
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
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
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
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 co
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]
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 sw
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. *witho
> > 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]
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
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 We
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 critic
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
17 matches
Mail list logo
