FalsePattern / jwin32

Win32 and DirectX mappings for java using Project Panama. Ignore the C# tag, it's just reference code used for decompilation
GNU General Public License v3.0
11 stars 3 forks source link

Windows Runtime (WinRT) APIs #5

Open Thomas-Vos opened 2 years ago

Thomas-Vos commented 2 years ago

Do you have any plans to support the WinRT APIs?

The WinRT APIs are COM based. I tried including one of the WinRT headers config.h headers, and jwin32 generated a lot of COM wrappers. The resulting JAR was around 114MB and it took quite a long time to generate.

The generated COM APIs seemed to be alright, but I was unable to test them because I could not figure out how to link with the WinRT libraries.

Do you know how to link with the WinRT APIs in Java?

There is a wrapper for the WinRT APIs for C++ to make the APIs more accessible, where they mention you can link with an umbrella framework called WindowsApp.lib. Not sure if that is related when using the WinRT COM APIs directly. See: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/get-started#linking

Some examples how to use WinRT from C:

Maybe it is easier to just use the WinRT APIs from C++ using the C++/WinRT wrapper library (headers projection). The WinRT APIs would be easier to use that way. I think in that case the best way would be to create DLL which uses the WinRT APIs from C++, and use that DLL using Panama from Java. This would solve the linking issues, as that could be done from C++ using the WindowsApp.lib. Do you have any experience with the WinRT APIs?

FalsePattern commented 2 years ago

To use WinRT method calls, you need to include ole32 for COM, and the respective winrt library. For instance, to use methods from windows.ui.h, you need to also load the Windows.UI library. You can find the list of the winrt libraries in System32, all of them start with Window.

However, the main problem with adding WinRT support is that the COM object and COM interface UUIDs don't seem to be available in any runtime dll libraries, and are instead included inside C/C++ programs during compile time. To fix this issue, all of the UUIDs that exist inside WinRT would need to be included in jwin32. A possible alternative is what you said in the last paragraph, which is wrapping WinRT calls in a custom native library, and including that one.

Unfortunately, i don't see an easy way of fixing this issue currently without manually hunting down every single WinRT COM Interface IID and RuntimeClass UUID.