Replying the gtk-app-devel list, Bcc:ing to you. Please don't send me
personal mail about GTK+. Use the mailing lists.
> I noticed that alot of the examples use the int main(int argc, char*
> argv[]) entry type..
That's hardly surprising, as that is the standard for C programs, and
100% portable, is it?
> as you know this for visual studios means that it is supposed to be a
> console based app.
Who cares? And what's bad about that? They are *examples*, as you
said. You don't want warnings or error messages printed to stderr to
go unnoticed during testing and development, would you?
Once one has a *complete* application, ready to be shipped, one can
start bothering with whether to turn it into a windowing
executable. No need to do it earlier, it's only counter-productive.
Anyway, an interesting fact: the windowing/console setting is just a
field in the executable header, from Windows's point of view. The
WinMain()/main() difference is just a *convention* enforced by Visual
Studio. If one has a console app, foo.exe, with main(), one can run:
editbin /subsystem:windows foo.exe
and it's magically turned into a windowing app... (editbin.exe comes
with Visual Studio).
There is absolutely nothing in the Windows OS that would prevent an
app whose source code has main() instead of WinMain() from having a
GUI with "normal" message loop, etc, regardless of whether it is
marked in the executable header as a console or windowing app, for
instance. And nothing that would force an windowing app (as indicated
by the executable header) to actually have a GUI and be
message-driven, for that matter.
Try this for instance: make a copy of %windir%\system32\notepad.exe,
say np.exe, in some other location. (A copy because otherwise Windows
will automagically "restore" the proper notepad.exe right away, I
think.) Turn it into a console app with editbin. Double-click on it in
Explorer. A console window opens! (And closes when you quit the app.)
Then copy %windir%\system32\ipconfig.exe to ic.exe. Turn it into a
windowing app. Double-click on it. Nothing seems to happen. No console
window flashes showing the output, like if you run ipconfig.exe from
Explorer.
Now run ic.exe from the cmd.exe command line. No output. (Because when
Windows runs windowing apps they by default have invalid standard
input/output/error handles.) But then run it like this:
ic.exe 2>&1 | more
and you see it's output, because when you explicitly redirect I/O, the
standard handles aren't invalid. (Yes, 2>&1 *is* cmd.exe syntax. Yes,
it is the same syntax as used in Unix shells. Amazing how great minds
think alike, isn't it?)
> so what i decided to to so that i didnt have to edit any of the sample
> code i create a function that converts the windows getcommandline string
> into the same format that is used by argv and argc and it fallows the
> same rules that the windows stdlibs used for taking parameters.
No need for that, the C library's startup code already does it, also
for apps that have WinMain() instead of main(). The split up command
line is available in __argc and __argv, declared in stdlib.h.
The WinMain() function in GIMP, for instance, looks like this:
int _stdcall
WinMain (HINSTANCE hInstance,
HINSTANCE hPrevInstance,
char *lpszCmdLine,
int nCmdShow)
{
return main (__argc, __argv);
}
All the above is not GTK+-related at all. Shouldn't Windows
programmers already know this? Isn't this mentioned in the fine
manuals you got with Visual Studio?
--tml
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
