have evtexport handle CRLF platform dependent in embedded in strings

[uckelman-sf]

String values in evtx files sometimes contain embedded newlines, which are CRLF because they're written on Windows. In the attached exmaple, the value starting at offset 0x19472 is one such:

Application.evtx.gz

C:\Windows\System32\LogFiles\Scm\SCM.EVM
C:\Windows\servicing\Sessions\Sessions.xml
C:\Windows\System32\LogFiles\Scm\SCM.EVM
C:\Windows\Logs\CBS\FilterList.log
C:\Windows\Temp\WER6E75.tmp.WERInternalMetadata.xml
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Critical_10.0.10586.0_1_58b6cec169647e71609bf1745452c849866c6e89_00000000_cab_12bc6e95\memory.hdmp
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Critical_10.0.10586.0_1_58b6cec169647e71609bf1745452c849866c6e89_00000000_cab_12bc6e95\minidump.mdmp

evtxexport writes these string values to stdout witout altering them. Because stdout is a text stream, it translates \n to the platform-appropriate line ending. On Windows the \r\n which ends each line in the above string has its \n translated to \r\n, while on Unix the \n remains an \n. The result is that in evtxexport's output, string values with embedded line endings have \r\r\n in them on Windows and \r\n in them on Unix---neither of which is a platform-appropriate line ending.

The correct thing to do is to translate the \r\n in these strings to \n before writing them to stdout, as then stdout will produce the platform-appropriate line ending. (Note that switching stdout to binary mode would not fix the problem, as in that case the line endings would remain \r\n on Unix.)

[joachimmetz]

This is a long way of just asking to make end of lines in the output of record strings platform aware. This is not a high priority for me seeing compatibility issues in specific projects keep me preoccupied.