Many thanks Przemek.
-mwindows did the job well.
Strange that STDERR/STDOUT don't work
on Windows systems (but this won't be the
last oddity with Windows for sure), so I'll
simply add some other means to display required
startup (help and some error) information, in
a window or something, so the whole problem
is worked around. There is nothing critical
involved. The only slightly ugly side of
it is that the *nix version of the same app
could well use these facilities.
Brgds,
Viktor
On 2008.10.28., at 15:44, Przemyslaw Czerpak wrote:
On Tue, 28 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
This happens with r9763, when compiled and built
with MinGW 4.1.2, and having HB_GT_WVT_DEFAULT
+ HB_GT_WIN in my app code.
Now, when the app starts, it's putting some
app headers on the command line via OutErr(),
than goes CUI. This was normal behavior
in Clipper times. (the app also has a command
line help screen, other than these it doesn't
use the Out*() functions).
Out*() functions are redirected to STDOUT/STDERR
handles. It's a platform dependent issue if such
handles are open and redirected to some device
or file in each new process.
It's a standard in most of OS-es except MS-Windows.
In Windows GUI and CUI applications needs different
startup code and inherits different settings from
caller. Usually GUI application does not have open
STDOUT/STDERR handles so releated functions does not
work.
In *nixes there is no difference between GUI and CUI
programs and you do not need separated binaries for
both modes.
In MinGW authors tired to replicate such functionality
so it's possible to make mixed programs. If you are using
MSYS then it should be possible to create GUI programs
where STDOUT/STDERR is redirected to MSYS console. The
bad side effect is that if console is not available this
code allocates new console and you have your own GUI window(s)
and console window which handles STDOUT/STDERR output.
MinGW tries to recognize type of application automatically
by looking for main() and WinMain() functions in linked
binaries. It can be also controlled manually by programmer
using -mwindow and -mconsole switches.
The default setting and switch/autodetection priority was
changing in last years so I cannot say what is default in
your system now. In the past some MinGW versions unconditionally
forced console mode if linker found C main() function in linked
function list. It's the reason why we moved mainstd.c from HVM
library to separate mainstd library in MinGW builds to allow users
adding them to linked library list only when he needs console
application.
What happens with MinGW, is that a separate
console window opens with the header text,
plus the usual WVT window opens with the app itself,
while the console window stays on the background
for the whole running time.
See above. If you use -mwindow GCC switch and/or remove
mainstd from linked library list then you will create
pure GUI program without console allocated automatically
when parrent process does not set valid STDOUT/STDERR output.
For MSVC/BCC, the situation is a bit different,
here the Out*() functions simply don't do anything.
See above. They can create only pure GUI or CUI programs
without any mixed versions which are available in MinGW.
I think none of the these behaviors are very good,
and I'm not sure what are the platform possibilities
or what could I do on the app level to get around these
(besides removing all Out*() functions of course).
If you want Out*() functions working in pure GUI programs
then you need sth connected to STDOUT/STDERR. It usually
should be set by calling process. Probably if you will
use some consoles with such functionality then it will
work though there is also problem with automatic GUI programs
detaching but I think it should be a way to resolve it though
it's rather question to MS-Windows programmers/users not to me.
In any case, I think MinGW and MSVC/BCC should be
behave (if possible) more similarly.
So just use -mwindow MinGW switch for linking GUI programs
and if your MinGW version needs it then remove mainstd lib.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
