Possible Regression

[amarcionek]

Testing the latest tip of master and found some issues with a few of the platform related functions. Specifically, there were a number of functions I added back in November in #532. All of the MPR functions and some of the security functions aren't working. I noticed they were modified in #541. Likely the cause is the change to String from WString. So I changed a few of the structs back to WString and retested all of MPR with success.

Testing this on Windows 10 and Server 2012 R2.

[amarcionek]

Further investigation reveals its just the structure members. I can keep the function signatures as String.

[twall]

You should be able to have the default w32 type mapping handle those, maybe
it's because the struct is declared outside of the library mapping which
defines the type mapping options?

On Wednesday, June 1, 2016, Adam Marcionek notifications@github.com wrote:

Further investigation reveals its just the structure members. I can keep
the function signatures as String.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#668 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAuMrSUCQ588J51xm-5S3rvVvcn2zoU0ks5qHef0gaJpZM4Ir45k
.

[amarcionek]

Bingo. I moved the definition of NETRESOURCE out of Winnetwk.java and into Mpr.Java where the instance uses W32APIOptions.DEFAULT_OPTIONS, changed the structures back to String and it works now. There is no INSTANCE in Winnetwk becasue its not a DLL and so Native.loadLibrary wouldn't make sense.

Is this the fix or is there another way to keep those in Winnetwk since that is JNA best practice? I'm happy to move those structures into the relevant DLL files if so.

Update: Also, if I go ahead and make this change, should I only move the structures that are at issue or all of them? E.g. NETRESOURCE is the only one I would move. Same is true for SHARE_INFO_* structures in LMShare, I would move them to NetApi32.

[matthiasblaesing]

My analysis: by default java string is mapped to char_, but the Win32 functions expect wchar_ (always or depending on calling style selected by w32.ascii). When a struct field is declared as WString the mapping is fixed to wchar* and it works (as long as the unicode variants of functions are invoced).

The PR is not yet complete - I'll have to look through the over files touched by #541, to adjust all structures, affected in the same way.