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 shotCode: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.
Last edited by CornedBee; 10-12-2007 at 02:21 AM.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
That clears some stuff up, Mr. CornedBee to the rescue
"When your work speaks for itself - don't interrupt!"
-Samantha Ingraham.
Why would it have such a limitation? You can run a GUI program from the command prompt, right? So why should system() not be able to?Originally Posted by histevenk
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".
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
