I do not have much experience working with COM and was wondering if anyone knew the minimum amount of information I have to provide to #import a dll into a cpp file (which will be used to make a dll). According to MDSN (http://msdn.microsoft.com/en-us/library/8etzzkb6(v=vs.80).aspx) I need to include a type library resource such as an .ocx file. Is this the case even for a Microsoft shared dll (e.g. mso.dll)? In addition, what are the other type library resources can I use?
From what I have gathered so far, I just need to provide enough information to the MIDL for it to form the interface to the dll in the right way (this seems to be the essence of COM).
The original link is dead. https://learn.microsoft.com/en-us/cpp/preprocessor/hash-import-directive-cpp?view=vs-2019 seems to be the new URL.
In the link that you listed a key sentence is "#import creates two header files that reconstruct the type library contents in C++ source code". When you #import MSO.DLL you are importing a type library to your project (not to your cpp file) and it creates the necessary COM interface definitions. So you don't need to provide additional information.
But there are probably other files you need to #import in order to use Office applications, depending on what you are trying to do.
Related
I would like to create a static library in C++ to store my functions.
I'm aware this question has been asked on the Cplusplus forums but I could really use a
more accurate description of what to do.
As far as I'm aware you create a new Win32 program and then add the header file (.h) and the
code file (.cpp).
So in fact I have a few questions.
1 - How do I put my code into these files?
Do I use the .cpp?
2 - I did manage to make a simple library with an add function alone, but after compiling
and building it I was unable to #include it in a program. Why is this?
Could someone please write out a step-by-step approach to making this so I can finally do it.
I am aware MSDN has a tutorial for this, and I have looked at it.
The thing is it uses a OOP approach to making the static library, and the calls to the
functions within the library use the :: operator (think its an operator), too often which is what I want to avoid.
Would like to start simple, basically.
Thanks for any help given.
The idea of a static library, is that you write your code as usual, but you compile it as a static library. The users of a static library still need your header files, but they don't need your .CPP files anymore, because the actual implementation is contained in your static library file.
To use a library, you include the header files you need, and then link the library file with your program.
Here is a link to the microsoft walkthrough.
http://msdn.microsoft.com/en-us/library/vstudio/ms235627.aspx
How to create and use a static library using Visual Studio
Here is excactly how you do it in Visual Studio 2012.
To create a library, create a new C++ project. In the wizard, at Application Settings, choose Static library. Uncheck Precompiled header.
Create your library as you want. Don't forget to declare everything in header files.
Compile the project as you usually would. This creates a .lib file in the debug folder of your solution
To use the library, create an application as you usually would.
To link the library with your project, drag the .lib file to your project in visual studio.
To let visual studio find your header files, right click your project. Choose Properties->Configuration properties->C/C++. There is a input box called Additional Include Directories. Here, you have to write the path to the header files of you library.
You can now use the header files as if they where made by your project directly. The implementation of your library is taken from the .lib file, and everything should compile and run well.
Another option, is referencing the whole libary project in your application. To do this, you must get the library project in your solution. Right click your solution in Visual Studio->Add->Existing Project. Then you have to reference the project. Right click your project->References->Common Properties->Framework and References->Add New Reference->Choose your project. Now you can edit your library in this solution and use it directly in your application.
I have just started reading up on the JNI and guy from the C++ side of our project has just pointed me towards 2 files, the Java Interface and the DLL file.
With the DLL in hand do I need to have any other knowledge of what is going on on the C++ side. Do I now just put the DLL in the class path and access it via the Java interface he has given me? He created a header file using the Java interface and this is included in the .cpp file. From that I assume the DLL was generated.
The following is some of the code I have
System.loadLibrary("PredictionService");
JNIPrediction predictor = new JNIPrediction();
predictor.getPredictions("test");
I don't get any errors so does this mean it is loading the DLL successfully and calling the getPredictions() method inside the DLL?
Basically I was needing to know is this how you use JNI typically.
A 'Java Interface File' is not a commonly defined term. You need at least a C header file or some documentation to indicate how the functions in your DLL need to be called. The only information you're likely to get from the DLL itself is the names of the available methods.
While it is possible to embed debug information in the DLL which describes the DLL method signatures, it's not likely that you have such in your DLL, and you need additional tools to be able to make use of it.
This is a newbie request. I'm looking for materials on .dll creation. Specifially, i want to create a .dll out of a simple 3D engine i've made to learn about the process. I need information on dynamic link libraries that go deeper than the wikipedia page, how are they created, what's necessary, how to create different .dll files for "debug" and "release", how to create a PDB file for it and how to create a header file that'll allow for easy usage of the library from a, f.e., C++ program. Material with strong theoretical side (not as much, "how to create a dynamic link library in visual studio") would be great.
Please share good materials on the subject, all i can find is some information here and there and it doesn't paint the picture for me.
Reading between the lines, I think you really want to know about libraries in general rather than dll's specifically. A library is simply a handy package of object (compiled) code, along with some information about how to call into it. In C++, this usually takes the form of a .h file.
With static libraries (.lib), the linker pulls in the code it needs in exactly the same way as it does with all the rest of your classes. A normal class will get compiled to object code (MyClass.obj), and when they're all done the linker sticks them all together and wires up any inter-object calls with the appropriate addresses. It's the identical process with .lib library files. You end up with a big ball of executable code which includes both your classes, and the library functions within it.
With a dynamic library (.dll), the only difference is that the linking (wiring) happens at runtime instead of at compile time, and the library object code remains in a separate ball - the dll file. When you compile your exe, all calls that use functions in the library are mapped to a stub function. When Windows loads the dll for you, it will stick the dll code into the same memory area as your process, and wire up the stub functions to the real functions that are now available.
The only other difference is that a dll must expose a function that Windows can call when it loads or unloads the dll, in case the dll wants to do any initial setting up / clearing down. This is traditionally called DllMain().
If you want to learn about libraries, I would concentrate on creating a static .lib first before worrying about dll's. This is where most of the work is. Once you have a lib it is child's play to turn it into a dll.
The main thing you need to think about when creating a library is how you are going to expose your API (Application Programming Interface). This is just which functions/classes you are going to expose to the people using your library. You don't have to expose them all, but you do have to decide WHAT to expose. Are you just going to expose some C style functions, or are you going to expose entire objects? This is the real challenge when designing a library. You should try and make your API as easy to use, and obvious as possible if people (and you!) are going to find your library useful.
As for pdb files, differently named release/debug modules, and creating .h files. These are identical to when doing so in an exe.
1) Create a new DLL project, using VS wizard.
2) Add your existing source files to it.
3) Put into *.def file (which should have been created by the wizard) the names of the functions that you want to export from your DLL, as described here.
Basically, that's it. Debug and release configurations are automatically created by the wizard, but if you want the 2 variants to be named differently, you can change their output names: go to Project Properities -> Configuration Properties -> General -> Target name.
I have to use third party, unmanaged COM dll into my .NET application. I need to modify this assembly to produce a custom RCW. In order to Edit Interop Assembly I need the type library of the particular assembly. Can any one explain me that how to How to generate type library from unmanaged COM dll?
There is no option in regsvr32 to generate type library.
Thank you,
Best Regards,
Robo.
You need the OLE-COM Object Viewer, available as part of whatever is the latest Windows SDK. Then you can go to File->View Type Lib and save the IDL to a text file. Then you can use MIDL (also part of the Windows SDK) to regenerate a TLB and header file. Something like this should do for basic cases:
midl /out c:\temp /header MyHeader.h MyIDLFile.idl
If all you're trying to do is create an Interop Assembly from a native dll (and the native DLL embeds the TLB as a resource), you can just call tlbimp directly on the dll:
tlbimp Foo.dll /out:Interop.Foo.dll
Which will generate Interop.Foo.dll. You can then use ildasm to modify the IL:
ildasm Interop.Foo.dll /out=Foo.il
If all you have is that COM DLL, you can't generate a type library. A type library describes the COM interfaces implemented. But an unmanaged COM DLL merely needs to expose DllGetClassObject. This only gets you an IClassFactory, which lets you create new objects if you knwo the correct type up front.
If the typelib is embedded in the DLL Resources and the TLB file itself is what is required then 3rd party software can extract it (though, as others have pointed out, this may not be the most desirable option).
E.g. using Resource Hacker:
Open the DLL file.
Navigate to the TYPELIB\1\1033 (or whatever) node in the tree view.
From the menu, choose Action -> Save Resource as binary file...
Chose a file name and give it the .TLB extension.
You can now reference that .TLB file and build without requiring the original DLL, e.g.
#import "test.tlb" named_guids
Visual Studio IDE can directly extract binary resources from non-managed .exe and .dll files.
If the type library is saved as a binary resource in a non-managed COM DLL (e.g. one built using VS native C++ compiler), you can extract it as follows:
Open the .dll file in the VS resource editor (the default editor when opening executables).
Navigate to the type library resource ("TYPELIB", then 1) within the resource tree.
Right-click on the type library resource and select export. That brings up a "Save File As" dialog box.
In the "Save File As" box, change the filename from the default (typically, bin1.bin) to something like MyLibrary.tlb and click Ok.
Confirm by opening the exported .tlb file with OleView.exe (results should look identical to those you see by opening the .dll with the OleView.exe).
To extract type libraries from managed DLLs (e.g., the ones built using C#), VS includes the tool Tlbexp.exe (run it from the VS command prompt):
https://msdn.microsoft.com/en-us/library/hfzzah2c(v=vs.110).aspx
I am developing a C++ library that I want to pass on to my team. The library has just one class with a bunch of methods.
So, I have developed the class definition file (X.cpp) and a corresponding class declaration file (X.h).
Here are my questions --
In Visual Studio 2005, whats is the most straight forward way to build this library as a DLL, such that I get the following files:
X.lib : which I can pass to my team so they can link against my library
X.dll : which I can pass to my team for run-time
Instead of a DLL, should I rather be going the static library way ?? If so, how do I go about doing this in Visual Studio 2005 & will this give me a X.lib file that I can pass on to my team ?
Any explanations or references are very welcome.
Thank you very much.
The easiest way to build a DLL, is New->Project->Win32 Console Application. Then on the dialog select DLL and select "Exports Symbols". This will synthesize a dll with a .h, and .cpp file which demonstrate how to export your classes. You can get rid of this .h/.cpp but first import your class add the appropriate #ifndef statements. Now as far as DLL versus Static library if its a single small class, that doesn't change particularly often you might be better off with a static library, its simple, its concise, it doesn't add another dependency which needs to be shipped with your product. A DLL is nice if the code in the .cpp file changes often (ie. the function implementations) because you can just swap in the new DLL.
From your description, it looks like you already have a Visual C++ project (correct me if I'm wrong). If so, when you go into project properties, under "General" you can find "Configuration Type" - switch it to "Static library" or "Dynamic library" as needed.
If you choose "Static library", then you will just get a .lib file that can be immediately used.
If you choose "Dynamic library", and you export any functions from your DLL (e.g. by marking them with __declspec(dllexport)), an export .lib will be generated automatically.
It's hard to tell which option is preferable without knowing the specifics of what you're doing. In general, I'd recommend defaulting to static libraries, because it's usually good enough, and there are more traps when dealing with DLLs (especially ones that export C++ symbols).
I think that, in most cases, a dll is a better choice than a static lib because your team will not have to recompile their code when you distribute a new version of your library.
I struggle with this too sometimes.. because I can't find where the elusive setting is within C++ Project Properties.. So I decided to jot it down for my own sanity as a blog post.
HTH