The really messy problem is that the standard as written before my complaints to Pelles and Watcom was ambiguous which allowed the other compiler writers to interpret %s==TCHAR, the most desirable and least obfuscated method for Windows TCHAR development. The standard was clarified shortly after to say %s==8-bit char which is hostile to Windows TCHAR development but it does say the Pelles implementation is according to the standard and the other compilers are not. This puts compilers in two camps with incompatible handling of %s and neither side can change because of the compatibility problems that would arise and neither side wants to change because there is or was a standard that said the chosen method was right. This means that for the foreseeable future Pelles %s handling will be incompatible with MSVC unless you make Pelles link those functions against MSVCRT.DLL.
Since this problem looks like it won't be going away I've had to revise my macros that adapt %s to the correct width depending on the compile and compiler. These macros don't handle the case where Pelles is linked to Microsoft LIBS like MSVCRT.DLL.
#define W_pch "lc"
#define W_pst "ls"
#ifdef __POCC__
#define A_pch "c"
#define A_pst "s"
#ifdef UNICODE
#define T_pst W_pst
#define T_pch W_pch
#else
#define T_pst A_pst
#define T_pch A_pch
#endif
#else
#define A_pch "hc"
#define A_pst "hs"
#define T_pst "s"
#define T_pch "c"
#endif
// TCHAR test[256]; _sntprintf(test,NELEM(test),_T("%") A_pst _T("%") W_pst _T("%") T_pst,"char",L"wchar",_T("tchar"));