Hello,

I've tried to port a bc++5.02 DOS project on an 386ex embedded platform to
dmc++ (because Borland produces really poor code and has still many compiler
errata).
I need far memory model, C++ exception handling, and RTTI. In medium memory
model (-mm), all works fine (except that I have far too less memory in
DGROUP), but when I compile with (-mc) or large (-ml) memory model, I get
"abnormal program termination" as soon as an exception is thrown, regardless
if it is a simple throw (e.g. int, "throw 8;") or a structured exception type
(class MyThrowable).

Using set_terminate() and set_unexpected shows that terminate() is called, but
unexpected() never gets called, so i reckon a serious bug in exception
handling within memory models with far data pointers.

Switching off RTTI doesn't help, only changing the memory model.
Switching to 32 bit mode is no alternative, as we are doing heavy interrupt
services in our program, and that would require a bigger restructuration of
the application.

Is this issue known, is there any workaround?

Bernd Linsel wrote:
> I've tried to port a bc++5.02 DOS project on an 386ex embedded platform to
> dmc++ (because Borland produces really poor code and has still many compiler
> errata).
> I need far memory model, C++ exception handling, and RTTI. In medium memory
> model (-mm), all works fine (except that I have far too less memory in
> DGROUP), but when I compile with (-mc) or large (-ml) memory model, I get
> "abnormal program termination" as soon as an exception is thrown, regardless
> if it is a simple throw (e.g. int, "throw 8;") or a structured exception type
> (class MyThrowable).
> 
> Using set_terminate() and set_unexpected shows that terminate() is called, but
> unexpected() never gets called, so i reckon a serious bug in exception
> handling within memory models with far data pointers.
> 
> Switching off RTTI doesn't help, only changing the memory model.
> Switching to 32 bit mode is no alternative, as we are doing heavy interrupt
> services in our program, and that would require a bigger restructuration of
> the application.
> 
> Is this issue known, is there any workaround?

It isn't a known issue. I think you might be the first to use EH for large model!