https://bugs.winehq.org/show_bug.cgi?id=43966
--- Comment #17 from VitorMM vitormm@portingkit.com --- (In reply to Ken Thomases from comment #16)
"Faster answer"? In either case, the failure would only happen at the time of the attempt to create the 125th thread or whatever. If the call to i386_set_ldt() fails because you let Wine try a too-high index, then you get the "i386_set_ldt: Invalid argument" message and probably an access violation immediately afterward.
If you change LDT_SIZE so that Wine doesn't even try the too-high index, then CreateThread()/CreateRemoteThread()/RtlCreateUserThread() returns an error status code. The caller may or may not actually check the return value. If it doesn't, then it just goes on assuming the thread was created when it wasn't. There may or may not be immediately obvious consequences, including log messages.
Well, technically that's something that should be something handled by the application, and not by Wine :P
If I understood correctly, the access violation isn't going to be received by the Windows application. Instead, this will crash Wine due to the access violation, or not?
In any case, this should just be a temporary hack for a beta version of the OS. It's not terribly important exactly how it fails, is it?
Well, Wine doesn't even launch without that change, and considering that Apple may not change that, leaving those as the real parameters for macOS, this may become more than a temporary hack :P
Also, if the Windows application fails to create the thread, it may find a way to handle it if it was properly programmed. If Wine receives an access violation, there is no way that this should be properly handled in order to proceed using the application, or I misunderstood the consequences of the access violation?