by Michael S. Kaplan, published on 2006/04/16 06:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/04/16/577108.aspx
It might take you back to Almost Live and the Lame List, and if so then I was able to inspire the right memories.
It is not a weekly posting, so it's not 'What's weak, this week'. But it will likely just be me periodically posting something that I think shows a certain ignorance of the importance of Unicode/internationalization in software, so perhaps you can think of it as something more like a 'Who put Unicode in the commode' (you have to work a little harder to get the scansion right, but it is possible!).
Anyway, I am looking over at Heath Stewart's blog, and his recent post Opening Patch Files when Compiled for Unicode. Now I am not calling Heath lame here at all -- he isn't, and this is really good information, and I am glad he is putting it out there:
If you want to open a .msp file with the Windows Installer APIs, you must pass
ERROR_OPEN_FAILED(110) is returned. Below is the definition of both
MSIDBOPEN_READONLYfrom msiquery.h in the Windows Installer SDK.
#define MSIDBOPEN_READONLY (LPCTSTR)0
#define MSIDBOPEN_PATCHFILE 32/sizeof(*MSIDBOPEN_READONLY)
LPCTSTRis defined as
UNICODEis defined, which is defined as
sizeof(wchar_t)is 2, the value of
MSIDBOPEN_PATCHFILEis 16 when
UNICODEis defined. If you pass this to either the
MsiOpenDatabaseAfunction or the
ERROR_OPEN_FAILEDis still returned. The value must always be defined as 32.
For the automation method
Installer.OpenDatabasethe second parameter must be set to
msiOpenDatabaseModePatchFileto open a patch, which is always defined as 32.
The lame part is a general approach that people take when they think about Unicode, due to specific attitudes both inside and outside of Microsoft:
Most developers probably haven't run into this problem yet because of support for Windows 95, 98, and Me, where Unicode is not natively supported and it's typically undesirable to have to ship and support two bootstrap applications. Since Windows NT, 2000, XP, 2003, and future platforms support both ANSI and Unicode it makes sense to compile bootstrap applications for ANSI or MBCS.
It is actually this particular prevailing attitude that finally inspired MSLU as a project -- there had to be a way to get people supporting Unicode, even if they did have to support Win9x.
The problem now is that no one wants to support Win9x in their platforms, but if there is any kind of downlevel story involved (whether it is the Windows Installer folks not supporting a Win9x Unicode version of their support or the C++ folks not wanting to ship an MSLU-ized version of MFC, or whatever) it amounts to a passive-agressive, whiney "it's too late to support your Unicode solution in our product, but we have to keep encouraging the customer ANSI solution of our product."
I wonder how many more years will these teams try to wish the problem away (as people did on the Windows side for so many years before approval was given to do MSLU) before they give up and finally do something about it. Because until it is easy to do, until there is a good backcompat story, and until it is the default setting, most people will not choose Unicode for their solution....
This post brought to you by "Ề" (U+1ec0, a.k.a. LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND GRAVE)
# mpz on 16 Apr 2006 8:37 PM:
# Dean Harding on 18 Apr 2006 3:41 AM:
# Michael S. Kaplan on 18 Apr 2006 3:48 AM:
# Dean Harding on 18 Apr 2006 7:21 PM:
# Michael S. Kaplan on 18 Apr 2006 7:54 PM:
# Dean Harding on 18 Apr 2006 9:27 PM:
go to newer or older post, or back to index or month or day