I haven't used PAR, but I wonder why it would skip any stdin, stdout, stderr handling when you request a GUI. Having written console and gui apps in C for Windows, I know there's no technical reason a gui can't also use the standard file descriptors.
--
[ e d @ h a l l e y . c c ]
| [reply] |
PAR does not magically make your perl app console-less. It does so by doing quite a few things behind the scenes like, close STDIN/STDOUT/STDERR, tells the OS not run the program in console-less mode, and a few other things. PAR is a hack that allows you to virtually "compile" your interpreted script -- it does not do this by actually compiling it, it wraps your script inside a perl interpreter executable.
For instance if you look at the actual code that accomplishes this below (from PAR), you will see that it goes into the executable and sets bytes to make the application a windows no console exe. This inherently closes off parl's (the exe that is used as the interpreter wrapper) STDIN/STDOUT/STDERR.
sub _strip_console
{
my $file = shift;
my $preoff = shift || 0;
my ($record, $magic, $signature, $offset, $size);
open my $exe, "+< $file" or die "Cannot open $file: $!\n";
binmode $exe;
seek $exe, $preoff, 0;
# read IMAGE_DOS_HEADER structure
read $exe, $record, 64;
($magic, $offset) = unpack "Sx58L", $record;
die "$file is not an MSDOS executable file.\n"
unless $magic == 0x5a4d; # "MZ"
# read signature, IMAGE_FILE_HEADER and first WORD of IMAGE_OPTION
+AL_HEADER
seek $exe, $preoff + $offset, 0;
read $exe, $record, 4+20+2;
($signature,$size,$magic) = unpack "Lx16Sx2S", $record;
die "PE header not found" unless $signature == 0x4550; # "PE\0\0"
die "Optional header is neither in NT32 nor in NT64 format"
unless ($size == 224 && $magic == 0x10b) || # IMAGE_NT_OPTIONA
+L_HDR32_MAGIC
($size == 240 && $magic == 0x20b); # IMAGE_NT_OPTIONA
+L_HDR64_MAGIC
# Offset 68 in the IMAGE_OPTIONAL_HEADER(32|64) is the 16 bit subs
+ystem code
seek $exe, $preoff + $offset+4+20+68, 0;
print $exe pack "S", 2; # IMAGE_WINDOWS
close $exe;
}
| [reply]
[d/l] |
Really? I just created a simple test application in MS VC++ 6 here, and the fprintf(stderr, ...) statements I put inside WinMain don't seem to do anything at all. (same with stdout)
In fact, I'm not sure that what the poster is asking about can be done at all, really - when you start a win32 gui application from the command prompt, the command prompt returns to you as soon as the executeable is loaded. I don't think it's possible to have a win32 gui application that interacts with the command window from which it was launched, by windows' design.
It is of course possible to have a win32 console application that hides its own console window immediately after launching, and to write a console application that detaches from its console window, but both of those will flash a console window onscreen before continuing.
I'll go check the Microsoft documentation to see if what the poster desires is even possible with windows.
Update: There's a function that's new in windows XP that'll let you re-attach to the parent console (AttachConsole) however, this still has problems, because your output will be all messed up with the returned command line prompt, and you can't really read from the console in that case.
But the cause is not helpless! Googling on AttachConsole gave this article which contains a workaround, which I'll post separately.
| [reply] |