For DOSEMU users - djgpp and ^C troubles

For DOSEMU users - djgpp and ^C troubles

Post by Alberto Vigna » Mon, 17 Feb 1997 04:00:00



Hi.

Take a program compiled with djgpp 2.0, even a very simple one. Run it under
Linux dosemu (0.64 or 0.65 version). Stop it with ^C and restart it.
If you are not satisfied with the results :(, you can try this patch:

----------------------------------------------------------------------------
diff -urN dosemu-0.65.0.6/src/dosext/dpmi/dpmi.c dosemu-0.65.0.6/src/dosext/dpmi/dpmi.c
--- dosemu-0.65.0.6/src/dosext/dpmi/dpmi.c      Fri Jan 24 09:47:46 1997

        }                       /* _trapno==13 */
        else
 #ifdef __linux__
-               do_cpu_exception(scp);
+       /*
+        * When we stop a djgpp program with ^C, it just goes down, and
+        * we get a stack exception. If we continue we stay in DPMI,
+        * and this is _not_ a good thing. dosemu or djgpp library bug?
+        */
+               if (_trapno == 12) quit_dpmi(scp,1); else
+                       do_cpu_exception(scp);
 #endif
 #ifdef __NetBSD__
        do_cpu_exception(scp, code);
----------------------------------------------------------------------------

Can someone (Eli?) enlighten me on what's going on when you press ^C?
When a djgpp program terminates normally, I see all the shutdown sequence
up to the int0x21-AX=4Cxx which signals dosemu to quit the DPMI server.
This doesn't happen with ^C; on the dosemu side, I have currently to rely
on the stack fault to understand what went on. There should be a better
way.

Thanks
Alberto

 
 
 

For DOSEMU users - djgpp and ^C troubles

Post by Eli Zaretski » Tue, 18 Feb 1997 04:00:00



> Can someone (Eli?) enlighten me on what's going on when you press ^C?
> When a djgpp program terminates normally, I see all the shutdown sequence
> up to the int0x21-AX=4Cxx which signals dosemu to quit the DPMI server.
> This doesn't happen with ^C; on the dosemu side, I have currently to rely
> on the stack fault to understand what went on.

I'm not the best person to ask about these issues, so I cc: this to
Charles Sandmann who might have better insight.  Please take the info
below with a grain of salt, in case I confuse things.

I think this is a bug in DOSEmu.  It probably handles ^C specially and
kills the DJGPP program before ^C ever gets to it.  Because if ^C
would get to your program, it will cause (almost) the same chain of
events as with Ctrl-Break (which works, right?):

        1) the ^C key is detected by the keyboard interrupt handler
installed by the DJGPP startup code;

        2) the keyboard handler invalidates the DJGPP DS selector;

        3) when your program accesses any of its data, the invalid DS
causes an exception;

        4) the exception gets caught by the DJGPP exception processor;

        5) the exception processor prints the message about SIGINT and
aborts your program by calling `_exit' (or calls your SIGINT handler
if you installed one);

        6) `_exit' shuts down the program and eventually calls the DOS
Int 21h/AH=4Ch function.

[What's different about Ctrl-Break is that it generates interrupt 1Bh
which is hooked by the DJGPP startup code, instead of being detected
by the keyboard handler.]

One thing that I would suggest testing is to install a handler for
SIGINT and see if it gets called at all when you press ^C or
Ctr-Break.

Charles?

 
 
 

For DOSEMU users - djgpp and ^C troubles

Post by a.vign.. » Tue, 18 Feb 1997 04:00:00



Quote:>> Can someone (Eli?) enlighten me on what's going on when you press ^C?
>> When a djgpp program terminates normally, I see all the shutdown sequence
>> up to the int0x21-AX=4Cxx which signals dosemu to quit the DPMI server.
>> This doesn't happen with ^C; on the dosemu side, I have currently to rely
>> on the stack fault to understand what went on.

Many thanks for your suggestions!

Quote:>I think this is a bug in DOSEmu.  It probably handles ^C specially and
>kills the DJGPP program before ^C ever gets to it.  Because if ^C
>would get to your program, it will cause (almost) the same chain of
>events as with Ctrl-Break (which works, right?):

Right.

Quote:>    1) the ^C key is detected by the keyboard interrupt handler
>installed by the DJGPP startup code;

>    2) the keyboard handler invalidates the DJGPP DS selector;

>    3) when your program accesses any of its data, the invalid DS
>causes an exception;

This is what I see. There is a SetSegmentLimit(0xcf,0xfff) as soon as
^C is written in the BIOS keyboard buffer, and since ds=es=ss=0xcf this
is the cause of the stack fault.

Quote:>    4) the exception gets caught by the DJGPP exception processor;

>    5) the exception processor prints the message about SIGINT and
>aborts your program by calling `_exit' (or calls your SIGINT handler
>if you installed one);

Hmmm... I installed a SIGINT handler, and what I see is that after the
1st exception there is now another SetSegmentLimit (0xcf,0x5ffff);
after that, my handler is called. It then calls _exit, and all works fine.

Maybe the client code is killed before it gets a chance to change the
segment limits again; as a result, in the 'normal' case, _exit doesn't
get called.
This bug is of course not self-evident (timing?), needs some digging
into the dosemu code :(

And BTW the patch I proposed seems to have side effects on the DOS timer :(

Alberto

 
 
 

For DOSEMU users - djgpp and ^C troubles

Post by Eli Zaretski » Wed, 19 Feb 1997 04:00:00



Quote:> >       3) when your program accesses any of its data, the invalid DS
> >causes an exception;

> This is what I see. There is a SetSegmentLimit(0xcf,0xfff) as soon as
> ^C is written in the BIOS keyboard buffer, and since ds=es=ss=0xcf this
> is the cause of the stack fault.

That would suggest that the DOSEmu DPMI host doesn't switch to a
separate stack when an exception hits.  You could probably see if
that's the case by looking at the Linux sources.

Quote:> 1st exception there is now another SetSegmentLimit (0xcf,0x5ffff);
> after that, my handler is called. It then calls _exit, and all works
> fine.

This seems like the DJGPP exception processor at work: when the
exception happens, it makes DS selector valid again, then calls your
handler.

Quote:> Maybe the client code is killed before it gets a chance to change the
> segment limits again; as a result, in the 'normal' case, _exit doesn't
> get called.

That's what it looks like, yes.
 
 
 

1. A DOS bug that may cause trouble for djgpp users

As hereinunder, Messy-DOS's *.BATfile caller goes BATs when it finds an `=' in
an argument. This may cause obscure trouble for people who call a Gnu C/C++
program via a *.BAT . I have MS-DOS 6.22 . <-------- marks lines that I typed.

C:\AMZIP>TYPE T$.CC           <------------
#include<stdio.h>
main(int nargs,char**Arg){int i;
for(i=0;i<nargs;i++) printf("%4dth arg is `%s'\n",i,Arg[i]);}
C:\AMZIP>TYPE T$$.BAT               <-------------
t$.exe %1 %2 %3 %4 %5 %6 %7 %8
C:\AMZIP>t$ cat=and=mouse=games     <----------------
   0th arg is `c:/amzip/t$.exe'
   1th arg is `cat=and=mouse=games'

C:\AMZIP>t$$ cat=and=mouse=games        <------------------

C:\AMZIP>t$.exe cat and mouse games
   0th arg is `c:/amzip/t$.exe'
   1th arg is `cat'
   2th arg is `and'
   3th arg is `mouse'
   4th arg is `games'

2. Commodore Includes?

3. dosemu trouble

4. How many of you are totally new to MS's PDA's?

5. Where Can I get DJGPP's User Manual or User Guide by ASCII Text

6. CoolEdit96....Digital sound editor

7. PDF filenames not listed in Acrobat Catalog 5.0 index

8. DJGPP, DOSEmu and IPX

9. DJGPP under Linux DOSEMU or Wine

10. Dosemu .66.7 and DJGPP + RHIDE 1.3C

11. dosemu & djgpp

12. running DJGPP programs in DOSEMU?