Alex Taylor, 20091218 On Sun, 1 Nov 2009 08:54:18 +0200 Steven Levine wrote: >> > >Pretty much. The standard library string functions operate on a >> > >per-byte level; they neither know nor care how many displayable >> > >characters those bytes represent. > > > > Most runtimes also have wide-character string functions. True, but all of OS/2's NLV DBCS codepages are byte-based variable-width encodings, so the wide-character functions are actually pretty useless. (They're more or less useable when dealing with UCS-2 UniChar strings, which are USHORT sequences; but since the OS/2 ULS API provides its own, more capable, family of functions for dealing with same, they're still not terribly useful for the most part.) >> > >The main worry is in dealing with double-byte characters that contain a >> > >backslash \ as the second byte. C compilers (and runtimes) all seem to >> > >be smart enough to recognize them, so you don't have to escape them... >> > >NORMALLY. > > > > In C you are going to have to escape them if they are followed by a > > character the look like a valid backslash escape. For example "\F" will > > typically pass through unsullied while "\B" will not. I could be mistaken, but I'm pretty sure that if a DBCS codepage is used (or specified), the C compiler generally knows enough to ignore any \ that occurs after a DBCS lead byte. > > >from memory, I think STRINGTABLE resources have to escape their >> > >secondary-byte backslashes but all other items (e.g. MENUITEMS, dialog >> > >strings, etc) must not. (Unless I have that backwards... like I said, >> > >this is from memory.) > > > > If you find an example of this, I'd like to see it. You've been a lot > > more involved in the gory details of DBCS than I have. I don't remember very clearly now, unfortunately. I mostly just arrived at my conclusions through repeated experimentation in trying to build the XWorkplace Japanese DLL. I could probably work it out if I dug into the sources for a while, but it may be a while before I can get around to doing that. I really should, though... frankly, this is the sort of thing that needs to be quantified and written down. >> > >properly. Some backslashes had to be escaped, others had to be left >> > >unescaped. And it didn't really compile reliably unless I was actually >> > >running under codepage 932 (Japanese), regardless of the command-line >> > >switches I used. > > > > Was this with or without the DBCS variable set in the environment? Which DBCS variable? I did try setting all the relevant command-line switches in the compiler(s) that I could find, without it helping much.