CString Implementation Problem: Flaw or Feature

Chong Zhang -- cz@dana.ucc.nau.edu
Wednesday, April 10, 1996

[Moderator's note:  Consider this part of the existing thread on
this subject.]

Environment: VC2.5c/WFW 3.11 or VC4.1/Win95/Win NT

The first time I encountered the problem was when I wrote a DLL which
should be used by both MFC based applications and non-MFC based
applications, such as VB applications. I used static MFC library in the
DLL. And MFC based applications used MFC DLLs.

The problem is the implementation of the NULL string which uses a pointer
to a static location, _AfxChNil (16bit) or rgInitData (32bit). But once
the DLL uses static MFC, and EXE uses DLLs, there are TWO copies of these
static objects in the scope. Passing NULL string between DLL and MFC will
cause protection FAULT.

But using static MFC is the only way if the DLL is intended to be used by
NON-MFC based applications. Correct me if I am wrong.

Even though I found a work arround, but it is not very efficient. I wish
MFC guys can fix that if I am right.

---

Dean McCrory -- deanm@microsoft.com
Friday, April 12, 1996

[Mini-digest: 3 responses]

>>
>The problem is the implementation of the NULL string which uses a
>pointer
>to a static location, _AfxChNil (16bit) or rgInitData (32bit). But once
>the DLL uses static MFC, and EXE uses DLLs, there are TWO copies of
>these
>static objects in the scope. Passing NULL string between DLL and MFC
>will
>cause protection FAULT.
<<

This is by design.  It will not be 'fixed' since it isn't a bug.

>>
>But using static MFC is the only way if the DLL is intended to be used
>by
>NON-MFC based applications. Correct me if I am wrong.
<<

You are wrong.  MFC 4.0 (32-bit) allows you to write a DLL which uses
the DLL version of MFC and is still callable from non-MFCDLL
applications.  The option is right in AppWizard.

// Dean

-----From: "David W. Gillett" 

  Apparently, passing a null CString from one instance of MFC to 
another doesn't work, because of the way that such objects are 
implemented.

  The question I ask myself is this:  Why should it work?  You are 
quite correct that your DLL must link statically to MFC to be used by 
non-MFC apps.  The way I see it, that static linking encapsulates and 
*hides* the fact that this DLL happens to use MFC in its 
implementation.
  As such, no other code should know or care that the DLL uses MFC; 
the fact should not be anywhere visible in the DLL's exported 
interface.  So why is an app trying to pass it a CString (an MFC 
object...) and expect sense to be made of it?

  [It occurs to me that you might have a subset of the exported 
interface that uses MFC and so is only callable from MFC code.  If 
that's the case, I'd seriously consider splitting that code off into 
a separate wrapper, either as a class to be used in MFC apps that 
call your DLL, or as a helper DLL that links dynamically to MFC and 
calls the non-MFC interface to your main DLL.]

Dave

 
-----From: Dan Kirby 

This is by design.  If you want to pass MFC objects from .EXEs to DLLs, you 
MUST create an MFC Extension DLL rather than a _USRDLL DLL (or regular DLLs 
if your using VC++ 4)  . See MFC Technote #33 for more information  about 
extension DLLs.
--dan

---

| Вернуться в корень Архива |