You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the last few years more recent builds of Windows 10 have gained better and better support for UTF8. It may be possible to switch to the char based APIs for the Windows backend and switch to linking to UCRT as well. This would, in theory, enable for more code to be reused between the Windows backend and POSIX systems.
If this were to be done, we could probably also switch to using char strings exclusively in the public API of hidapi. I found it strange hidapi even uses wide characters, and I assume it is related to the Windows backend.
The text was updated successfully, but these errors were encountered:
Lets separate the two things: switching from wchar_t to char in the public API and switching from CRT to UCRT for Windows backend. Those are totally independent things.
Stop using wchar_t in the public API - I like that idea very much, and that is something for v1 for sure. That is a huge backward incompatible API change and I don't see it happening any time soon. It does not require using UCRT - the legacy CRT library still can be used with that just fine.
As for using/switching to UCRT - I don't have a strong oppinion as I haven't used it myself yet. What I'm sure is that it would complicate deployement for some users, specially for those who still need Windows7 support. And it would require some efforts to fix something that is not broken as of yet.
Now regarding re-using code. There'are 4 different backends, not just Windows and POSIX. The only code that can really be re-used is mostly not related too strigns conversions (e.g. hid_enumerate or hid_error). Most of other code is platform-specific and won't be re-used anyway.
I found it strange hidapi even uses wide characters, and I assume it is related to the Windows backend.
There're mostly legacy reasons for that - Alan Ott chose to use it at the time and we can't "just change" it as of this moment.
I guess his motivation was the fact that most HID devices are USB HID devices, and by USB standard - strings are UTF16-LE characters which are easier to convert to wchar_t than to anything else. Note that the initial API was designed back in 2010 - UTF8 wasn't as widely popular back then.
In the last few years more recent builds of Windows 10 have gained better and better support for UTF8. It may be possible to switch to the char based APIs for the Windows backend and switch to linking to UCRT as well. This would, in theory, enable for more code to be reused between the Windows backend and POSIX systems.
If this were to be done, we could probably also switch to using char strings exclusively in the public API of
hidapi
. I found it strangehidapi
even uses wide characters, and I assume it is related to the Windows backend.The text was updated successfully, but these errors were encountered: