Hello everyone,
I have recently started to (try) working on the implementation of WinRT speech recognition (Windows.Media.Speech), which seems to be mainly used by a few games right now (e.g. Phasmophobia). I already finished working on the IDLs, and stubs for the most needed interfaces. The first hurdles weren't really hard to solve, but now, as I'm not the most experience Wine dev and WinRT isn't such a big thing in Wine yet, I came across a few issues that I'd like to discuss:
*What are the plans on handling the reuse of common COM-objects across different WinRT dlls? E.g. Creating a vtable for something like IVector<HSTRING>, every time it's used in different DLLs, seems counterproductive and creates unneeded redundant code, because it always provides the same functionality.
*What are the requirements for external libraries to be used in Wine? I thought of using something like VOSK or Mozilla DeepSpeech for voice recognition. Would those be acceptable?
Bernhard
Am Mittwoch, 19. Jänner 2022, 01:32:55 EAT schrieb Bernhard Kölbl:
Hello everyone,
*What are the plans on handling the reuse of common COM-objects across different WinRT dlls? E.g. Creating a vtable for something like IVector<HSTRING>, every time it's used in different DLLs, seems counterproductive and creates unneeded redundant code, because it always provides the same functionality.
It seems a bit similar to IStream, an interface that is commonly implemented by users of certain APIs (e.g. windowscodecs, msi, gdiplus).
We have certain shared data structures in include/wine/ , e.g. list.h and rbtree.h . It seems to me adding a header file that adds a basic IVector implementation around an array of strings might be doable.
Note that we shouldn't export any helper functions from Wine DLLs that don't exist in the same way on Windows. Hence why a statically compiled header is preferable in this case.
*What are the requirements for external libraries to be used in Wine? I thought of using something like VOSK or Mozilla DeepSpeech for voice recognition. Would those be acceptable?
External libraries generally fall into 3 categories:
1) Small self-contained libraries that can be built as PE DLLs, e.g. zlib, libpng, etc: See the libs/ directory in Wine. We import the source, build them with mingw, but we offer distros a way to replace them with their own provided PE files
2) Huge stuff like wine-gecko and mono: They are shipped as PE builds in a separate blob that gets downloaded or provided by the distribution
3) Things that need to talk to the host operating system, e.g. opengl, alsa, xlib, etc: DLLs that interface those libraries are split PE/so modules that communicate past the windows/unix boundary with NT syscall like mechanisms.
I guess the speech libraries probably fall in category 2, or maybe 3. Doing this as a split PE/so module might be helpful if those libraries talk to special hardware or aren't freely redistributable. I particularly have Mac OS in mind here, with its proprietary Siri things and Neural Engine.
-
Bernhard Kölbl -
Stefan Dösinger