Prev: File paths (UNC, mapped drives, etc.) in a client-server environment,how to?
Next: Layered Modal Window
From: Joseph M. Newcomer on 12 Feb 2010 08:51
See below...
On Fri, 12 Feb 2010 01:53:01 -0800, mk <mk(a)discussions.microsoft.com> wrote:

>> The universe is not only stranger than we imagine, it is stranger than we
>can imagine.
>Just to come back to our minuscule planet, I'd like to sum up the
>discussion: Loading a MFC dll from a MFC application only succeeds when the
>devil is blind. So, combining MFC binaries created in different projects (not
>to mention different companies) is a breakneck task.
>
>In other words, MFC dlls are not self-contained like WINAPI dlls.
****
MFC DLLs were never intended to be "self-contained" in the fashion you interpret. MFC is
and always has been a set of version-specific libraries that work with an executable
image.

The Windows API DLLs are also not "self contained"; some APIs have been deprecated (most
of the Win16 APIs are gone, for example MoveTo); others have been added, on each release.
Therefore, you cannot be guaranteed that you can run an executable built for OS version
n+1 on version n or lower.
****
>Accordingly, you never can merely implement against the interface of a MFC
>dll; you always must use the Dependancy Walker to check what MFCxx.dll is
>used. And if you want to implement an API in a MFC dll, you must build
>distinct versions that fit the MFC dll version of each potential client
>application. If that is true, MFC's dll concept isn't very convincing, is it?
****
Any interface you export from an MFC-based DLL has potential problems. Key here is that
you must build a truly isolated component. It may not return any MFC-based objects to its
caller, may not rely on any MFC-based state (such as the handle map), and must present a
pure C-compatible interface to its callers. Extension DLLs violate the assumption that it
does not need to rely on any MFC-based state, and therefore present serious problems.

Note that this is true for any library system; it is not limited to MFC. Consider if I
have a database library in a DLL. I wrote another DLL which uses the database library. My
DLL, call it A, was built with database library version 1.0. You want to use my library,
but you only have database library version 2.0. Lots of luck. It probably won't work,
for a variety of reasons. Try mixing two versions of the C runtime.

In other words, you have some unrealistic expectations of the MFC DLLs, and when they
don't live up to your unrealsitic expectations, you think this is a condemnation of the
MFC concept. It isn't. It is true for nearly any library set in existence, and the few
execeptions are extremely rare.

Note that you cannot substitute GDI32.DLL from Vista for the GDI32.DLL that comes with
Win7. Is that a condemnation of the Windows kernel?

Microsoft goes through IMMENSE amounts of effort to try to maintain the stability of the
Win32 API interface. This is rarely justified by anything outside. For years, they
maintained a common MFC runtime, MFC42.DLL, which had the property that it kept changing
and extending, but was compatible with MFC 4.2, 5.x and 6.x. Eventually, this became
impossible to continue doing. They abandoned this approach with MFC70. So yes, you now
have to produce versions of your extension DLLs compatible with MFC70, MFC71, MFC80 and
MFC90. As well as U and D versions. I know of no workarounds for this piece of reality.
It's how the world works.

Note also that static linking doesn't solve this; rather, static linking makes this
problem immediately serious, since each DLL has its own private copy of the MFC library
linked into it, and these copies do not share anything. This means you get the problem on
every build, not just when the MFC application version changes.
joe

>
>mk
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: mk on 12 Feb 2010 11:37
Hi Goran,

> So when "extension" fits, by all means, use it.
> (I think it does __not__ fit in your case).
You're right. It definitely doesn't fit. I hoped there would be a
workaround. But, it looks like there is none.

> Multiple MFC versions can coexist in one process. [...]
> BUT! But... Because there's no interaction between anything in our
> code and said shell extension (and especially since their's is a
> different MFC version), there's no problem whatsoever.
This "BUT" is a great problem. I hardly can persuade the extension dll
vendor to change over to unicode when I'm not sure that this will solve the
problem.

So I think the only way is to completely rethink the architecture.

Thanks for all your help!

mk

From: mk on 12 Feb 2010 12:13
Hi Joe,

> The Windows API DLLs are also not "self contained"; some APIs have been deprecated (most
> of the Win16 APIs are gone, for example MoveTo); others have been added, on each release.
> Therefore, you cannot be guaranteed that you can run an executable built for OS version
> n+1 on version n or lower.
You're right. But I think it is a great advantage over MFC when the binaries
merely depend on the OS and shell versions and not on the environment they
were built with. This eases a lot of work.

> So yes, you now have to produce versions of your extension DLLs compatible with MFC70, MFC71, MFC80 and
> MFC90. As well as U and D versions. I know of no workarounds for this piece of reality.
> It's how the world works.
>
> Note also that static linking doesn't solve this; rather, static linking makes this
> problem immediately serious, since each DLL has its own private copy of the MFC library
> linked into it, and these copies do not share anything. This means you get the problem on
> every build, not just when the MFC application version changes.
If only I had known! That would have saved me lots of work. From the MSDN
docs I received the impression that only regular and extension dlls must use
the same MFC version. But using the same mfc dlls application-wide is
unfeasible in my constellation. So, there's nothing left than to completely
modify the architecture...

Thanks a lot for your help!

mk
From: Ajay Kalra on 12 Feb 2010 13:50
On Feb 12, 11:37 am, mk <m...(a)discussions.microsoft.com> wrote:
> Hi Goran,
>
> > So when "extension" fits, by all means, use it.
> > (I think it does __not__ fit in your case).
>
> You're right. It definitely doesn't fit. I hoped there would be a
> workaround. But, it looks like there is none.
>
> > Multiple MFC versions can coexist in one process. [...]
> > BUT! But... Because there's no interaction between anything in our
> > code and said shell extension (and especially since their's is a
> > different MFC version), there's no problem whatsoever.
>
> This "BUT" is a great problem. I hardly can persuade the extension dll
> vendor to change over to unicode when I'm not sure that this will solve the
> problem.

In that case, you are stuck with using the same version of MFC as that
of the extension DLL that the vendor provides. Typically vendor will
provide various versions of the library.

Also, keep in mind that if the vendors library version is a release
version only, you will issues in mixing that DLL in debug version of
your app.

--
Ajay

First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: File paths (UNC, mapped drives, etc.) in a client-server environment,how to?
Next: Layered Modal Window