[ros-kernel] Re: Striped VIM for ReactOS

[Phillip S. <ps...@cf...>]

The C runtime library startup code does not mess with the console, so 
either the console is freed/allocated in kernel32.dll or ntdll.dll before 
the program entrypoint is called, or possibly something is done differently 
in the parent process.  You can verify this by using the editbin command 
from VC or the SDK to change the subsystem type of an existing exe, which 
does not effect the crt startup code in the exe.  Because of this, you 
can't create a hybrid app that uses a console if it inherits one, or does 
not if it does not.

At 10:42 AM 11/13/2001 -0500, you wrote:

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