It seems to be very difficult to find any information about what is actually supported. My belief is that the codepage you use has to map exactly onto one of the defined ANSI font ranges in Windows. See the 'code page bitfields' list in the FONTSIGNATURE structure for what GDI understands, at http://msdn2.microsoft.com/en-us/library/ms776441.aspx.
Summary if this is correct: supported codepages are 1252, 1250, 1251, 1253, 1254, 1255, 1256, 1257, 1258, 874, 932, 936, 949, 950, 1361, and IBM/OEM codepages 869, 866, 865, 864, 863, 862, 861, 860, 857, 855, 852, 775, 737, 708, 850 and 437. I'm not even sure that the OEM codepages would work. Summary of my thinking: Windows Installer uses the same codepage to translate everything as it does to display. To display, it has to create fonts using one xxx_CHARSET value as defined in the LOGFONT structure for ANSI compatibility (recall that Windows Installer 1.0 was designed primarily for installing Office 2000 on Windows 9X). Only codepages which map exactly onto one xxx_CHARSET value will work correctly. Therefore I would expect that there's a call to TranslateCharsetInfo with TCI_SRCCODEPAGE, fairly early on in execution, to determine what the correct CHARSET value is. If it fails - which it will if not one of the specified values above - Windows Installer will fail to run the package. By its nature UTF-8 cannot have an associated ANSI charset. Because of this you *cannot* localize anything that is installed in the package. Only localize the strings that are displayed in the UI. If you're trying to display strings in the installation UI in an unsupported language/character set, you'll have to write some external UI. If you want to localize your application I would strongly recommend using the satellite DLL model, where you have separate DLLs containing your localized resources. .NET Framework supports satellite DLLs implicitly by probing in folders named after cultures (e.g. en-US, de-DE) before looking in language-neutral folders. See "Creating Satellite Assemblies" at http://msdn2.microsoft.com/en-us/library/21a15yht.aspx and the System.Resources.ResourceManager class. MFC supports loading resources from a different DLL instance than the application or DLL. See Tech Note 57 for MFC 6.0 at http://msdn2.microsoft.com/en-us/library/x6h91d9w.aspx or "Localized Resources in MFC Applications: Satellite DLLs" at http://msdn2.microsoft.com/en-us/library/8fkteez0.aspx for MFC 7.0 and later. ATL also supports setting a resource instance: see SetResourceInstance (ATL 7.0 and later) or set the m_hInstResource for ATL 3.0 and earlier. Finally Windows Vista has added a mechanism they're calling MUI Technology, for which see "Multilingual User Interface" in the SDK at http://msdn2.microsoft.com/en-us/library/ms776201.aspx. None of this obviously helps if you have already authored your application relying on being able to install localized strings in the installation package. -- Mike Dimmick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DEÁK JAHN, Gábor Sent: 14 December 2007 01:36 To: WiX-users Subject: [WiX-users] Unicode. Unicode? Hello, did anybody find a way to make codepage 65001 work? I don't need CJK but a couple of Latin 3 (ISO-8859-3) characters, sadly not supported by any of the Windows codepages. Building the MSI seems to go all right but it refuses to run with an error: "This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package." ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
