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
Related
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.)
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 would like to know if it is possible to include an executable file in another one, and then run it directly from there.
For example, if I am writing a GUI frontend to clprog.exe, I would want to have one file, guiprog.exe, that will run it's internal version of clprog.
Assume including the source of the wrapped program in the wrapper program is not an option.
I am more interested in this as a theoretical question, so answers applying to either windows or linux are fine (I am not familiar with other OSs), as well as using any language (C/Java/ASM/other, though I assume if it will be possible in any of these languages it will be ASM and maybe C, and obviously not Java)
First thought that comes to mind is a .NET solution.
If the external executable is a .NET assembly, you could embed it inside of your own project, and at run time load that into an in-memory assembly and execute using reflection.
If the embedded executable was built with .NET I think you would have to extract and temporarily save the executable, execute it as a separate process and then delete it, if you don't want to leave it's trace.
I am looking into making a C program which is divided into a Core and Extensions. These extensions should allow the program to be extended by adding new functions. so far I have found c-pluff a plugin framework which claims to do the same. if anybody has any other ideas or reference I can check out please let me know.
You're not mentioning a platform, and this is outside the support of the language itself.
For POSIX/Unix/Linux, look into dlopen() and friends.
In Windows, use LoadLibrary().
Basically, these will allow you to load code from a platform-specific file (.so and .dll, respectively), look up addresses to named symbols/functions in the loaded file, and access/run them.
I tried to limit myself to the low-level stuff, but if you want to have a wrapper for both of the above, look at glib's module API.
The traditional way on windows is with DLLs. But this kind of obselete. If you want users to actually extend your program (as opposed to your developer team releasing official plugins) you will want to embed a scripting language like Python or Lua, because they are easier to code in.
You can extend your core C/C++ program using some script language, for example - Lua
There are several C/C++ - Lua integration tools (toLua, toLua++, etc.)
Do you need to be able to add these extensions to the running program, or at least after the executable file is created? If you can re-link (or even re-compile) the program after having added an extension, perhaps simple callbacks would be enough?
If you're using Windows you could try using COM. It requires a lot of attention to detail, and is kind of painful to use from C, but it would allow you to build extension points with well-defined interfaces and an object-oriented structure.
In this usage case, extensions label themselves with a 'Component Category' defined by your app, hwich allows the Core to find and load them withough havng to know where their DLLs are. The extensions also implement interfaces that are specified using IDL and are consumed by the core.
This is old tech now, but it does work.
I think the thing I want to do is called GUI/command line wrapping sftp(1). I need an easy way to start that program and react on its output while running. Additionally I have to be able to send input to it, full interaction is required.
I tried forkpty (emulated TTY), but there wasn't one good example findable using forkpty for that job, instead several warnings about overflows in in arguments and advisories not to use it. Another weird thing about this was the windowsize argument...
Please either give me one or many example(s) on how to call & interact with command line programs in C or another way of integrating sftp in an iPhone GUI
Rejoice! Expect was created to solve exactly your problem. It's based on Tcl, which is not so pleasant, but the tool is pleasant, it's really well designed, and there's a good book by Don Libes, who created the tool.
Expect scripts are written in Tcl, but it is totally easy to integrate a Tcl script into a C program such that other parts of the C program don't even know that Tcl is being used.
Have you used any of the popular scripting languages Ruby/Python/Perl/etc? They all have pretty full featured libraires for opening and communicating with other processes.
the subprocess module in python for example, or Popen in Ruby... there would also be lots of reference material around the web to help you out.
If a GUI was also required you could look at GTK extensions
Instead of calling sftp(1), how about using libssh? It has full sftp subsystem support.