« October 2006 | Main | January 2007 »
December 26, 2006
[Tech Support] Finding entry points when importing from a self-made DLL in C#
Merry Christmas to everyone, I hope yours was as good as mine. We had a great time at home with our 3 year old twins.
The next technical challenge was importing from a self-made DLL (created in C++) in a C# application. I set it up and ran the program only to get "entry point not found." The problem was that the C++ compiler mangled the names of my functions. This feature (it's not a bug) was not well documented in the dll-import literature but I suppose I should have known it anyway. There are several ways to get around this.
The first is to enclose funtion headers and bodies in "extern "C"" blocks in the exporting C++ files. This prevents the names from being mangled. This is pretty straightforward.
The second is to use dumpbin.exe to examine function names in the dll. I found dumpbin.exe in C:\Program Files\Microsoft Visual Studio 8\VC\bin but needed to add the location of mspdb80.dll to my path environment variable (that's in Control Panel | System | Advanced) to get the thing to run. dumpbin.exe /Exports and not dumpbin.exe /symbols gave me what I wanted. After finding all that the C# import declarations ...
[DllImport ("mydll.dll", EntryPoint="#2")]
private static extern int myInt();
gave me what Iwanted because myInt was listed second with ordinal #2. Also,
[DllImport("dll-tests.dll", EntryPoint="?myInt@@YAHXZ")]
private static extern int myInt ();
did as well because that was the mangled form of my function name. And, just to bring this full circle, after I added some extern "C" blocks to my exporting C++ files, the import went down as...
[DllImport("dll-tests.dll")]
private static extern int myInt ();
Finally, don't forget to put the dll in the directory that houses your C# executable (or someone on your path).
Now that that's solved, on to exporting CGAL classes (or datastructure or just functions, we'll see) to C#. Our research goal is to use CGAL classes quickly in prototyping ideas. We'll worry about efficiency later.
Posted by jones at 07:56 AM | Comments (0)
December 23, 2006
[Tech Support] building and using a DLL in C++ in VisualStudio 2005
As a professor, I have an uncanny ability to overlook details when I write code. I tend to look at the big picture, and that's a good thing most of the time when writing proposals, designing classes etc. I just finished building and using a DLL in C++ in VS 2005. It was a traumatic experience. Here's the details I overlooked. They were mostly on the importing side.
1. The __declspec(dllimport)int myInt(void); stuff has to appear (a) outside of enclosing namespaces (b) outside of class declarations because (a) putting it in a namespace will cause the linker to not find it and (b) you can't use __declspec (dllimport) within a managed class. The linker was dutifully telling me exactly that but it took me a while to figure out exactly what it meant.
2. You can list the libraries on which your stuff depends under... Project | Properties | Linker Input | Additional Dependencies. This would be where you list the .lib file that comes with your .dll file. It's just a simple text field that you type the name of your lib file into. That's a little odd, but the path will get worked out under the General item in the "Additional Library Directories" field where you do get to browse for a path.
3. The .dll needs to appear in the directory from which your project is executed. This was easy to figure out and solve, but bears mentioning.
4. The linker can be made to create verbose output under Linker | General | Show Progress and this output appears in the buildlog which can be linkto to from the output window (surprisingly). Just as an interesting datapoint: once I got the feedback loop closed by making the linker verbose, it took about 10 minutes to solve all the other problems. You can't fix what you can't see. True statement.
That's about it. Other than those little details, the C++ books, websites and MSFT documentation were all spot on. It may be clear at this point that I am somewhat clueless about VisualStudio as a project development tool. It's true. Although VS is much better than the Makefiles and command line tools that I know and "love", I still know how to do stuff in a Makefile and it takes time to figure out which sequence of mouse clicks are equivalent to 10 characters or less in a Makefile. Even worse, learning Makefiles is easy beacuse you just copy somebody else's. Learning VS click sequences is more painful because there's no flat text files to copy and modify.
Posted by jones at 10:50 PM | Comments (0)
December 11, 2006
[Research] CGNP: My new lab
My new lab is the "Computer Generated Natural Phenomena" Lab. I am working with a grad student (co-adivising with Parris Egbert) and two undergrads. We even made a lab webpage to increase our visibility.
Natural Phenomena isn't a hugely hot research area in graphics right now. There's usually a paper in two in SIGGRAPH and there's a Natural Phenomena workshop held with Eurographics each year. I believe that while CGNP is hugely important in visual storytelling, the fundamental algorithms and assumptions haven't changed much in 10 years. Computing technology has come along way since 1996 and it's time to rethink and re-invent CGNP technology. So far, it's been a ton of fun too.
Posted by jones at 04:31 PM | Comments (0)