Direct2D Anwendung

[Kas Ob.]

Zitat von pcoder:

@Kas Ob.
Also nur eine Pascal declaration order (VTable) kann korrekt funktionieren, aber welche?
Für IDWriteFontSet1 gibt es nun noch eine weitere Variante hier

Delphi-Quellcode:

    function GetFilteredFonts(const {count: indexCount} indices: PUInt32; indexCount: UInt32; out {COM out pointer} filteredFontSet: IDWriteFontSet1): HRESULT; stdcall; overload;
    function GetFilteredFonts(const {count: fontAxisRangeCount} fontAxisRanges: PDWRITE_FONT_AXIS_RANGE; fontAxisRangeCount: UInt32; selectAnyRange: BOOL; out {COM out pointer} filteredFontSet: IDWriteFontSet1): HRESULT; stdcall; overload;
    function GetFilteredFonts(const {count: propertyCount} properties: PDWRITE_FONT_PROPERTY; propertyCount: UInt32; selectAnyProperty: BOOL; out {COM out pointer} filteredFontSet: IDWriteFontSet1): HRESULT; stdcall; overload;

Strangely enough it seems Rust guys ditched this IDWriteFontSet1 altogether

I am not sure what exactly is your question, so sorry, but if you asking about the correctness of the implementation and VTable layout, then using the header file lets say from https://github.com/apitrace/dxsdk/bl....h#L3053-L3099 will be correct as long as you are using Visual Studio compiler, but as i listed few example earlier and how even Rust struggling to fix this mess, as suggested a correct layout and re-ordering of these overloaded interface methods that will fic this once and for all.
And the correct order for Pascal/Delphi and Rust and any other compiler or language (as long it will not act like VS compiler and switch order) should be as posted before this one :

Delphi-Quellcode:

    function GetFilteredFonts(indices: UINT32;
                              indexCount: UINT32;
                              out filteredFontSet: IDWriteFontSet1): HResult; overload; stdcall;

    function GetFilteredFonts(properties: PDWRITE_FONT_PROPERTY;
                              propertyCount: UINT32;
                              selectAnyProperty: BOOL;
                              out filteredFontSet: IDWriteFontSet1): HResult; overload; stdcall;

    function GetFilteredFonts(fontAxisRanges: DWRITE_FONT_AXIS_RANGE;
                              fontAxisRangeCount: UINT32;
                              selectAnyRange: BOOL;
                              out filteredFontSet: IDWriteFontSet1): HResult; overload; stdcall;

Simply order-reverse overloaded methods at first occurrence, of course if they are scattered between other methods then group them at first occurrence.

The header mentioned at https://www.winsoft.sk/win32api.htm is wrong and doesn't comply with Windows SDK, so i will assume someone might tried one function and only fixed it by shuffling them and didn't try the others, or just gave up, the order is wrong and look like this

Delphi-Quellcode:

    procedure GetFilteredFonts(const {count: indexCount} indices: PUInt32; indexCount: UInt32; out {COM out pointer} filteredFontSet: IDWriteFontSet1); safecall; overload;
    procedure GetFilteredFonts(const {count: fontAxisRangeCount} fontAxisRanges: PDWRITE_FONT_AXIS_RANGE; fontAxisRangeCount: UInt32; selectAnyRange: BOOL; out {COM out pointer} filteredFontSet: IDWriteFontSet1); safecall; overload;
    procedure GetFilteredFonts(const {count: propertyCount} properties: PDWRITE_FONT_PROPERTY; propertyCount: UInt32; selectAnyProperty: BOOL; out {COM out pointer} filteredFontSet: IDWriteFontSet1); safecall; overload;

[TiGü]

I think the problem with the MfPack translations is that at some point they took the order from the MSDN website (or auto-generated documentation) instead of using the real header files from the Windows SDK one-to-one.

[Kas Ob.]

Zitat von TiGü:

I think the problem with the MfPack translations is that at some point they took the order from the MSDN website (or auto-generated documentation) instead of using the real header files from the Windows SDK one-to-one.

No, the problem is not that, Windows SDK header and the documentation are correct and identical, the problem exist in Microsoft compiler and undocumented behaviour, this is what cause this mess, the compiler rearrange VTable layout at its own, hence producing its own layout that will work and always work with the same headers, the problem is different compilers will follow strict layout and this layout doesn't with the binary produced by lets say VS compiler, but all these headers belong to Windows components that produced by that quirky compiler and hence all other compilers need to adjust their own header to make their own binary compatible with these shipped with/for Windows, in this case Media Foundation and DirectX ( yes Direct3d and DirectDraw both suffer from this very strange binary when it comes to overloaded interface methods)

[pcoder]

Zitat von TiGü:

using the real header files from the Windows SDK one-to-one.

Im SDK header (.h) file gibt es keine Beschreibung der ABI-Reihenfolge, kann deshalb nicht! verwendet werden.

[TiGü]

Ach du Scheiße, es stimmt.
Dann ist ja auch gar nichts Verlass und der Aufruf von COM-Interfaces vom Windows Betriebssystem Komponenten mit überladenen Methoden ist mehr oder weniger zufällig:

https://learn.microsoft.com/en-us/an...svgelement-api
https://github.com/FactoryXCode/MfPack/issues/4
https://github.com/microsoft/win32metadata/issues/600 (check kennykerrs Antwort)
https://github.com/microsoft/win32metadata/issues/815
https://stackoverflow.com/questions/...-the-same-name

[Kas Ob.]

Zitat von TiGü:

Ach du Scheiße, es stimmt.
Dann ist ja auch gar nichts Verlass und der Aufruf von COM-Interfaces vom Windows Betriebssystem Komponenten mit überladenen Methoden ist mehr oder weniger zufällig:

*Browser translation : with overloaded methods is more or less random*
It is not random at all, it is consistent just not documented, and specific only to the compiler that Microsoft used to build Windows and its component.

So for other compilers to comply and compile a binary compatible with Microsoft Built binaries, the headers for other languages (and compilers, being Delphi or even C++ or...) must be adjusted manually.