cannot use a certain dll under freepascal, but works with delphi- cdecl problem?

[valdir.marcos]

I don't think this is SEH fault tho - there is no exception at all under delphi.

Delphi doesn't know anything else, so that is why that is important.
And yes, specifically ms compilers mess with the float settings.(and are not in any way compliant to standards)
Glad it is now solved.

That has nothing to do with MS compilers. It would be similar with GCC: C/C++ programs normally don't expect floating point exceptions (floating point exceptions are not part of the standard). FPC (and Delphi) by default set the exception mask to something different, so it is rather common that one has to change the exception mask when working with such libraries.

It is actually that the Borland 32 bit compilers - including C++ builder - adhere to the IEEE 754 described standards for floating point handling, whereas msvc does not adhere. if other compilers follow msvc they are also not standards compliant.
But indeed the issue exists for many years and up until now I only have to solve it for ms compiled code, or recompile for C++ builder (which I do not recommend for 32 bit since it optimizes not as good as msvc.)
Danny Thorpe wrote a lengthy blog about this many moons ago. I'll see if I can find it.

Is it this one?
PC Mag, 22 feb 1994, PowerProgramming, Danny Thorpe, Senior Quality-Assurance Engineer for the Pascal Development Team at Borland International  in 1980's and 1990's.
https://books.google.com.br/books?id=v5YwX3auv0cC&pg=PA284&lpg=PA284&dq=Danny+Thorpe++floating-point+operations&source=bl&ots=8ju2aRzoc5&sig=ACfU3U2esJskwOHoUkfHXMES_KnHXPSdCw&hl=pt-BR&sa=X&ved=2ahUKEwi-y4_Wg93lAhU3ILkGHVC2CMkQ6AEwAXoECAkQAQ#v=onepage&q=Danny%20Thorpe%20%20floating-point%20operations&f=false

Or is it here?
Delphi Compiler Core blog (2003-2005) Added to Archives
Posted by Danny Thorpe at 12:02 am Sep 14, 2012
https://dannythorpe.com/2012/09/14/delphi-compiler-core-blog-2003-2005-added-to-archives/

[Thaddy]

Neither. It should be somewhere around 1997-8. He wrote specifically about interfacing with non-IEEE 754 compliant dll's, specifically msvc and  Delphi32.

[JernejL]

Interesting how this floating point stuff is not so uniform at all.
 
It does bother me that the exception information in fpc and lazarus debugger in this case was very useless,
 
Visual studio said "Multiple floating point traps (parameters: 0x00000000, 0x00001921)."
 
FPC/Lazarus: "Project TexWorkshop raised exception class 'External: ?'. At address 72D1117A"
 
Could this be a good example for a bug report / improvement?
 

[Thaddy]

Different compilers compile different code and to different addresses, so that is not a bug  by itself.

[440bx]

Could this be a good example for a bug report / improvement?

I agree that there is definitely room for the message to be improved.  Personally, I think it is worth reporting.  Reporting it will make it visible and give the FPC developers the opportunity to decide if they want to do something about it.

[JernejL]

Different compilers compile different code and to different addresses, so that is not a bug  by itself.

This is not a matter of code, but debugging - debugger in visual studio made a more correct error message than gdb + lazarus debugging combo, debugged were identical binaries.
 

[valdir.marcos]

Could this be a good example for a bug report / improvement?

I agree that there is definitely room for the message to be improved.  Personally, I think it is worth reporting.  Reporting it will make it visible and give the FPC developers the opportunity to decide if they want to do something about it.

Different compilers compile different code and to different addresses, so that is not a bug  by itself.

This is not a matter of code, but debugging - debugger in visual studio made a more correct error message than gdb + lazarus debugging combo, debugged were identical binaries.

It seems that, in the future, GDB will be deprecated and abandoned in favor of fpDebug.
Maybe this bug report should be better addressed to improve fpDebug.