Asking opinion UWP support #216
Comments
|
I'm a bit familiar with that Microsoft UTF-16 choice to support unicode, it's really a pain. So if I understand correctly, in UWP applications, you have to use only the wide char version of functions in the Win32 API, you can't use the ANSI version. What is exactly the issue with tests then? Sorry, I don't have a Windows environment to test right now. |
|
I'm glad you have interest for UWP support! Currently, the policy is to support unicode by utf-8 and according to their articles, microsoft updated the functions which were once for ANSI to ones for utf-8. Assuming this is true, the problem would be files like examples/client/getopt.h (which was last updated in 2015, before the policy update). When _UNICODE is defined, which is the case for UWP, getopt.h tries to offer functions for utf-16. This leads to compile errors as client is written for "char"s not "wchar_t"s. I guess one way of handling this issue would be finding another Windows implementation of getopt that supports utf-8. Though I cannot promise, I'll try to find some time for further investigation... |
|
OK I see the problem with getopt, I think it can be solved. However, what is the issue with tests then, since they don't rely on it? |
|
The errors for the tests come from a different place. They are related to the C function calling convention. To support Unity, I build with -DCAPI_STDCALL=ON and this leads to a conflict with the callback functions from examples and tests when built for UWP. Besides these there are some more sources of errors. See below for the error messages. The below image is about the first half of them and the text file is the full list of them. One good news is that all errors from datachannel-client is coming from the unicode issue. So, we can try solving the issues one by one, starting from the unicode (i.e. getopt) one, I guess. Do you have a particular plan in mind to solve the getopt issue? In case you have, since I work on a Windows machine, I can give it a try. |
|
Actually, the calling convention issues are the easier to fix, so I'll fix them first. It seems getopt for Windows separately implements an Ansi version and a Unicode version, and it doesn't call Win32 API. Since the example only requires the Ansi one, I think the Unicode one can just be removed. |
|
Both are done in #219 @hanseuljun Could you please try it and tell me how it goes? |
|
Thanks a lot for the update! It compiles well, but running datachannel-tests returns this error message. This cryptic error message 'A dependent dll was not found' does not tell which dll is missing. |
|
I'm back! So, I tried the UWP build and what I found was errors coming from libsrtp this time. I don't know why I haven't seen them last time, maybe I did set NO_MEDIA on I guess. I submitted a pull request fixing libsrtp first and I'll try to not forget coming back to this issue... |
|
OK, you didn't see these problems last time because libsrtp wasn't a submodule, instead the library automatically linked against libsrtp on the host if present. |
|
Thanks for the clarification! |
|
The above libsrtp pull request got merged, though I'm not sure you are willing to update to a version for that is not a public release... |
|
No it's fine, they don't seem to release often and I need the other lib usrsctp to be bleeding edge anyway. |
|
I tried to go through the above "unable to activate Windows Store app" error a few times but I couldn't figure out what causes them. It seems like a dll files is missing but there is just no way I can find which one is missing... Given that the examples are already not included in the current version of the libdatachannel UWP build, I think it would be fine to close this issue for now and maybe reopen it later. |
|
OK, I'm closing the issue, please reopen if you need. Back in the day I used Dependency Walker to debug missing DLL issues, maybe it can help here? |
|
I have tried that but I still couldn't figure out which was missing... |
|
That's a shame, you are nearly there... Is there any way I can help on this? |
UWP is what Microsoft is pushing as an application framework, and unfortunately, since I work on AR headsets and Microsoft is currently the only competitive manufacturer of them, I have no choice but follow their directions. However, I am not sure you would like to perfectly support UWP.
Currently, libdatachannel works fine for UWP as a library, but examples and tests don't work. I can detour this with the NO_TESTS and NO_EXAMPLES options you thoughtfully provide, but wanted to ask you are interested in the fixes of the tests and examples.
The root cause of failure to build them comes from an old mistake from Microsoft. When everyone started supporting unicode, instead of utf-8, they chose utf-16, which is based on 16-byte characters. This made them end of using wchar_t instead of char for strings. So, when you build applications to support unicode, the Windows APIs by default want const wchar_t* as inputs, instead of const char*.
Also, making this a little bit more complicated, though it is part of Microsoft finally making the right decision, they are coming back to utf8: https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page. If you go this way, this means code such as examples/client/getopt.h becoming obsolete. They handle defining of _UNICODE as a sign to use wchar_t instead of char, which is no longer the recommendation.
I'll stop here for now since this is already quite terrible, but in case you interested in adding UWP support to libdatachannel, let me know. To build as UWP with cmake, you can add
-DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION="10.0"
It means an application framework for Windows Store (Microsoft had many of them) and the one for Windows 10 (UWP, the current one which I hope last longer than its ancestors.)
An example command would be
cmake -S . -B .\build -G "Visual Studio 16 2019" -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION="10.0"
The text was updated successfully, but these errors were encountered: