On Tue, Apr 10, 2012 at 2:46 PM, Mikael mikael.rcv@gmail.com wrote:
Dear REPLeffect,
Windows EXE:s are hardwired to either be console or UI apps.
^ I'm well aware of that. Perhaps you missed the earlier message where I said this:
After adding the ___LIBRARY define, the application ran fine when compiled as a non-console windows app. I even checked the portable executable header of the executable to confirm that it was using the "windows" subsystem (as opposed to "console") -- which it was.
The portable executable header in Windows applications has a "Subsystem" field in it that determines whether an app is a console app or a standard windows GUI app.
Here's an article discussing the PE header, for anyone who is interested.
http://msdn.microsoft.com/en-us/library/ms809762.aspx
By default, Gambit produces EXE:s that are console apps.
^^ That should be true of applications compiled and linked using gsc (as Marc pointed out in the message to you that he quoted in his first response to this thread). However, as you might guess from the above quote from my previous post, I'm compiling and linking modules separately. I'm embedding Gambit Scheme in a C++ executable (initializing a ___setup_params_struct structure, then calling ___setup, etc). My final link is actually being done by a qmake-generated makefile, and the windows subsystem is being set by the link performed from there. I'd already dealt with the subsystem change before posting my original question.
UI app means, don't create a console window unless any console IO is made by the app, and if that is made, then a _new_ console window is opened.
Console app means, that if the app is executed within a console already, then it'll use that console, and if it's not, a new console will be created for it.
At this point I'm sure you realize that I already knew the difference between console and non-console apps in Windows (as well as the fact that standard GUI apps have the ability to create a console).
When I asked the original question, I was more wondering how much Gambit had been used for GUI applications which did not have a console at all -- that is, "windows" subsystem apps which also don't create a console separately (as they can, with AllocConsole, but obviously most GUI apps usually don't).
I probably should not have brought up the discussion about WinMain the way I did -- it is a separate piece of the puzzle, and I probably confused the issue by doing so. Then again, it was related to the problem of missing ___LIBRARY defines in one place in my build, so I guess I'm glad I brought it up anyway. :-D
This is how Windows is hardwired as regards console windows.
To see how to produce an UI app, which is what you want, see the "How to build GUI apps for Win32 " section at http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Compiling_Gambit_softw...
It summarizes as: The key recipe in here is to pass -D_WINDOWS to cl.exe, and /subsystem:windows to link.exe .
Was this of help to you?
The wiki entry is a good link to point to when discussing this, just a little late in the conversation (since both the subsystem and the _WINDOWS macro have already been discussed) :-D
Also, as I mentioned in the original post, I'm not using Visual C++, I'm compiling with g++ under MinGW. For g++ you have to add the subsystem selection to the link flags like this:
-Wl,-subsystem,windows
For now I'll probably just stick with the CreateProcess solution, and look for something more elegant at a later date. Would be nice if AllocConsole in a GUI app allowed you to create the console hidden, but its obvious that the use case I'm looking for isn't something that Microsoft was trying to provide when they designed the console API.