[python-win32] Suggestions for a unicode build

[Roger Upole]

Tim Roberts wrote:
> Roger Upole wrote:
>> Mark suggested that I get some feedback from the community regarding
>> some of the issues involved in creating a Unicode build of win32api.
>>
>> Some functions already allow you to call the ansi or wide-character 
>> version,
>> such as FormatMessage/FormatMessageW.  This leaves some ambiguity
>> as to how they should behave in a Unicode build.
>> Some options:
>>     Have only FormatMessage, calling FormatMessageW
>>     Leave both FormatMessage and FormatMessageW, both calling
>>         FormatMessagW (this would probably be the most backward 
>> compatible)
>>     Have FormatMessage as unicode and also add FormatMessageA in case
>>         there's a need to explicitely call the ansi function.
>>
>
> 4. Have FormatMessage always call FormatMessageW and supply the MSLU DLL
> for Win98. That is probably the best option for performance, since the
> number of ANSI-only platforms is so low now.

Just supplying the Dll is not sufficient.  The .pyd would also have to be 
linked
against unicows.lib, which would mean creating a separate release for
win98.

>> It may also be possible to release the module in both wide-character and
>> ansi.
>> The question here:  Is it worth the trouble ?
>>
>
> In my opinion, no.


Do the two of us constitute a consensus ? :)

>> Another issue is whether or not to remove obsolete functions, 
>> specifically
>> the functions that deal with .ini files.  (WriteProfileSection,
>> WriteProfileVal, etc)
>> Technically, they've been obsolete since win95, but that doesn't mean 
>> noone
>> uses them.
>>
>
> I don't think Microsoft has ever documented them as obsolete.  In fact,
> there was an article in MSDN Magazine just two years ago showing how to
> use the profile functions from .NET code, and recommending their use
> over the registry for user-specifiable parameters.
>
> Now, it's true that it is easy to write a Python module to parse INI
> files, but I don't think it's really necessary to take any action at all
> here.  The profile functions still work, so let's keep using them.

The MSDN docs for the Profile functions all have a comment that says
"This function is provided only for compatibility with 16-bit versions of 
Windows.
Applications should store initialization information in the registry."

I'm not averse to leaving them in as long as everyone's okay with
them still calling the ANSI functions.  However, this may still require
extra work with Py3k where strings are all Unicode.

          Roger