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

REPLeffect repleffect at gmail.com
Tue Apr 10 15:42:09 EDT 2012


On Tue, Apr 10, 2012 at 2:13 PM, REPLeffect <repleffect at gmail.com> wrote:
> On Mon, Apr 9, 2012 at 12:52 PM, Marc Feeley <feeley at 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 at 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.html
>>>>
>>>> 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.



More information about the Gambit-list mailing list