Re: convert an MFC application to MFC DLL

Hi all,

Thanks a lot for your replies.

I inherited the project and was asked to do something to eliminate
activeX as well as 3rd party library and not to alter the old C codes
(an embedded code).
For a quick fix, I just call gui part from .NET via interop. It seems
to work so far although again it may be a wrong approach.

It looks like, as Joe pointed out, rewritting it is my next step.
Tom

On May 27, 10:59 am, Joseph M. Newcomer <newco...@xxxxxxxxxxxx> wrote:
See below...

On Wed, 27 May 2009 05:26:07 -0700 (PDT), Tom Gonuts <funkygon...@xxxxxxxxx> wrote:
Hi,

I have an odd problem in converting MFC application to MFC DLL. As
already mentioned, I have an Visual C++ 6 MFC application which
contain some old C files and their headers. In the header files, most
variables were declared with keyword extern. After changing some
syntaxes, I was able to compile and run this application without any
problem using Visual Studio 2008.

****
This suggests that there are too many global variables. Which means it is a badly-written
C program. And an abysmally-written C++ program.
****

However, when I tried to convert this application to MFC DLL by
creating a new MFC DLL project and importing all necessary files, I
ran into problems. Error LNK2001 shows that there are unresolved
symbol. The odd part is that all the unresolved symbols were declared
as an external variables. All the header files which contain extern
variables were included in a single main.cpp.

****
That is expected. You either have to move the variables into the DLLs (thus keeping the
poor structure) or rewrite the code to look like modern code.

Once the variables are in the DLL, they cannot be accessed by the main program. This is
correct and expected behavior. If the variables are left in the main program, they cannot
be accessed by the DLL. This is correct and expected behavior.

The whole notion that there is a "single" main.cpp which contains the declarations of the
variables already says something about the quality of the code structure, which is to say,
abysmal. Sounds like Freshman First Assignment quality code. This is quite possibly the
single worst way to structure global variables, and the second-worst way is to put them
all in the CWinApp-derived class. If I use a global variable, I typically have a .cpp
file that declares exactly that variable, and a header file that has the extern
declaration, and the header file gets included in ONLY those modules that require access
to that global variable (the notion of having the equivalent of main.h that defines the
extern declarations for all the variables in main.cpp is the sort of thing that marks the
code as well-and-truly amateur code; if there are extern declarations sprinkled throughout
the .cpp files, that is even worse!)

You cannot put the variables in the DLL and access them from the program (this is Really
Bad Style and is generally an invitation to total flaming disaster); generally, if the
program needs to access data stored in the DLL, the correct approach is to supply
setter/getter function pairs. The DLL certainly has zero chance of accessing them if they
are declared in the main program.

Converting an MFC application to an MFC DLL is really a poor approach. You have to
refactor the code into those parts which make sense in a DLL, and those parts which
cannot. For example, your document and view code could be put in a DLL (and since, if
they are properly coded, they would not require access to any global variables, this
should work). Similarly, any dialog and its class can be put into the DLL, because no
dialog would ever, ever, under any circumstances, access a global variable, unless it is
so badly written that it must be recoded to fix such a gross defect. So that's out of the
way. It is possible, with a major stretch of the imagination, to figure out how to get
the mainframe code into the DLL, although that isn't really recommended; if you are a DLL,
you will be part of some *other* application that has its *own* mainframe.

The real secret is to reduce the number of global variables to zero. I have found that
the rare cases where global variables are useful means that I might have one to five in a
given app of 200,000 lines of code.

So you need to explain what you mean by "converting an MFC application to a DLL". In
general, this is not even possible, although you can move *components* of your MFC
application to a DLL, you cannot make the *application itself* be a DLL. You have to
explain the context in which this DLL will be used, and who will use it, just to be able
to discuss the refactoring. The variables in question cannot be used in the
CWinApp-derivec class (that is, for example, in InitInstance and ExitInstance), or in the
main frame; if they are, the program structure is deeply flawed and needs to be rethought.

A good predicate: when coding a global variable, ask "is this really necessary?" The
answer is almost always "no", and in the few cases where they make sense, you can then
understand how to use them. Also look into singleton classes. Note that classes that
contain static members require care when exporting them from DLLs.
joe
****

Can anyone give me some rough idea what I did wrong here?

Thanks,
Tom

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

.

Relevant Pages

  • Re: Queries about DLL Exports
    ... global variables for use it. ... dll with out redefining?Macros are for use at compile-time, so #define them within your project. ... shared memory concept in dll? ... makes header file for Exporting things from dll in other project.Look up __declspec dllexport and dllimport. ...
    (microsoft.public.vc.language)
  • Re: convert an MFC application to MFC DLL
    ... I have an odd problem in converting MFC application to MFC DLL. ... This suggests that there are too many global variables. ... The whole notion that there is a "single" main.cpp which contains the declarations of the ...
    (microsoft.public.vc.mfc)
  • Re: Using TLSAlloc to read data into a DLL
    ... DLL_PROCESS_ATTACH, as you indicate. ... etc. to be able to do this - that global variables are not ...     Igor Tandetnik ...
    (microsoft.public.vc.language)
  • Re: Queries about DLL Exports
    ... global variables for use it. ... global variable from dll? ... shared memory concept in dll? ... makes header file for Exporting things from dll in other project. ...
    (microsoft.public.vc.language)
  • Functions exported in C++ and global variables;
    ... Functions exported in C++ and global variables; ... I'm working with a DLL project in VISUAL C++ that exports one function with ... of a dll global ...
    (microsoft.public.vstudio.development)
Loading