🚀 go-pugleaf

Minghua Yao wrote:
> 
> I have a C module 

Sorry, no answer to your problem.
Just to let you know that your mailer does not wrap long lines.
Check it out.
Bye.

-- 
Regards,
---------------------------------------------------
Danny Hendrickx   |                               |
Alcatel Telecom   |                               |
Antwerp, Belgium  | hendrida@btmaa.bel.alcatel.be |
-----------------------------------------------------------------
"Man is the best computer we can put aboard a spacecraft... 
and the only one that can be mass produced with unskilled labor." 
-----------------------------------------------------------------

While prying the lemmings from hir ankles 23 Apr 1996 20:45:30 GMT,
myao@mailhost.ecn.uoknor.edu (Minghua Yao) wrote:

>I have a C module which uses "fopen()" to open a file. When called by a
> C main(), the module works well and the file can be opened. But if this
> module is called by a TSR code (which is loaded at an interrupt not used
> by the DOS, and is executed by activating this interrupt), the file which does
> exist cannot be opened often times. Sometimes (seldom,though) the file
> can be opened. If so, the machine will die. The behavior seems to be
> undefinte.

Could you be running afoul of the InDos problem?  Sometimes in a TSR
it's not safe to use some int 21h functions; if fopen() uses int 21h
you could sometimes run into problems.  Others here will be able to
say with better certainty how likely this is and suggest workarounds
if this is your problem.

Minghua Yao wrote:
> 
> I have a C module which uses "fopen()" to open a file. When called by a C main(), the module works well and the file can be opened. But if 
this module is calle
> 
> The working enviroment is DOS. I use 80x86 assembly for The TSR and Borland C for the C module. The C module is resident part of the TSR.
> 
> Anybody's help will be greatly appreciated.

The problem is likely that you are calling a dos function from a TSR.  
When doing so,  you must check the InDos flag to make sure that the 
Int21h interrupt is not being run.  You see, int 21h is not reentrant, 
which means it can't be run again before it is finished running the 
first time.  If you invoke the TSR while a call to interrupt 21h is 
being made,  the interrupt call will be put on hold and your code will 
be called.  You said that your code opens a file.  This will most likely 
use int 21h to do so.  When int 21h is called again, it is already 
running.  This will have serious consequences on the operation of DOS,  
and usually causes a system crash.  What you need to do,  is call int 
21h, function 34h, before your tsr is loaded.  This will return the 
address of the InDos flag in ES:BX.  By checking this address you can 
tell when dos is running. (if it is, it will be 1, otherwise it will be 
0).  We still have the problem, however.  If dos is at the command line 
the indos flag is still set.  Therefore,  you need to also hook int 28h 
- the Dos idle flag.  Dos calls this interrupt when it is waiting for 
user input.  When everything is clear,  you can run your procedure to 
open a file.
		
						Ian MacLennan

myao@mailhost.ecn.uoknor.edu (Minghua Yao) wrote:

>I have a C module which uses "fopen()" to open a file. When called by a C main(), the module works well and the file can be opened. But if this module is called by a TSR code (which is loaded at an interrupt not used by the DOS, and is executed by activating this interrupt), the file which does exist cannot be opened often times. Sometimes (seldom,though) the file can be opened. If so, the machine will die. The behavior seems to be undefinte.

>The working enviroment is DOS. I use 80x86 assembly for The TSR and Borland C for the C module. The C module is resident part of the TSR.

>Anybody's help will be greatly appreciated.

Dos is not reentrant. This means you can not make and calls to dos
when another dos call is already in progress.  If you do then the
results are undetermined. There are ways to determine when it is safe
to call dos and ways to set a flag so that as soon as it is ok the
dirty deed will be done then. It is rather a lot to explain but there
are many good books on the subject.

I hope I haven't insulted your intelligence but it sounds like this is
the problem if it works fine from main. l8r

myao@mailhost.ecn.uoknor.edu (Minghua Yao) writes:

>I have a C module which uses "fopen()" to open a file. When called by a 
>C main(), the module works well and the file can be opened. 
>But if this module is called by a TSR code (which is loaded at an interrupt 
>not used by the DOS, and is executed by activating this interrupt), 
>the file which does exist cannot be opened often times. Sometimes 
>(seldom,though) the file can be opened. If so, the machine will die. 
>The behavior seems to be undefinte.

>The working enviroment is DOS. I use 80x86 assembly for The TSR and 
>Borland C for the C module. The C module is resident part of the TSR.

>Anybody's help will be greatly appreciated.

High,

there are possible two reasons. 
1. InDOS-Flag
   Indeed it is important that there is no other action in DOS, because
   DOS is not reentrant. The way to check it out is already discribed.

2. The stack !!
   The C-module fopen() uses a very large buffer for reading the file.
   And this buffer will be allocated on the normal stack. If perhaps you
   have the DOS-stack activ, it will be the reason. If you use a stack
   that you have defined, perhaps it will be too small.
   I also used the fopen()-module and have had the same results you have
   now.
   The InDOS-flag did not help. I have changed all the fopen-calls to the
   low-level-routine open(). With the open()-module it runs fine and I did
   not need a too large stack for the buffer.

Perhaps it helps

   Rainer


--
------------------------------------------------------------------------------
Rainer Wenn     				       rainer@tpki.toppoint.de
24145 Kiel-Meimersdorf
------------------------------------------------------------------------------