Re: console/GUI programs... FW: [ros-kernel] Re: Striped VIM for ReactOS

[Christopher Faylor <cgf at redhat dot com>]

On Wed, Nov 14, 2001 at 09:36:32AM +1100, Robert Collins wrote:
>This may be of interest to some folk.... 
>
>I'm going to see if I can find such prolog code in gcc anywhere, and if
>so create a variant just for the mixed mode programs (such as setup.exe,
>the X server etc).

I think the author is slightly confused.  The subsystem bit is set in
the executable header.  MSVC's dumpbin.exe shows executables as either a
"CUI" if it is a console app or a "GUI" if it is a windows app.

I'm pretty sure that the decision on how to handle the console is done
by the windows loader.  AFAIK, it's not up to program control as to
whether the program inherits a console or not.

If there was prologue code, it would somehow be invoked by -mwindows.
If you look at the code in gcc, you can see that the only thing that
-mwindows seems to do is pass the '--subsystem windows' option to ld.
This does cause the linked program to use a different startup function
but I don't think that it does anything magical.

cgf

>> -----Original Message-----
>> From: Craig Barkhouse [mailto:craig@wanware.com]
>> Sent: Wednesday, November 14, 2001 2:43 AM
>> To: ros-kernel@reactos.com
>> Subject: [ros-kernel] Re: Striped VIM for ReactOS
>> 
>> 
>> 
>> ----- Original Message ----- 
>> From: "Robert Collins" <robert.collins@itdomain.com.au>
>> To: <ros-kernel@reactos.com>
>> Sent: Monday, November 12, 2001 8:11 PM
>> Subject: [ros-kernel] Re: Striped VIM for ReactOS
>> 
>> 
>> > > -----Original Message-----
>> > > From: Craig Barkhouse
>> > > To: ros-kernel@reactos.com
>> > > Sent: 11/12/01 1:40 PM
>> > > Subject: [ros-kernel] Re:  Bug Report - VIM for Win32
>> > >
>> > > The difference is mainly what the compiler inserts into 
>> your program
>> > as
>> > > startup code.
>> 
>> > I thought a GUI app was _not_ passed the console handle when it's
>> > started from cmd.exe (or an equivalent).
>> > 
>> > Thats more than a compiler difference IMO.
>> > 
>> > If however, this is a compiler issue, please please please 
>> let me know
>> > what call is in the prolog to get attach to the console - the only
>> > AttachConsole call I know of is in XP, and the behaviour of 
>> not getting
>> > the console handle has existed since win95.
>> 
>> By default, a newly created process inherits the same console 
>> (if any) of its parent, unless the process was created using 
>> the CREATE_NEW_CONSOLE flag.  Console apps therefore don't 
>> have to call anything special in order to attach to the 
>> console if they are launched from a process that is attached 
>> to a console.  To handle the case where they are launched 
>> from a process that is not attached to a console (a "GUI" 
>> app), "console" apps have an explicit call to AllocConsole() 
>> in the startup code that gets executed before main().  This 
>> call silently fails when the app has already inherited a console.
>>    "GUI" apps, on the other hand, don't want a console.  When 
>> they are luanched from a process that is not attached to a 
>> console (a "GUI" app), they're fine.  To handle the case 
>> where they are launched from a process that is attached to a 
>> console (a "console" app), "GUI" apps have an explicit call 
>> to FreeConsole() in the startup code that gets executed 
>> before WinMain().  This call silently fails when the app 
>> hadn't inherited a console.  So you see, it's not that the 
>> GUI app never had access to the parent console; it's that the 
>> GUI app has voluntarily detached itself.  How do you get back 
>> to that console?  I guess XP's new AttachConsole() API 
>> function does that.  Prior to that, you could only ensure 
>> that you were attached to *some* console by calling AllocConsole().
>>    To summarize, the main difference between console apps and 
>> GUI apps is whether the app calls AllocConsole() ("console") 
>> or FreeConsole() ("GUI") at startup time.  It is my 
>> understanding that it is the compiler which inserts this 
>> startup code for doing any initialization tasks -- such as 
>> setting up the *argv[] array -- before launching the user's 
>> main function.  The compiler knows which way to write the 
>> startup code based on the /SUBSYSTEM: option you pass it, or 
>> based on a default set of rules (main()? console; WinMain()? 
>> GUI).  This being the case, if the compiler allows you to 
>> write this code yourself (I *think* VC++ 6.0 does, but I'm 
>> not 100% sure and I can't find the option right now), you 
>> could in theory create an app that ran as a GUI app when 
>> launched from a GUI app, but ran as a console app when 
>> launched from a console app.
>> 
>> 
>> ==================o remove yourself from this mailing list, 
>> go to =ttp://www.reactos.com/home/mailing.html         
>> =================
>> 

-- 
cgf@redhat.com                        Red Hat, Inc.
http://sources.redhat.com/            http://www.redhat.com/