[gambit-list] Gambit on Windows with no console window

REPLeffect repleffect at gmail.com
Tue Apr 10 18:28:45 EDT 2012


On Tue, Apr 10, 2012 at 2:46 PM, Mikael <mikael.rcv at 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_software_for_different_target_environments
>
>
> 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.



More information about the Gambit-list mailing list