wxUSE_UNICODE+woe issues:

- wxString.fn_str() returns a wide-character C string, not suitable
  for fopen.  But since there's nothing like UTF-8 under woe, it's
  pretty normal: a (say) Japanese string can't be converted to plain
  ASCII.  As a result, all our code need to use a wrapper that will
  call fopen or _wfopen for ANSI and Unicode builds respectively
  (making me wonder why wxWidgets provides a portability in the first
  place).

  Same for loads of other functions, such as chdir, stat, getenv,
  sdt::iostream, etc.

  You'd need something like this:
  #if wxUSE_UNICODE && _WIN32
    FILE* lDmodFileIn = _wfopen(mFilePath.wc_str(), L"rb");
  #else // ANSI&GNU/Linux
    FILE* lDmodFileIn = fopen(mFilePath.fn_str(), "rb");
  #endif // Unicode/ANSI&GNU/Linux

- There are issues with #include order.  One order that was used to
  avoid a crash in ANSI is causing issues in Unicode (cf. BZip.hpp).
