Using C++ Dll's in WIN32 Apps

[Mike Doner]

Hello All,

Im currently working on a piece of software (written in Win32) which uses DLLS which were written in VC++ with MFC.

In my DLL, I have a dialog class which displays an Active-X spreadsheet of some data which was created in the WIN32 portion of my application.

This configuration works great for the most part, until I tried running it on a machine that had Windows 98 (I'm Running WinNT, also tried running on a 95 Machine with VC), that didnt have Visual Studio installed.

When I first ran this application on the 98 Machine, When I clicked the button in My Win32 app to start the DIALOG (in the DLL, written in MFC), I got errors complaining that it was missing "MFCxxx.DLL". I ran this a few times until It didnt complain anymore (I copied all the .DLL's It needed to the system directory).

When I click the button now, I get a DAE (Debug Assertion Error) giving me some error about a heap or something.

I'm assuming its a DLL problem, or maybe, a 98 problem.. Anyone have any light to shine on this situation?

Thanks a million
Mike,
tootired@hotmail.com

[Paul McKenzie]

Did you build a Debug version of the DLL or release version? If you are running the Debug version, you will need MSVCRTD.DLL, which is usually not installed on machines that do not have Visual Studio (which is a vast majority of PC's). If you built the release version, the error probably stated MSVCRT.DLL which (from what I am told) *is* part of the Win 95/98 installation, so everyone has that file. I believe that you are attempting to run a debug version of your DLL.

As to the debug assertion error (this is a clue that you are attempting to run a debug version of the library, since the release version cannot do this), it is important that you write all of the info that the message box is telling you. You should have a line number and file name.

If it is a heap error, the problem might be the DLL and the way you may be sharing memory between applications (I'm assuming that you're sharing memory). If you are sharing memory between the DLL and the application, make sure that you *do not* use new() to allocate the shared memory. You should always use GlobalAlloc() and GlobalFree() when sharing data between applications, since the heap manager of the app may not exist or be different than the DLL's. GlobalAlloc() and GlobalFree() are real Windows handles that can be shared between applications.

It could also be that you have incompatible versions of the Microsoft DLL's and you may have haphazardly copied over newer versions of the Microsoft DLL's. The way to get around this is to build the DLL using the static version of the MFC libraries. This way, you could have ran the program and not worry about any extra DLL's, since the code is linked into the DLL itself. Unlike what you may have been told, building DLLs using the static version of the library is not as bad as it seems, and saves you from these headaches, especially if you intend to run your program on more than a few machines with different configurations.

Regards,

Paul McKenzie