--- robert_brewington <[EMAIL PROTECTED]> wrote: > 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.
I think you need to export - so add the CAMAPI_EXPORTS to the project and remove what you have currently. > > > > > > 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/ > > > > > Mickey M. Construction Partner Inc. http://www.constructionpartner.com ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
