Windows: Support for UCRT? #619

New issue

Open

opened 2023-09-03 08:31:54 -05:00 by ghost · 1 comment

ghost commented

2023-09-03 08:31:54 -05:00

(Migrated from github.com)

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.

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.

Youw commented

2023-09-04 03:53:59 -05:00

(Migrated from github.com)

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.

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.

👍 1