In a console based application, how do you run a new program without closing the original. For example I open a console version of microsofts "run". The program opens the new program you type in.
Printable View
In a console based application, how do you run a new program without closing the original. For example I open a console version of microsofts "run". The program opens the new program you type in.
You mean like the system() call?
No, I mean, in a program you could have something like
and the other program would appear on the screen.Code:open(a_different_program.exe);
Correct me if I'm wrong, but I'm pretty sure that's what the system() call does... if you want a console application to open in a new window, you'll have to do something like pass cmd.exe the name of the console application as an argument.
Could you give me an example.
I thought system could only be used toaccess things like "ping" that are commonly used in command prompt. I also read elsewere on this forum that system(); isn't a good command to use.
I think you may be wanting ShellExecute(), which to my knowledge is similar to system()? I don't quite know, however I do know you can do this:
To my knowledge, again which may be wrong, system() echos as if you went to start->run->cmd and you typed the text in. ( Which can probably open a new process too, if that's what you are wanting )Code:#include <windows.h> // ShellExecute()
...
// The below line will open your homepage in Firefox if it's installed
ShellExecute(NULL, "open", "C:\\Program Files\\Mozilla Firefox\\firefox.exe", NULL, NULL, NULL);
...
Also, if you are wanting to create a process and control it, that's a whooooooooole nother story.
Whilst system() is the most portable (although not very portable), it is also the least safe.
http://faq.cprogramming.com/cgi-bin/...&id=1043284392
I didn't get an error, but I also didn't get any effect from the shell execute(); command.
Can you post the code you used the ShellExecute with?
>I also read elsewere on this forum that system(); isn't a good command to use.
system() is a perfectly good function to use. It's bad when it's misused (for example, using it to call things like "pause" when you can simply use getchar() ).
>To my knowledge, again which may be wrong, system() echos as if you went to start->run->cmd and you typed the text in.
It's been awhile since I used Windows, but I'm pretty sure that typing a Win32 program at the prompt will open it the way it's supposed to execute, but then again, I could be wrong. I know this works on Mac and Linux.
Code:
ShellExecute(NULL, "open", "1.exe", NULL, NULL, NULL);
You should change "1.exe" to the path of 1.exe. For example, if 1.exe resided in C:\ you would need to use:
Code:ShellExecute(NULL, "open", "C:\\1.exe", NULL, NULL, NULL);
The program is still not opening and I get the following errorCode:
ShellExecute(NULL, "open", "C:\\Dev-Cpp\\me\\1.exe", NULL, NULL, NULL);
196
C:\Dev-Cpp\Me\dos.cpp
[Warning] passing NULL used for non-pointer converting 6 of `HINSTANCE__* ShellExecuteA(HWND__*, const CHAR*, const CHAR*, const CHAR*, const CHAR*, INT)'
Maybe it's different on Dev-Cpp? I don't know why it would be, but I don't get the warning and it works just fine when I use it.
Maybe you need to use:
I am going off a crazy hunch here, so it's probably wrong but maybe worth a shot :oCode:ShellExecute(NULL, "open", "C:\\Dev-Cpp\\me\\1.exe", NULL, NULL, SW_SHOW);
IT WORKED!
Thank you.
Hm...that makes me question weather or not MSVC++ automatically changes NULL to SW_SHOW or if I have even more questionable knowledge of the function then I previously thought...Many hours may be spent on this debate. /thinking cap
Dev-C++ is the only compiler I ever used So I can't answer Your question.
How portable is ShellExecute()?
Hm, that's a good question. It's defined in <windows.h> so probably only across Windows Platforms, but maybe other OS's have their own version of the function? If they do, I do not know if it's the same function name and parameters, or if it is with another file header.
I guess you should know that my overall project is an entire operating system. Thats why I need this command so that other programs can spawn off of mine. Probably the most difficult part is trying to make something that has no ties to anything else. That includes trying to make my own type of "window" without using the windows header (don't worry about that now.). This is why I need to know if it's portable because if not, then it's back to the drawing board.
And yes I know it's a big goal.
Well then if that's your goal, it's back to the drawing board. If you want to know if you can use it, msdn.microsoft.com, look up the function on that site and if it says "requires whatever" such as windows.h or kernal32.dll it's offlimits.
SW_SHOW is a constant with the value 0.
NULL is typically defined as 0.
Thus it appears to work.
But not under GCC (Dev-C++'s compiler), which has a keyword __nullptr (or something like that) which is used instead of 0 for NULL.
ShellExecute is a Win32 function. It is not portable to anything but the Win32 API.
hstevenk, if you want to write an OS, you have to work under the rules of a "freestanding C++ implementation". In other words, absolutely nothing is portable. Your code is specific to the platform you write it for, which is in fact the platform you're writing. You can't rely on anything. You can't rely on any C or C++ library functionality to be available - in fact, part of implementing an OS is writing your own C and C++ libraries, or at least porting an existing one.
And when I say not anything, I mean that. You can't call malloc() until you've implemented malloc() yourself. You can't use new until you've implemented operator new (or use an implementation that calls malloc().) You can't throw exceptions until you've decided on an ABI and implemented an exception handling mechanism. Oh, and part of that is porting the compiler so that it emits code that fits your new platform. I suggest porting GCC, since it's pretty much the only one where the source is available.
Of course, you may be able to reuse lots of open source code, use existing standards to code against (e.g. the ELF binary format, DWARF2 debugging and exception handling information, the POSIX system API etc.). It will save you a lot of work in the area of specifying, and it will make porting of the various tools far easier. Nevertheless, you still need to do the porting, you still need to pick the specs to code against.
That clears some stuff up, Mr. CornedBee to the rescue :D
Thanks everyone.
I know I am being a bit questioning but I have another question for you. How would I go about creating my own library.
Start a new thread for new topics. Also, be more elaborate on what you want to do, because there are many things you could call "creating my own library".