Main Executable runs Launcher Executable and then Launcher runs Main Executable - delphi-2007

I have two .exe programs, one is the game launcher and the other is the main executable. How would i go about making my main executable run the game launcher if someone goes to open it. It would be something to do with the .dpr file and some Windows API's i am guessing just not sure what/where to start to be honest.
Reason i want it like this is simply because, the game launcher will be used to update the game and then when complete start the game thus people will always be using the latest up2date files.
So the functionality i would like too require is:
I can click on Main Executable or Launcher Executable both will open Launcher Executable and then when updates / downloads are complete Launcher will start Main Executable when the user has clicked Start button.
/Thanks

Have the main executables startup code look for a command-line parameter of your choosing. You can use the RTL's FindCmdLineSwitch() function for that purpose. If the parameter exists, run the game normally. Otherwise, use the Win32 CreateProcess() function to run the launcher executable and then exit itself. When the launcher is ready, it can use the CreateProcess() function to run the main executable, passing it the command line parameter to run the game.
For example:
Main.dpr:
Var
SI: TStrartupInfo;
PI: TProcessInformation;
Begin
If not FindCmdLineSwitch('RunGameNow') then
Begin
ZeroMemory(#SI, SizeOf(SI));
SI.cbSize := SizeOf(SI);
...
If CreateProcess(nil, 'launcher.exe', nil, nil, False, 0, nil, nil, #SI, #PI) then
Begin
CloseHandle(PI.hThread);
CloseHandle(PI.hProcess);
End;
Exit;
End;
... Run game normally...
End.
Launcher.dpr:
Begin
...
CreateProcess(nil, 'main.exe /RunGameNow', nil, nil, False, 0, nil, nil, #SI, #PI)
...
End.

Related

Why does my program work fine by running it directly but not as a service? Linux C

Goodday guys,
I am trying to build and run program in linux (raspberry) as a service.
It is a sample application that uses the Cerence SDK C API that implements a wake-up-word (WUW) plus command utterance recognition.
I can execute it by ./name.exe or using the Makefile commands.
The problem is that when I execute the program by console it works fine, without any problem.
When I try to execute it as a service (using both systemd or crontab and also rc.local), an error occours.
This is the function that gives me error:
printf("Selecting audio configuration %s\n", audioScenarioName);
rc = nuance_audio_IAudioManager_activateScenario(audioMgr, audioScenarioName);
if (NUANCE_COMMON_OK != rc) {
printf("Audio scenario activation failed: %d\n", rc); <-- returns 1 (error, impossible to activate scenario)
return rc;
}
ActivateScenario it's a function that simply selects the correct mic (audioScenarioName) following a JSON file and the audio manager (audioMgr).
Unfortunately this function returns 1 if something goes wrong, closes the program and nothing else.
This is the JSON:
"type": "AudioInput",
"name": "mic_input",
"adapter_type": "CUSTOM_AUDIO",
"adapter_params": {
"device_name": "default"
},
"audio_format": { "uses": "16khz_1ch" }
The service should be running as root permissions (default).
I also tried by setting the whole folder as chmod -R 777 as a test, but same problem.
This is my service:
[Unit]
Description=My Service
[Service]
Type=simple
ExecStart=+/home/pi/.../nameexec
Restart=on-failure
RestartSec=5
KillMode=process
[Install]
WantedBy=multi-user.target
I've also set the absolute path of its lib directory that it needs into the ld.so.conf file.
The only libraries I put in it are the .so ones, but not .h.
I am now trying to understand what might be different about starting the same executable but in different ways.
Could it be a permissions issue? Or is it not detecting the microphone? Any library out of place?
I really don't know why it works with the classic command and not as a service.
Can someone please help me with this?
Thank you in advance!
I succeeded!
The problem was the microphone being used.
Using Raspbian ver. Desktop, I set the mic from the bottom right part of the taskbar and changed the defaults in/out.
But these settings seem to be not system-wide and not used by the services in background (even though the "User=" is set to "pi").
So I had to change alsa.conf file:
sudo nano /usr/share/alsa/alsa.conf
Then find and edit these lines:
defaults.ctl.card cardnumber
defaults.pcm.card cardnumber
You can find the card number by running arecord -l.

Launch interactive session via script bridge

I am trying to launch an interactive debugging session from a python script via the SWIG-generated lldb module. The program to debug is nothing but an empty main function. Here is my current attempt:
import lldb
import sys
import os
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(False)
target = debugger.CreateTargetWithFileAndArch("a.out", "")
# The breakpoint itself works fine:
fileSpec = lldb.SBFileSpecList()
mainBp = target.BreakpointCreateByName("main", 4, fileSpec, fileSpec)
mainBp.SetAutoContinue(False)
# Use the current terminal for IO
stdout = os.ttyname(sys.stdout.fileno())
stdin = os.ttyname(sys.stdin.fileno())
stderr = os.ttyname(sys.stderr.fileno())
flag = lldb.eLaunchFlagNone
target.Launch(target.GetDebugger().GetListener(), [], [], stdin, stdout,
stderr, os.getcwd(), flag, False, lldb.SBError())
It seems to me that whatever flag I pass to target.Launch (I tried amongst those flags), there is no way of switching to an interactive editline session. I do understand that the primary purpose of the python bindings is non-interactive scripting, but I am nevertheless curious whether this scenario could be made possible.
There is a method on SBDebugger to do this (RunCommandInterpreter). That's how Xcode & similar make lldb console windows. But so far it's only been used from C and there's something wrong with the C++ -> Python bindings for this function such that when you try to call it from Python you get a weird error about the 5th argument being of the wrong type. The argument is an int& and that gives SWIG (the interface generator) errors at runtime.
Of course, you could just start reading from STDIN after launch and every time you get a complete line pass it to "SBCommandInterpreter::HandleCommand". But getting RunCommandInterpreter working is the preferable solution.

How to debug cgi program written in C and running in Apache2?

I have a complex cgi executable written in C, I configured in Apache2 and now it is running succesfully. How can I debug this program in the source code, such as set break points and inspect variables? Any tools like gdb or eclipse? Any tutorial of how to set up the debugging environment?
Thanks in advance!!
The CGI interface basically consists in passing the HTTP request to the executable's standard input and getting the response on the standard output. Therefore you can write test requests to files and manually execute your CGI without having to use Apache. The debugging can then be done with GDB :
gdb ./my_cgi
>> break some_func
>> run < my_req.txt
with my_req.txt containing the full request:
GET /some/func HTTP/1.0
Host: myhost
If you absolutely need the CGI to be run by Apache it may become tricky to attach GDB to the right process. You can for example configure Apache to have only one worker process, attach to it with gdb -p and use set follow-fork-mode child to make sure it switches to the CGI process when a request arrives.
I did this: in cgi main i added code to look for an existing file, like /var/tmp/flag. While existing, i run in a loop. Time enough to attach to cgi process via gdb. After then i delete /var/tmp/flag and from now I can debug my cgi code.
bool file_exists(const char *filename)
{
ifstream ifile(filename);
return ifile;
}
int cgiMain()
{
while (file_exists ("/var/tmp/flag"))
sleep (1);
...
your code
Unless FastCGI or SCGI is used, the CGI process is short-lived and you need to delay its exit to have enough time to attach the debugger while the process is still running. For casual debugging the easiest option is to simply use sleep() in an endless loop at the breakpoint location and exit the loop with the debugger once it is attached to the program.
Here's a small example CGI program:
#include <stdio.h>
#include <unistd.h>
void wait_for_gdb_to_attach() {
int is_waiting = 1;
while (is_waiting) {
sleep(1); // sleep for 1 second
}
}
int main(void) {
wait_for_gdb_to_attach();
printf("Content-Type: text/plain;charset=us-ascii\n\n");
printf("Hello!");
return 0;
}
Suppose it is compiled into cgi-debugging-example, this is how you would attach the debugger once the application enters the endless loop:
sudo cgdb cgi-debugging-example $(pgrep cgi-debugging)
Next you need to exit the infinite loop and wait_for_gdb_to_attach() function to reach the "breakpoint" in your application. The trick here is to step out of sleep functions until you reach wait_for_gdb_to_attach() and set the value of the variable is_waiting with the debugger so that while (is_waiting) exits:
(gdb) finish
Run till exit from 0x8a0920 __nanosleep_nocancel () at syscall-template.S:81
0x8a07d4 in __sleep (seconds=0) at sleep.c:137
(gdb) finish
Run till exit from 0x8a07d4 in __sleep (seconds=0) at sleep.c:137
wait_for_gdb_to_attach () at cgi-debugging-example.c:6
Value returned is $1 = 0
(gdb) set is_waiting = 0 # <<<<<< to exit while
(gdb) finish
Run till exit from wait_for_gdb_to_attach () cgi-debugging-example.c:6
main () at cgi-debugging-example.c:13
Once you are out of wait_for_gdb_to_attach(), you can continue debugging the program or let it run to completion.
Full example with detailed instructions here.
I'm not sure how to use gdb or other frontends in eclipse, but I just debugged my CGI program with gdb. I'd like to share something that other answers didn't mention, that CGIs usually need to read request meta-variables defined in RFC 3875#4.1 with getenv(3). Popular request variables in my mind are:
SCRIPT_NAME
QUERY_STRING
CONTENT_LENGTH
CONTENT_TYPE
REMOTE_ADDR
There variables are provided by http servers such as Apache. When debugging with gdb, we need to set these values by our own with set environment. In my case, there're only a few variables neededa(and the source code is very old, it still uses SCRIPT_URL instead of SCRIPT_NAME), so here's my example:
gdb cgi_name
set environment SCRIPT_URL /path/to/sub/cgis
set environment QUERY_STRING p1=v1&p2=v2
break foo.c:42
run
For me both solutions for debugging the CGI in gdb without web server presented above didn't work.
Maybe the second solution works for a GET Request.
I needed a combination of both, first setting the environment variables from rfc3875 (not sure if all of them are really neded).
Then I was able to pass only the params (not the compltete request) via STDIN from a file.
gdb cgi_name
set environment REQUEST_METHOD=POST
set environment CONTENT_LENGTH=1337
set environment CONTENT_TYPE=application/json
set environment SCRIPT_NAME=my.cgi
set environment REMOTE_ADDR=127.0.0.1
run < ./params.txt
With params.txt:
{"user":"admin","pass":"admin"}

statically compile an android program

i'm trying to write something into the dmesg log before /system being mounted.
my trouble is that for write into dmesg ( on android ) i need to use the android-specific stuff, not just my usually crossdev arm system.
just:
__android_log_print(ANDROID_LOG_DEBUG, "libnav", "DEBUG - custom program started");
all fine if you compile it as follow ( i make a standalone toolchain in /var/tmp/android ):
arm-linux-androideabi-gcc --sysroot /var/tmp/android/sysroot -llog -o custom_program custom_program.c
BUT the above command will build a dynamically linked executable, which will run fine if system is yet booted up.
"easy, just compile it statically!" i thought.
the android ndk comes with some libs but the liblog is only liblog.so, not liblog.a, so how can i log something in dmesg before /system beign mounted ?
thanks in advance.
Using arm-unknown-gnueabi-gcc and
fopen the /dev/kmsg and fprintf on the FILE * returned by fopen.
running the program while android is running will write into dmesg, but not if in early boot process. why?
#auselen
i yet have modified init to startup this static program:
init.rc snippet
on post-fs-data
write /dev/kmsg "launching test"
exec /data/test
all i see in dmesg is this...
<4>[ 6.336816] launching test
<6>[ 6.336902] init: command 'write' r=0
<6>[ 6.337115] init: command 'exec' r=-1
here you are the executable source code: http://pastebin.com/Hym1APWx

How Do I Compile a C Program to Run Without a Command Box?

I need a very simple program to run on any version of Windows, let's say >= Win 98, without requiring any pre-installed framework like dotnet. I thought C would be a great idea to do this.
The program should start a process from the parent directory by using a system command.
Start C program (invisible) > program starts process > program exits
This is how it looks:
#include <stdio.h>
#include <stdlib.h>
int main() {
system("..\\someprogram.exe");
return 0;
}
I call this program from a Flash projector, which only allows to start programs in a specific subfolder "fscommand" – but I have to start a process located in the same directory as the projector.
Anyway, it works fine! But the C program opens a command box, then starts the process and leaves the command box open as long as the process runs. So here is how it should work, in order how i would appreciate it:
Do not open a command box at all (I'd like that, really ;)
Both 3) and 4)
Close the command box after starting the process (exit the C program)
Open the command box minimized by default
I can't change any Windows settings for the C executable or use a shortcut, as this will run directly from a CD later.
I use Open Watcom to compile my program. Both image types (target options) that produce an executable (Character-mode Executable / Windowed Executable) have the same result.
I did a google search and found http://www.ntwind.com/software/utilities/hstart.html
Your using a console app, you could change it to a windows app using winmain()
You can use a shortcut to a file in the same folder, not sure why your discounting that method.
start will give you a fork so your intermediate app can close - not sure about win98 tho.
system("start ..\\someprogram.exe");
Instead of system you can use createProcess to launch the app, theis will avoid the system commands console.
STARTUPINFO si;
PROCESS_INFORMATION pi;
ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( &pi, sizeof(pi) );
// Start the child process.
if( !CreateProcess( "..\\someprogram.exe", // module name
NULL, // Command line
NULL, // Process handle not inheritable
NULL, // Thread handle not inheritable
FALSE, // Set handle inheritance to FALSE
0, // No creation flags
NULL, // Use parent's environment block
NULL, // Use parent's starting directory
&si, // Pointer to STARTUPINFO structure
&pi ) // Pointer to PROCESS_INFORMATION structure
)
{
printf( "CreateProcess failed (%d).\n", GetLastError() );
return;
}
// Wait until child process exits. In your case you don't care to wait anyway
// WaitForSingleObject( pi.hProcess, INFINITE );
// Close process and thread handles.
CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );
The console window shows up because you built your program as a console application. I don't know how to avoid that in C, but in Delphi is was a simple {$Console Off} pragma in the project file.
GCC has a command line option -mwindows, which I think achieves the same, so you could search into this direction.
I think the _exec and/or _spawn functions do what you need, though I'm not sure.
If not, you can always use CreateProcess, though it can be a little more tedious in some ways.
You could (for example) use hstart instead of your own program to start that exe.
(This would result in no black box at all.)
CreateProcess with CREATE_NO_WINDOW flag is what you want, but I want to add something. To support also cmd style commands (such as DIR, SET, ... ) which have no executables and can't be passed to CreateProcess alone, you should call cmd.exe /C someprogram where someprogram is name of executable, bat file, or command.
A friend came up with a completely different solution. Now I use AutoIt with a short compiled script to start the process. This is very simple and the launcher process is completely invisible. :)
filename = ..\someprogram.exe
if FileExist(filename) {
Run, open %filename%
}

Resources