there is a quote from Algorithms for Java (sedgwick 2003) p. 135:
"we commonly use driver programs when developing or debugging adt iplementations"
what is meant by driver program?
google just gives me loads of info about programming drivers, clearly not related
In this context a driver program is just a program that uses the class or algorithm that you're developing. It's primarily used for testing your code while you develop it.
A Driver program, as I understand it, is just a simple class that instantiates the overall program you have created.
In University programs, we started learning Java by making very simple Drivers, that just passed in parameters to random classes and methods.
It's simply a program designed to call various APIs and pieces of logic you are working with. E.g. if you have a library that reads XML files, does some sort of transform on it, and writes the transformed data into another file, to work with that library you create a driver program which does nothing but call those 3 APIs and does error handling - e.g. it drives/directs your API to do its work.
A driver is generally a (relatively) simple executable program designed to exercise some component that isn't directly executable, like a library or ADT or test suite, etc. For example you might have a Table class that supports reading in CSV, and supports outputting to CSV and HTML. You might write a simple program that takes on the command line the name of an input CSV file and a format to output to so you can confirm the Table class does what you expect. All the driver would do is construct an instance of the Table and read in the file and use it to write out in the specified format.
Related
I am doing a project with a fairly powerful 32-bit microcontroller, the STM32F4 (with 192K RAM and 1024K Flash). I am using C. The system I wish to create consists of this controller (I'll call it the 'host') and a small module (the 'client').
The client simply contains a memory bank and an LED controller that both use the same data line (I2C) to connect to the host. The host can read from the memory and send commands to control the LED outputs on the client.
I want to be able to write code directly on the client's memory. Then at runtime, the host will pull the code from the client and run it - and the code will be limited to doing two things:
Manipulating variables in an arbitrary way
Sending commands to the LED driver based on these variables.
I want these limitations so that anyone can write code for a client without being able to do something malicious to the host. I am looking for a way to run a scripting language interpreter on the microcontroller for this purpose. The code on the client would then be text-format and it would be interpreted on the host.
I have looked into eLua but it looks like it would require me to implement all of my C code on the host as Lua libraries, which I would like to avoid. Does anyone know of a solution where I can just interface to the I2C library and run simple scripts without too much pain?
If not, is there something out there that I can build on to build this simple interpreter myself?
I can provide any clarification if needed.
You have two variants runs on a single engine: bytecode interpreter.
Today I found this intro video: http://www.youtube.com/watch?v=OjaAToVkoTw
Very simple tutorial on making VM from scratch.
And two variants:
cross/target scheme: run compiler you write yourself (flex/bison as
a first candidate) on a host (Windows/Linux/...), and transfer readily to
use bytecode image to Cortex-M target, or
self-hosted compiler runs on target Cortex-M: (a) in native code or (b)
written itself in a bytecode
As a most simple variant, you can implement FORTH system -- its parser need the only lexer, you can write in an hour from scratch, or generate by flex. And you can find a lot of FORTHs some of them works on (1) method: host compiler, and target bytecode interpreter connected via UART.
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.
ive previously asked another questions about building my dll, but it seams like its heading in the wrong direction :) So I have reformulated and explained more her.
So what im trying to build is a dll that will work as an interface between my delphi program and some one else's C program.
What this dll must do is recive a String from the C program then send it to the delphi program where it will be combined with some data and stored, under the current user of my program.
How can i call a method in my Delphi program(running program) to store the message from the dll ?
Im using Delphi 5.
This is what ive got so far:
DLL:
//Parent application: MyDelphiApp
library MyDllLink;
uses
ShareMem,
SysUtils,
Classes,
Dialogs,
Main;// Main is a form from my delphi app. This is not allowed/recomended ?
{$R *.RES}
procedure Transfer(sMessage: PChar); stdcall;
begin
try
//If including Main in the uses clause, then this will also be wrong:
MainForm.StoreDllMessage(sMessage);
except
showmessage('Error');
end;
end;
exports
Transfer;
end.
Delphi app:
procedure TMainForm.StoreDllMessage(sMessage: String);
begin
//StoreMessage just stores it in a DB
StoreMessage(sMessage +' '+sCurrentUserName);
end;
I may be understanding this wrong but it seems like you want the same copy of the DLL to be loaded by both the C program and the Delphi program at the same time. You can't do that and can only really achieve it using a whole lot of work involving inter process communication. The applications will have separate process space and memory.
I would suggest a slightly different approach. In the DLL have a function called SendStringFromCApp and a function called GetStringIntoDelphiApp (or something suitable).
The C program will load a copy of the DLL as normal and call the SendStringFromCApp function. This function will store the passed in data in some common intermediate format (such as a simple database). It will treat the storage as a kind of queue and simply add data to this queue. A database is the most obvious choice but it could be as simple as a common directory and the data is stored as small text files with an increasing integer as the file name.
The Delphi program will load its own copy of the DLL and will call GetStringIntoDelphiApp which will read the first item from the queue/internal storage and process it as required and delete it from the store. Then it will read the next etc etc.
The benefit of this is that both the C and Delphi apps can run independently. Only the DLL needs a common config and the C program can continue to work even if the Delphi app isn't running and vice versa.
It's basically a producer-consumer queueing system for separate processes.
Like I said, I may have misunderstood the requirements!
For the easiest possible IPC try WM_COPYDATA with PostMessage or SendMessage
Microsoft doc:
http://msdn.microsoft.com/en-us/library/ms649011%28VS.85%29.aspx
Microsoft sample:
http://msdn.microsoft.com/en-us/library/ms649009%28v=VS.85%29.aspx
And much more info on google:
http://www.google.com/search?q=WM_COPYDATA&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:pt-BR:official&client=firefox-a
Try implementing an IPC (InterProcess Communication). You will have 3 separated processes.
The Delphi exe
Ths C program
A non windowed process (com service, exe, ...)
Use the non windowed as the server, the other 2 are clients.
See this for IPC in Delphi, and this for IPC in C. There is a lot of ways to do IPC. If you look for IPC in your favorite search engine I'm pretty sure that you will find a common way to do IPC for C and Delphi because it's just some win32 api ballet.
As loursonwinny says, IPC is the way to go.
You should understand that every DLL is loaded within the address space of a single application. Thus a DLL that is used by a Delphi and a C application will exist two times in memory. (Well, not completely, the code sections are shared, all data in the DLL exists twice.) So basically your DLL cannot simply share data between two processes.
There are exceptions, of course. For example, a keyboard hook could be created in a single DLL which is loaded in your Delphi application, then injected into the address space of the C process. Then the DLL can 'peek' into the memory space of the C application and capture some information. (Keyboard events with KeyHooks.) But KeyHooks and similar injectable DLL's will be noticed as "bad" by the average antivirus product. And for good reason, because this is behaviour you'd expect from a computer virus.
Another solution instead of IPC would be the use of a memory mapped file. There are several components available as open-source or commercially but you can also use the Windows API to create these.
The Windows API also provides techniques like Named Pipes and MailSlots, which can also be used for interprocess communication. It doesn't need to be TCP/IP but you will need some way for the two processes to communicate with one another. And this logic could indeed be build in a single DLL, where you'd define just two methods. One for the server, one for the client. It is a complicated technique, though. And Delphi 5 is a bit old so I don't know which solution would work best for you.
The DLL must callback to the Delphi program. When the Delphi program starts up, it'll register a callback function. Then the DLL knows what to call when it is invoked by the C program.
Example:
http://delphi.about.com/od/windowsshellapi/a/callback_delphi.htm
This example uses a callback to allow the windows API to call back into your delphi app. Same idea here, but instead of the Windows API, you're going to be called by your own DLL.
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.
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