thank you for your help so far and sorry for disturbing you with mypatches again so soon.
Thank you for the work you've been putting into this. Please continue disturbing me with improvements in mixed-mode support for as long as you like.
While looking a bit further into my app under Wine I found out that somemixed assemblies are completely broken under Wine/Mono due to the fact that native entry point is not called at all. It relates to both 32 bit and 64 bit. 32 bit works fine under native MS .Net which apparently does call the entry point. The entry point address is present in IMAGE_COR20_HEADER (when appropriate flag is set in Flags member). It is DllMain-type entry point having the same parameters. This entry point does static initialization, e. g. calls all the constructors for static classes. I am attaching preliminary patch to illustrate what I am talking about. It would be great if you could give some high level feedback on whether you like the idea of doing this in general before I will be spamming it to wine-patches.
This seems like the right approach. If the app works in .NET on Wine, that would be another indication that mscoree is the right place for this.
I checked ecma-335, and sadly the flag isn't documented there. How did you find out about it?
The potential issue which I can imagine with it is that if there aresome old apps (built with VS 2003) which called CLR code in native init but by chance worked if native init was not called at all, may stop working. MSDN says that such apps could non-deterministically deadlock when loaded; with Wine/Mono they will lock deterministically I think ( https://msdn.microsoft.com/en-us/library/ms173266.aspx). Still I suppose the issue with entry point should be addressed somehow since it affects "normal" newer applications.
Well, pretty much any change in behavior could cause a regression. Unless there's something else that we should fix first (because programs will start using it), I wouldn't worry about it.