Correct. I found the files that I had to use to work around problems, and they’re OCX files not DLL files (even though the internals are DLLs). Though again notice that this was VB6’s use of its own language version, no foreign codings involved.

VC++6 had trouble with Unicode but I don’t remember now if it had trouble with its own language version (MSDN pages sure did though). Actually VC++2005 SP1 still has some trouble with Unicode. I ought to try VC++ 2008.

“Perhaps you would have been happier if Xp was not released until VS.NET was released”

No, XP should have been released when XP was ready for release, and that was when XP SP2 was released. I hold nothing against releasing CTPs as CTPs, and XP prior to SP2 should have been released as CTPs. It is fortunate that Microsoft did the right thing with SP2, not charging customers double to get a bugfix release.

Microsoft also did the right thing with some service packs for Visual Studio 6, fixing bugs without charging extra. I’ve read enough about regressions from SP5 to SP6 to suggest that Microsoft’s memory needs refreshing. VS6 SP7, VS2002 SP2, VS2003 SP2, and VS2005 SP2 are sorely needed.

Anyway, in this case the OS issues and language library issues appear to be independent. I hadn’t recalled which library files were involved in this particular problem, but later you and I both found that this one involved language libraries. I agree that COMDLG32.DLL isn’t a problem here.

Sunday, March 02, 2008 8:37 PM by ndiamond

Yes, the characters assigned to code points between 0×80 and 0xFF differ between the ISO standards and the ANSI standards. The characters in that range in most Windows fonts are defined by ANSI standards.Fortunately, many of us don’t have to worry about code paged character sets any more.

You’re right, I should have been more specific and said “Xp was designed with the single world-wide binary model concept, and MS made great strides towards reaching that goal in many of the feature areas.” Some functionality and API stayed for backwards compatibility. Windows Vista goes even further. Of course, one of the inhibitors to advancements in OS development is backwards compatibility issues.

The problems you saw in the Jpn version of Xp were VB runtime issues. VB was notoriously renouned for its inability to deal with various character sets and charset issues. VB.NET is much better.

Perhaps you would have been happier if Xp was not released until VS.NET was released, but you know what they say about being on the bleeding edge of the sword.

Friday, February 29, 2008 11:35 AM by I.M.Testy

The ISO Latin 1 character set assigns code points 0×80 through 0×9F to control characters. You want Windows code page 1252 which assigns many of those code points to printable characters.

“Xp is a single worldwide binary”

It is not. Vista comes a lot closer to that goal than XP does.

“and all internal processing is in Unicode.”

GetProcAddress. gethostname. DbgPrint. You’re very close to right though (a lot closer than the assertion that XP is a single worldwide binary).

XP came out before Visual Studio .Net. It was still necessary for VB6 programs to run on XP. One or two service packs were enough to make Japanese VB6 executables display Japanese correctly on Japanese XP. As mentioned, I’m not sure if these problems were because of COMDLG32.DLL or because of runtime libraries for various Visual Studio languages.

Friday, February 29, 2008 4:03 AM by ndiamond

Actually, I do mean the ANSI Latin 1 character set which the the Windows 1252 (Latin 1) code page is derived, as referenced here (http://www.alanwood.net/demos/ansi.html) and here (http://orwell.ru/info/ansi.htm) and here (http://www.medcalc.be/manual/ansi_character_set.php), and other places such as the ANSI library. But, nice try!

WRT to COMDLG32.DLL, I specified the Windows Xp operating system. Xp is a single worldwide binary and all internal processing is in Unicode. Therefore, your language version argument is outdated and a false assumption that would cause a tester to waste valuable cycles. But, I am sure you knew that.

I would however suggest that you upgrade from NT 4.0 to Window Xp or Vista.

Friday, February 29, 2008 12:12 AM by I.M.Testy

That is almost well defined. It would be more accurate to say Code Page 1252 since, e.g., you probably want 0×80 to mean what Code Page 1252 says instead of what ISO Latin 1 says. But anyway it’s pretty close.

“COMDLG32.DLL’s file save functionality”

That is poorly defined. In some cases you need to say which language version of Windows is involved. In some cases even in the NT series I’ve seen misbehaviour but I’m not sure if that’s because of COMDLG32.DLL or because of runtime libraries for various Visual Studio languages. Anyway since we are talking about code pages and not Unicode, I think you’d better specify which language version of COMDLG32.DLL.

“NTFS file system”

That too. I haven’t tested to see if NTFS partitions that are formatted while a Turkish environment is active get their upcasing tables defined appropriately for Turkish, but from what I’ve read about the design it seems to me that they “should” get correct upcasing tables. The Win32 and NT APIs participate in deciding whether two filenames that differ only in casing are identical or not, but the partition’s upcasing table ought to be paramount in order to preserve the partition’s integrity.

Thursday, February 28, 2008 9:53 PM by ndiamond