Is there a way to execute another program, such as notepad, as a thread so it shares the same memory space as my program? So if my program ends, so will notepad and so that notepad won't show up in task manager, just my program?
+2
A:
No, certainly not for a non-managed app like notepad.
For a managed app, however, you can load the assembly using the utilities in System.Reflection and begin execution of the Main() method (or, rather entrypoint).
However, there are a few features in the System.Process class that can help you emulate what you are looking to do.
John Gietzen
2010-07-02 21:37:34
+1
A:
No. This would be a very bad idea, in any case, as it would potentially cause all sorts of nasty things to occur. The other program would have no way of knowing what it should initialize and what was already initialized by the hosting program, etc.
You can, however, force notepad to close with your program. Just call Process.CloseMainWindow (nice) or Process.Kill (force it to die) on the process you create when your application shuts down.
Reed Copsey
2010-07-02 21:38:19
+1
A:
No, this is not possible (barring you trying to do some odd, virtualization style environment within a single process.)
To ensure that notepad dies with your app, create a job object, assign your app to it before launching notepad. When your program closes, the job object will be destroyed and all child processes in the job object will also be closed.
Michael
2010-07-02 21:38:38
+1
A:
Theoretically, you could do the same job the OS loader does - load the executable, find the main entry point and call into it from your thread.
Note that you most probably will run in all sorts of app-compat problems, as the code in that executable does not expect it to be executed in this way.
Franci Penov
2010-07-02 21:39:38
This won't work for lots of cases - there's lots of process wide infomration that would need to be partitioned. Even something as simple as calling GetModuleHandle(NULL) or GetCommandLine() would return the wrong results.
Michael
2010-07-02 21:41:55
Loading the executable and running it _will_ work. As I said though, what happens _after_ that is undefined. :-)
Franci Penov
2010-07-02 21:43:20
You have an interesting definition of work :) It wouldn't even make it to the program's entry point - look at the source code WinMainCrtStartup or __mainCRTSTtrtup. Many of the API calls would not work correctly.
Michael
2010-07-02 21:47:34
By "work" I mean it'll start executing. Notice I did not say "work _correctly_". :-)
Franci Penov
2010-07-02 22:45:01
just for the fun of it I actually did look at the source code for `__tmainCRTStartup` and while I don't see much that actually necessarily need to fail, I also don't see much issues with skipping that one and calling straight `WinMain`/`wWinMain` (for windowed apps) or `main`/`wmain` (for console apps). the CRT was most probably already initialized by the host process, so why not just straight into the process-specific code?
Franci Penov
2010-07-02 22:53:59
note that the OP did not ask for "virtual process" isolation or partitioning, he just asked if it's possible to execute the code on one of his own threads instead of starting new process. :-)
Franci Penov
2010-07-02 22:55:09