Re: Source code for gtk-demo



Sai Korada writes:
Can anyone guide me to source code for gtk-demo application.

Fetch GTK+ sources, ftp://ftp.gtk.org/pub/gtk/v2.10/gtk+-2.10.6.tar.gz
, look in the demos/gtk-demo folder.

Actually I want to know what is the entry point for a GUI
application (like int main() for ordinary applications).

Whenever an application is created using int main(), it leaves a black
console window open, that just looks as ugly as possible. 

Sigh, I mailed messages about these issues to this very list just a
couple of days ago. (Are you the same person as "devilsclaw"?) Check
the archives. Anyway, I'll reiterate...

Firstly, you should mention right away that you are talking about
Windows issues, so that people who aren't interested in Windows
won't wonder what the heck you are talking about. You did know that
the distinction between "GUI" and "console" applications is a
peculiarity in Windows only, didn't you?

Anyway, you are confusing two things here. Whether the (C/C++ level)
entry point is main() or WinMain() is irrelevant from the Windows
operating system's point of view. Windows executables of course don't
even need to be written in C or C++, so they don't necessarily even
have had anything called main() or WinMain() in their source code. The
operating system doesn't know or care what language the executable is
written in.

The *real* entry point of an executable is the one that the
AddressOfEntryPoint field in the "optional" PE header (which isn't
optional for executable images) specifies. (See
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx )

For an app written in C or C++, that real entry point is in an object
linked in (statically) from the C library. It's definitely not main()
or WinMain(). It's that startup code that calls the user-written
main() (or WinMain()) function.

The distinction between GUI and console apps is from the Wndows
operating system's point of view only a question of whether the
Subsystem field in the optional PE header has the value
IMAGE_SUBSYSTEM_WINDOWS_GUI (2) or IMAGE_SUBSYSTEM_WINDOWS_CUI (3).

That decides how Windows starts the executable, whether it opens a
console window for it (if it doesn't inherit one from its parent) or
not. (If the exectuable is run with a console window, the standard
input/output/error handles are attached to it, unless the
CreateProcess() call asked for other assignments.)

Just by changing that field in an executable you can switch it from
being a GUI app to a console app and back. Whether it has a main() or
WinMain() (or whether it was written in C or C++ at all) is irrelevant
from the operating system's point of view. Also, the GUI/console
distinction has no relation to whether the app actually creates and
shows any windows and has a GUI or not.

Now then, what confuses you is that the Microsoft C/C++ compilers and
IDE enforce the *convention* that when creating a GUI application, it
should have a user-written WinMain(), and when creating a console
application, it should have a main(). The GNU compilers and tools, for
instance, don't enforce this.

When running gtk-demo, I could realize that it doesn't even start a
black console window. Any hint on how this can be done. 

Are you sure? The gtk-demo.exe distributed as part of the official
Windows gtk+ development packages on ftp.gtk.org is linked as a
console application. Are you running gtk-demo from a command prompt in
a console window? In that case console apps don't open any new console
windows, but use the one they are started from.

I've been trying all the methods, but unfortunately nothing seems
to work as expected.

What methods have you been trying?

To create a GUI executable, you can do it several ways:

1) If using Microsoft tools: Write standard C code with main() and
  none of this WinMain() crap, let your tools create a console
  executable, and only then when you are ready to ship it, use the
  editbin command to switch the subsystem field in the header. editbin
  is part of the Microsoft tools.

        editbin /subsystem:windows yourapp.exe

2) If using Microsoft tools: Tell the tools that you want to create a
  GUI executable, and write a WinMain() then. If you want, you can
  have WinMain() just call a main() function, in that way your code is
  more portable. (You can get at the parameters to pass to main() by
  using __argc and __argv, which are declared in stdlib.h.)

3) If using GNU tools, just add -mwindows to the linking command
  line. You can still write your code with just a main().

4) Some other combination.

In addition to the above, there is the additional convention that if
one writes an "UNICODE" application, instead of main() and WinMain()
one has wmain() or wWinMain().

You should really have a look at for instance the crtexe.c source file
in the Platform SDK. That is the source from which the object files as
used by the Microsoft tools to contain the actual entry point of an
executable is compiled. (Different variants for GUI/console and
"ANSI"/"UNICODE" apps.)

As you notice from the above, nothing GTK+-specific is mentioned. The
above knowledge is something "C/C++" programmers who claim they know
Windows could be supposed to be familiar with, for chrissake.

--tml




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]