I have legacy code in C++Builder 6. I try to create a DLL from source code, but only one thing which I have on output is an EXE. I tried to change the application target extension and entry point, but nothing helps.
I think about compiling from console, but there is some errors in the project, that I can't see when compiling in the IDE. I have linker errors, which I can't fix.
At least all code are "extern C" and I need lib and dll.
How can I compile a DLL from the app source?
A DLL needs certain pre-defined functions and the project Wizard creates them for you automatically, so
Start a new fresh project as a DLL/library project.
Create a simple function that you can test.
Compile the DLL and load it (and call the test function) from an .exe in another project to check that it's working.
Copy the essential parts of your old code, bit by bit, from the old .exe project into the correct places in the new DLL/library project.
Done.
Related
I am using Visual Studio 2015 Community Edition and I followed Microsoft's tutorial on creating implicit dll's here https://msdn.microsoft.com/en-us/library/ms235636.aspx and I referenced the dll successfully in a C++ console application (I did it just to see if it would work).
When I tried adding the dll project to the references for a Visual Basic Windows Form Application, I got an error saying "A reference to 'DLL Project Name' could not be added." After some research, I think it's because VB targets the .NET framework while the C++ dll targets Windows, but that's all I managed to figure out. I would greatly appreciate any help on reconciling this, or setting up some solution that involves a C++ dll and a GUI project that uses the dll (I just chose VB for the GUI since it's really quick and easy to set up).
Note that both the DLL project and the Visual Basic project are in the same solution.
Your tutorial won't help you invoke the code from .NET and you are correct in assuming it to be a .NET framework inter-op. issue. You can use p-invoke to import and call the DLL or create a COM wrapper around your DLL and register it in the GAC then reference it via a COM CreateObject call.
Other possibilities are to convert it to a C++/CLI .NET C++ DLL.
References:
P-Invoke
COM
-UPDATE-
I suppose I should also mention that if you target Universal Windows Platform (UWP), it also provides a clean binding across .NET and C++ and hides some of the busy COM wire-up.
A C++ DLL should be added to your *.NET application with a post-build event "xcopy" command like this one:
xcopy "$(SolutionDir)DLL\$(ConfigurationName)"\*.dll "$(TargetDir)"*.* /Y
from your selected project go to Project-->Properties-->Compile-->Build Events-->Post-build event command line
Enter the appropriate copy command.
In the above example, several C++ DLLs were collected in a "DLL" folder in the Solutions Directory. They all get copied to the application folder every time the application is built. There were DEBUG and RELEASE versions of those DLLs in separate sub-folders.
As other posters noted, you also must have correct p-invoke declarations for your C++ DLLs in your *.NET code.
I am new to DLL development and appreciated for any help.
I have an existing c++ project and am trying to build it into dll using visual studio 2012. I changed the target extension and configuration type to be dll. I also excluded my main function. When I rebuilt it, the compiler complains:
LINK : fatal error LNK1561: entry point must be defined
When I moved the main function back, I could build the project successfully.
I want to make a dll only because there are functions and objects I need to use for another project, so i don't think I need a main function for the dll. Is having a main function the only solution for this error? Thank you in advance.
Just like a program requires main, DLLs require DllMain, a place to start and handle loading and unloading of the DLL.
Rather than a DLL consider a static library. There is far less overhead, no DllMain and supporting loaders and unloaders, and they are built directly into the compiled executable so you don't have to carry an extra file around and run the risk of clients with out of date DLLs or some malicious tool replacing your DLL with theirs. If you don't need the ability to swap out the the library with a replacement, a DLL is probably overkill.
I need to build a DLL that can then be loaded with JNI from a java program. I was able to do this last year and it worked fine. I'm trying to recompile my same .cpp file now though that I make the dll with and it is failing because of an included dll dependency that gets brought in.
I have a c++ program that calls about 5 functions from some existing C++ code here. These functions are part of a huge codebase that are normally all linked together to build a set of 5 dlls.
I use dependency walker to view my dll and last year it compiled with just 2 dependent system dlls being put in my dll. Today I'm trying to recompile the same dll, but it brings in a 3rd dll file if I link with the .lib file from our existing codebase that contains the functions I use.
Basically I know my dll will work fine with JNI if I can avoid that 3rd dll showing up in my program. The problem is I don't know how to reference the functions I need in my code from our existing code base without linking to the lib file.
I can get this to work with standard c++ files and methods. This problem only happens when I reference this preexisting code from our huge codebase.
If I do not link my .obj file with a .lib file from our code I get unresolved reference messages from my Borland 5.5 compiler I have to use.
The overall issue is that my dll file works fine when I call it from a c++ exe file, but Java cannot handle something in it. Also, if I compile my code into a .so file in unix instead of a windows dll, Java JNI works fine and can load it. I know the problem is related to how Windows uses dlls, and I know if this 3rd dll doesn't load as part of my dll it will also work. I just have no idea what I did last year to build my dll without this 3rd one showing as a dependency.
If I comment out the functions from our existing code it compiles fine and loads because the 3rd dll dependency doesn't get put in my dll.
More Details
I had a message about missing _strcopy, so I linked in the cw32mti.lib file and that went away, but then that cw32mti.dll shows up in my dll file. How do I prevent the missing reference message for something like that and prevent it from putting the dll in my dll?
My link command looks like this.
ilink32 mydll.obj, mydll.dll,,cw32mti
The only way I get the other missing references to work is adding the other dll to my link command like:
ilink32 mydll.obj, mydll.dll,,cw32mti.lib other.lib
Where other.dll contains functions I call from mydll.dll such as calculate(int a, int b), so my code has a link it in like calculate(num1, num2); The problem is when I use the lib that contains the calculate method, it also brings in other dlls linked to the other.dll that I do not want to load. I need to be able to call calculate(num1, num2) without adding other.dll to mydll.dll. This worked before without dynamically calling calculate and using the getprocaddress type of coding.
Update - I eventually had to give up on getting the windows dll to work with the smartheap memory manager. Since this code was deployed in unix, I was able to just build the .so files and get those to work with JNI. For the Windows dll compile, I put some conditional compiler statements around the JNI code that was causing the smartheap dll to be loaded, so then when it compiles in windows it does not use that code. Instead I just had it print out a statement saying it was not executing in windows.
We also ran into issues later with getting our 64 bit JBoss server to run and load these 32 bit .so files. I ended up running a parallel JBoss server next to the 64bit one and called the methods that referenced the 32 bit library on the 32 bit instance of JBoss.
It may evolve into more later, but for now this task is working for us after months of trying many different things. I appreciate all of the help and input here.
If you can get your hands on the application DLL built from last year, use TDUMP to see what the module dependencies are. (You might have to analyze all the DLLs to get a good picture.) Then endeavor to reproduce that in the new DLL, probably by adjusting the linker's configuration .DEF file.
Without any code or .DEF file shown in your question, it is very difficult to be more specific.
I'm working on a game which has different "modules" that I am developping on separate projets for now, with VS2010.
So far I have each project in its own solution, and the main.cpp file is used to basically initialize and do some quick tests on my project, that I change very often.
Is it possible (and how) to have 1 solution regrouping several projects while at the same time having also one "main" function per project that I could launch independently of the other projects to test one project specifically?
Here's what I would do:
Put all your projects in one solution. There is some button or menu option somewhere to Add a Project to a solution. The advantage of this is that you can be editing multiple projects at once and Visual Studio will automatically rebuild everything that needs to be rebuilt when you compile.
All your reusable code (code used in more than on executable) should be divided up into projects that compile to DLLs.
For each executable you want to generate, you should have a project that compiles to an executable and references/links to the DLLs it depends on. Each executable project will have its own main function which runs when you run the exe.
If you want to have a way to test your DLLs without generating an executable, you can make an entry point in your DLL and run it using rundll32. This would be good for developers testing your DLLs, but I would never tell a user to use rundll32.
The build configurations are specific of each project, including which class contains the main method -IIRC, you can define several main in your project and define which one should be called through project configuration-.
I have a vb project which calls functions in a dll.
The dll is created in a separate vs project (portaudio), which is written in c.
The dll c project compiles clean and builds the required dll, which I am currently dropping in c:\windows\system to vb runtime can see it.
VB Project lives in c:\devprojects\vbtest
C Project lives in c:\devprojects\portaudio with the project file in c:\devprojects\portaudio\build\msvc. Dll created in Win32\debug under this msvc directory.
When I call the dll function, is it possible for the vs debugger to step through the c function in the dll - I have all the code etc, but I don't know if VS2005 supports this kind of mixed language debugging.
If this is possible, could you advise how I should set up my Visual Studio to achieve this.
Many thanks
David
It is not necessary to have both projects in the same solution, but you should compile both projects with debug symbols enabled.
Now in your VB net solution Project/Properties, in the Debug tab make sure that "Enable unmanaged code debugging" is checked.
Also make sure that the dll loaded is in the same place where it was compiled, else it may not found the pdb where the debug symbols are stored.
Create a solution with both projects, add the reference in VB project to C project using 'Add Reference..' dialog -> Project and build them all in debug mode.
How do you calls C dll from VB?
If its VB.NET then this is very easy, just set up a solution with both projects under it, set up their dependencies and ensure that on build the debug version of the VB project links to the debug lib/dll produced from your C++ project. Visual Studio does the rest.
I've done this before a couple of times with C# applications calling a C++ dll. I didn't intend to set this up, but tried stepping through whilst debugging assuming I would get the assembly listing and could at least work out somethig of what was going wrong with my code... however it loaded the correct .cpp file and allowed me to continue stepping through that code.