Mail Archives: djgpp/2000/07/18/00:34:29
> > From: Esa A E Peuha <peuha AT sirppi DOT helsinki DOT fi>
> > Newsgroups: comp.os.msdos.djgpp
> > Date: 14 Jul 2000 10:04:11 +0300
> >
> > > Beware: binding programs with PMODE/DJ is known to have bad effects
> > > when that program is invoked from another DJGPP program which uses
> > > CWSDPMI. I found that out when I tested unzip32.exe (available from
> > > DJGPP FTP sites), which is also bound to PMODE/DJ, for the same
> > > reasons you did. When I invoked it from `redir', it frequently
> > > crashed/rebooted/hung my machine. I'm guessing that there's some bug
> > > in PMODE that triggers a disaster in CWSDPMI.
> >
> > I looked into this. It seems that when CWSDPMI is present, the PMODE
> > stub is unable to transfer execution to the COFF image.
>
> I saw much more dramatic phenomena than that, as described above. Or
> are you saying that PMODE couldn't jmp to the program's entry point
> and only *after* that crashed?
>
> Any idea why cannot it pass the execution thread? Perhaps you could
> elaborate a bit about what exactly happens that prevents it to jmp to
> the entry point. To me, it looked as some memory managing problem
> (when it didn't hang immediately ;-) because CWSDPMI said something
> about page tables.
Complaints about pagetables usually means that there are DOS memory problems.
It may be out of DOS memory or corrupted bitmaps.
In any case, does the bad behavior get shown if you just run CWSDPMI itself
before the PMODE/DJ image? If not, then the exec code and nesting seems to
be contributing. If someone would post enough information to diagnose or
reproduce it in a minimal environment I'd look at it.
- Raw text -