From: m on
Another possibility is to use the /ENTRY linker option to change the entry point to a routine that sets these values and then calls WinMainCRTStartup. This is also CRT and linker specific, but at least this way you sit under the CRT and there is no chance that the first few IOPs will be lost.
"Jonathan de Boyne Pollard" <J.deBoynePollard-newsgroups(a)NTLWorld.COM> wrote in message news:IU.D20100304.T121751.P2212.Q0(a)J.de.Boyne.Pollard.localhost...
I have the following code snippet, that tries to redirect a program's standard output/error to a file.


HANDLE fHandle = CreateFile(...);

SetStdHandle(STD_OUTPUT_HANDLE, fHandle);
SetStdHandle(STD_ERROR_HANDLE, fHandle);

fprintf(stdout, "string #1\n");
fprintf(stderr, "string #2\n");...but it doesn't work. Output text goes to console instead of file. Any ideas?


By the time that your code comes to execute, your runtime library has already queried Win32 for the standard handle numbers, and saved them in internal library data structures. Whatever subsequent alterations you make at the Win32 level, the stdout and stderr streams end up using the Win32 handle numbers that were already saved. You need to alter the runtime library's idea of what those Win32 handles are. Of course, the mechanism for doing this is highly specific to which C/C++ implementation you are using.


For OpenWatcom, for example, this involves the creative use of the close() and _open_osfhandle() functions to re-map (library) file descriptors 0, 1, and 2 to different underlying Win32 handles (obtained from CreateFile() of course). This will make the file-descriptor-level I/O functions such as read() and write() use the new Win32 handles. One then needs to ensure that stdin, stdout, and stderr are open and associated with file descriptors 0, 1, and 2, if this is not already the case.

From: Jonathan de Boyne Pollard on
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:hmp5a401ljo(a)news6.newsguy.com" type="cite">
<p>Now, since some functions will write to the standard I/O <code>FILE</code>
objects, and some to the standard I/O handles, it's best to reassign
both, unless you know all the output you want redirected will be using
one abstraction or the other.</p>
</blockquote>
<p>Actually, there are three APIs, not two.&nbsp; I'm surprised to find that
although answers to this are frequently given, they're frequently
wrong, too, including one such answer that was published in <i>Windows
Developer Journal</i>.&nbsp; Hence I've written a Frequently Given Answer on
<a
href="http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/redirecting-standard-io.html">redirecting
standard I/O from within a program</a>.</p>
</body>
</html>
From: Michael Wojcik on
Jonathan de Boyne Pollard wrote:
>
>> [I wrote:]
>> Now, since some functions will write to the standard I/O |FILE|
>> objects, and some to the standard I/O handles, it's best to reassign
>> both, unless you know all the output you want redirected will be using
>> one abstraction or the other.
>>
> Actually, there are three APIs, not two.

Quite right, and I ought to have mentioned that. Thanks for the
correction. (The third, for anyone who hasn't read the document
Jonathan posted the link to, is the POSIX API.)

I tend to avoid mixing the POSIX and Win32 APIs in the same program,
where possible, so I didn't think of mentioning the POSIX I/O
functions in my previous post. But even if the programmer writing the
main program avoids the POSIX functions, it's entirely possible
library code will call them.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University