Ah, that's it. I found where the linker specifies to use the .def file, and now it works correctly.
I like your ColdOne idea:) brew --- In [email protected], Thomas Hruska <[EMAIL PROTECTED]> wrote: > > robert_brewington wrote: > > Hi, > > > > I am new to the group, trying to get help on using Visual C++ Express > > 2008. I have a fair amount of experience in C, but have not been > > active for several years. I am having trouble getting Studio 2008 to > > create a viable dll file. My adventures are described below - > > hopefully someone can point out the foolishness of my ways! > > > > I have been given a set of files from a vendor, which should compile > > to create a starting dll. These files include > > > > stdafx.cpp > > stdafx.h > > Brew.cpp > > Brew.h > > Brew.def > > Brew.dsp > > > > So, I installed Visual Studio 2008 C++ on my Vista machine; it spent a > > lot of time installing .NET version 3.5 as well. I don't see anywhere > > that I am using .NET, but don't know how I would tell. > > > > I created a new project, and selected "Win32 Project". > > The stdafx files were the same as what the vendor sent. I copied the > > contents of the Brew.h and Brew.cpp to the blank files created by > > Visual C++. I don't know what to do with the .def and .dsp files. > > > > The Brew.h file has the following: > > > > // The following ifdef block is the standard way of creating macros > > which make exporting > > // from a DLL simpler. All files within this DLL are compiled with the > > CAMAPI_EXPORTS > > // symbol defined on the command line. this symbol should not be > > defined on any project > > // that uses this DLL. This way any other project whose source files > > include this file see > > // CAMAPI_API functions as being imported from a DLL, wheras this DLL > > sees symbols > > // defined with this macro as being exported. > > #ifdef CAMAPI_EXPORTS > > #define CAMAPI_API __declspec(dllexport) > > #else > > #define CAMAPI_API __declspec(dllimport) > > #endif > > > > So, I added the /D CAMAPI_API declaration to the Project building process. > > > > The project now builds, and creates a Brew.dll file. Sounds good! > > > > However, it doesn't work. The application is supposed to pick up the > > dll from a particular directory (in Program Files) when it runs. This > > does not seem to be happening. > > > > I tried running regsvr32 on the dll, and I get the error > > The module Brew.dll was loaded but the entry point DllRegisterServer > > was not found. Make sure that Brew.dll is a valid dll or OCX file and > > then try again. > > > > So, it seems my DLL is not built right somehow. I also tried running > > regasm (apparently used for .NET projects), but the regasm program is > > not recognized. > > > > I downloaded a utility that shows me the entry points into the DLL. I > > compared my Brew.dll with a valid dll produced by someone else and > > things look pretty similar. However, there are a couple of routines > > which look different. In Brew.dll, I see > > Brew.dll ?CamAPIGetDeviceId@@[EMAIL PROTECTED] Ordinal 32 > > versus > > GoodOne.dll CamAPIGetDeviceId Ordinal 22 > > > > So, I seem to have decorated function names, whereas the good library > > has undecorated names. In addition, their Ordinal number is set in the > > .def file. I tried adding the .def file to my project, but it didn't > > seem to make any difference. > > > > So, does all this make sense to someone? Does something stand out as > > to how to make my dll work correctly? I am lost at this point. > > > > Thanks for any help, > > Brew > > I hear my name being called! I'm one of the few people here who know > VC++ very well. > > > IMO, the dllexport/dllimport mechanisms of VC++ don't work "properly". > They leave name-mangled names (as you have discovered) in the DLL. > There's some logical reasoning for the way it works but I don't recall > the reason. The way VC++ works in terms of DLLs consistently leaves > people confused. > > The de facto "standard" tool for analyzing DLLs is Dependency Walker > (aka Depends - not the undergarments). > > I'm slightly surprised the .def file didn't work. Try dropping the > ordinal assignments and make sure there is an EXPORTS section. Also, be > absolutely sure the linker is configured to _use_ the DEF file. (Just > having the .def file in the files list for the project is not enough - > you have to edit the linker properties page and let the linker know of > the file's existence). > > A .dsp file indicates the project you are working with was designed for > Visual Studio 6. An ancient and broken compiler suite. VS 2008 should > be able to convert the project automatically to solution (.sln) and VC++ > Project (.vcproj) files and successfully build the files. In theory. > > Upon success, consider naming the DLL 'ColdOne.dll'. > > -- > Thomas Hruska > CubicleSoft President > Ph: 517-803-4197 > > *NEW* MyTaskFocus 1.1 > Get on task. Stay on task. > > http://www.CubicleSoft.com/MyTaskFocus/ >
