On Wed, 3 Mar 2004, Luchezar Georgiev wrote: > On Tue, 2 Mar 2004 21:06:03 +0000 (GMT), Bart Oldeman wrote: > > > at first sight it looks good to me, thanks! The one thing I saw that might > > have to be changed is the location of the new stack. Since RBIL table 1690 > > (very end of interrupt.g) specifies a few variables up to 7d? and this new > > stack should certainly not be part of the swappable data area. > > I now look at this table and I now see why the stack size was selected > as 384 bytes! I wonder if these words are too "MS-DOS internal use only" > and whether we should care about them.
Yes we should care! This area is used by all sorts of TSRs and network redirectors that live "under" DOS. These fixed locations cannot be changed without breaking apps that rely on undocumented DOS in various ways. > One possible solution would be to > decrease the stack size to 288 bytes (120h) - then the four stacks could > fit. theoretical perhaps.... Have a look at the stacks after DOS has booted to see how much is left (you can see the high water mark by watching 90 90 ...) -- 288 bytes is really not a lot and Tom and I have had to go through some real trouble in the past to reduce stack usage. > I don't know. I'd like to ask you to write a description of the kernel > stack usage, Most is described in books such as Undocumented DOS. They describe the disk_api (int21/ah>0ch), char_api (int21/ah<=0ch) and error stacks (for int24) that we have too. On top of that FreeDOS has private stacks for the builtin clock (sysclk.c) and block (dsk.c) device drivers. Of all these stacks need to be in the swappable data area, since if a SDA-swapping TSR decides to reenter DOS it will need to restore the stacks after finishing. Some TSRs such as THELP however are called from int28 where DOS uses the char_api stack. So THELP is free to call any DOS function on the disk_api stack. However the new stack you now have put in is not affected by any re-entering so can stay out of the SDA. > and how the STACKS configuration parameter affects it. Not at all. STACKS affects the (dynamically allocated) IRQ stacks used by hardware interrupts (ints 8-f and 70-77) STACKS=0,0 causes 0 IRQ stacks -- a side effect could be that the DOS stacks (or application stacks) could overflow then. Bart ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
