[ros-kernel] Re: Striped VIM for ReactOS

[Craig B. <cr...@wa...>]

----- Original Message -----=20
From: "Robert Collins" <rob...@it...>
To: <ros...@re...>
Sent: Monday, November 12, 2001 8:11 PM
Subject: [ros-kernel] Re: Striped VIM for ReactOS


> > -----Original Message-----
> > From: Craig Barkhouse
> > To: ros...@re...
> > 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).
>=20
> Thats more than a compiler difference IMO.
>=20
> 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.


====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================