I have an external function from an opencv dll, cvCreateFileCapture, that should take the path as an input and return a structure.
CV_IMPL CvCapture * cvCreateFileCapture (const char * filename)
I created a vs2010 project for testing purposes from where i call this function with a valid file path and get the structure i was supposed to get returned.
When I call this function from a different program (I'm using labVIEW) I jump into the same function with the same input but it returns 0.
Does anyone have an idea why it works 1 way but not the other?
The C call is CvCapture* p = cvCreateFileCapture("C:/Users/****/Downloads/Disturbedloc.avi");
the labview call looks like this:
Load time debugging
If the library call works in one environment but not another, then there's a difference in the environment. There are two main approaches:
Use depends.exe to make sure that opencv has the correct linkage. Perhaps Visual Studio is inspecting opencv for other libraries (like FFMPEG or GStreamer) and adding extra loader instructions to fetch those binaries on launch. LabVIEW, on the other hand, will do a pure dynamic load, and if the library doesn't correctly advertise its dependencies, then those libraries won't be loaded and you'll get a NULL pointer.
Attach Visual Studio to LabVIEW before your VI makes the first call into opencv then watch the Modules window to see if the support libraries are resident in memory. Comparing against your working Visual Studio program would show if any are missing.
Loading missing libraries by force
That run-time linking doesn't work in opencv is a bug in their project. You should report that to them.
You have two workarounds:
Fix the bug, build opencv yourself, and redistribute it with your application.
Call dummy entry points in each dependency to prompt LabVIEW to bring them into the process. Then start calling into opencv.
Once it's working
Since your opencv dll returns a pointer to a struct, you have two options:
Wrap and adapt the opencv library in another C/C++ library so that the inputs/outputs are simpler data types, like numerics.
Use a cluster and some specific Call Library Function node configuration so that LabVIEW can understand the memory layout of the opencv types. NI has a some good documents describing how LabVIEW interfaces with external libraries, but start here: Calling C/C++ DLLs from LabVIEW.
I've just tried and it is working for me.
Here is the front panel:
And the block diagram:
I'm using Labview 2014 and OpenCV 3.0.
I had problems (i.e. 0 returned) with more complex Paths (including spaces, etc.)
Related
I have an executable (that I created using Visual C++ 10), and I need to use its capabilities from another program I wrote (same environment). Due to complex deployment requirements which I won't go into, building a DLL from the required functionality and loading it in both programs is not something I can do.
So I thought that I can __declspec(dllexport) some functions in the EXE, and then LoadLibrary() will let me GetProcAddress() them.
Obviously this can't be done, though when I started looking at it - it looked feasible.
Specifically, when you __declspec(dllexport) functions in an EXE project, Visual C++ also generates a lib file for dynamic linking - so you don't even need to use LoadLibrary() - just link against the resulting lib and call the functions.
Unfortunately, the main problem is that when you declare the resulting file as an EXE, Visual C++ adds the "CRTmain" entry point into the resulting file, instead of the "CRTDLLmain" that a DLL gets. When Windows (automatically) LoadLibrary() the EXE from your main program, it doesn't call the the "CRTDLLmain" entry point (because it doesn't exist), the C runtime for the module doesn't get initialized, and as a result all interesting work (such as memory allocation) fails with interesting(*) runtime exceptions.
So as follows, my question is: is there a way to cause Visual C++ to build into the resulting file both the "CRTmain" entry point and the "CRTDLLmain" entry point?
(*) "Interesting" as in an old Chinese curse.
Yes it is possible.
http://www.codeproject.com/Articles/1045674/Load-EXE-as-DLL-Mission-Possible
The idea is a) to patch the IAT and b) to call the CRT before calling your exports.
Simply no!
The Problem is that the CRT and in the EXE you want load, uses some globle variables. You main EXE does the same. So how should Memory allocation work?
If you want to use such a structure you must use a DLL to be Aware of meulti threading, CRT initialization ans all this other stuff. You need this!
But what about COM Automation? Wouldn't tis be an easy solution to use your code in one EXE from another?
The short answer, is "no". After looking far and wide, there is no way to get VC++ to do what I want, and quite likely not any other compiler.
The main issue is that the main() entry point most people know and love is not the real entry point in C++ executables: the compiler needs to do a lot of initialization work to get the "C++ Run Time library" to a usable state, as well as initialize globals, statics and the likes. This initialization uses different code in shared libraries than in executables and there is no way to one to behave like another.
One thing that possibly can be done, is to build the shared functionality into a DLL, and for the primary executable to embed the DLL as a resource, and load it from a memory mapped region of the executable file (there are several code samples how to do this with VC++ on stackoverflow and elsewhere on the web). Now another program can do the same thing by loading the DLL from the bundling executable.
I am running Windows 7, and I know the DLL was built using Visual Studio C++ 2010. Since I don't have the source code I can't build it on-the-fly in R when creating a package (NAMESPACE). At this stage, I don't need to create a package, I just want to load the library in R using dyn.load(). Since it is a dll I suppose it is portable to any client program, but I would just make sure, because I know that it was not compiled using GNU gcc.
EDIT:
I want to call all the functions that the dll deploys.
Yes, R can load it using dyn.load. You may or may not be able to actually call the functions it exports, though. Unless the functions' arguments correspond to what R can handle, they won't be usable. If this is the case, you can write a wrapper dll that acts as a translation layer between it and R.
I have a large code written in C, but I did not write all of it myself. I wish to create an overview of the call structure in the code for reference. That is: I wish to know what (non-standard) functions are called by the different functions in the code, and thus create a hierarchy or a tree of the different functions. Are there any free, Unix compatible programs (that means no Visual Studio, but a Vim plugin or such would be neat) that can do this, or will I have to write something that can do this myself?
Doxygen does that too, it has to be enabled though.
For an overview of available tools see
http://en.wikipedia.org/wiki/Call_graph
There is a Vim plugin C Call-Tree Explorer called CCTree
http://www.vim.org/scripts/script.php?script_id=2368
As you mentioned a Vim plug-in, check out http://sites.google.com/site/vimcctree/. It uses CScope to generate the tree, so you will need to first generate a CScope db of your source files.
Have a look at http://www.gson.org/egypt/ This uses GCC to process the code and extracts the interdependencies within the program from the AST it emits.
gprof will do that. It also generates an execution profile, but in doing so it creates a call tree.
I just downloaded SourceTrail (https://github.com/CoatiSoftware/Sourcetrail/releases) and it did what I wanted, which was pretty close to what I think you want.
(What I wanted was to find out what routines called the function I was considering changing, or needed to understand).
Note that it is no longer maintained, but it did exactly what I wanted. It runs under Windows and Linux, and made finding who calls a function pretty trivial (as well as following that function's call tree down as needed). If you care, it has a GUI (is a GUI? whatever).
It does the parsing itself, but it didn't take very long to run, perhaps about the same time or a little less than compiling the code.
But if you want text only, or don't want to use a gui, or don't want to have it scan the code, this isn't for you.
(Notes - in my case, I was hyper-focused on one or 2 functions, and didn't care what system functions were being called. I spent some time stubbing out all the include files that were needed (since I ran the parse on one machine (A Linux machine) that didn't have all the include files needed for the Windows program I was looking at, and then did the exploration on a different (Windows) machine. Which, I should mention, worked perfectly. I just copied the entire source tree from my Linux machine to my Windows machine (which included the Sourcetail project file), loaded Sourcetail and had it load the project - done.)
I program in Delphi (D7 and D2006) on Windows XP (migrating in the near future to Windows 7). I need to use a mathematical library for some of the work I am doing and most of the math libraries (I am inclining towards Mathematica at present) I have looked at will produce compiled C code. Such code will provide specific functionality to my main programs.
I have a very basic question - given this development setup - how do I start utilising the compiled c code from Delphi? I really need baby steps to get me started on the process.
I've done quite a bit of this with my FE product OrcaFlex. You have two options to link to your C code from Delphi: static or dynamic. I link statically because it makes distribution and versioning much easier. But it's really quite a trick to get it to work statically and you have to rely on a number of undocumented aspects of Delphi.
I suspect that for your needs dynamic linking is best. Basically you need to compile and link your C code into a DLL. I recommend using the Borland C compiler to do this. You can use the free command line version BCC55 to do this. The advantage of using Borland C is that it makes the same assumptions about the 8087 floating point unit as Delphi does. If you build with MSVC then you will find that MS have elected not to raise floating point exceptions. Borland C does raise floating point exceptions. This is a bit of a corner case but it becomes relevant if you are trying to ship a product that you need to be robust.
You should know that the C code will, by default, use the C calling convention and I'd just stick with that. You bring it into Delphi by declaring the external routine as cdecl calling convention.
The other thing you need to take care on is defining a clear interface between the two modules. You need to make sure that exceptions don't cross the module boundary and that you don't pass any special types (e.g. Delphi strings) across the boundary. So for a string use a PChar (or even better PAnsiChar or PWideChar to be sure that it won't change meaning when you upgrade to Delphi 2009 and later).
I have been very happy with the SDL Library from Lohninger (http://www.lohninger.com/mathpack.html). It is written in Delphi and compiles right into your application, so there are no bundling or calling convention problems or floating point usage differences, as discussed by other responses in this thread.
Take a look at what he includes. If you're lucky, your needs will be met by his library and you'll be able to use it!
If you currently have Mathematica installed, go to the documentation centre and lookup guide/CLanguageInterface otherwise that guide is available on the web and have a good read there.
My understanding is that Mathematica can generate C-programs that link up with the Mathematica engine via MathLink if you need full function, or if you only need lower-level features then it is capable of generating code that can be statically linked with compiled Mathematica libraries. So that standalone code is possible.
See the Code Generator documentation.
If you can convert the C programs in to DLLs, then accessing such external functions from Delphi is relatively simple with external declarations.
function MathematicaRoutine(const x : double) : double; external 'MyInterface.dll';
There are bound to be a great number of complexities in getting this to work if you need to achieve a static bind, for use where Mathematica is not installed, if indeed it is possible. I have never attempted it.
You can mix your project with Delphi and C++ (Builder) code using RAD Studio. Put the automatically created C code into a C++ Builder file (.cpp) and for the rest add Delphi files.
I am interested in calling SoX, an open source console application, from another Windows GUI program (written in Delphi naturally). Instead of dealing with scraping and hiding the console window, I would like to just convert the application to a DLL that I can call from my application.
Before I start down this path I am curious how much work I should expect to be in for? Are we talking a major undertaking, or is there a straight forward solution? I know some C, but am by no means an expert.
I am not expecting SoX specific details, just EXE console application conversion to DLL in general. If someone is familiar with SoX though, even better.
For the specific topic of turning a console executable into a library by modifying the C source code, it depends on how the command-line application is factored. If it's written in such a way that I/O is funneled through a small set of functions or even better function pointers, then obviously it will be trivial.
If it's all done with printf, scanf and friends, then you'll probably be best off by finding / creating an include file that all the source files include and adding a macro that redirects printf/scanf and friends to your own functions that are written so as to be amenable to DLL implementation. Things like printf can be built from vsnprintf (use the n-version for safety), so you don't need to reimplement the whole C RTL I/O subsystem. However, there is no vsscanf, but there are third-party implementations on the web.
If the code is using fprintf, fscanf, etc. to enable indirection between files and the console, you're still out of luck. The FILE structure is opaque, and unlike Pascal text files, a portable text file driver cannot be implemented. It might still be possible if you spelunk in your specific C RTL, but you'd be better advised going down the macro route and reimplementing your own renamed FILE type.
Finally, the "popen()" approach is possible in Delphi and made somewhat easier in Delphi 2009 with the TTextReader and TTextWriter classes. Combine these with TFileStream wrapped around pipes, and specify pipes for standard input, standard output and standard error in the new process and STARTF_USESTDHANDLES, etc., and it will work. If you don't feel like writing your own, there are third-party equivalents / samples on the web for Delphi too. Here's one.
In Windows, you just call CreateProcess with the SoX command line. I don't know the Delphi bindings for Win32, but I've done this exact thing in both Win32 and C#.
And now that you know CreateProcess is what you want to call, a google search on how to do that from Delphi should give you all the code you need.
Delphi Corner Article - Using CreateProcess to Execute Programs
Calling CreateProcess() the easy way
You might not even need a DLL, you can use the popen() function to run a console application and collect any output text.
Run the process, the way Indiv advised and capture the output like how Adam has shown.
However if you still want to do the DLL conversion, this will get you started
Configure SOX for windows and compile it
Create an empty DLL project using your C++ tool
Add the SOX files to be part of the project
Add a new Function called DLLMain
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID ) {return TRUE;}
Add a .DEF file (use the project name as the file name) that lists the exports in the DLL - Add the following content to it
LIBRARY "name.DLL"
EXPORTS
CallOldMain PRIVATE
Rename the main of SOX as CallOldMain
Write a CUSTOM function to log the output / return error etc.
Find all printfs / cout in the SOX application and replace it with calls to your custom function above
Once the DLL is compiled you can now call the function CallOldMain with the same parameters main programs of C expects. You could modify this signature to return the errors / output from above.
Disclaimer: I know nothing about SoX. It might be that the code is structured to make this easy, or it might be more hard. Either way, the process is the same:
First you want to find the functions in the SoX application that you want to call. Most likely the console app has code to parse the command line and call the appropriate functions. So first off, find the functions you want to use.
Next, check out the info on exporting functions in DLLs from C at this site: Creating And Using DLLs
Then make a new makefile or visual studio project file with the target being a DLL, and add the sourcefiles from the SoX program that you have modified to be exported.
You don't mention what your toolchain is, but if you configure gcc in Windows, you can use the normal config;make;make install to just compile sox. In the process, it will create a dll file, and the console app. Or, you can just specify the make target to only make the dll. This will compile a windows native library that only depends on the MS C runtime dll, and you can use this in your own app.
You can execute a console application and capture its output using pipes. You use une side of the pipe as stdout for the CreateProcess and you read from the other side like a common file.
You can see a working example written in delphi here: http://delphi.about.com/cs/adptips2001/a/bltip0201_2.htm