Prev: File paths (UNC, mapped drives, etc.) in a client-server environment,how to?
Next: Layered Modal Window
From: Mihai N. on 11 Feb 2010 04:31

> If so, I think you should abstain from any use
> of MFC extension DLLs (especially those built with the same MFC
> version as A). This is because extension DLLs integrate tightly with
> the application - but that's not intended in your case, you seem to
> want your DLL R to use EX, not A (is this correct, BTW?). So I think
> that you should see with your EX vendor if they have a regular DLL
> build - that's IMO a correct option.

++100


--
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

From: Goran on 11 Feb 2010 08:30
On Feb 11, 8:34 am, mk <m...(a)discussions.microsoft.com> wrote:
> In a support article (http://support.microsoft.com/kb/167929/en-us) I found
> the statement that constellations like the following are allowed.

Well... "Allowed" is a strong word. (And TFA does not say that). But,
mixing MBCS and Unicode MFCs in one process can happen, and is OK as
long as MBCS and Unicode modules don't try to interact using MFC
classes. If they do, it's at best a mystery as to what would happen -
but should not work correctly.

But if DLL exposes e.g. only a C interface, it is irrelevant that
there are two MFCs inside. That is certainly "allowed".

Note also that there's no extension DLLs in the diagram - they really
are for something else.

> Hence, the problem in my constellation is the call from the extension dll to
> another extension dll.

Are you sure? I'd wager that the problem is the use of extension DLLs
in general. And there are other problems as well - if you have a
missing ordinal, you really should first find out what that ordinal
is. Once you know what is missing, you can go looking further.

> Then there should be a chance to bring a constellation to work in which the
> Ansi exe calls my Unicode regular dll

Yes, that should be OK.

>, and the regular dll directly calls
> either ext dll. Am I right with this thought?

That's pretty much not OK and knowing what I know about MFC extension
DLLs, I don't know how this is supposed to work. Not to mention that
you are trying to mix Unicode and MBCS __extension__ DLLs - that to me
seems like a seriously troubled idea.

Goran.
From: Goran on 11 Feb 2010 08:45
On Feb 10, 11:02 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
> What version of VS are you using to compile your system?  If it is not VS6, you are
> already in deep trouble; not only can you not mix Unicode and ANSI versions of the MFC
> DLL, you cannot mix versions such as MFC42 and any other version such as MFC70, MFC80 and
> MFC90.  

Joe, I don't think that's strictly true. Why do you think that?

The sticky point is interaction between modules - if various DLLs
export only plain C (non-MFC) stuff corresponding MFC versions will be
loaded and each module (DLLs + EXE) will be attacking it's own MFC
version and all will be fine. (But anything can use MFC stuff
internally all they want).

If, however, exported DLL functions contain MFC artifacts -
pheeewwww... I think all bets are off then.

Problems will IMO certainly arise with extension DLLs - they will want
to elbow-in themselves into corresponding MFC version runtime data.
But if there are multiple regular DLLs and/or EXE that use same MFC
version, then what? I'd guess that would explode in amazing ways.

Goran.
From: Joseph M. Newcomer on 11 Feb 2010 09:47
See below...
On Thu, 11 Feb 2010 05:45:16 -0800 (PST), Goran <goran.pusic(a)gmail.com> wrote:

>On Feb 10, 11:02�pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
>> What version of VS are you using to compile your system? �If it is not VS6, you are
>> already in deep trouble; not only can you not mix Unicode and ANSI versions of the MFC
>> DLL, you cannot mix versions such as MFC42 and any other version such as MFC70, MFC80 and
>> MFC90. �
>
>Joe, I don't think that's strictly true. Why do you think that?
>
>The sticky point is interaction between modules - if various DLLs
>export only plain C (non-MFC) stuff corresponding MFC versions will be
>loaded and each module (DLLs + EXE) will be attacking it's own MFC
>version and all will be fine. (But anything can use MFC stuff
>internally all they want).
>
>If, however, exported DLL functions contain MFC artifacts -
>pheeewwww... I think all bets are off then.
****
If there is an extension DLL, then it is probably expecting to share the MFC universe with
the application. This is what I was triggering on. There is an implicit sharing of the
MFC objects, and it is uncertain exactly what will happen if, say, an ANSI extension DLL
calls the ANSI MFC AfxGetApp() when there is a Unicode app managed by a different DLL. I
think it starts going downhill from there.

The notion of a "pure C" interface isn't sufficient; they have to be completely isolated
under the floor, and extension DLLs are not isolated from the app. Also, there are
problems if the lower level DLLs try to manage any MFC objects, such as windows, in a way
that would invoke interactions between the DLLs, or expect that there was a single image
of the handle map.

Also, he mentioned a "message-based" WINAPI interface, a sequence of words that make no
sense. WINAPI is merely __stdcall in sheep's clothing, so is irrelevant to the
discussion, and "message-based" suggests that there are HWNDs involved.
****
>
>Problems will IMO certainly arise with extension DLLs - they will want
>to elbow-in themselves into corresponding MFC version runtime data.
>But if there are multiple regular DLLs and/or EXE that use same MFC
>version, then what? I'd guess that would explode in amazing ways.
****
Probably. The operative phrase might be "the interactions would not only be stranger than
we can imagine, they will be stranger than we could *possibly* imagine"
joe
****
>
>Goran.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 11 Feb 2010 09:53
See below...
On Wed, 10 Feb 2010 23:34:07 -0800, mk <mk(a)discussions.microsoft.com> wrote:

>> What version of VS are you using to compile your system? If it is not VS6,
>you are
>> already in deep trouble; not only can you not mix Unicode and ANSI versions of the MFC
>> DLL, you cannot mix versions such as MFC42 and any other version such as MFC70, MFC80 and
>> MFC90.
>To complete the disater scenario, I actually to use VS2008. But the regular
>dll only exposes the following simple interface
>int WINAPI SetupDlabDLL ( HWND hwnd )
>int WINAPI FinishDlabDLL ( HWND hwnd )
>All other communication happens via a simple Winapi window messaging
>interface.
>There is not a single object (and accordingly no MFC object) passed between
>the components. Therefore I hope that the different MFC versions are
>irrelevant.
****
It's more than that; you have to make sure there is no implicit assumption about, say,
having a single message map, or other implicit sharing. The extension DLLs rely on a lot
of under-the-floor implicit state sharing (that's why they're called "extension" DLLs)
****
>
>> >Ansi exe -> regular dll unicode -> ext dll Unicode -> ext dll unicode.
>> >Is this constellation officially supported by MFC?
>> ****
>> On the contrary, it is not only unsupported, but forbidden.
>
>In a support article ( http://support.microsoft.com/kb/167929/en-us) I found
>the statement that constellations like the following are allowed.
>
> ------------- --------------
> = = = =
> = MFC = Calls = MFC =
> = APP = ------------> = USRDLL =
> = = = =
> = = = =
> ------------- --------------
> | |
> | |
> | Calls | Calls
> | |
> \/ \/
> ------------- --------------
> = = = =
> = = = =
> = MFC40d = = MFC40Ud =
> = DLL = = DLL =
> = = = =
> ------------- --------------
> \ /
> \ /
> \ Calls / Calls
> \ /
> \/ \/
> -------------
> = =
> = =
> = MSVCR40d =
> = (CRT) =
> = =
> -------------
>
>Hence, the problem in my constellation is the call from the extension dll to
>another extension dll.
****
Extension DLLs are the heart of the problem. Note that in the above image, both the DLLs
are actually debug DLLs, and share a single, common, MSVCR40d. And the names should give
you a hint about the age of this article; the "40" DLLs were VS 4.0. VS 4.0 dates back to
around 1996 or so, and was buggy as all-get-out, and was replaced by VS 4.2 (the first
tolerable VS of the 4-series; the 3-series would not even work correctly if there was
multithreading going on) and these were replaced by VS6 in late 1997 or early 1998. So
you may be relying on an article that was written 15 years ago, in a different universe.
****
>Then there should be a chance to bring a constellation to work in which the
>Ansi exe calls my Unicode regular dll, and the regular dll directly calls
>either ext dll. Am I right with this thought?
****
Those extension DLLs are going to cause problems. Serious problems. Because they want to
implicitly share internal runtime state with what they think is the executable image, and
it sounds like that is using a completely different version of MFC. So the notion of
consistency in sharing state between two different DLLs enters the picture, and that is
not supported. It only works if there is well-and-truly NO sharing of any state. It is
not even clear to me why the above picture can work.
joe
****
>
>Thanks, mk
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: File paths (UNC, mapped drives, etc.) in a client-server environment,how to?
Next: Layered Modal Window