Dear REPLeffect,
Windows EXE:s are hardwired to either be console or UI apps.
By default, Gambit produces EXE:s that are console apps.
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.
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?
Kind regards, Mikael
Den 10 april 2012 22:42 skrev REPLeffect repleffect@gmail.com:
On Tue, Apr 10, 2012 at 2:13 PM, REPLeffect repleffect@gmail.com wrote:
On Mon, Apr 9, 2012 at 12:52 PM, Marc Feeley feeley@iro.umontreal.ca
wrote:
On 2012-04-09, at 12:59 PM, REPLeffect wrote:
On Mon, Apr 9, 2012 at 9:16 AM, Marc Feeley feeley@iro.umontreal.ca
wrote:
On 2012-04-09, at 9:44 AM, REPLeffect wrote:
So I'm wondering -- has Gambit ever been tested to work without the console window? I know you can hide it when calling the process-related procedures, but I couldn't find anything in the documentation or on the mailing list about the main app not having a console.
It is clearly possible, for example the Jedi IDE for JazzScheme is a
window application written with Gambit. Perhaps looking at the Jedi sources will give you some ideas.
Also, here's an old message to the Gambit ML which seems related :
https://mercure.iro.umontreal.ca/pipermail/gambit-list/2011-March/004939.htm...
Finally, I sent a private message on this subject which I should have
CC'd to the Gambit ML. It is copied below.
Let me know if you need more assistance.
Marc
[snip]
Thank you, Marc. That was very helpful. Turns out, I was not defining ___LIBRARY while compiling one of my scheme modules, nor when compiling at least one of the link files I was generating.
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 only thing that puzzled me, was that I was still getting a terminal window popping up with my debug messages printed to standard output. On a hunch, I ran the executable and piped stdout to an output file. When I did this, no console window popped up, and the application ran as expected.
So my question is this -- If a Windows app with Gambit embedded does not have a console, does the runtime open a new one (using CreateProcesss, I'm assuming) in order to display data sent to stdout? And if so, are there any setup parameters I can change to prevent this? Ideally I'd like to be able to turn this on and off at will, or at least be able to chose one way or another at startup. For debugging purposes, it is handy to have the console, but for my users I'd want to shut it off.
On Windows, the console is actually created by a call to AllocConsole
in lib/os_tty.c (on Unix, the "controlling terminal" is opened). This is done lazily upon the first output (or input) to the "console port" (which is the port returned by the procedure console-port). The console port is the port normally attached to the REPL channel. So the console will pop up when an error message needs to be output, or when pp is called (with no explicit port argument), or when a REPL is started for any of many reasons.
Funny -- just before I saw this reply I had been poking around in os_tty.c and discovered this. I figured this would be the key to getting the behavior I was looking for.
The REPL channel's port can be changed by adding the -:d- runtime
option when the program is started. This will assign the standard input/output to the REPL channel. For example :
% gsi -e "(/ 1 0)" > out *** ERROR IN (string)@1.1 -- Divide by zero (/ 1 0) % cat out % gsi -:d- -e "(/ 1 0)" > out % cat out *** ERROR IN (string)@1.1 -- Divide by zero (/ 1 0)
Moreover, by adding a 0 to the runtime debug options, the display of
the error message will be supressed:
% gsi -:d0- -e "(/ 1 0)" % echo $? 70 % gsi -:d- -e "(/ 1 0)" *** ERROR IN (string)@1.1 -- Divide by zero (/ 1 0)
[snip]
I had already been running my app with -:d-, but somehow missed -:d0 -- that almost gives me what I want (by suppressing the error messages). However, I have some messages in my app that are being sent to stdout, and even with -:d0, the console is still being shown by these. Of course, the AllocConsole call is the culprit.
This led me to doing some experimentation. I tried calling AllocConsole before creating the main Qt window of my application, but that made the console pop up immediately (which is what I was trying to avoid). Then I decided to cheat it a little, and use CreateProcess to restart my app with the creation flags set to CREAecTE_NEW_CONSOLE|CREATE_NO_WINDOW -- then once the app was loaded, I caused it to show its main window. That worked fine, but I wasn't satisfied with it, because I was having to start two processes to start up the app.
Finally, it occurred to me that I should try to first create the main window, but not show it, then call AllocConsole while the main window is hidden, and then show the main window. This did exactly what I wanted. The console is created, but it is hidden from the users view. As a side benefit, if you start the application from a command shell (cmd.exe), or from a MSYS or cygwin terminal (rxvt or mintty), you get the console output. In the case of cmd.exe, a new console window is opened which displays the output. In the case of rxvt and mintty, the output is displayed in the terminal itself.
This is precisely the behavior I was looking for.
AARGGHHHH!!!
After all of that, looks like my final solution is totally bogus. I forgot to change the desktop shortcut I was using to test AllocConsole on a hidden main window. Contrary to what I thought, I was *still* using the two-process method to start up the app. After pointing the shortcut to the correct executable, the console still shows up when AllocConsole is called (even if the main window is still hidden). Ah, well, at least I have an only slightly-lame solution. _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list