Regarding WinRT and external libraries

[Stefan Dösinger]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220119/9bfc0db8/attachment.sig>