Hello, Do you know that is the purpose of __native_startup_state and __native_startup_lock variables used in __tmainCRTStartup() static function which is called only from the EXE application entry point?
I tried to find some documentation, but there is nothing neither on Microsoft webpage and neither in gcc or mingw projects. It looks like that __native_startup_lock is some synchronization which prevents nested execution of __tmainCRTStartup() function. But it is even possible? The only thing which I can imagine that could be possible to happen to make __tmainCRTStartup() execute more times and in paralel is that some initialization function registered in __xi_a-__xi_z or __xc_a-__xc_z arrays creates a new thread and threads entry point jumps to the main EXE application entry point (which then calls __tmainCRTStartup again). Or is there any other option? Anyway even above scenario, the application would mostly crash as after the __native_startup_lock code block is other mingw-w64 specific code which is not guarded by synchronization and would execute more times. I was looking into msvcrt and ucrt source code and both contains this sequence too. With the difference that everything is guarded by the __native_startup_state and __native_startup_lock which seems that prevents duplicate execution. Note that in ucrt those variables are prefixed with __scrt_, called __scrt_current_native_startup_state and __scrt_native_startup_lock. So it seems that duplicate execution of main EXE application entry point in other thread is something which looks like to be possible and visual c++ runtime is explicitly prepared for it. It is something which should be supported? Maybe what could be related to this code, is following. I found is that for mixed assemblies which contains both managed .net code and unmanaged native code there can be a deadlock during initialization. https://learn.microsoft.com/en-us/cpp/dotnet/initialization-of-mixed-assemblies https://web.archive.org/web/20070304222002/http://msdn.microsoft.com/library/en-us/dv_vstechart/html/vcconmixeddllloadingproblem.asp But the possible deadlock described in both articles applies only for DLL builds, not EXE applications. So I'm not sure if it is somehow related at all. In any case if that special code is really needed, it would be nice to document it, what it is doing and why it is needed. And if it is not needed then it is better to remove it. Because currently it is quite hard to understand the whole initialization code which happens before execution of main() function. And hence also harder to figure out what code related to that __getmainargs() issue. Pali _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
