I am currently facing a task where I have to integrate an IMU, whose API has been developed using Visual Studios 2015 with an integration software whose API is only compatible with Visual Studios 2010.
I already tried adapting the IMU API to VS2010 but that got too complicated and tedious. It is not doable in a reasonable amount of time.
A solution which I thought of, was to implement a class in VS2015 (let's call it BridgeClass) which would read the desired data from the IMU using a simple struct. This would be implemented as a dll and I could link it to the integration software in VS2010.
However, the part which is unclear is, how could I keep the two libraries separated from each other, so that VS2010 never 'sees' anything of VS2015 that upsets it. Is this possible using a dll? I will have to link the IMU library to the BridgeClass (for example to open the port to and read data from the IMU), will this, in turn, be linked to the integration software and end up being the same as directly integrating the IMU?
I would be very helpful if someone could give me some information regarding this or point me to some helpful links. Thank you!
As long as your DLL's API doesn't use any of the standard library and no exceptions are thrown across the DLL boundary it should work in mixed visual studio versions.
You need to use char* instead of std::string. No std::vector, std::shared_ptr, std::unique_ptr etc.
One other thing which you need to be careful of is that anything allocated in the DLL must be deallocated inside the DLL, this is usually done with a c factory function and a c destructor function that your application can call to create and destroy objects.
Related
One of our products is a C++ application - using MFC (MDI). (And we skin the application with Codejock.)
I've been asked if we could "port the application to .NET" - so it would be possible to use, e.g., C# libraries and other .NET features. I know there is something called "C++.NET" - or maybe (if I understand it right) it should be called "managed C++" now. But I don't know much about it.
My question: Is this at all possible? Could we run an MFC-application as "managed C++"? (And can an application using Codejock be run as a "managed C++" application?) There is some other threads about this, but I haven't been able to find "a definitive answer"...
I'd be very grateful for some good advice! :-)
As far as I understand, you want to keep your MFC/Codejock GUI and allow the use of .NET libraries from you application's C++ code.
This is indeed possible, but for a complete application that is currently compiled as "native" C++ it is probably not such a good idea to convert all of it to being compiled with C++/CLI. "It Just Works (IJW)" is a nice meme, but it doesn't work always :-)
We have the same situation, namely a C++/MFC/Codejock application that needs to call into .NET assemblies. This works mostly without problems:
We have C++/CLI modules that offer a native C++ DLL interface for the native C++ code to call into and that then route these call on to an assembly written in C#.
We also have C++/CLI assemblies that offer a .NET interface for the C# code and then call back into pure native modules.
It should also be possible to have a single (say, exe) project that is compiled natively and you only enable the /clr switch for selected cpp files that need managed interop. And at the end you link everything together. Since we've never mixed it that way, I can't really say anything about this approach however. What I can say for sure though is that it is possible to compile parts on a module as /clr and parts as native.
I faced a similar problem some years ago, and found that unless for trivial cases converting from un-managed to managed or reverse side was really painfull. I ended leaving the two worlds each in its side, and simply use interop to have the COM - .NET compatibility.
It was not very nice, but a lot cheaper. The conclusion that we should wait a major evolution to consider a full rewriting.
I have a C++ application that historically uses a Delphi IClientTable interface (MIDAS.DLL??) to maintain a local file database (.CDS file). Within our C++ application, IClientTable is a COleDispatchDriver MFC interface/object.
I would personally like to move away from this altogether and use SQLite, but unfortunately I am not in the position to do this right now.
Can somebody please tell me if there is an open source replacement for this COM overhead? I would like a simple DLL, library or set of source files to compile into my program to get rid of the COM interface which is causing me so much grief.
If you really want to know why I want rid of the COM interface - its odd - we've used it for 10 years without problem. Recently we've found a customer with Windows XP Embedded and for some reason when we use the IClientTable COM dispatch interface, this causes Windows WM_QUERYENDSESSION messages to be absorbed, or no longer reach my application. The minute I stop using the IClientTable interface, I get the WM_QUERYENDSESSION messages.
In short: the IClientTable COM dispatch interface appears to stop Windows from being allowed to log off/shutdown.
I'm not aware of any alternative ways to open binary ClientDataSet files. ClientDataSets can use also use an XML file format but I don't know if your IClientTable interface gives you access to that functionality.
If you weren't aware of this already the ClientDataSet's dependency on COM was removed in I think either Delphi 2007 or Delphi 2009. Recompiling your wrapper DLL in a recent version of Delphi may help, if the COM dependency comes from the ClientDataSet.
To the best of my knowledge there is no such thing as an IClientTable in any version of Delphi. I'm guessing that IClientTable is part of a wrapper DLL written by your team to encapsulate the ClientDataSet's features. If whoever wrote that wrapper DLL exposed the IClientTable interface as a COM object that may also be part of reason for your dependency on COM.
I currently have an old unmanaged C++ DLL using MFC. This DLL has a bunch of code which is multi-threaded and written back in 2003 using VC6. This code sadly doesn't work anymore.
I've been tasked with finding an alternative way of running this multi-threaded code so that it does function as intended. Someone before me had already rewritten it in C#, and I need to port that C# code over to VC++. I did some research and realized that I could save some time in the porting process by just porting the C# code to VC++ (using the .NET framework). But then I realized that my old MFC DLL cannot run this .NET code.
My idea is to write this multi-threaded code in a VC++ DLL (using the .NET framework) and using some form of interoperability to be able to call the functions from the old DLL to the new DLL.
I have looked into COM interoperability as well as wrapper classes. What is the best way of accomplishing this? Are there any tutorials that could help me with this task? (I've already done some extensive searching and there are a lot of tutorials using unmanaged C++ DLLs to C# DLLs, but not much that pertains to my situtation).
Just so you know, I cannot compile the old DLL with /clr as this DLL is hosted in an old Win32 application as well. Compiling with /clr causes the application to crash, or else this would have already been done.
TO CLARIFY: I'm curious as to why calling functions residing in a C# DLL from an unmanaged C++ DLL through a COM interop seems so simple compared to doing the exact same thing using a managed C++ DLL. I even have a proof-of-concept between C# and C++, but I can't for the life of me begin to understand performing the exact same task with C++. Does there happen to be just a simple tutorial for calling just one simple (let's say 'Add') function from unmanaged C++ to managed C++?
If you have a (managed) DLL, regardless of the language(s) it is written in, you need a process to run it in. If you have a native process that -- for whatever reason -- must not use the CLR, that you cannot directly use a managed DLL (any code that depends on the CLR in-process) from this process directly.
You would need a second helper process that runs the managed DLL and, for example, exposes a COM interface that the native process could call. (out of process COM server)
I have looked into COM interoperability as well as wrapper classes. What is the best way of accomplishing this?
Not sure what you mean with wrapper classes, but an out of process COM server for your managed DLL could do the trick. (Obviously, this is quite some overhand wrt. to managing the proper registration and startup/shutdown of the helper process.)
Breaking the problem up a bit (as far as I understand):
[oldish Win32 app (no! CLR)]
<- normal DLL interface -> [native/MFC DLL (no! CLR)]
<- via COM -> [stuff in a separate executable]
If this is what you are looking for, then this article (just a quick Google hit) may be helpful:
http://www.codeproject.com/KB/COM/BuildCOMServersInDotNet.aspx
For COM in general, I think any COM tutorial should cover what you are supposedly trying to do.
I want to create a DirectX 'filter' that sources a single channel of audio. I have seen the Platform SDK sample projects, but the downside there is that those require the ATL library.
Is there a way to create DirectX filters without resorting to ATL or MFC? I.e., some way using only gcc (e.g., MinGW) and other actually free tools?
If I understand right, the filter has to be a COM component. You can, sort of, write those from most compilers, if need be.
However, the boilerplate that would involve would be incredible, I had a 18kloc codebase that turned into 25kloc when turned into COM components (ended up turning it back just because there was more boilerplate COM than actual code for small plugins).
MFC isn't necessary or always involved in writing COM components, that I know of.
ATL helps simplify that greatly, by providing templates and functions to handle a lot of the details at compile-time. You may be able to use it from GCC, but I'm not sure what would happen; I doubt it would work well, though it might work.
Without ATL, you need MIDL and to generate the code from there. That is possible with free tools, it's done in a few places in the Wine project; you may check the code and toolchains there.
No matter where you do it, it'll be a pain, and a serious pain if you insist on using "actually free" tools for it (as they're not particularly designed to work with COM).
If you had DirectShow filter in mind, the best starting point would be PushSource Windows SDK Sample, which generates video and making it generate audio.
Also note that DirectShow bases classes are one of the earliest COM bases and they do not use ATL/MFC. The base classses themselves are also included with Windows SDK.
I have an application written in native C++ which I'd like to get running on the .NET virtual machine. I was thinking of recompiling the C++ code as C++/CLI, using the Visual Studio 2008 compiler. Regrettably, I don't find any documentation on how to do this, so hence my questions:
Does this actually make sense? Am I trying the impossible?
Where can information on the topic be found?
Go to project properties -> General -> Common Language Runtime support -> change to /clr
It's called CLR now. Read about it here and here.
A lot of native C++ code will actually just compile and run on C++/CLI. This is really a kind of hybrid compiler that can call native Win32 functions and use standard C libraries like OpenGL. You can even call COM interfaces directly (all the stuff you can do with a native C++ compiler).
The .Net library is also available but for these you create managed classes (using the ref class keyword). You will use gcnew to allocate memory for these classes (from a garbage collected heap). Memory for your normal classes is still allocated using new and delete (from a standard, non garbage-collected heap).
In short, you can migrate to .Net in bits and pieces, though there is still some friction when switching between managed and unmanaged classes.
I found this book useful: Pro Visual C++/CLI.
In C++ you can simply recompile your codebase with /clr. This technique called IJW (It Just Works) so you can easily use your existing classes with CLR.