Loading MBCS extension dll into Unicode regular dll

Hello,

I am working at an application that has the following (admittedly somewhat
strange) module architecture:
* Application "A" dynamically loads my regular Unicode MFC DLL "R"
(presumably by using LoadLibraryA)
* "R" statically loads my unicode extension dll "E"
* "E" itself statically loads two MBCS extension dlls written by a external
vendor.

Unfortunately, my regular DLL "R" (and hence, the two extension) cannot be
loaded by the application.

Now the questions: Is my model architecture generally feasible? Might the
root of the problem be that "R" and "E" use the MFC90UD.DLL whereas the
external extension dlls use  "MFC90D.DLL"?

Thanks mk

Why not? Have you used Depends to check if all necessary DLLs arepresent?

Why not? Have you used Depends to check if all necessary DLLs are
present?


I do not see any immediate reason why it should not - but we have really
only got a tiny bit of the picture.


For a release product none should require the "D" (debug) versions -
however I think the direct answer to your question is that it (of
itself) should not be an issue.

Dave

taleYour entire process should have one MFC dll, either go with 90UD or90D.

t
al
e

Your entire process should have one MFC dll, either go with 90UD or
90D. Why do you need to mix?
Also, why do you need R to be not an extension DLL?

If you are limited by external vendors linking to a different version
of MFC than you do, you have only two choices: have a different
version of your app which matches the external vendors app or get
external vendors libs with the version that you are using. With
Extension DLLs you are going to have issues immediately if different
version of MFCs are used in the same process(For starters,
AfxGetMainWnd would be different for each versrion).

--
Ajay

See below...****Well, I would expect it to use LoadLibrary.

See below...

****
Well, I would expect it to use LoadLibrary.  It will call LoadLibraryA if it is an ANSI
(8-bit character app) and LoadLibraryW if it is a Unicode app.  You did not say what kind
of app it is.
****
****
I have no idea what "statically loads" means for a DLL.  Did you mean "implicitly loads"?
Static loading of a library is what happens when you directly link a .lib file into an
executable image.

Note this is an odd sequence, to load an extension DLL from a regular DLL.  Also, there
are serious issues here.  If the executable is an ANSI app, and you load a Unicode
extension DLL, you are begging for disaster to strike.  This is because you will end up
with two completely different, and incompatible, copies of the MFC runtime, one for the
executable and one for the extension DLL E
****
****
Again, I assume you meant to say "implicitly loads".  And here you have another disaster
scenario.  An 8-bit extension DLL will load the 8-bit version of the MFC library; you have
a different version loaded for your extension DLL "E", and this might be different from
the executable.

This is a scenario that, instead of asking "why does not it work?", I am more inclined to
ask "How could it possibly work?"
****
****
This is a meaningless statement.  If it "cannot be loaded", there are error messages
issued, or error codes returned.  Without knowing what this vague handwave of "cannot be
loaded" means, that is, WHAT IS SEEN TO OCCUR, IN DETAIL, I will have to find my old
crystal ball and dust it off, and I do not feel like doing that right now.
****
****
Absolutely.  As I said, I would expect that this would fail in some interesting fashion,
but I would be incredibly surprised if it worked at all.  You really cannot mix MFC
runtimes like this.  Each DLL tries to maintain an image of what is going on, and the
images will conflict.  Not a feasible solution.  You will have to figure out how to make
this work in some other fashion, such as acquiring updated DLLs from the third party, or
reverting everything to ANSI/MBCS.  But on the whole, I think the current configuration is
doomed to never work.
joe
****
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Hi Joe,thank you for your answer.

Hi Joe,

thank you for your answer.

Well, it is also an application of an external vendor. It can be extended by
registering plug-in dlls which then are loaded at startup. it is definitely an
ANSI application. But it is not specified whether the plug-ins are loaded via
AfxLoadLibrary or via the Win32 LoadLibrary.

Sorry. I indeed meant "implicitly".

I am not calling the extension dll directly from the application. I am aware,
that an extension dll and its client application have to use the same version
of MFCxx.dll. But I thought the CWinApp-derived object in my regular dll
would act as client and hence would decouple the extension dll from the
application.

I am not familiar with the MFC internals. Accordingly, was not quite sure
whether the 8-bit and the unicode MFC libraries are compatible. But from my
point of view, there is no reason why the two runtimes of the same version
should not be able to interact.

Unfortunately, that is my problem as well. The error occurs while the dll is
loaded. So there are neither error messages nor error codes. I only obtain a
first chance exception in the ntdll.dll.
The debugger's output is as follows. Where "NpcDlabQslrD.dll" is the reguar
dll "R". "NpcDlabQslrUxD.dll" is my extension dll "E". "edaq.dll" and

'DASYLAB.EXE': Loaded 'D:\Dlab90\NpcDlabQslrD.dll', Symbols loaded.
'DASYLAB.EXE': Loaded 'D:\Dlab90\NpcDlabQslrUxD.dll', Symbols loaded.
'DASYLAB.EXE': Loaded 'D:\Dlab90\eDaq.dll'
'DASYLAB.EXE': Loaded 'D:\Dlab90\Logger.dll'
'DASYLAB.EXE': Loaded 'C:\WINDOWS\system32\MFC42D.DLL', Symbols loaded.
'DASYLAB.EXE': Loaded 'C:\WINDOWS\system32\MSVCRTD.DLL', Symbols loaded.
'DASYLAB.EXE': Loaded 'C:\WINDOWS\system32\MSVCP60D.DLL', Symbols loaded.
'DASYLAB.EXE': Loaded 'C:\WINDOWS\system32\MFCN42D.DLL', Symbols loaded.
First-chance exception at 0x7c9766c6 in DASYLAB.EXE: 0xC0000138: Ordinal Not
Found.

The thing is that I tested this architecture before we implemented it and
everything worked out fine. For days, I am trying to build test binaries that
cause this error. But I cannot reproduce it. Hence, this architecture seems to
work for most configurations.

Provided I could persuade the vendor of the ansi extension dlls to build a
unicode version, would the module dependencies would look like this:
Ansi exe -> regular dll unicode -> ext dll Unicode -> ext dll unicode.

Is this constellation officially supported by MFC?

Thanks, mk

Hi Ajay,thanks for your answer.R is a plug-in used to extend A.

Hi Ajay,

thanks for your answer.

R is a plug-in used to extend A. A and the other extension dlls are written
by external vendors.

I am not very familiar with MFC. So, I ask myself why this is a problem. it is
absolutely plausible that the use of two different MFC versions can cause
compatibility problems. But my dlls are all using the same version of MFC
(9.0). 0ne dll accesses MFC via the Ansi interface, the others via the
unicode interface. Why should Microsoft create two interfaces to the same
runtime and prevent them from interacting?

Do you know anythink about the reasons for this behavior?

Thanks, mk

tal(I will call these EX)I agree with Joe that this is your problem right here.

t
al

(I will call these EX)

I agree with Joe that this is your problem right here. I do not think
you should be able to load external ANSI MFC extension DLLs EX for use
with, effectively, Unicode regular MFC dll R. (E seems to be
tangential to the issue.).

About your use of Unicode for R: if application is ANSI, why? Unicode
gives you possibility for your code to speak more than one language
(or code page ;-) ). But A cannot do it. R is bound to A, so even if it
does speak more languages, A will not grok them. I frankly see no point
in Unicode use in R.

I'd like to comment on the application aspect. You say that R is a
plugin for A. If it is a plugin, chances are that R should exposes pure
C interface A will use. 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 is 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 is IMO a correct option. Or, if A uses a different MFC
version from you, I would not be surprised that all is OK, albeit
really weird (and possibly not future-proof ;-) ).

You see, the thing with extension DLLs is that they really are made
with one executable in mind: everyone plays nicely in a homogenous
environment, in the best interest of the __application__. But your
case is heterogeneous.

(If A exposes MFC-dependant interface (or C++-runtime-dependent one),
R is stuck with whatever MFC version application is built with. That
is IMO highly unlikely. it is not the end of the world, but is a major
annoyance and stupidity on the part of A.)

Goran.

It has nothing to do with .

It has nothing to do with Microsoft. If you have static variables/
singletons in a DLL, multiple instances of the DLL in a process will
return different values. This will invalidate any method that you uses
these variables. Mixing unicode and non-unicode of the same version
will cause this issue as well.

We did have the same problem with plug-ins at my previous
employer(Autodesk); with each new version of MFC or when we introduced
Unicode and plugs ins were not, we had to get the correct version of
plug ins. This problem kind of goes away if the plug ins are Regular
DLL as then these will be independent. But then you are loading
multiple versions of MFC.

--
Ajay

See below...

See below...

****
AfxLoadLibrary is just a fairly trivial wrappon around ::LoadLibrary.
****
****
The CWinApp-derived object in your regular DLL has nothing to do with application apps and
is invisible to any DLL that is called.
****
****
Actually, there is no reason to assume that they could EVER interact correctly.  There is
nothing that makes this possible, or even desirable.
****
****
This pretty much says it all.  There is an attempt to resolve a DLL via an ordinal entry
point and that ordinal is not defined.  This can be caused by a variety of reasons,
including having a DLL compiled for version n of Windows and running it on version n-1 or
lower, or if you have a DLL that is using ordinals to link, having an obsolete version of
the DLL relative to the .lib file you are using.

You will have to figure out which DLL is failing to load.

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.
****
****
Then you just happened to have a set of circumstances that worked, in spite of the fact
that they are definitely not expected to.
****

you areTo complete the disater scenario, I actually to use VS2008.

you are
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.


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.
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?

Thanks, mk

++100--Mihai Nita [ MVP, Visual C++]http://www.mihai-nita.

++100


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

ndWell... "Allowed" is a strong word. (And TFA does not say that).

nd

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 do not try to interact using MFC
classes. If they do, it is 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 is no extension DLLs in the diagram - they really
are for something else.

to

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.

he

Yes, that should be OK.


That's pretty much not OK and knowing what I know about MFC extension
DLLs, I do not 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.

VS6, you arens of the MFCMFC70, MFC80 andJoe, I do not think that is strictly

VS6, you are
ns of the MFC
MFC70, MFC80 and

Joe, I do not think that is 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 is 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.

See below...

See below...

****
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 is not 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.
****
****
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
****
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

See below...

See below...

****
it is 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 is why they are called "extension" DLLs)
****
****
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.
****
****
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
****
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

The correct quote is "There are more things in heaven and earth than aredreamt

The correct quote is "There are more things in heaven and earth than are
dreamt of in your philosophy."
;-)


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

Actually, I am misquoting J.B.S.

Actually, I am misquoting J.B.S. Haldane, who said

The universe is not only stranger than we imagine, it is stranger than we can imagine.
joe


Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

that make noThat's exactly what I meant.

that make no

That's exactly what I meant. The exe and my regular dll are communicating by
sending window messages.

mk

can imagine.

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.
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 is not very convincing, is it?

mk

he(notCit?

he
(not
C
it?

Well... In that light, only MFC __extension__ concept is not "very
convincing". But it is quite useful when used properly. I have a
couple of commercial MFC libraries and they offer builds in "regular"
and "extension" form. So when "extension" fits, by all means, use it.
(I think it does __not__ fit in your case).

Multiple MFC versions can coexist in one process. In fact, that
happens all the time.Heck, when I load our in-house software, I see it
sucks in MFC 71 which we do not use and we have no plugins. Reason is
dead simple: there is a shell extension on my system that uses MFC71.
When file dialog pops-up, shell loads and there you have it.

BUT! But... Because there is no interaction between anything in our
code and said shell extension (and especially since their's is a
different MFC version), there is no problem whatsoever.

Similar goes for "regular" DLLs built against same version MFC dlls.
AFX_MANAGE_STATE, and you are done.

With regard to the notion that one must build different DLL version
for different MFC versions used by the client - yes, this is true.
However, it is impossible otherwise. MFC changes from version to
version. New functionality is added, there might be incompatibilities,
or reliance of client code on non-documented features (I had that).
You cannot reasonably expect to link to "same" DLL over a course of so
many years.

Additional constraining factor is binary interface change. C++
language does not define an ABI, so smallest change in compiler might
break binary-level compatibility. Consequence being that in theory,
only MS compiler can compile for MFC. Any other compiler vendor must
work for this to be possible, or build their own MFC from sources,
which is a move of disputable value.

And finally, comparison with a C-only-interface DLL such as system
DLLs is unfair - the very reason why we use C++ is that C is PITA. But
with additional power comes additional complexity. So deployment-wise,
C++ modules do not work as wide, not unless you drop to C interface).
Note also that, in a way, pure C interface DLLs work by luck:
1. system uses it, so everyone else has to understand it
2. it is brain-dead simple, so everyone can easily call it
Not so with C++.

Goran.

See below...

See below...

****
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.
****
****
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 will not 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
do not live up to your unrealsitic expectations, you think this is a condemnation of the
MFC concept.  It is not.  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 is how the world works.

Note also that static linking does not 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

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Hi Goran,You're right. It definitely does not fit.

Hi Goran,

You're right. It definitely does not fit. I hoped there would be a
workaround. But, it looks like there is none.

This "BUT" is a great problem. I hardly can persuade the extension dll
vendor to change over to unicode when I am 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

Hi Joe,You're right.

Hi Joe,

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.

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 is nothing left than to completely
modify the architecture...

Thanks a lot for your help!

mk

heIn that case, you are stuck with using the same version of MFC as thatof the

he

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