Ahhh, I now understand the problem. And it's still NOT a Unicode problem.

Within the Windows-Code-Pages, there are Single-Byte-Character-Sets (SBCS) and Multi-Byte-Character-Sets (MBCS). (Again, nothing to do with any flavor of Unicode.) I think us Americans are most familiar with the SBCS-Code-Pages. In fact, I wasn't even aware the VB6 IDE could deal with the MBCS-Code-Pages, but apparently it can.

In fact, here's an MSDN quote:

Asc Function ... The range for returns is 0 – 255 on non-DBCS systems, but –32768 – 32767 on DBCS systems.
Way back, when I first read that, I probably thought they were referring to Unicode, but I now don't think that's the case. I didn't test, but dreammanor seems to have shown this whereas Asc("中") = -10544 and Ascw("中") = 20013. And the MSDN is clear that Ascw returns a Unicode (i.e., UCS-2) interpretation.

Also, just as another FYI, apparently Microsoft worked fairly hard to insure that all the initial Code-Pages (including MBCS ones) were translatable to UCS-2 (and vice-versa). I'm not at all sure that that's still true, and even Microsoft admits that this is a continually evolving effort.

But, regarding VB6, I'd think we'd be fairly safe if we just read these ANSI-Code-Page source code files and just immediately converted them to UCS-2 Unicode before doing anything.

LaVolpe, I didn't study your program enough to know if that's what you're doing. But it does seem that that's necessary if languages like Chinese are going to be correctly handled. If you're attempting to treat all source files as single-byte-characters, that's not going to work in the ANSI-MBCS cases.

Merry Christmas,
Elroy