From: ams AT ludd DOT luth DOT se (Martin Str|mberg)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: LONG: My INT31 handler isn't feeling too swell
Date: 6 Apr 1999 20:59:14 GMT
Organization: University of Lulea, Sweden
Lines: 83
Message-ID: <7edsj2$agf$1@news.luth.se>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990404093438 DOT 19395L-100000 AT is> <7e7j4e$cr4$4 AT news DOT luth DOT se> <20vhfc47t7 DOT fsf AT Sky DOT inp DOT nsk DOT su>
NNTP-Posting-Host: queeg.ludd.luth.se
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Michael Bukin (M DOT A DOT Bukin AT inp DOT nsk DOT su) wrote:
: One other thing I noted is that you are trying to reuse any selector
: freed with %ax=0x0001.  But this interrupt is used to free selectors
: allocated by other DPMI functions too, not just %ax=0x0000.  Also, you

Yes, but so what? Can't I reuse them as if originally allocated by 
%ax=0x0001? If they are freed (sp?), I thought I should be free (pun
intended) to reuse them, shouldn't I?

: are not changing C flag, because when you are using iret, flags are
: taken from stack.  IMHO, you should change flags on stack before using
: iret.  

Hmm. Yes that seems like a correct diagnose. At what offset of %esp
are the flags upon the entry of my interrupt handler (%esp+x, what is
x)?
:        Also, I think you should not use sti/cli in your interrupt
: handler.

Why not?

My thought there was that I was trying to issue an int, hence I must
enable interrupts otherwise they would be blocked.

: Anybody know what exactly is the problem with leaking descriptors on
: Windows-9X?  Test program shows that Windows DPMI server has no
: problems with allocating/deallocating selectors with 0x0000/0x0001, if
: I make a loop which allocates/deallocates selectors, then it works
: forever (I waited for 1000000 iteration and killed it with CTRL-C).
: 
: Windows may allocate some shadow descriptors for each application and
: not free it when application terminates, but simple reuse of
: descriptors will not work then, because we can only reuse deallocated
: descriptors.  Or maybe Windows does not deallocate resources when
: application terminates, then it might be possible to fix it by
: deallocating all resources that program allocated itself.
: 
: Anyone has any ideas how to find out what is the problem with Windows
: DPMI server?
: 
: I'm using the following code in my test programs:
: 
: if (_argc < 1)
:   {
:     fprintf (...);
:     exit (1);
:   }
: 
: /* Hook interrupts.  */
: 
: spawnvp (P_WAIT, _argv[1], _argv + 1);
: 
: And use the same code (without hooking interrupts) in another test
: program which is then called from the first one.  I used it to
: intercept which DPMI calls are executed by DJGPP programs (a lot of
: them are used, still trying to interpret results).

This is a nice program that displays the problem (courtesy of someone
on c.o.m.d):

#include <stdio.h>
#include <process.h>
#include <sys/segments.h>

int main(int argc, char *argv[])
{
  int i;
  if (argc > 1)
    {
    fprintf(stderr, "my_cs: %04x\n", _my_cs());
    return 0;
    }
  for (i=0;i<0xffff;i++)
    {
    spawnl(P_WAIT, argv[0], argv[0], "1", NULL);
    }
  return 0;
}


My Dying Bride, Like Gods of the Sun,

							MartinS