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

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

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).

Rob 

> -----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         
> =================
>