The target computer has no serial port, but it has an i1394 port, so maybe I
can try using Windbag over i1394, if I find a cable and ... hmm, and install
Windbag onto some other host that has an i1394 port...

Looks like I need to do more reading and experimenting, when I get the time
to try Cezary Noweta's suggestion.

Um, so what?  The problem isn't in _wfopen_s.  New text is being appended to
the existing debug log exactly as hoped.  The problem comes in with either
_vsnwprintf_s or _ftprintf_s.

Hmm, yes, thank you.  Luckily this week's user name has no percent signs,
but I'd better not add any potentially risky metadebugging code to
production code  ^_^

Those match the values that I found this morning, looking them up.

It does get worse.

I deleted the file and then ran the program with this code:
 _tfopen_s(&pf, LOG_FILE_NAME, _T("a, ccs=UNICODE"));

http://msdn2.microsoft.com/en-us/library/z5hh6ee9(VS.80).aspx
*  The flag is only used when no BOM is present or if the file is a new
*  file.

That is a lie.  _tfopen_s created a new file and it created the thing with
ANSI encoding not Unicode.

I deleted the file again, created a file in Notepad containing only an empty
line (CR-LF pair), saved it in Unicode, and then again ran the program with
this code:
 _tfopen_s(&pf, LOG_FILE_NAME, _T("a, ccs=UNICODE"));

http://msdn2.microsoft.com/en-us/library/z5hh6ee9(VS.80).aspx
*  If mode is "a, ccs=<encoding>", fopen_s will first try to open the file
*  with both read and write access. If it succeeds, it will read the BOM to
*  determine the encoding for this file;

This time _tfopen_s seems to have performed correctly.  Now let's continue.

http://msdn2.microsoft.com/en-us/library/z5hh6ee9(VS.80).aspx
*  When a Unicode stream-I/O function operates in text mode (the default),
*  the source or destination stream is assumed to be a sequence of multibyte
*  characters. Therefore, the Unicode stream-input functions convert
*  multibyte characters to wide characters (as if by a call to the mbtowc
*  function). For the same reason, the Unicode stream-output functions
*  convert wide characters to multibyte characters (as if by a call to the
*  wctomb function).

In other words, it doesn't matter if _tfopen_s performed correctly because
_ftprintf_s is still going to screw it up.  Let's look for confirmation of
this screw-up.

http://msdn2.microsoft.com/en-us/library/c4cy2b8e(VS.80).aspx
*  For the same reason, the Unicode stream-output functions convert wide
*  characters to multibyte characters (as if by a call to the wctomb
*  function).

Yup, no provision at all for keeping Unicode as Unicode.

However, both of those are half-lies.  Half the time, _ftprintf_s violated
MSDN and it kept Unicode as Unicode in the spirit (but not the letter) of
http://msdn2.microsoft.com/en-us/library/z5hh6ee9(VS.80).aspx.
The other half of the time, _ftprintf_s screwed up worse.

Notepad opened the file in Unicode.  The display alternates, a bunch of
readable lines, a few lines of garbage, a bunch of readable lines, a few
lines of garbage, etc.

It seems that ccs=UNICODE is unusable.  It changes the result from being
mostly readable (with a little bit of lossage) to being half readable (with
half garbage).

It gets even more worse.

I added this call:
 _ftprintf_s(pf, _T("%s\n"), _tsetlocale(LC_CTYPE, _T("")));
The output was:
 Chinese_Hong Kong S.A.R..950

So there is absolutely no excuse for _ftprintf_s to screw up on Chinese
characters.  The DLL is not running in the C locale, it's running in the
Chinese Hong Kong locale, code page 950, exactly as it should be.

Here's more MSDN stuff too.
http://msdn2.microsoft.com/en-us/library/x99tb11d(VS.80).aspx
*  LC_CTYPE
*  The character-handling functions (except isdigit, isxdigit, mbstowcs, and
*  mbtowc, which are unaffected).

So mbtowc is one of the exceptions, it wouldn't have been affected even if
the C locale were in use, and presumably it would always use code page 950
and screw up because it's miscoded -- however, wctomb isn't one of the
exceptions, so it would have been affected if the C locale were in use, and
it would screw up differently from the way it actually screws up.

Anyway, thank you whoever it was who said that _vsnwprintf_s isn't broken
and _ftprintf_s.  Sorry I found it hard to believe you.  You're absolutely
right.  _ftprintf_s is broken.

Surely you could fix the bug with _ftprintf_s(pf, _T("%s"), szBuf).

(In standard C, L"%s" in a format string takes a char * argument,
just like "%s".  In Microsoft C, it instead takes a wchar_t *
argument.  I don't know if there is a way for Microsoft to
correct this violation without breaking countless programs.)