What exception model does it use for both x86 and x64 and what is the minimal windows version supported?

[tomay3000]

Hello, I would like to know what exception model does it use for both x86 and x64 and what is the minimal windows version supported? Also if it is possible to link libmcfgthread statically?

TIA.

[lhmouse]

Hello,

I would like to know what exception model does it use for both x86 and x64 and what is the minimal windows version supported?

i686-w64-mingw32 uses SJLJ and x86_64-w64-mingw32 uses SEH.

The minimum Windows version is the same as MSYS2 (Vista I think).

Also if it is possible to link libmcfgthread statically?

No.

[tomay3000]

Thank you for the quick reply.

i686-w64-mingw32 uses SJLJ and x86_64-w64-mingw32 uses SEH.

I actually like the fact that it uses SJLJ over DWARF for i686-w64-mingw32 because it is the only model that ensures compatibility when linked with other libraries without crushing, I have suffered with MSYS2's DWARF one.

The minimum Windows version is the same as MSYS2 (Vista I think).

Unfortunately, I still have few clients running windows XP :(

Also if it is possible to link libmcfgthread statically?

No.

I prefer to have one big final executable with all the needed libraries linked statically, rather than a bunch of DLLs following it everywhere :( TDM-GCC has successfully patched his version to link it statically here https://jmeubank.github.io/tdm-gcc.

I have tried the meganz mingw-std-threads before, here https://github.com/meganz/mingw-std-threads but it just gives you the illusion that you are using std threads, and requires few header modifications of the source code.

With your version it requires patching the GCC source code. Unless you continue supporting it ;) by proving the tool-chain binary releases.

I know, posix for windows sucks and is the worst out there, especially compared to yours (mcf).

Maybe some day the Win32 threading model for Mingw-w64 will be available in the near future, and I hope it will be yours (mcf) instead, for its performance, but nothing is promising.

I am gonna try it out for production and I hope everything go smoothly.

Thank you.

[lhmouse]

Thank you for the quick reply.

i686-w64-mingw32 uses SJLJ and x86_64-w64-mingw32 uses SEH.

I actually like the fact that it uses SJLJ over DWARF for i686-w64-mingw32 because it is the only model that ensures compatibility when linked with other libraries without crushing, I have suffered with MSYS2's DWARF one.

That was my consideration too.

The minimum Windows version is the same as MSYS2 (Vista I think).

Unfortunately, I still have few clients running windows XP :(

Then you have to either stuck with winpthreads, or patch the source of mcfgthread so it works with XP.

1. Read http://locklessinc.com/articles/keyed_events/.
2. On Windows XP, NtWaitForKeyedEvent and NtReleasekeyedEvent return errors if the first argument (handle to a keyed event) is NULL. So you have to open \KernelObjects\CritSecOutOfMemoryEvent explicitly. However, you only have to do this once. The handle can be stored in a global variable so it is available along with the process.

Also if it is possible to link libmcfgthread statically?

No.

I prefer to have one big final executable with all the needed libraries linked statically, rather than a bunch of DLLs following it everywhere :( TDM-GCC has successfully patched his version to link it statically here https://jmeubank.github.io/tdm-gcc.

I have tried the meganz mingw-std-threads before, here https://github.com/meganz/mingw-std-threads but it just gives you the illusion that you are using std threads, and requires few header modifications of the source code.

Static linking is evil.

With your version it requires patching the GCC source code. Unless you continue supporting it ;) by proving the tool-chain binary releases.

I know, posix for windows sucks and is the worst out there, especially compared to yours (mcf).

Maybe some day the Win32 threading model for Mingw-w64 will be available in the near future, and I hope it will be yours (mcf) instead, for its performance, but nothing is promising.

I have heard of no such plan from MSYS2. mingw-w64 does not have binary releases, not to mention prebuilt toolchains.

I am gonna try it out for production and I hope everything go smoothly.

Thank you.

No problem. :)

[tomay3000]

I have heard of no such plan from MSYS2. mingw-w64 does not have binary releases, not to mention prebuilt toolchains.

MSYS2 supports only DWARF. mingw-w64 is outdated, the latest version available is 8.1.0.

[lhmouse]

No it is *mingw-builds that is outdated. As mingw-w64, we don't provide prebuilt packages ourselves.

[lhmouse]

There have been efforts to make this library able to be linked statically, and the exception model for x86 has been switched to DWARF2 now.

As for exceptions: The only standard behavior that is relevant here is that uncaught exceptions shall result in a call to std::terminate().

[lhmouse]

I am closing for now. If you have questions about other packages (GCC, GDB, etc.) please open a new issue at https://github.com/lhmouse/MINGW-packages.

[tomay3000]

There have been efforts to make this library able to be linked statically, and the exception model for x86 has been switched to DWARF2 now.

As for exceptions: The only standard behavior that is relevant here is that uncaught exceptions shall result in a call to std::terminate().

It is very sad that you have decided to drop SJLJ for x86, as it was the only compatible to link against MSVC DLLs with C exported functions without causing the application to crash.

[lhmouse]

In reality, all upstream MSYS2 packages have been being built with the DWARF exception model for years, so I think people should have been used to it.

The primary reason of this change is that, prior to it, it was necessary to keep both libgcc_s_dw2-1.dll and libgcc_s_sjlj-1.dll in the same package, otherwise existent MSYS2 packages might fail. This was not only error-prone (it had to be copied by hand), but also confusing.