Call Command from Mupen64Plus dll using RUNDLL32 through Command Prompt - dll

I'm using the Nintendo 64 emulator, Mupen64Plus.
It has a file called mupen64plus-ui-console.exe used to launch games through command-line. It also accepts keyboard shortcuts to perform commands, but it is limited.
Mupen64Plus Commands/Functions
This wiki page shows a list of all commands that can be called, I think from the mupen64plus.dll.
RUNDLL32
I read how to pass commands to a dll like this:
RUNDLL32.EXE <dllname>,<entrypoint> <optional arguments>
Calling a Command with RUNDLL32
I'm trying to call M64CMD_STATE_LOAD with cmd.exe, to load a save file.
Info from Wiki:
Command Functions Prototype m64p_error CoreDoCommand(m64p_command
Command, int ParamInt, void *ParamPtr)
ParamInt Ignored ParamPtr Pointer to string containing state file path
and name, or NULL
This command will attempt to load a saved state file. If ParamPtr is
not NULL, this function will load a state file from a full pathname
specified by this pointer. Otherwise (ParamPtr is NULL), it will load
from the current slot.
I have the Mupen64Plus emulator running a game. I then open cmd.exe and paste in this line.
RUNDLL32.EXE "C:\Path\To\mupen64plus.dll", CoreDoCommand M64CMD_STATE_LOAD 1 "C:\Path\To\MySave.m64p"
Problem
It accepts the command, I get no errors, but the save file isn't loaded.
Questions
Are the arguments being passed wrong?
Does the mupen64plus.dll not have hooks into the currently running mupen64plus-ui-console.exe?
Is it loading the save file into nothing?
Is it not possible to do it this way?

Related

Can we pass a command line argument to property file reader in jmeter

I have a config.property file that contains all the property values to be used in jmeter, so i am using property file reader plugin to read the property file, here the problem is i don't want to hard code the path to config.properties file in property file reader so i want it to pass as command line argument but it is not working
command i am executing is
.\jmeter -JPROPERTY_FILE=<file_location> -n -t <path_to_jmx> -l <path_to_jtl> -j <path_to_log>
In the File Path of Property File Reader, replace:
${PROPERTY_FILE}
By using __P function:
${__P(PROPERTY_FILE)}
Your mistake is that you’re using Variable syntax for a property.
See:
http://jmeter.apache.org/usermanual/functions.html#__P
http://jmeter.apache.org/usermanual/functions.html#functions
You should be using __P() function like ${__P(PROPERTY_FILE)} or even __property() function like ${__property(PROPERTY_FILE,PROPERTY_FILE)}. The latter one automatically stores the retrieved value into a JMeter Variable so you won't have to additionally declare it under User Defined Variables of the Test Plan
Instead of using custom plugins I would suggest going for built-in JMeter functionality, there is -q command-line argument which allows loading and arbitrary .properties file so you will not have to install the plugin, care about order of Configuration Elements, etc.

How to add a user defined function in QDB Library?

QDB is a database provided by QNX Neutrino package. I went through the QDB documentation to add a user defined SQL function: http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.qdb_en_dev_guide/writing_functions.html?cp=2_0_8
I created a source file which had my user define SQL function written in C and qdb_function structure definition. I built it with a make file to create libudf.so.
As suggested by QDB I added Function = udftag#libudf.so in the qdb.cfg. But while running the qdb in the shell prompt, it is giving the error (in bold):
qdb -I basic -V -R set -v -c /etc/sql/qdb.cfg -s de_DE#cldr -o tempstore=/fs/tmpfs
QDB: No script registered for handling corrupt database.
qdb: processing [TempMainAddressBook]Function - Can't access shared library
and qdb is getting exited immediately.
I have tried following things:
made sure sqlite3 library is added in the make file
source code is in strictly in C by using directive : extern "C" to avoid name mangling as the file extension is .cpp. I also tried with .c extension.
given the absolute path of the libudf.so in qdb.cfg as : Function = udftag#/usr/lib/libudf.so
qdb_funcion struct is properly defined in library's source code only.
tried without using the static declaration of function(mentioned in the qdb docs)
After trying all hits and trials also, I am getting the same error every time which is Can't access shared library
If any one has any idea to resolve this error please share.
Suggestion 1: run qdb by setting LD_DEBUG=1, like in:
LD_DEBUG=1 qdb command line options
This will output a lot of debug information from the dynamic loader as it attempts to locate and then load the .so files. Check what is the path that it output before the "Can't access" message is displayed.
Suggestion 2: obvious but make sure that the permissions are OK for the .so file. Do you have the execution permission set?
Suggestion 3: check if the error message is identical if you completely remove the .so file from the system
Suggestion 4: increase the number of lower-case 'v'-s. QDB likely supports more, with progressively more verbose information provided as you increase the numbers (6 should be enough for full verbosity)

Providing input files during compilation

To run a CUDA C program we build the program and then run the binary file created from the command line as
/.prgm_bin_file
If for example the program needs some input files like for programs to image processing, I want to supply the data files or the input files at the time of compilation.
How can I do that. How the above command can be edited to give the required files.
Thanks in advance.
If your program opens data files to use for input, it's using some file I/O API to do so. For example, one possible method is to use fopen.
Just to use it as an example, if you are using fopen, it expects a filename (a character string) passed as the first parameter.
Many programs will take this filename from a the command line used to invoke the program. But there's nothing that would prevent you from hard-coding the filename:
fp=fopen("mydata", "r");
In that case, the program would always attempt to open the file mydata
But if your program is already designed to use the filename as a command line parameter, it's not clear that this is any more useful than just invoking your program that way:
./prgm_bin_file mydata

FORTRAN input from mouse

What is the FORTRAN input statement (e.g., READ statement, or OPEN statement) to accept input from a mouse? For example, in Windows explorer, it is possible to right-click on a file and then select a FORTRAN executable from the menu that appears. How do I make such a FORTRAN program capture whatever the mouse sends (e.g., capture the name of the file, or whatever the mouse transmits)? Information out there about FORTRAN input seems restricted to input from a file or the keyboard. I cannot find anything about input from a mouse.
I've made progress on my own and, for those interested, here it is:
Firstly, the "fortran standard" does not directly support input from a mouse. But Windows Explorer can be made to pipe a file name into a fortran executable nevetheless.
Under Windows, the right-click generates the full \path\filename as a command line argument. That information can be captured by a fortran using "get_command_argument", as follows:
PROGRAM get_filename
CHARACTER(len=100) :: arg
CHARACTER(len=2000) :: filename
filename = ''
! NB: spaces in a file name define separate arguments, so re-assemble the file name as it comes in
i = 1
DO
CALL get_command_argument(i, arg)
IF (LEN_TRIM(arg) == 0) EXIT
filename = TRIM(filename)//' '//TRIM(arg) ! putting the spaces back in
i = i+1
END DO
WRITE (*,*) 'file= ',TRIM(filename)
read(*,*)
END PROGRAM
A link to the executable can be placed in the Windows right-click menu, as explained here:
http://www.howtogeek.com/107965/how-to-add-any-application-shortcut-to-windows-explorers-context-menu/
You need to add "%1" to the name of the executable to make it accept command line arguments,
e.g., I called my executable "PW_copy.exe", and so the final registry entry was: \path\PW_copy.exe %1
It works!
Dragging the mouse across several files generates separate threads each with a different file name.

ActiveTCL - Unable to run a batch file from an Expect Script

I was originally trying to run an executable (tftpd32.exe) from Expect with the following command, but for some unknown reason it would hanged the entire script:
exec c:/tftpd32.351/tftpd32.exe
So, decided to call a batch file that will start the executable.
I tried to call the batch file with the following command, but get an error message stating windows cannot find the file.
exec c:/tftpd32.351/start_tftp.bat
I also tried the following, but it does not start the executable:
spwan cmd.exe /c c:/tftpd32.351/start_tftp.bat
The batch file contains this and it run ok when I double click on it:
start tftpd32.exe
Any help would be very much appreciated.
Thanks
The right way to run that program from Tcl is to do:
set tftpd "c:/tftpd32.351/tftpd32.exe"
exec {*}[auto_execok start] "" [file nativename $tftpd]
Note that you should always have that extra empty argument when using start (due to the weird way that start works; it has an optional string in quotes that specifies the window title to create, but it tends to misinterpret the first quoted string as that even if that leaves it with no mandatory arguments) and you need to use the native system name of the executable to run, hence the file nativename.
If you've got an older version of Tcl inside your expect program (8.4 or before) you'd do this instead:
set tftpd "c:/tftpd32.351/tftpd32.exe"
eval exec [auto_execok start] [list "" [file nativename $tftpd]]
The list command in that weird eval exec construction adds some necessary quoting that you'd have trouble generating otherwise. Use it exactly as above or you'll get very strange errors. (Or upgrade to something where you don't need nearly as much code gymnastics; the {*} syntax was added for a good reason!)