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

> "the interactions would not only be stranger than
> we can imagine, they will be stranger than we could *possibly* imagine"


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

From: Joseph M. Newcomer on 12 Feb 2010 02:12
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

On Thu, 11 Feb 2010 21:59:18 -0800, "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote:

>
>> "the interactions would not only be stranger than
>> we can imagine, they will be stranger than we could *possibly* imagine"
>
>
>The correct quote is "There are more things in heaven and earth than are
>dreamt of in your philosophy."
>;-)
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 03:06
> 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.

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

mk
From: mk on 12 Feb 2010 04:53
> 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.
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?

mk
From: Goran on 12 Feb 2010 08:20
On Feb 12, 10:53 am, mk <m...(a)discussions.microsoft.com> wrote:
> 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 isn't very convincing, is it?

Well... In that light, only MFC __extension__ concept isn't "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 don't use and we have no plugins. Reason is
dead simple: there's 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'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.

Similar goes for "regular" DLLs built against same version MFC dlls.
AFX_MANAGE_STATE, and you're 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's 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's brain-dead simple, so everyone can easily call it
Not so with C++.

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