X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" Newsgroups: comp.os.msdos.djgpp Subject: Re: file close being called Date: Sun, 19 Oct 2014 16:51:18 -0400 Organization: Aioe.org NNTP Server Lines: 103 Message-ID: References: NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse AT aioe DOT org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Bytes: 4147 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Sun, 19 Oct 2014 13:07:14 -0400, Louis Santillan wrote: > On Sat, Oct 18, 2014 at 6:25 PM, Rod Pemberton > wrote: [fixed Usenet bottom posting] >> >> I'm seeing Int 21h, AH=3Eh (close file) being >> called in protected mode (PM) or perhaps it's >> being reflected to PM by the DPMI host. >> >> I've searched the sources for DJGPP and CWSDPMI >> and I can find no indication that this interrupt >> is called by DJGPP in PM or being reflected by >> CWSDPMI to PM. >> >> Does anyone know why or where this is happening? >> > > I think you're gonna need to tell us a whole lot more > about your situation here. DOS version, DOS drivers, > TSRs, your source (smallest example thar exhibits the > same issue) that is being run when you see this. > Ok. I'm not sure why. The issue was stated clearly. And, I'd expect that DJ or Eli or Charles should know about this ... > DOS version, MS-DOS v7.10 (Windows 98/SE) This is 16-bit RM code. So, it can only be the cause if CWSDPMI is reflecting Int 21h, AH=3Eh to PM. > DOS drivers, Japheth's HIMEMX This is 16-bit RM code. So, it can only be the cause if CWSDPMI is reflecting Int 21h, AH=3Eh to PM. > TSRs, Franck Umberto's XMSDSK This is 16-bit RM code. So, it can only be the cause if CWSDPMI is reflecting Int 21h, AH=3Eh to PM. Those three things are all I load, normally. I doubt that removing XMSDSK or chaning HIMEMX back to HIMEM will change anything, but I'll check. I conditionally load Henrik Haftmann's DOSLFN or Nagy Daniel's CuteMouse when needed. I'll use P. Frosts DDL or David Woodhouse's DEVLOAD to conditionally load other drivers. In this case, nothging but the three items above are loaded. > your source (smallest example thar exhibits the > same issue) that is being run when you see this. As stated previously, the issue is not with my code. It doesn't open or close any files or do anything really. It simply setups up _go32_dpmi_chain_protected_mode_interrupt_vector() for Int 21h, calls system(), and monitors what AH is called for Int 21h in PM. That's it. When DJGPP apps are executed they triggering Int 21h, AH=3Eh. So, I know it's related to DJGPP apps and isn't related to my code. Int 21h, AH=3Eh and Int 21, AH=4Ch are being called. 4Ch is the DPMI exit in PM and DOS exit in RM. All Int 21h calls, except AH=4Ch, should be redirected to RM via a call to Int 31h and the DPMI host, CWSDPMI. DJGPP is setup this way by design since there are no callable interrupts in PM. AIUI, only IRQ's, Int 21h AH=4C, Int 1Ch, Int 23h, Int 24h, and Int 31h should be normally seen in PM with DPMI hosts. I'm just trying to find out why and where this one interrupt is being called in PM, apparenlty by DJGPP applications, when there are no interrupt routines setup for PM. E.g., is CWSDPMI monitoring it for some reason? Is DJGPP CRT calling it? Etc. Where? I need to know if I can block this, unchain this, or prohibit it in PM, and what it'll mess up if anything. So, DJGPP's CRT, or perhaps something int DJGPP's library for system() is making a PM call, or CWSDPMI is reflecting file closes to PM. Rod Pemberton