Thank you for your vote of confidence.
I have not proceeded with any code changes because I have not yet fully
convinced myself that this is the best solution.
My guess at this point is to output per code page compliant strings because the
enclosing parent data structure is organized by LCID/charset. This solution
seems to be the least bad one.
The complications and points to keep in mind are (at least)…
1. Although Unicode is one of the “charset” identifiers, it is not clear
if that is considered a binary format for the purposes of the “wType” field.
Is there any way to get more information on the meaning and intent of this
field?
2. Distinguishing between the Microsoft documentation that is discussing
the input to the resource compiler (rc.exe) (like
http://msdn.microsoft.com/en-us/library/windows/desktop/aa381058(v=vs.85).aspx)
vs. the in file data structures (like
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646987(v=vs.85).aspx)<http://msdn.microsoft.com/en-us/library/windows/desktop/ms646994(v=vs.85).aspx)>
3. If trustworthy,
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646987(v=vs.85).aspx
may provide the answer. Quoting the last paragraph:
“A String structure may have an szKey value of, for example, "CompanyName" and
a Value of "Microsoft Corporation". Another String structure with the same
szKey value could contain a Value of "Microsoft GmbH". This might occur if the
second String structure were associated with a
StringTable<http://msdn.microsoft.com/en-us/library/windows/desktop/ms646992(v=vs.85).aspx>
structure whose szKey value is 040704b0 — that is, German/Unicode.”
However, there is clearly support in the Windows Explorer for the unexpected
Unicode format string without the 0n1200/0x04B0 indicator. Is there any
possibility of getting an explanation from someone familiar with the Windows
Explorer internals? Is this Explorer behavior happenstance or is there
specific code to comply with some as of yet unknown to us Microsoft guidelines
or best practices?
Given my current understanding, I expected that the Windows Explorer would have
shown only the first character of the string values because of the second byte
of the string being a null string terminator. Hopefully, the Windows Explorer
is not using the “IsTextUnicode” API because it is mostly considered a “bad
thing” by those in the know
(http://blogs.msdn.com/b/michkap/archive/2005/01/30/363308.aspx)
Keeping this perspective, WiX has been around a long time and there has been
little outcry on this topic. I raised the issue because I wrote an unrelated
tool that audits my company’s products for compliance with my company’s
specific release criteria. My program reported that the Burn bundle under
test was not compliant with a particular test.
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Wednesday, July 10, 2013 10:41 AM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Possible flaw in Burn bundle output .exe's Version
Resource?
Mike, did you get a fix to this? It sounds like you understand the ancient data
structure better than we did. <smile/> If there is an issue here it would be
great to come up with a root fix.
On Fri, Jul 5, 2013 at 4:10 PM,
<mike.strat...@bentley.com<mailto:mike.strat...@bentley.com>> wrote:
Bob,
Thank you for your quick response.
Although closely related to the bug report that you listed below, this is
different problem.
The “wType” indicates binary/text data to follow. Unicode may be considered
binary, but the enclosing VerFileInfo structure’s “charsetID” value should be
0n1200/0x04B0 for Unicode and 0n1252/0x04e4 for English/Multilingual, etc. as
listed on
(http://msdn.microsoft.com/en-us/library/windows/desktop/aa381049(v=vs.85).aspx)
Perhaps the solution is to set “wType” to zero, and output a code page (not
Unicode) appropriate string. I don’t really like this code page based
solution, but it seems to be in the spirit of this ancient data structure.
From: Bob Arnson [mailto:b...@joyofsetup.com<mailto:b...@joyofsetup.com>]
Sent: Friday, July 05, 2013 5:10 PM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Possible flaw in Burn bundle output .exe's Version
Resource?
Known bug: https://sourceforge.net/p/wix/bugs/3169/
On 05-Jul-13 13:27, mike.strat...@bentley.com<mailto:mike.strat...@bentley.com>
wrote:
Before I file a bug (or change the code myself), I am looking for opinions on
the following.
When I open a Burn bundle output installer exe using the Visual Studio Resource
Editor, various customary Version Resource fields like CompanyName,
FileDescription, etc. are empty. However, these fields are shown in the tool
tip when hovering over the .exe in the Windows Explorer. They are also shown in
the Windows Explorer Property Details tab.
According to
http://msdn.microsoft.com/en-us/library/windows/desktop/aa381058(v=vs.85).aspx<http://msdn.microsoft.com/en-us/library/windows/desktop/aa381058%28v=vs.85%29.aspx>,
the “charsetID” should be 0x04B0 for Unicode and 04e4 is default English. For
this particular example, at offset 0x12C129BD, the hex dump below shows that
0n1252/0x04e4 is specified yet the following string is in Unicode not ASCII or
UTF-8.
0x12C12987 00 00 00 00 00 a4 02 00 00 00 00 53 00 74 00 72 00 69
.....¤.....S.t.r.i
0x12C12999 00 6e 00 67 00 46 00 69 00 6c 00 65 00 49 00 6e 00 66
.n.g.F.i.l.e.I.n.f
0x12C129AB 00 6f 00 00 00 80 02 00 00 00 00 30 00 34 00 30 00 39
.o...Ђ.....0.4.0.9
0x12C129BD 00 30 00 34 00 45 00 34 00 00 00 5c 00 3c 00 00 00 43
.0.4.E.4...\.<...C
0x12C129CF 00 6f 00 6d 00 70 00 61 00 6e 00 79 00 4e 00 61 00 6d
.o.m.p.a.n.y.N.a.m
0x12C129E1 00 65 00 00 00 00 00 42 00 65 00 6e 00 74 00 6c 00 65
.e.....B.e.n.t.l.e
0x12C129F3 00 79 00 20 00 53 00 79 00 73 00 74 00 65 00 6d 00 73 .y.
.S.y.s.t.e.m.s
0x12C12A05 00 2c 00 20 00 49 00 6e 00 63 00 6f 00 72 00 70 00 6f .,.
.I.n.c.o.r.p.o
0x12C12A17 00 72 00 61 00 74 00 65 00 64 00 00 00 50 00 26 00 00
.r.a.t.e.d...P.&..
The values are specified using the typical
<?define COMPANY = "Bentley Systems, Incorporated"?>
<?define COPYRIGHT="Copyright (c) 2013 $(var.COMPANY)"?>
<Bundle Name="$(var.APPDISPLAYNAME)" Version="$(var.VERSION)"
Manufacturer="$(var.COMPANY)" Copyright="$(var.COPYRIGHT)"
UpgradeCode="$(var.UPGRADE_CODE)" IconSourceFile="$(var.MF_ICON)">
Is this a bug or am I misunderstand this arcane minutiae?
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
--
sig://boB
http://joyofsetup.com/
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
