I'm not sure I understand.

Aren't apps installing their own MFC42.dll?
Also I don't understand why newer apps will run any better if they
don't work with _native_ MFC42.dll!

Please elaborate.

oops, i wrote that wrong.  native mfc42.dll doesn't work at all with wine, i 
was using mousepad's diablo II maphack companion (unethical, but it was just a 
test of programs i was running), and the program wouldnt load because there is 
no builtin mfc42.dll and when i tried to run it with the native one from win2k 
sp2, it gave an error.

oops, i wrote that wrong.  native mfc42.dll doesn't work at all with wine, i 
was using mousepad's diablo II maphack companion (unethical, but it was just a 
test of programs i was running), and the program wouldnt load because there is 
no builtin mfc42.dll and when i tried to run it with the native one from win2k 
sp2, it gave an error.

Well, *which* error do you get ?
Remember that this is BugZilla.
Being verbose helps.
Of course native mfc42.dll should really get fixed if broken,
as it is crucial for a helluva lot of programs.

im not sure the error, i will post tomorrow, but as far as i can see (from 
looking in wine/dlls) there isnt a native mfc42.dll *at all*...

Created attachment 97 [details]
Error output when there is no mfc42.dll in wine's path or the directory of the calling program

ok, i have the error.  it appears as i said that there is no builtin 
mfc42.dll.  but an update.  the mfc42.dll from win98 does not work with wne.  
mfc42.dll from win2k does work, but you muxt be in the directory that the file 
you are running is in (i.e. if mhc.exe is in /win_emu/D2Stuff/MapHack then you 
must cd to that dir...and since mhc requires d2maphack.exe then d2maphack 
should also be in there...)

the error i get with no mfc42.dll is listed in the attachment above

Try to copy the library to your windows/system directory.

ok that should fix some problems, but actually the thing about being in the 
same directory only applies if another file is required by the program being 
run (in this case d2maphack.exe), and it apparently only applies if the app 
directory isn't in the wine path...

Dustin, can we close the bug?

Well, what error is happening in the win98 mfc42.dll case ?

not sure, i will take a look tonight...  as for closing the bug, nah dont do it 
yet, im gonna go ahead and work on it, but i need to know where in the msdn to 
find out what portions of the windows api are part of mfc42.dll

confirm via comments, assigning to myself, as i will attempt to work on it...

I'm not sure where to look in MSDN to find out what all is in MFC42.dll, if 
someone could point me in the right direction?  Or if someone knows more about 
this, feel free to accept it and start working on it...

AFAIK mfc43.dll contains implementation of the Microsoft MFC library.
MFC is object-oriented C++ interface to Windows API.
To "implement" MFC means the same as "rewrite" Delphi's VCL or TrollTech's QT.
I'm not sure if you want to do that ;-)

Not really, it would just be nice though to have a builtin MFC42.dll, but since 
it correlates with C# I'm not even going to think about it ;)

I do not think it has anything to do with C# - this is pretty big C++ library.

Ohh, after re-reading your last post I understand what you were saying...  
Hmmmm... Too bad there isn't an unresolved option which would close the bug but 
show that it was never resolved...

The resolution is clear - WONTFIX :-)

MS Visual C++ comes with the source of MFC. You may redistribute it, so on I386 
there is no sense in a rewrite. Recompiling the MFC source is however daunting,
but has been achieved before.

No use of this bug.

*** Bug 3285 has been marked as a duplicate of this bug. ***

*** Bug 4461 has been marked as a duplicate of this bug. ***

Created attachment 1816 [details]
spec file for mfc42.dll

Perhaps it is time to reopen this

Reopening this bug 

I think that this as an enhancement.
Hence changing this to enhancement rather than a bug

I'm not so convinced.  This is something that is required by many apps.  
However small the app, if it is something that is required, it should not be 
considered an enhancement.  However, for right now I will leave the status as 
is.

Even though this is something that could be as daunting as rewriting QT or 
VCL, it should still be done because native doesnt (at last check) work with 
wine, and we aren't going for running native dll's anyways.  I think part of 
the ultimate goal of the project is to be rewrite all of the windows api.  
Putting that into context, even though MFC is not a core part of windows (even 
though it isnt included with windows), it is still a part of the windows api, 
and therefore it needs to be rewritten.

Ask Alexander about this.
According to him this a minor subproject, AFAIR.
So I thought it would be better we make it an enhancement to wine.

The licensing is such that any of those programs are allowed to ship it the
native version, but don't. The licensing is also such that we can't ship it with
Wine (something vague about being non-trivial program).

*** Bug 5794 has been marked as a duplicate of this bug. ***

*** Bug 5794 has been marked as a duplicate of this bug. ***

This is pretty nice, I want to see how this progresses.

I would like to see this DLL implemented, too.

Lack of it prevents me from using a program to convert maps for use with my
PalmPilot GPS software. This program is supposed to run with Windows95.

$ wine GpsPilot\ Cartographer.exe
err:module:import_dll Library MFC42.DLL (which is needed by
L"Z:\\media\\hdb5\\GPS_Pilot\\GpsPilot Cartographer.exe") not found
err:module:LdrInitializeThunk Main exe initialization for
L"Z:\\media\\hdb5\\GPS_Pilot\\GpsPilot Cartographer.exe" failed, status c0000135

$ wine --version
Wine 0.9.9

$ uname -a
Linux sheaf 2.6.15-27-k7 #1 SMP PREEMPT Fri Dec 8 18:22:01 UTC 2006 i686 GNU/Linux

There's a redistributable from MS that (also) contains MFC42.DLL:
http://support.microsoft.com/kb/q259403/
Also see: http://msdn2.microsoft.com/en-us/library/aa260978(VS.60).aspx

Implementing MFC is outside the scope of the Wine project.

Closing.

Agreed.  This bug should have been closed a long time ago, really.

The most that Wine should do is educate users, I think.
e.g. if mfc42.dll is required but not present, Wine might
want to pop up a dialog box explaining the problem
and suggesting they install some mfc42 app that is
packaged properly and thus installs the missing library.

Personally I don't see the point of educating: Wine prints a clear message
on the command line about a missing DLL. A case of missing MFC42.DLL is not
different from any other case of a missing/not installed library.

The console messages are not visible when users don't run the app
from the commandline.  We need to solve that in general sometime,
perhaps by having our logging code recognize some errors as worthy
of displaying in a popup, or perhaps by having a tray icon to show
the Wine console (kind of like the Javascript console in browsers).

mfc42.dll is a microsoft redistributable.  There are other dlls that
are sometimes missing that are not redistributable, or are not from
Microsoft.  Because MS redistributables are freely available
as part of other freely available apps, a certain amount of
guidance for the users can go a long way.  Alternately, we could
have wineprefixcreate install one of those apps automatically;
that would make the mfc42.dll problem go away...

Created attachment 5946

Please do not attach mfc42.dll to this bug report.  
Doing so might violate the license agreement.  
mfc42.dll should only be redistributed
in conjunction with a windows application.
Sites like dll-files.com which allow it
to be downloaded for free are also in violation,
and should be avoided.

*** Bug 8879 has been marked as a duplicate of this bug. ***

So I just did a clean reinstall of Win98 in VMWare (without installing
VMWare tools which also seems to install MFC42.DLL), and even on a completely
clean Windows _98_ system MFC42.DLL is already present in C:\WINDOWS\SYSTEM.
Although I see the point that MFC42.DLL is quite a large undertaking and probably not the most vital thing to wine, I believe that it would be incorrect to simply write it off as something that never needs to get implemented natively in wine as it is:
(a) present by default in Windows versions as early as 98 (the only one I checked to be fair)
(b) required by many programs, many of which do not install it (even Microsoft redistributables that require it such as Windows Scripting Host don't install it).

Anyhow, just my 2 cents.

Misha

At some point in the future, we might want to do
this, but there is very little urgency, and 
many other problems to deal with.
It would be more productive to simply make it
easy for users to install some freely downloadable
app that happens to come with the runtime.

That is fair that it is a low priority. Can we refer users to the VC redistributable from Microsoft (e.g., that winetricks downloads; perhaps we can add a link on the winehq site or wiki) or is there something in the licensing that prohibits this? 

The installer of the game Mafia doesn't work at all without manual install mfc42.dll.

It's fair to give users workarounds.  My favorite workaround
would be to point them at a set of applications which,
if any one is installed, will fix the problem by
installing a copy of mfc42.  Winetricks is an ok workaround
too but it's kind of command-line-y, and it relies on
goodwill from Microsoft, so I wouldn't push it on end users.

*** Bug 11353 has been marked as a duplicate of this bug. ***

*** Bug 14426 has been marked as a duplicate of this bug. ***

Actually there are some software like keygens that require this dll.

(In reply to comment #50)
> Actually there are some software like keygens that require this dll.

That's another reason to not provide support for pirated content.

Yeah - if heck freezes over, and we do implement mfc42 someday,
it won't be for keygens.

Created attachment 29784 [details]
Program that requires mfc42.dll (log)

There are programs that need the MFC.dll series and copying from windows
installation won't work even if they are the same.

If we work better with notepad.exe and regedit.exe implemented, shy wouldn't we
implement also some other libraries? If wine had strictly APIs will be
unusable. How many programs and libraries to implement as open source? Well,
from my point of view in depends on how much progress in the development are we
achieving.

I think religious or ethical issues like not developing libraries for a
program that read the bible or another that generates keys or another that
decompiles software, is a seatback in wine development. If not developing them,
I think it should obbey to other reasons.

I have an example 19KB program written in Microsoft Visual C++ 6.0 and needs
the following libraries (see attachment for details).

(In reply to comment #54)
> I think religious or ethical issues like not developing libraries for a
> program that read the bible or another that generates keys or another that
> decompiles software, is a seatback in wine development. If not developing them,
> I think it should obbey to other reasons.

It's not a religious or ethical issue, but a legal one. Encouraging software piracy gets wine in hot water.

Wine runs plenty of bible/koran studying software, and also some malware. However, wine does not intentionally attempt to support malware, nor software piracy.

Mfc42 may be implemented someday to help legitimate applications, not keyloggers/generators. If they benefit, that would be unintentional.

*** Bug 24254 has been marked as a duplicate of this bug. ***

The Rise of Nations installer is affected by this. It has a DLL that has this as a dependency. Without mfc42.dll, the product key verification is broken. Is it possible to reopen this bug?

Ah, I remember this bug. Surprised to see variations of it still kicking
around. At any rate, it has indeed been a long time since this was reported and
after reviewing things with a different set of eyes (much more mature eyes), I
agree with others that this should be a low priority, if any.

Richard: linked in some comments above are some downloads that will install mfc42.dll for you. Once it is installed, then the Rise of Nations installer should work without any problems. If, however you have problems after installing one of those downloads and verifying that the necessary dll is installed on your system, please feel free to open a new bug report regarding breakage when using that native dll.

I also agree with Dan's comments a couple of years ago about a possible popup
for interesting messages. Missing shared object libs would be a handy one to
have, since Fedora x86_64 doesn't, at present, install OpenAL i686 by default,
and since we do already have a popup about wine-gecko at first launch.

I'll take this to the list before filing a bug, to get opinions on it. Sure
there are higher priorities, but I've seen some lower priority things sneak in
lately. :-)

(In reply to comment #58)
> I'll take this to the list before filing a bug, to get opinions on it. Sure
> there are higher priorities, but I've seen some lower priority things sneak in
> lately. :-)

Brain food.

I agree this should be at least reopened. Just because it wont be fixed "just yet" doesn't mean it never will.

Now, what could be done in a more... human time scale is implement the most common functions from MFC42. Having a stub dll and maybe a couple doz^M^M^Mhundred functions should fix a handful of issues.

The MFC42 source is available with Visual Studio. What are the implications for Wine? Even though developers are not allowed to reuse that source in Wine, are they allowed to at least look at it in order to implement functions properly?

What's amazing with Wine is how hundreds of users will create patches for their own issues, for their own app. If an app crashes because MFC42.dll is missing, the current solution is "winetricks and that's it". Having a stub dll, even if it has to warn on every load "MFC42 is poorly supported. If you have issues, try native.", could get us patches to slowly support it more and more.

Ok, yeah, this is an insane project; but so is Wine, and it's doing well so far. This could even be done during GSoC, and before you know it, pops-your-knuckle we have a MFC42.dll good enough for most apps.

Once again, just brain food.

Nope, anybody who has even looked at Microsoft's mfc sources
can't work on a wine implementation of mfc.

msvcp80.dll is another one we never thought we'd do, but it turned
out a bunch of apps only needed a very few functions from it.
If somebody analyzes the pidgen problem and finds that only six
functions are really needed from mfc42, then, well, maybe it'd make sense
to implement them.

LOL Jerome and Dan, as fast as I can type them, you have more coming.

@Jerome, I disagree that the bug should be reopened, but perhaps another bug for smaller issues such as the "pidgin problem" Dan mentioned could be opened to get incremental stubs in place, if someone was willing/able to take on the work.

Sadly, my skills in programming are almost nil. Compare that statement to how I thought 10 years ago at the top of this bug. ;-)

Anyways, not having mfc is not a huge deal no matter what apps need it, imo, as long as a copy installed with some other app can do the job without issues. It seems to me that so far that still works, so getting a builtin mfc*.dll should continue to be a low priority for the foreseeable future.

(In reply to comment #60)
> Nope, anybody who has even looked at Microsoft's mfc sources
> can't work on a wine implementation of mfc.

Has this actually been confirmed for MFC42.dll? What with its source code being kind of publicly available and what not.

Just because it is publicly available does not mean it's not licensed such that a derivative work is illegal.

(In reply to comment #63)
> Just because it is publicly available does not mean it's not licensed such that
> a derivative work is illegal.

IANAL, but it sounds like there is a difference between "writing derivative work", and plain old "related, non-derivative work after looking at publicly available source code".

It also sounds like "having looked at private microsoft source code" most likely means you're an ex-microsoft employee or partner, which wouldn't apply to MFC42.

Once again, not a lawyer, but it's worth doublechecking.

Publicly available does not mean free to use by anyone for any purpose, however. GPL code can and does get "stolen", by way of someone using code and not posting their modifications to the public; and the "thieves" can and often-times do get prosecuted -successfully- after refusing to release their source.

Same goes for publicly available non-GPL code. If the license forbids it, but someone reads it and then builds or helps build a wine builtin mfc*.dll, and microsoft sees that code in the wine tree, then wine as a whole is in deep trouble.

If you write a mfc*.dll from scratch and then you compare that dll source code with the microsoft's one and they match in some way, what can you do? If the implemented function works, it is obvious that have to share some code, how can you see if is copied or not?

If you write similar code accidentally that's fine. If you write similar code because you have seen the MS source that's a copyright violation.

Anyone who plans to work on the mfc implementation in the future should stay far away from the MS source, and never look at it or even download it.

A few thoughts:

1. Obtaining the MFC source from Microsoft under a LGPL compatible license might not be out of the question because Steve Ballmer recently claimed that Microsoft "loves open source". Considering that the WINE project would stand to gain a substantial contribution if Microsoft were to donate the MFC source under a LGPL compatible license, I think it would be worthwhile to try.

Steve Ballmer's email is Steve.Ballmer@microsoft.com according to Microsoft's website(1). I expect that emails received at that address are processed by his secretaries, so in order to send him an email that would make it to him, someone important like Alexandre Julliard would need to send it. I imagine that the body of the email could be something along the lines of "Dear Steve Ballmer, I am <A> from the WINE project. The MFC source code is available to almost everyone who wants it, but the WINE project has <X>, <Y> and <Z> legal concerns that prevent its use in both source and binary form. You recently said that Microsoft loves open source, so it would be much appreciated if you would make the MFC source available to the WINE project under a compatible license. Yours truly, <A>".

(1): http://www.microsoft.com/presspass/exec/steve/2007/03-14convergence.mspx 

2. I already opened a bug about pidgen.dll, but it was closed as a duplicate of this.

3. Provided that #1 is not an option, then a dummy dll with a bunch of stubs would be awesome. I am a senior computer science student and unlike most of the computer science students at my university, I made it a point to learn C and C++, If a stub was available to tell me what functions were being called, I could try implementing the functions that pidgen.dll uses using Microsoft's MSDN documentation and then submit them as patches. I plan to take 20 credits this semester on top of doing some minor undergraduate research, so time is an issue for me, but I could try my hand at it on one of the upcoming holidays, provided that there is a dummy dll with stubs in place that define a place for me to insert code.

4. I know that the WINE project is very strict about the identities of its contributors. What would I need to do in order to meet the WINE project's requirements for submitting patches?

(In reply to comment #68)
> 4. I know that the WINE project is very strict about the identities of its
> contributors. What would I need to do in order to meet the WINE project's
> requirements for submitting patches?

http://wiki.winehq.org/SubmittingPatches

Followup discussion about this is off bugzilla's topic and belongs on wine-devel.

*** Bug 24924 has been marked as a duplicate of this bug. ***

Age of Empires: Complete Collection is affected by this bug at the License Key entry dialog.

Error Message: 
"Invalid CD Key!"
"Error loading the PID Generator DLL. The DLL could not be found! Please make sure the file is available in the installation directory and try again,"

workaround with:
winetricks -q mfc42

*** Bug 27039 has been marked as a duplicate of this bug. ***

Dear all,

According to Bug 19816 , Alexandre Julliard says it is ok to start accepting request for mfc42 , so is it right time for reopen this bug now?

Regards.


==========================================
Alexandre Julliard 2009-08-23 12:16:19 CDT
(In reply to comment #5)
> Windows also ships msvbvm50, mfc40, mfc42, mfc71, msvcp50, msvcp60, msvcp70,
> msvcp71, msvcr70, mdac.
> 
> Is it ok to start accepting requests for those as well?

Yes, certainly.
==========================================

Seems so.

I think windows 7 comes with a lot of these bundles, and others like Net Frameworks.

Just for fairness: those who know that "app X doesn't work because of this bug", pls do include this bug in appDB for such app. Also: those who find this bug really important (as I do, because I do need my app running), pls consider voting.

*** Bug 27284 has been marked as a duplicate of this bug. ***

*** Bug 19473 has been marked as a duplicate of this bug. ***

*** Bug 27744 has been marked as a duplicate of this bug. ***

*** Bug 28930 has been marked as a duplicate of this bug. ***

*** Bug 27370 has been marked as a duplicate of this bug. ***

*** Bug 29548 has been marked as a duplicate of this bug. ***

*** Bug 29675 has been marked as a duplicate of this bug. ***

*** Bug 30095 has been marked as a duplicate of this bug. ***

*** Bug 30310 has been marked as a duplicate of this bug. ***

*** Bug 31196 has been marked as a duplicate of this bug. ***

*** Bug 31196 has been marked as a duplicate of this bug. ***

*** Bug 32459 has been marked as a duplicate of this bug. ***

*** Bug 23091 has been marked as a duplicate of this bug. ***

*** Bug 32952 has been marked as a duplicate of this bug. ***

Confirming that this is still an issue in 1.5.24 for the Age of Mythology Gold Edition installer at the point of trying to enter the CD key.

After skimming the comments, I guess that's to be expected at this point.

Indeed Age Of Empires Complete Collection still complains of error loading keygen dll on install at the point of entering the key. Tested on wine version wine-1.5.24, installed from the Ubuntu 12.04 package manager.

*** Bug 33038 has been marked as a duplicate of this bug. ***

*** Bug 33042 has been marked as a duplicate of this bug. ***

*** Bug 33073 has been marked as a duplicate of this bug. ***

*** Bug 32271 has been marked as a duplicate of this bug. ***

*** Bug 33663 has been marked as a duplicate of this bug. ***

*** Bug 34729 has been marked as a duplicate of this bug. ***

(In reply to comment #98)
> *** Bug 34729 has been marked as a duplicate of this bug. ***

bug 34729 is not a dup of this bug

Age of Mythology currently doesn't install because of this bug and I think that it wouldn't use to many functions in here.

If I stub would be committed I would like to try and take a stab at this. I haven't contributed anything to wine yet but I would really like starting.

Or if there is any documentation on how to use the "spec file" I might be able to start from that one.

*** Bug 35212 has been marked as a duplicate of this bug. ***

Actually all missing DLLs should be shown as Error message boxes - it's default Windows behavior to whine about missing DLLs.

Why doesn't wine do that is a great mystery to me.

*** Bug 35614 has been marked as a duplicate of this bug. ***

Comment on attachment 97 [details]
Error output when there is no mfc42.dll in wine's path or the directory of the calling program


>[root@Hub D2Stuff]# ls
>MapHack/
>[root@Hub D2Stuff]# cd MapHack/
>[root@Hub MapHack]# ls
>d2maphack.cfg     minishrine02.dc6  minishrine15.dc6  shrine06.dc6  shrine15.dc6
>d2maphack.dat     minishrine03.dc6

Comment on attachment 97 [details]
Error output when there is no mfc42.dll in wine's path or the directory of the calling program


>[root@Hub D2Stuff]# ls
>MapHack/
>[root@Hub D2Stuff]# cd MapHack/
>[root@Hub MapHack]# ls
>d2maphack.cfg     minishrine02.dc6  minishrine15.dc6  shrine06.dc6  shrine15.dc6
>d2maphack.dat     minishrine03.dc6

Comment on attachment 97 [details]
Error output when there is no mfc42.dll in wine's path or the directory of the calling program


>[root@Hub D2Stuff]# ls
>MapHack/
>[root@Hub D2Stuff]# cd MapHack/
>[root@Hub MapHack]# ls
>d2maphack.cfg     minishrine02.dc6  minishrine15.dc6  shrine06.dc6  shrine15.dc6
>d2maphack.dat     minishrine03.dc6

Comment on attachment 97 [details]
Error output when there is no mfc42.dll in wine's path or the directory of the calling program

>[root@Hub root]#

Comment on attachment 29784 [details]
Program that requires mfc42.dll (log)

www.mapbackhack.com	046E

Hello folks,

refining the summary to target a specific MFC version and provide recipe in attempt to prevent people from creating further dupes in Bugzilla.

Bug 36984 targets 'mfc110.dll' in similar way (summary provides recipe).

Regards

Can mfc42.dll and any other third party dlls required to run Dos/Windows programs be installed via an option button on the graphical interface?

If y'all can do what those commercial versions claim they can do regarding finding and installing the latest drivers or libraries, etc, it can greatly enhance the usablity of the platform.

It would be nice if the OS could do this natively as much as possible and as transparent to the user as possible.

*** Bug 36865 has been marked as a duplicate of this bug. ***

Halo: Combat Evolved retail installer also uses PidGen.dll.

*** Bug 40503 has been marked as a duplicate of this bug. ***

Dependency Walker also fails without mfc42.dll, which is shipped by default with Windows 7.

*** Bug 43225 has been marked as a duplicate of this bug. ***

Is mfc related to mf?

If not, mfc is not implemented at all according to https://www.winehq.org/winapi_stats

If so, mf is only 3% implemented which would explain any issues with it.

(In reply to Aaron Franke from comment #116)
> Is mfc related to mf?
> 
> If not, mfc is not implemented at all according to
> https://www.winehq.org/winapi_stats
> 
> If so, mf is only 3% implemented which would explain any issues with it.

They're not related. If you read the prior comments, you'll note that this is unlikely be to fixed anytime soon if ever. Use the native dll via winetricks.

*** Bug 46722 has been marked as a duplicate of this bug. ***

(In reply to Austin English from comment #117)
> (In reply to Aaron Franke from comment #116)
> > Is mfc related to mf?
> > 
> > If not, mfc is not implemented at all according to
> > https://www.winehq.org/winapi_stats
> > 
> > If so, mf is only 3% implemented which would explain any issues with it.
> 
> They're not related. If you read the prior comments, you'll note that this
> is unlikely be to fixed anytime soon if ever. Use the native dll via
> winetricks.

For some applications the native DLL won't work -- for instance using otherwise open applications on non-x86 systems via winelib.

What would we need to do to at least get started on implementing some of the MFC API in winelib?  Once a template is in place it's just a matter of working through the missing calls.

(iirc https://github.com/wxWidgets/wxWidgets was at one time similar to mfc, don't know how deep that went.  Wouldn't be able to use any of it as is, I'm sure.)

Not sure if this would be of any help or not, but according to rabin2 -i (I haven't disassembled the file in any way, only looked at the imports) PidGen.dll only requires ordinal 825 from mfc42.dll, which is named "operatordelete".

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

(In reply to Anastasius Focht from comment #122)
> 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.

Yeah, I don't really want to deal with that either. Maybe if users treated Staging like a staging branch and not just another version of Wine.

*** Bug 8321 has been marked as a duplicate of this bug. ***

*** Bug 56518 has been marked as a duplicate of this bug. ***