X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
From:	"Rod Pemberton" <dont_have AT bitbucket DOT cmm>
Newsgroups:	comp.os.msdos.djgpp
References:	<43E12016 DOT 2070308 AT mainstreetsoftworks DOT com>
Subject:	Re: TSR issues (with code)
Lines:	69
X-Priority:	3
X-MSMail-Priority:	Normal
X-Newsreader:	Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2800.1441
X-IWN-Posted-By:	[68.60.59.250] Wed Feb 1 19:55:03 2006
Message-ID:	<7t88b3-d2q.ln1@news.infowest.com>
X-Complaints-To:	abuse AT eli DOT net
X-Trace:	52616e646f6d4956ab9aae61b20bf993acae1422cde01d166036f04ded8031b4ed2f07b6c7cb32c4f6630704743e93bca03f2d09843e4cf69d5d7d5e7e118171b89ae042aef309aff9b4aef2ad724af6b4454d131e7a45d005d92117348d059ad61751b025de0793064c9510bab68241e6d390b63e05200aec65382af4c3c2b5576c06264c22e2fcb5cf0e1fa18bd3cb
X-Abuse-Info:	Please be sure to forward ALL headers so that we may process your complaint properly.
NNTP-Posting-Date:	Thu, 02 Feb 2006 03:09:35 UTC
Date:	Thu, 02 Feb 2006 03:11:02 GMT
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

"Brad House" <brad AT mainstreetsoftworks DOT com> wrote in message
news:43E12016 DOT 2070308 AT mainstreetsoftworks DOT com...
> Hi, I'm actually porting an application from Linux, back to
> DOS (think along the lines of multi-threaded apache type daemon
> but not nearly as large or complex), and I've got everything working
> flawlessly _except_ the TSR portion.  Basically, I've separated the
> code out for testing to rule out anything within my application
> (test code ~250 lines, took out threading/context switches).  I've based
> the TSR code off of the standard Charles Sandmann DJGPP TSR.
>
> I've read everywhere about not making DOS calls within a TSR,
> but this is a necessary evil.  I read that you _can_ make
> DOS calls if you check the InDos and CritErr flags, and also
> add an interrupt handler to 0x28 as well to hook the Dos
> IDLE interrupt, since it is safe to execute DOS calls if
> InDos is 0x01 and CritErr is 0x00 within an 0x28 DOS IDLE
> handler.  (The only call I'm making that might call a DOS
> interrupt is write(), unless dosmemget() does and I don't
> know it).  I also call 'cli' upon entry to my interrupt handler
> to disable interrupts, and 'sti' upon exit to re-enable them.
>
> What's happening is this ... in WindowsXP in a DOS box, it runs
> flawlessly (it completes and unloads itself).  In DOS 6.22, it
> gets called around 1000 times, then DOS entirely locks up
> (the entire test ends at 10,000 and it calls write() every 100
> times the interrupt is triggered where InDos and CritErr are 0x00).
> My only thought is that I must not be checking the InDos or CritErr
> flags properly... I didn't see any code on how to do it from within
> protected mode, so I simply did a __dpmi_int call to get the address of
> each, and use dosmemget()  to retrieve the one-byte indicators
> for each, though maybe my usage is in error.
>
> I've attached the code to this message and compile it as:
> gcc -Wall -o testtsr.exe testtsr.c tsr.c
> I would greatly appreciate any insight anyone can provide!
>

Sorry,

It ran to completion after roughly 8 minutes in a both a Win98SE DOS-box and
in RM MS-DOS 7.10 (Win98SE).  I had to hit return to get the prompt back.
Perhaps, something else is interrupting the process or running at the same
time?

I did notice that CWSDPMI created a swap file on my machine, so maybe the
6.22 DOS machine doesn't have enough memory?

You can also try running stubedit and changing the DPMI host to
PMODETSR.EXE.  If the problem goes away, there is an issue with the way you
are using DPMI w/CWSDPMI.  I can provide more help, if this is the issue.

Other than that, I have a few comments:

1) _go32_my_cs  maps  to _my_cs() in go32.h

2) It appears that you eventually want this to work for DJGPP and OW.  In
which case, you should use 'disable' or '_disable' for 'cli' and 'enable' or
'_enable' for 'sti'.  DJGPP maps to one assembly instruction, but OW uses
_two_ assembly instructions for one of them...

3) It was hard to tell what was C code and preprocessor code because you use
spaces between '#' and the rest of the preprocessor directive.  I don't even
think that is legal, although it works.


Rod Pemberton

- Raw text -