Eugene
Wed May 11 18:08:16 CDT 2005
Doug Harrison [MVP] wrote:
> On Fri, 6 May 2005 14:19:34 -0700, Eugene Gershnik wrote:
>
>> Doug Harrison [MVP] wrote:
>>> On Fri, 6 May 2005 11:24:37 -0700, Eugene Gershnik wrote:
>>>
>>>> Depends. You may load third party code that has its own ideas (also
>>>> see below)
>>>
>>> Like I said, it should be rare.
>>
>> Because you say so?
>
> Because I believe that the thing I said should be rare, namely,
> WriteFile(hStdout), is a strange thing to do
[...]
LOL. Of all the code I've ever seen (an insignificatnt fraction of all the
code out there) most did much stranger things than this. Most windows
programmers I've seen don't know what is the difference between fwrite and
WriteFile.
And no it is not WriteFile(hStdout) but rather WriteFile(hFile) where later
hStdout was passed to the library by somebody not familiar with the code.
>> What kind of example do you expect? Do you want a dump of some
>> proprietary code? Sorry can't do that.
>
> If it's proprietary, then it is indeed *your* problem. However, if
> you're talking about a real library *I or someone else* might use
> that does WriteFile(hStdout), it would be interesting to know about
> it.
I have no idea about what you or anybody else may or may not use. FWIW the
number of people who have "my" problem by virtue of working in the same
place is most likely bigger than the number of people you ever worked with.
That's where my knowlege ends.
>> If there is any FUD here it is in your assertion that this should be
>> rare.
>
> Listen, you're the one who suggested but didn't motivate a call to
> SetStdHandle, something that clearly wasn't necessary for the OP's
> example
Two reasons. First this call will never harm anybody. You don't attach FDA
warnings to water bottle the way you do to drugs. Second code tends to
evolve and what was written in one environment tends to end up in another
pretty quickly. You assume that an example somebody posted is the real
target while I just see it as an example of something else he wants to
accomplish now or in the future.
[...]
> I still think it
> should be rare, as it isn't very sensible to do.
This doesn't follow. Most non-sensible things are very frequent.
> In that same message, you also raised the specter of DLL troubles,
> but you didn't talk about the conditions necessary for them to arise,
> nor did you talk about how to avoid the problem.
Pardon me for not being a language/compiler/whatever lawer and not turning
every post into MSDN addendum. Unless there is reason to suspect otherwise I
assume every poster to be smart and able to google details out for himself.
The problem is real and it is up to OP to decide whether it affects him.
> If you're going to reply to me and add something you think I missed,
> fine, but please explain it in sufficient detail that I don't need to
> come back and fill in numerous holes in what you wrote.
You don't need to do anything. If you feel that you must "fill in numerous
holes" this is your problem not mine.
> Also, when
> your contribution doesn't directly apply to the OP's question, as was
> the case here, you really ought to indicate this.
Ought? And again I consider the information to directly apply to OP or
anybody else who want to write reusable "RedirectStdout" function.
> When you don't,
> you're spreading FUD, because you're giving enough information to
> cause someone to worry, but not enough to ease or address those
> worries.
In which case an intelligent person can google/MSDN out the rest.
>> I don't know what is rare or not. Just stating a possibility I have
>> seen.
>
> In that case, maybe you should try holding yourself to the same
> standard of completeness you seem to be trying to impose on everyone
> else. If you did that, then instead of saying, "You might want
> to...", you might have said the more useful thing, "It doesn't matter
> here, but under conditions X and Y, you need to..." That might have
> been a helpful comment, and perhaps I would have avoided this entire
> exchange.
Why do you apply your own rules to me? If you want to write "War and Peace"
in every post by all means do so. I consider the information I have given to
be enough. If the OP or anybody else didn't understand/couldn't find why I
said what I said all they need to do is to ask. If they found out the reason
by themselves and decided for themselves why waste electrons?
[...]
You snipped the sentence I was replying to so here it is again
>>> When I've observed multiple CRTs in my programs, it's
>>> due to loading some DLL which is a black box and has no expectation
>>> of sharing CRT state with my process, so it doesn't matter
>
>> Who talks about CRT state??
>
> You do. You brought it up in your first reply to me.
>
[...]
>
> The stream stdout is part of CRT state.
Yes but "the destination where output goes" isn't. At least not in the mind
of an average user in the context of black-box dlls.
>> This thread was about redirecting output from a
>> process.
>
> Well. In two sentences, you denied something you introduced into the
> thread and implied that by responding to it, I'm going off-topic.
I don't see it but whatever.
>> If the dll outputs strings you pretty much would want it to write
>> to the same destination as the rest of your code.
>
> I'd also want to make sure those strings arrive in the correct
> sequence WRT my writes.
Very true. Do you expect me to mention this too just in case my posts are
too short for "War and Peace"? ;-)
> The
> standard model of a C program is one stdout.
And no DLLs or _dup2. We have left the standard model long ago, don't you
think?
>> Try to load JVM into your process. It uses (at least the 1.4
>> versions did) VC6 CRT. It also prints to stdout and stderr and what
>> it prints is pretty important.
>
> OK, thanks. I guess we could say this. If you want to load a
> component that uses stdout and friends, and you don't know that it
> links to the same CRT DLL as you, but you want its output to go to
> the same place as yours, then you must ensure SetStdHandle is called
> before you load it. That way, it should pick up the correct OS-level
> standard handles. For a console app, dup2 accomplishes this, but for
> a GUI app, you have to do it yourself, because dup2 sets the OS-level
> standard handles only when used in console apps. If one or both
> streams are buffered, there may be output sequencing problems unless
> it's arranged that the buffered stream in module X is flushed before
> module Y performs a write.
Great. I'll certainly use this (with due credit) when I'll decide to write a
book about stdio on Windows. ;-) For an NG post where all posters appear to
be intelligent this is too much IMO.
> While not relevant to the OP's question or
> my reply to him,
according to OP this may be relevant to him
> at least there's enough detail for this to be useful
> to somebody.
As was in the original version.
--
Eugene
http://www.gershnik.com