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.