8032443: ,Java Access Bridge version strings need to be fixed

[Pete Brunet]

Hi Magnus, Here's the update:
http://cr.openjdk.java.net/~ptbrunet/JDK-8032443/webrev.01
in particular line 134 at
http://cr.openjdk.java.net/~ptbrunet/JDK-8032443/webrev.01/windows/native/sun/bridge/AccessBridgeStatusWindow.RC.frames.html

Pete

On 2/24/14 1:55 PM, Pete Brunet wrote:
> Hi Magnus, Thanks very much for looking at this.
>
> On 2/19/14 3:55 AM, Magnus Ihse Bursie wrote:
>> On 2014-02-18 05:22, Pete Brunet wrote:
>>> Please review this change:
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8032443/webrev.00/
>>>
>>> for this bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8032443
>>>
>>> Some resource compiler defines are need so the JAB DLLs Properties sheet
>>> will have the proper information.  This change fixes the names that are
>>> displayed.
>> Pete,
>>
>> Even though I don't know how these RC flags are interpreted, I notice
>> that virtually all other libraries that has a JDK_FNAME and
>> JDK_INTERNAL_NAME also has a JDK_FTYPE=0x2L.
> From
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa381058%28v=vs.85%29.aspx
> The FILETYPE 0x02 is
> VFT_DLL    File contains a dynamic-link library (DLL).
>
> It's defined in winver.h.
>> (In fact, generalizing the pattern
>>
>>     RC_FLAGS := $(RC_FLAGS) \
>>         -D "JDK_FNAME=FOO.dll" \
>>         -D "JDK_INTERNAL_NAME=FOO" \
>>         -D "JDK_FTYPE=0x2L",
>>
>> that appear all over the place is something that has been on our
>> agenda, unfortunately for far too long without happening).
>>
>> It seems that there need to be a good reason for these libraries to
>> not match this pattern.
> In my case the 0x02 is defined in the RC file, but I'll change the patch
> to match what you describe above.
>> /Magnus