The latter does exception unwinding in the kernel on runtime faults (segv, division by zero, etc). It does _not_ unwind destructors or deallocate storage. And yes, I know about this because I had to debug it, on WinCE ARM, where we eventually discovered that there were two different MS compilers, one of which generated code that could be unwound and one of which didn't.
I got bitten porting code to Windows that use setjmp/longjmp not only for exception handling (more correctly: non-local control transfer -- the exception was actually handled by then), but also for implementing a thread library.
The code worked literally everywhere else, but it turned out that on Windows longjmp doesn't just load the registers from the buffer but also does some SEH bollocks. If I recall (and this was in 2006), it didn't matter for the exception handling, but it was a hard crash for switching threads.
So I had to write my own setjmp/longjmp for Windows in assembly language (i.e copy theirs and cut out the SEH bollocks).
Note that in Microsoft compiler land there are two kinds of exception, regular C++ ones and "structured exception handling". https://docs.microsoft.com/en-us/cpp/cpp/try-except-statemen...
The latter does exception unwinding in the kernel on runtime faults (segv, division by zero, etc). It does _not_ unwind destructors or deallocate storage. And yes, I know about this because I had to debug it, on WinCE ARM, where we eventually discovered that there were two different MS compilers, one of which generated code that could be unwound and one of which didn't.