I have an application which supports out-of-process COM automation. Now, I want it to be able to behave differently when it is launched by user and when it is started by COM to serve an automation request. How can I distinguish these cases from within the application?
Googling has brought me nothing, and the only idea I have so far is to determine the parent process, but I'm not sure how fragile it would be.
When COM launches local out-of-process server, it looks up registry for the hosting process path and appends "-Embedding" command line parameter. This is where you are supposed to look at to, respectively, detect COM launch.
The behavior is documented here:
COM appends the "-Embedding" flag to the string, so the application that uses flags needs to parse the whole string and check for the -Embedding flag.
Related
I currently have a resource light "unmanaged" Windows C++ application using:
CreateMutex to ensure there is at most a single instance of the application.
COPYDATASTRUCT to pass command line parameters over to that single instance, should another instance attempt to start (after sending data, it will then quit).
The use case is a simple one: launch a new application instance to open a file specified on the command line, or otherwise open the file in a previously-launched application instance.
How could I achieve the same behaviour in a Haskell program?
It looks like CreateMutex isn't offered in the Win32 package that comes with GHC. You'll need to either bind to it yourself using the FFI or emulate it in a cross-platform way. One trick commonly used on Linux is to choose a particular filename to act as the "mutex"; if it doesn't exist, you create it and write down how to contact you then delete it when you exit, while if it does, you read the contact information out of it to find out how to connect to the already running process. This approach does have downsides: if either your app or the computer as a whole goes down, you'll have stale contact information.
For IPC, I think there's a number of cross-platform interfaces. Wikipedia has an excellent list; especially suitable for doing this task in Haskell are sockets, (named) pipes, and dbus. For the latter two, you may need Cygwin, since they ultimately depend on getting the unix package installed.
We have an application that we have built as a bundle and we want to launch it from another process.
How should we do it?
From what I understand we can use openUrls(), openFile() or execve()
but I don't know which one better suits us.
Thanks
Since you're talking about an application, you don't want to go through the file association mechanisms. They're for opening documents, images etc. with an appropriate application. Since you don't seem to be sure what to ask, I'd say keep it simple:
The exec* family launches an executable directly. But note that it replaces the launching process with the launched application. Your launcher will stop executing at that point. If you want the launcher to continue to run, you want to use something that launches a subprocess. The low-level way is fork/vfork followed by exec, but it's far simpler to launch your app with system, which takes care of all that behind the scenes. (Assuming there are no security concerns about users on the other side of the world injecting execution paths).
If the launcher does not terminate as soon as it launches your app, you'll want to think about whether it "blocks" until the launched application terminates, or whether it launches the app asynchronously-- so that they then run in parallel. The launcher might also "wait" for the return value of the app, to check whether it succeeded and maybe do something afterwards. There are ways to do all that, but since we don't know what you need, I won't go into details.
In short: If the only job of your launcher is to start your app, use execl. If your launcher needs to do more, use system. If neither one quite fits your needs, you'll need to provide more information-- starting with the language your launcher is written in.
PS. Both of these have the advantage of generality and portability. They work for GUI and commandline applications, and they'll work on any Unix-like system, and to some extent on Windows. There's no need to lock yourself into Cocoa for something so simple.
If you're using Cocoa, you can use NSWorkspace's -launchApplication:.
From OSX documentation on NSWorkspaces:
openFile: Opens the specified file specified using the default application associated with its type.
openURL: Opens the location at the specified URL.
With url you can open also file on ftp, or http for example.
I want to be able to detect whether a given exe was shellex'd programmatically or if it was entered and executed interactively in, say, CMD.EXE.
Is there anything about the way an exe is launched that indicates the mechanism that was used to launch it?
Context: Windows XP, Visual Studio 6 languages.
There might be an easier way, but the only way I can think of is to check the parent process name, which involves a few steps:
Get the ID of the parent process.
Get the handle of the process, using the ID.
Use GetModuleFileNameEx with the handle found (and NULL as the module) to get the executable's name.
Check if the executable's name is cmd.exe or whatever.
Bear in mind that the parent process might already be gone when (or while) you do this check.
Edit:
If your program is a console application, you can also check the console it's running in. If it was run from cmd, it will usually use the same console. So, you can use GetConsoleTitle, for instance, and see if it's "Command Prompt". This might not work on localized or different versions of Windows, but it's easy if you have limitated cases. You can also use GetConsoleWindow and GetWindowThreadProcessId instead of steps 1 and 2.
You can differ between say CMD and Explorer by inspecting the parent process, but you can't tell if it happened due to user action or not. Also AFAIK all ways to launch a process result in the same NtCreateProcess/PspCreateProcess call, so you can't tell which API was used either.
I am porting an application which runs as a background service in windows at startup, we are porting the application to linux(SUSE Enterprise server), I'am completely new to linux. Can somebody help me on how to proceed with this. Like
Should I build the linux executable
After builiding the binary, what changes should I make to linux startup files to run this executable
How my service can register call back function to modify or change or send commands to my service while it is running
Yes, you should build a Linux binary. You may want to rephrase your question since I doubt this is the answer you want :-)
You should generally create what is known as an "init" file, which lives in /etc/init.d. Novell has a guide online which you can use to author the file. Note that while the init file is common, the exact method of letting the operating system use it varies depending on the distribution.
This is going to be a marked change for you. If you are doing simple actions such as re-loading a configuration file, you can use the signals functionality, especially the SIGHUP/HUP signal which is generally used for this purpose. If you require extended communication with your daemon, you can use a UNIX domain socket (think of it as a named pipe) or a network socket.
Another task you are going to need to accomplish is to daemonize your application. Generally this is done by first fork()ing your process, then redirecting the stdin/stdout pipes in the child. There are more details which can be answered by reading this document
See how-to-migrate-a-net-windows-service-application-to-linux-using-mono.
Under Linux, deamons are simple background processes. No special control methods (e.g start(), stop()) are used as in Windows. Build your service as a simple (console) application, and run it in the background. You can use a tool like daemonize to run a program as a Unix daemon.
I need to find out exactly what files/directories a Lua program uses so I can try to only pack what it needs into a ZIP file, and come up with a simple way to deploy this script.
I used SysInternals' Process Monitor, but I'm surprised by the small amount of information it returned while it watched the program (For Lua users out there, it's wsapi.exe, which is the launcher for the light-weight Xavante web server).
Does someone know of a good Windows application that can completely monitor what a program does, eg. something like a live version of the venerable PCMag's InCtrl5.
Thank you.
Process monitor will catch everything. If it's not catching the action then it must be happening in a different process. Try filtering based on the files you expect to be used rather than the process you expect it to happen in.