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
