This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients amaury.forgeotdarc, eric.araujo, loewis, runtux, tarek, techtonik, vstinner
Date 2011-10-16.16:55:03
SpamBayes Score 4.9535314e-09
Marked as misclassified No
Message-id <>
In-reply-to <>
> The problem is that the config file is parsed using
> GetPrivateProfileString, and the result is then passed to TextOut,
> SetDlgItemText, CreateWindow, etc. all of which are defined to accept MBCS
> strings. I agree that this can't work correctly in the general case.

These functions are available with an Unicode API:


> Changing the GUI functions to operate on Unicode strings is certainly
> feasible and a good idea. The main challenge then is the format of the INI
> file. IIUC, GetPrivateProfileStringW is willing to process UTF-16 (with
> BOM) encoded INI files, but I never tested whether it actually does.

bdist_wininst creates a long Unicode string for the INI data, and then encode 
it explicitly:

        if isinstance(cfgdata, str):
            cfgdata = cfgdata.encode("mbcs")

So I suppose that replacing "mbcs" by "UTF-16-LE" and add the BOM should be 

> In porting wininst.exe, it seems tempting to use the TEXT family of APIs.
> I'd advise against that, and recommend to explicitly use the *W functions.

Do we need to keep backward compatibility if we change the format of the config 
data? Or wininst-xx.exe are only usable with trailing config data in the .exe 
Date User Action Args
2011-10-16 16:55:04vstinnersetrecipients: + vstinner, loewis, amaury.forgeotdarc, techtonik, tarek, eric.araujo, runtux
2011-10-16 16:55:03vstinnerlinkissue10945 messages
2011-10-16 16:55:03vstinnercreate