Hi On Thu, May 27, 2021 at 3:11 AM Gert Doering <g...@greenie.muc.de> wrote: > > Have not tested this, just stared a bit at the code. Did not "fix" > the "%s v%s" issue Lev pointed out as this will be fixed in the next > patch... thanks. > > (I do wonder if "support ansi builds" is really something we want, if > that makes the code so complicated - "always UNICODE" seems to be much > simpler. What is the drawback of not supporting "ansi" builds?)
I prefer to write all new Windows code as unicode without any dependency on the defines UNICODE and _UNICODE --- i.e no TCHARs, explicit API calls, no _tprintfs. For old code, an easy option would be to retain the TCHARs, but assume we only build with UNICODE (TCHAR=WCHAR) and going forward don't care to support ANSI builds. As we did with the service. Even for this part of the code, I suspect ansi build is broken -- we never test it, do we. Selva _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
