Different MFC versions in DLLs and COM
Geoffrey Nicholls -- geoff@gazelle.com
Friday, January 17, 1997
Environment: MSVC 4.2b, Win 95
I have heard that if you have an MFC based application and link to an MFC
based DLL, that both the application and the DLL must use the same version
of MFC. I guess that is true whether you use the shared MFC DLL or
statically linked MFC libraries. My question has to do with inproc server
dlls that use COM. If I wrote a COM based DLL using MFC 3.0 and use
CoCreateInstance in my application, am I able to update the application to
MFC 4.2b without concern? Does COM isolate the versions of MFC from each
other?
Thanks,
Geoff
--------------------------------------
Geoffrey Nicholls
Gazelle Software
415/323-5545 (voice)
415/323-1913 (fax)
http://www.gazelle.com
667 Marion Ave
Palo Alto, CA, 94301
--------------------------------------
Mike Blaszczak -- mikeblas@nwlink.com
Tuesday, January 21, 1997
At 16:38 1/17/97 -0800, Geoffrey Nicholls wrote:
>Environment: MSVC 4.2b, Win 95
>I have heard that if you have an MFC based application and link to an MFC
>based DLL, that both the application and the DLL must use the same version
>of MFC.
Yes.
>I guess that is true whether you use the shared MFC DLL or
>statically linked MFC libraries.
Yes.
>My question has to do with inproc server
>dlls that use COM. If I wrote a COM based DLL using MFC 3.0 and use
>CoCreateInstance in my application, am I able to update the application to
>MFC 4.2b without concern? Does COM isolate the versions of MFC from each
>other?
COM isolates the unversionable interfaces of the container from a single
server. You could have an MFC 4.2b application that uses an MFC 4.0
OLE Control and an MFC 4.1 automation server without a problem. This
isn't a very good situation, since the DLLs will _all_ load in your process
and give you a very bloated working set, but it'll generally work.
The reason that it'll work is that each DLL doesn't exchange dynamically
allocated memory with eachother in a way that is incompatible. They also
won't ask exchange C++ objects with eachother--just COM objects, and
memory allocated using the OLE allocator.
.B ekiM
http://www.nwlink.com/~mikeblas/ <-- trip report central!
95 Honda VFR-750F / 88 Yamaha FZ-700 (damaged) / 94 Mazda RX-7
Serial #00050! / AMA - HRC - VFROC / Wang Dang Wankel
I am bored of this talk. It is time now for the dancing!
These words are my own - I do not speak on behalf of Microsoft.
Geoffrey Nicholls -- geoff@gazelle.com
Sunday, January 26, 1997
Environment: MSVC 4.2b, Win 95
I have heard that if you have an MFC based application and link to an MFC
based DLL, that both the application and the DLL must use the same version
of MFC. I guess that is true whether you use the shared MFC DLL or
statically linked MFC libraries. My question has to do with inproc server
dlls that use COM. If I wrote a COM based DLL using MFC 3.0 and use
CoCreateInstance in my application, am I able to update the application to
MFC 4.2b without concern? Does COM isolate the versions of MFC from each
other?
Thanks,
Geoff
[Resubmit - no one answered within 10 days]
--------------------------------------
Geoffrey Nicholls
Gazelle Software
415/323-5545 (voice)
415/323-1913 (fax)
http://www.gazelle.com
667 Marion Ave
Palo Alto, CA, 94301
--------------------------------------
Kenneth A. Argo -- argo@rias.COM
Monday, January 27, 1997
[Mini-digest: 2 responses]
If you use COM there is no direct relationship between the way the DLL =
is linked and the way the App is linked. In this case you can mix and =
match as you want.
Ken
=20
----------
From: Geoffrey Nicholls[SMTP:geoff@gazelle.com]
Sent: Sunday, January 26, 1997 4:02 PM
To: mfc-l@netcom.com
Subject: Different MFC versions in DLLs and COM
Environment: MSVC 4.2b, Win 95
I have heard that if you have an MFC based application and link to an =
MFC
based DLL, that both the application and the DLL must use the same =
version
of MFC. I guess that is true whether you use the shared MFC DLL or
statically linked MFC libraries. My question has to do with inproc =
server
dlls that use COM. If I wrote a COM based DLL using MFC 3.0 and use
CoCreateInstance in my application, am I able to update the application =
to
MFC 4.2b without concern? Does COM isolate the versions of MFC from each
other?
Thanks,
Geoff
[Resubmit - no one answered within 10 days]
--------------------------------------
Geoffrey Nicholls
Gazelle Software
415/323-5545 (voice)
415/323-1913 (fax)
http://www.gazelle.com
667 Marion Ave
Palo Alto, CA, 94301
--------------------------------------
-----From: Dave Kolb
Actually Mike B. answered this a while back.
Here is his text:
<<
At 16:38 1/17/97 -0800, Geoffrey Nicholls wrote:
>Environment: MSVC 4.2b, Win 95
>I have heard that if you have an MFC based application and link to an MFC
>based DLL, that both the application and the DLL must use the same version
>of MFC.
Yes.
>I guess that is true whether you use the shared MFC DLL or
>statically linked MFC libraries.
Yes.
>My question has to do with inproc server
>dlls that use COM. If I wrote a COM based DLL using MFC 3.0 and use
>CoCreateInstance in my application, am I able to update the application to
>MFC 4.2b without concern? Does COM isolate the versions of MFC from each
>other?
COM isolates the unversionable interfaces of the container from a single
server. You could have an MFC 4.2b application that uses an MFC 4.0
OLE Control and an MFC 4.1 automation server without a problem. This
isn't a very good situation, since the DLLs will _all_ load in your
process
and give you a very bloated working set, but it'll generally work.
The reason that it'll work is that each DLL doesn't exchange dynamically
allocated memory with eachother in a way that is incompatible. They
also
won't ask exchange C++ objects with eachother--just COM objects, and
memory allocated using the OLE allocator.
.B ekiM
http://www.nwlink.com/~mikeblas/ <-- trip report central!
95 Honda VFR-750F / 88 Yamaha FZ-700 (damaged) / 94 Mazda RX-7
Serial #00050! / AMA - HRC - VFROC / Wang Dang Wankel
I am bored of this talk. It is time now for the dancing!
These words are my own - I do not speak on behalf of Microsoft.
>>
>-----Original Message-----
>From: Geoffrey Nicholls [SMTP:geoff@gazelle.com]
>Sent: Sunday, January 26, 1997 4:02 PM
>To: mfc-l@netcom.com
>Subject: Different MFC versions in DLLs and COM
>
>
>Environment: MSVC 4.2b, Win 95
>
>I have heard that if you have an MFC based application and link to an MFC
>based DLL, that both the application and the DLL must use the same version
>of MFC. I guess that is true whether you use the shared MFC DLL or
>statically linked MFC libraries. My question has to do with inproc server
>dlls that use COM. If I wrote a COM based DLL using MFC 3.0 and use
>CoCreateInstance in my application, am I able to update the application to
>MFC 4.2b without concern? Does COM isolate the versions of MFC from each
>other?
>
>Thanks,
>Geoff
>
>[Resubmit - no one answered within 10 days]
>
>
>--------------------------------------
>Geoffrey Nicholls
>Gazelle Software
>415/323-5545 (voice)
>415/323-1913 (fax)
>http://www.gazelle.com
>667 Marion Ave
>Palo Alto, CA, 94301
>--------------------------------------
>
rick cameron -- rick_cameron@msn.com
Friday, January 31, 1997
On January 21, 1997 7:26, owner-mfc-l@majordomo.netcom.com on behalf of Mike
Blaszczak wrote:
> At 16:38 1/17/97 -0800, Geoffrey Nicholls wrote:
>
> >Environment: MSVC 4.2b, Win 95
>
> >I have heard that if you have an MFC based application and link to an MFC
> >based DLL, that both the application and the DLL must use the same version
> >of MFC.
>
> Yes.
>
> >I guess that is true whether you use the shared MFC DLL or
> >statically linked MFC libraries.
>
> Yes.
>
> .B ekiM
> http://www.nwlink.com/~mikeblas/ <-- trip report central!
> 95 Honda VFR-750F / 88 Yamaha FZ-700 (damaged) / 94 Mazda RX-7
> Serial #00050! / AMA - HRC - VFROC / Wang Dang Wankel
> I am bored of this talk. It is time now for the dancing!
> These words are my own - I do not speak on behalf of Microsoft.
>
>
>
Is this true even if the DLL is a _USRDLL (aka regular DLL) linking statically
to MFC and the RTL, and only exposes a C API - no C++ objects accepted or
returned, all memory management done inside the DLL?
If so, it makes it impossible to write a generic DLL, usable by any EXE, and
use MFC in the DLL!
- rick cameron, seagate software img
Kenneth A. Argo -- argo@rias.COM
Tuesday, February 04, 1997
This statement is NOT true if you are using COM and static linking in =
MFC ! I believe it is also NOT true for shared MFC, but I have always =
been against using shared DLL with any of our release products so I =
don't know 1st hand.
Ken
----------
From: rick cameron[SMTP:rick_cameron@msn.com]
Sent: Friday, January 31, 1997 4:10 PM
To: mfc-l@netcom.com
Subject: RE: Different MFC versions in DLLs and COM
On January 21, 1997 7:26, owner-mfc-l@majordomo.netcom.com on behalf of =
Mike=20
Blaszczak wrote:
> At 16:38 1/17/97 -0800, Geoffrey Nicholls wrote:
>=20
> >Environment: MSVC 4.2b, Win 95
>=20
> >I have heard that if you have an MFC based application and link to an =
MFC
> >based DLL, that both the application and the DLL must use the same =
version
> >of MFC.
>=20
> Yes.
>=20
> >I guess that is true whether you use the shared MFC DLL or
> >statically linked MFC libraries.
>=20
> Yes.
>=20
> .B ekiM
> http://www.nwlink.com/~mikeblas/ <-- trip report central!
> 95 Honda VFR-750F / 88 Yamaha FZ-700 (damaged) / 94 Mazda RX-7
> Serial #00050! / AMA - HRC - VFROC / Wang Dang Wankel
> I am bored of this talk. It is time now for the dancing!
> These words are my own - I do not speak on behalf of Microsoft.
>=20
>=20
>=20
Is this true even if the DLL is a _USRDLL (aka regular DLL) linking =
statically=20
to MFC and the RTL, and only exposes a C API - no C++ objects accepted =
or=20
returned, all memory management done inside the DLL?
If so, it makes it impossible to write a generic DLL, usable by any EXE, =
and=20
use MFC in the DLL!
- rick cameron, seagate software img
| Вернуться в корень Архива
|