https://bugs.winehq.org/show_bug.cgi?id=657
--- Comment #122 from Anastasius Focht focht@gmx.net --- Hello qsniyg,
while this could work for the case of native 'pidgen' (Wine's builtin one is a stub dll that prefers native over builtin), it will likely trigger an influx of gazillion new bug reports. All the auto-generated stubs will cause all kinds of user-visible crashes instead of previous mostly silent application load failure behaviour.
Users/triagers will create new bugs per stub to request addition of simple/semi-stubs because they don't understand that this approach can't work for majority of the MFC applications. Additionally it will send a false signal of hope: "hey, there is builtin MFC - let's start with implementing this and that".
Most of the dupes linked here are not the result of 'pidgen' failures but from real MFC apps that require a lot of MFC classes to be implemented.
You could ask maybe Wine-Staging project folks if it's possible to fly a trial balloon with them (and see the impact) ;-) If that happens we should definately create a new ticket, covering the addition of a stub MFC42 dll + minimal pidgen dependency implementation (if that's just one export). This one should remain as one-for-all meta-bug, although I would add "implementation" to the summary to distinguish both.
My general (personal) opinion about MFC hasn't changed all the years. I consider it a huge waste of time/valuable developer resources if someone is really going for implementation of this legacy/obsolete technology. The Wine project still lacks developer resources in various other areas/components which are way more useful for the general populace.
Regards