0

I have redirected the stdout of java.exe using pipe. Now I read the output using ReadFile and char buffer:

ReadFile( childStdOUTRd, buffer, sizeof(char) * 4096, &read, NULL);

The buffer will be assigned correct data. But if I change it to TCAHR[4096]:

ReadFile( childStdOUTRd, buffer, sizeof(TCHAR) * 4096, &read, NULL);

The buffer received gibberish. Do I miss something ?

zzy
  • 1,771
  • 1
  • 13
  • 48
  • How are you deciding that the buffer received "gibberish"? – M.M Jul 24 '15 at 03:23
  • @MattMcNabb Those are words can not be read. – zzy Jul 24 '15 at 03:48
  • @buttifulbuttefly It is wchar_t. – zzy Jul 24 '15 at 03:49
  • @zzy how are you trying to read them? Can you show the code you use to read them. – M.M Jul 24 '15 at 03:53
  • @MattMcNabb It is same to https://msdn.microsoft.com/zh-cn/library/windows/desktop/ms682499(v=vs.85).aspx , just change the buffer to tchar and child process is java.exe (run a .jar game). – zzy Jul 24 '15 at 04:42

1 Answers1

1

Firstly you should check the return value of ReadFile. If it returned FALSE then the read failed and the data might be gibberish.

Also, check the value of read. It will say how many characters were read. Don't try to work with anything in the buffer beyond the value of read bytes.

Next, the ReadFile function receives raw bytes, it does not interpret them. If your system has TCHAR defined as a 16-bit wchar_t, then this call will read 8192 bytes from the input stream. It should work correctly.

You didn't say how you determined that the buffer received "gibberish". If you are trying to pretend that the buffer contains actual wchar_ts but the input stream did not contain wchar_ts then it will not make sense. The solution to this is: Don't Do That.

Finally, TCHAR has not been relevant for the last 15 years. Use either char or wchar_t according to your needs.

M.M
  • 138,810
  • 21
  • 208
  • 365