Re: [Mingw-w64-public] [PATCH 1/2] crt: Add fallback _vscprintf() implementation
On Sat, 15 Jan 2022, Pali Rohár wrote: In attachment are updated patches which adds these redirects and usage of F_NON_I386() macro. With these redirects it is possible to compile target mingw applications also with those gcc linker flags -Wl,--disable-auto-import -Wl,--disable-runtime-pseudo-reloc. Previously gcc really throw linker error about undefined symbols _vscrpintf. Thanks! These patches look acceptable to me. If Jacek doesn't mind, I'll go ahead and push them in a couple days. Anyway, is not this redirect required to add also for _wassert() function which is in mingw-w64-crt/misc/wassert.c file? Because it use same construction like _vscprintf in my patch. And similarly other source files which calls __mingw_get_msvcrt_handle() function? No, it doesn't seem to be necessary there. Both _wassert and _vscprintf are declared with _CRTIMP. This is a macro that expands to dllimport normally, unless _CRTBLD is defined - which is defined when building mingw-w64-crt. So for code within mingw-w64-crt, it sees all these functions without dllimport - which is necessary when we are reimplementing those functions here. But that also means that for code in mingw-w64-crt which calls another _CRTIMP function, it also sees that function without the dllimport attribute. Currently there doesn't seem to be any code in mingw-w64-crt calling _wassert, but if there was, we would need the same kind of extra redirect there too. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API
On 1/16/22 15:26, Luca Bacci wrote:
Probably many of you already know about that blog post by Raymond Chen, but
I'll post a link here anyway because it's relevant to this discussion:
https://devblogs.microsoft.com/oldnewthing/20220113-00/?p=106152
I never heard of it. I tested just now with midl 8.01.0626, and it does
work,
placing explicit RetVal argument, shipped d3d12.h header uses same
structure now.
We could probably adopt this option and output formatting for widl too.
Now let's wait for one more C-compat switch that will deal with
overloaded methods in DirectWrite headers, making it usable in C.
Il dom 16 gen 2022, 11:52 Vincent Torri ha
scritto:
On Sun, Jan 16, 2022 at 10:44 AM Martin Mitáš wrote:
Hello.
I was dealing with this exact problem some time ago.
Note the problem is wider. At certain point in time, Microsoft stopped to
care about C compatibility of (some of) their SDK headers. This includes
GDI+ and Direct2D APIs for example.
I.e. even if you somehow make it work with mingw-w64 headers, it would
still
not be buildable with MSVC. If you need that, your options are even more
limited and Wine headers won't help you much as I think their headers are
not compatible with Microsoft SDK.
It is for a toolkit that is not portable to msvc anyway. So I care
only about mingw-w64
For my projects, I've eventually ended with creating C-compatible headers
for D2D and GDI+. You can find them here:
https://github.com/mity/c-win32
hoo, you're the author of md4c :-) I use it for this toolkit :-)
I'll look at it.
However note they are not a drop-in replacement for two reasons:
(1) They are designed to live alongside standard SDK headers: The cost of
this decision is that all their top-level identifiers differ ("c_"
prefix).
not a problem. Only a few functions have problems. Technically
speaking, I can even replace them by something else (GetPixelSize -->
size of the client region of the Windows, and GetPixelFormat, well, I
use only one pixel format, so not a problem). Your license is also
good.
(2) They provide only stuff I needed so they're incomplete in many ways.
That said however adding more stuff should be quite a straight-forward
exercise.
i did something similar to have a dcomp C API for some functions.
So whether this is the right path forward for you, I don't know. Depends
on your trade-off considerations and requirements.
thank you
Vincent Torri
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] crt: Fix v*scanf functions
Currently v*scanf functions are broken and crash when are called with more
than 30 arguments in va_list. This is because va_list v*scanf functions are
redirected to variadic *scanf functions and this redirect implemented in
scanf.S file has fixed limit for 30 arguments.
Number of arguments for msvcrt *scanf function can be determined from
format string by counting number of '%' characters which are not followed
by another '%' or '*'. Every scanf parameter is pointer and therefore has
fixed size which means that required stack size can be exactly calculated.
Fix this scanf.S redirect implementation by dynamically allocating stack
for exact number of pointer parameters.
---
I have tested this patch for i686 and x86_64. Both ARM (arm32 and aarch64)
changes are untested, so please test it if vsscanf() on these platforms
still works.
With this patch following code works fine without any crashing.
Compile for msvcrt with -std=c89 or -D__USE_MINGW_ANSI_STDIO=0
#include
#include
int call_vsscanf(const char *str, const char *format, ...)
{
int ret;
va_list ap;
va_start(ap, format);
ret = vsscanf(str, format, ap);
va_end(ap);
return ret;
}
int main()
{
char b[53];
call_vsscanf(
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ",
"%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c"
"%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c",
[0],[1],[2],[3],[4],[5],[6],[7],[8],[9],[10],[11],
[12],[13],[14],[15],[16],[17],[18],[19],[20],[21],
[22],[23],[24],[25],[26],[27],[28],[29],[30],[31],
[32],[33],[34],[35],[36],[37],[38],[39],[40],[41],
[42],[43],[44],[45],[46],[47],[48],[49],[50],[51]
);
printf("b=%s\n", b);
return 0;
}
---
mingw-w64-crt/Makefile.am | 2 +
mingw-w64-crt/stdio/scanf.S | 166 ++
mingw-w64-crt/stdio/scanf2-argcount-char.c| 9 +
.../stdio/scanf2-argcount-template.c | 22 +++
mingw-w64-crt/stdio/scanf2-argcount-wchar.c | 9 +
mingw-w64-crt/stdio/vfscanf.c | 6 +-
mingw-w64-crt/stdio/vfwscanf.c| 6 +-
mingw-w64-crt/stdio/vsscanf.c | 6 +-
mingw-w64-crt/stdio/vswscanf.c| 6 +-
9 files changed, 154 insertions(+), 78 deletions(-)
create mode 100644 mingw-w64-crt/stdio/scanf2-argcount-char.c
create mode 100644 mingw-w64-crt/stdio/scanf2-argcount-template.c
create mode 100644 mingw-w64-crt/stdio/scanf2-argcount-wchar.c
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 5fe84f8bafe4..6cae3b4a52d2 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -504,6 +504,7 @@ src_libmingwex=\
misc/wmemset.c misc/ftw.c misc/ftw64.c
misc/mingw-access.c \
\
stdio/mingw_pformat.h\
+ stdio/scanf2-argcount-char.c stdio/scanf2-argcount-wchar.c \
stdio/vfscanf2.S stdio/vfwscanf2.S stdio/vscanf2.S
stdio/vsscanf2.S stdio/vswscanf2.S \
stdio/vwscanf2.S stdio/strtok_r.c stdio/scanf.S \
stdio/_Exit.cstdio/_findfirst64i32.c stdio/_findnext64i32.c
stdio/_fstat.c \
@@ -2244,6 +2245,7 @@ EXTRA_DIST += revstamp.h \
profile/gcrt0.c \
profile/COPYING \
profile/CYGWIN_LICENSE \
+ stdio/scanf2-argcount-template.c \
stdio/scanf2-template.S
DISTCHECK_CONFIGURE_FLAGS = --host=$(host_triplet) $(withsys)
diff --git a/mingw-w64-crt/stdio/scanf.S b/mingw-w64-crt/stdio/scanf.S
index 1e0bed9452ac..ae8090e4cf9c 100644
--- a/mingw-w64-crt/stdio/scanf.S
+++ b/mingw-w64-crt/stdio/scanf.S
@@ -9,17 +9,14 @@
The goal of this routine is to turn a call to v*scanf into a call to
s*scanf. This is needed because mingw-w64 uses msvcr100.dll, which doesn't
support the v*scanf functions instead of msvcr120.dll which does.
- Unfortunately, there is no defined way to know exactly how big a va_list
- is, so we use a hard-coded buffer.
-
- I suppose a sufficiently-motivated person could try to parse the format
- to figure out how many tokens there are... */
+*/
/* The function prototype here is (essentially):
- int __ms_vsscanf_internal (void *s,
+ int __ms_v*scanf_internal (void *s,
void *format,
void *arg,
+size_t count,
void *func);
I say 'essentially' because passing a function pointer as void in ISO
@@ -37,19 +34,6 @@
*/
.def __argtos;.scl2;.type32;.endef
-/* The max number of pointers we support. Must be an even number
- to keep the 64bit stack 16byte aligned. Must not be less than 4. */
-.equ entries, 30
-
-/* 64bit pointers are 8 bytes. */
-.equ sizeof, 8
-
-/* Size of our buffer. */
-.equ iBytes, entries * sizeof
-
-/* Stack space for first 2 args to s*scanf. */
-.equ
Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API
Probably many of you already know about that blog post by Raymond Chen, but
I'll post a link here anyway because it's relevant to this discussion:
https://devblogs.microsoft.com/oldnewthing/20220113-00/?p=106152
Il dom 16 gen 2022, 11:52 Vincent Torri ha
scritto:
> On Sun, Jan 16, 2022 at 10:44 AM Martin Mitáš wrote:
> >
> >
> > Hello.
> >
> > I was dealing with this exact problem some time ago.
> >
> > Note the problem is wider. At certain point in time, Microsoft stopped to
> > care about C compatibility of (some of) their SDK headers. This includes
> > GDI+ and Direct2D APIs for example.
> >
> > I.e. even if you somehow make it work with mingw-w64 headers, it would
> still
> > not be buildable with MSVC. If you need that, your options are even more
> > limited and Wine headers won't help you much as I think their headers are
> > not compatible with Microsoft SDK.
>
> It is for a toolkit that is not portable to msvc anyway. So I care
> only about mingw-w64
>
> > For my projects, I've eventually ended with creating C-compatible headers
> > for D2D and GDI+. You can find them here:
> >
> > https://github.com/mity/c-win32
>
> hoo, you're the author of md4c :-) I use it for this toolkit :-)
>
> I'll look at it.
>
> > However note they are not a drop-in replacement for two reasons:
> >
> > (1) They are designed to live alongside standard SDK headers: The cost of
> > this decision is that all their top-level identifiers differ ("c_"
> prefix).
>
> not a problem. Only a few functions have problems. Technically
> speaking, I can even replace them by something else (GetPixelSize -->
> size of the client region of the Windows, and GetPixelFormat, well, I
> use only one pixel format, so not a problem). Your license is also
> good.
>
> > (2) They provide only stuff I needed so they're incomplete in many ways.
> > That said however adding more stuff should be quite a straight-forward
> > exercise.
>
> i did something similar to have a dcomp C API for some functions.
>
> > So whether this is the right path forward for you, I don't know. Depends
> > on your trade-off considerations and requirements.
>
> thank you
>
> Vincent Torri
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API
On Sun, Jan 16, 2022 at 10:44 AM Martin Mitáš wrote:
>
>
> Hello.
>
> I was dealing with this exact problem some time ago.
>
> Note the problem is wider. At certain point in time, Microsoft stopped to
> care about C compatibility of (some of) their SDK headers. This includes
> GDI+ and Direct2D APIs for example.
>
> I.e. even if you somehow make it work with mingw-w64 headers, it would still
> not be buildable with MSVC. If you need that, your options are even more
> limited and Wine headers won't help you much as I think their headers are
> not compatible with Microsoft SDK.
It is for a toolkit that is not portable to msvc anyway. So I care
only about mingw-w64
> For my projects, I've eventually ended with creating C-compatible headers
> for D2D and GDI+. You can find them here:
>
> https://github.com/mity/c-win32
hoo, you're the author of md4c :-) I use it for this toolkit :-)
I'll look at it.
> However note they are not a drop-in replacement for two reasons:
>
> (1) They are designed to live alongside standard SDK headers: The cost of
> this decision is that all their top-level identifiers differ ("c_" prefix).
not a problem. Only a few functions have problems. Technically
speaking, I can even replace them by something else (GetPixelSize -->
size of the client region of the Windows, and GetPixelFormat, well, I
use only one pixel format, so not a problem). Your license is also
good.
> (2) They provide only stuff I needed so they're incomplete in many ways.
> That said however adding more stuff should be quite a straight-forward
> exercise.
i did something similar to have a dcomp C API for some functions.
> So whether this is the right path forward for you, I don't know. Depends
> on your trade-off considerations and requirements.
thank you
Vincent Torri
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API
On Sun, Jan 16, 2022 at 10:18 AM Nikolay Sivov wrote: > > > > On 1/16/22 10:06, Vincent Torri wrote: > > hello > > > > On Sat, Jan 15, 2022 at 9:28 AM Vincent Torri > > wrote: > >> On Sat, Jan 15, 2022 at 7:43 AM Nikolay Sivov > >> wrote: > >>> > >>> > >>> On 1/14/22 23:05, Vincent Torri wrote: > On Fri, Jan 14, 2022 at 6:31 PM Nikolay Sivov > wrote: > >> on the contrary, CreateBitmap(), DrawBitmap(), BeginDraw(), EndDraw() > >> or SetTransform() are working with the C API. > >> > >> Does someone have an idea of the problem. I have a test program if you > >> want > > It's a known thing, C-compatible prototypes would be different for such > > methods: > > > > D2D1_SIZE_U * ID3D1HwndRenderTarget_GetPixelSize(void *this, D2D1_SIZE_U > > *size). > but then I have a compilation error because in d2d1.h provided by > mingw-w64, GetPixelSize() has only 1 argument, not 2. > >>> Naturally, because headers are not prepared for that. > >>> > >>> If you wanted to use C++ with msvc compatible prototypes, there is > >>> WIDL_EXPLICIT_AGGREGATE_RETURNS for that, > >>> for C definitions it won't work, you'll have to use wine headers, or > >>> more specifically a header widl produces from wine's d2d1.idl. Widl > >>> detects such cases automatically, see is_aggregate_return() in widl > >>> sources. > >>> > >>> I think what should be done is WIDL_EXPLICIT_AGGREGATE_RETURNS case for > >>> C definitions patched in for mingw headers. > > i've installed wine in archlinux, and > > ID3D1HwndRenderTarget_GetPixelSize is defined with another macro, i > > guess, which i don't know the value (no lucj with an fgrep -r in > > /usr/include/wine > > > > so i don't know the declaration of the function with d2d1.h provided with > > wine > > Please take a closer look, there is a function wrapper called > ID2D1HwndRenderTarget_GetPixelSize(). yes, and it has 1 argument, the render target (in the archlinux installed wine) > Also see attached patch, maybe that's enough to make it work for now. I'll try it, thank you Vincent Torri ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API
Hello.
I was dealing with this exact problem some time ago.
Note the problem is wider. At certain point in time, Microsoft stopped to
care about C compatibility of (some of) their SDK headers. This includes
GDI+ and Direct2D APIs for example.
I.e. even if you somehow make it work with mingw-w64 headers, it would still
not be buildable with MSVC. If you need that, your options are even more
limited and Wine headers won't help you much as I think their headers are
not compatible with Microsoft SDK.
For my projects, I've eventually ended with creating C-compatible headers
for D2D and GDI+. You can find them here:
https://github.com/mity/c-win32
However note they are not a drop-in replacement for two reasons:
(1) They are designed to live alongside standard SDK headers: The cost of
this decision is that all their top-level identifiers differ ("c_" prefix).
(2) They provide only stuff I needed so they're incomplete in many ways.
That said however adding more stuff should be quite a straight-forward
exercise.
So whether this is the right path forward for you, I don't know. Depends
on your trade-off considerations and requirements.
Regards,
Martin
Dne 14. 1. 2022 v 18:16 Vincent Torri napsal(a):
> Hello
>
> first, I'm on Win10
>
> After initializing Direct2D, when I call
>
> ID2D1HwndRenderTarget_GetPixelSize
>
> with a HwndRenderTarget, i get a seg fault.
>
> But when I use the C++ API, no problem.
>
> there is the same behavior with GetPixelFormat()
>
> on the contrary, CreateBitmap(), DrawBitmap(), BeginDraw(), EndDraw()
> or SetTransform() are working with the C API.
>
> Does someone have an idea of the problem. I have a test program if you want
>
> thank you
>
> Vincent Torri
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API
On 1/16/22 10:06, Vincent Torri wrote:
hello
On Sat, Jan 15, 2022 at 9:28 AM Vincent Torri wrote:
On Sat, Jan 15, 2022 at 7:43 AM Nikolay Sivov wrote:
On 1/14/22 23:05, Vincent Torri wrote:
On Fri, Jan 14, 2022 at 6:31 PM Nikolay Sivov wrote:
on the contrary, CreateBitmap(), DrawBitmap(), BeginDraw(), EndDraw()
or SetTransform() are working with the C API.
Does someone have an idea of the problem. I have a test program if you want
It's a known thing, C-compatible prototypes would be different for such
methods:
D2D1_SIZE_U * ID3D1HwndRenderTarget_GetPixelSize(void *this, D2D1_SIZE_U
*size).
but then I have a compilation error because in d2d1.h provided by
mingw-w64, GetPixelSize() has only 1 argument, not 2.
Naturally, because headers are not prepared for that.
If you wanted to use C++ with msvc compatible prototypes, there is
WIDL_EXPLICIT_AGGREGATE_RETURNS for that,
for C definitions it won't work, you'll have to use wine headers, or
more specifically a header widl produces from wine's d2d1.idl. Widl
detects such cases automatically, see is_aggregate_return() in widl sources.
I think what should be done is WIDL_EXPLICIT_AGGREGATE_RETURNS case for
C definitions patched in for mingw headers.
i've installed wine in archlinux, and
ID3D1HwndRenderTarget_GetPixelSize is defined with another macro, i
guess, which i don't know the value (no lucj with an fgrep -r in
/usr/include/wine
so i don't know the declaration of the function with d2d1.h provided with wine
Please take a closer look, there is a function wrapper called
ID2D1HwndRenderTarget_GetPixelSize().
Also see attached patch, maybe that's enough to make it work for now.
Vincent Torri
From 88508f6dd75b80ce7e4fc40053f568449447476b Mon Sep 17 00:00:00 2001
From: Nikolay Sivov
Date: Sun, 16 Jan 2022 12:13:25 +0300
Subject: [PATCH] d2d1: Fixup C method prototypes that are using aggregate
return values.
Signed-off-by: Nikolay Sivov
---
mingw-w64-headers/include/d2d1.h | 48
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/mingw-w64-headers/include/d2d1.h b/mingw-w64-headers/include/d2d1.h
index 66f3ee4dc..3c5c570df 100644
--- a/mingw-w64-headers/include/d2d1.h
+++ b/mingw-w64-headers/include/d2d1.h
@@ -613,9 +613,9 @@ interface ID2D1Bitmap : public ID2D1Image {
typedef struct ID2D1BitmapVtbl {
ID2D1ImageVtbl Base;
-STDMETHOD_(D2D1_SIZE_F, GetSize)(ID2D1Bitmap *This) PURE;
-STDMETHOD_(D2D1_SIZE_U, GetPixelSize)(ID2D1Bitmap *This) PURE;
-STDMETHOD_(D2D1_PIXEL_FORMAT, GetPixelFormat)(ID2D1Bitmap *This) PURE;
+STDMETHOD_(D2D1_SIZE_F*, GetSize)(ID2D1Bitmap *This, D2D1_SIZE_T *__ret)
PURE;
+STDMETHOD_(D2D1_SIZE_U*, GetPixelSize)(ID2D1Bitmap *This, D2D1_SIZE_U
*__ret) PURE;
+STDMETHOD_(D2D1_PIXEL_FORMAT*, GetPixelFormat)(ID2D1Bitmap *This,
D2D1_PIXEL_FORMAT *__ret) PURE;
STDMETHOD_(void, GetDpi)(ID2D1Bitmap *This, FLOAT *dpiX, FLOAT *dpiY) PURE;
STDMETHOD(CopyFromBitmap)(ID2D1Bitmap *This, const D2D1_POINT_2U
*destPoint, ID2D1Bitmap *bitmap, const D2D1_RECT_U *srcRect) PURE;
STDMETHOD(CopyFromRenderTarget)(ID2D1Bitmap *This, const D2D1_POINT_2U
*destPoint, ID2D1RenderTarget *renderTarget, const D2D1_RECT_U *srcRect) PURE;
@@ -630,9 +630,9 @@ interface ID2D1Bitmap {
#define ID2D1Bitmap_AddRef(this)
(this)->lpVtbl->Base.Base.Base.AddRef((IUnknown*)(this))
#define ID2D1Bitmap_Release(this)
(this)->lpVtbl->Base.Base.Base.Release((IUnknown*)(this))
#define ID2D1Bitmap_GetFactory(this,A)
(this)->lpVtbl->Base.Base.GetFactory((ID2D1Resource*)(this),A)
-#define ID2D1Bitmap_GetSize(this) (this)->lpVtbl->GetSize(this)
-#define ID2D1Bitmap_GetPixelSize(this) (this)->lpVtbl->GetPixelSize(this)
-#define ID2D1Bitmap_GetPixelFormat(this) (this)->lpVtbl->GetPixelFormat(this)
+#define ID2D1Bitmap_GetSize(this,A) (this)->lpVtbl->GetSize(this,A)
+#define ID2D1Bitmap_GetPixelSize(this,A) (this)->lpVtbl->GetPixelSize(this,A)
+#define ID2D1Bitmap_GetPixelFormat(this,A)
(this)->lpVtbl->GetPixelFormat(this,A)
#define ID2D1Bitmap_GetDpi(this,A,B) (this)->lpVtbl->GetDpi(this,A,B)
#define ID2D1Bitmap_CopyFromBitmap(this,A,B,C)
(this)->lpVtbl->CopyFromBitmap(this,A,B,C)
#define ID2D1Bitmap_CopyFromRenderTarget(this,A,B,C)
(this)->lpVtbl->CopyFromRenderTarget(this,A,B,C)
@@ -980,11 +980,11 @@ typedef struct ID2D1RenderTargetVtbl {
STDMETHOD_(void, Clear)(ID2D1RenderTarget *This, const D2D1_COLOR_F
*clearColor) PURE;
STDMETHOD_(void, BeginDraw)(ID2D1RenderTarget *This) PURE;
STDMETHOD(EndDraw)(ID2D1RenderTarget *This, D2D1_TAG *tag1, D2D1_TAG
*tag2) PURE;
-STDMETHOD_(D2D1_PIXEL_FORMAT, GetPixelFormat)(ID2D1RenderTarget *This)
PURE;
+STDMETHOD_(D2D1_PIXEL_FORMAT*, GetPixelFormat)(ID2D1RenderTarget *This,
D2D1_PIXEL_FORMAT *__ret) PURE;
STDMETHOD_(void, SetDpi)(ID2D1RenderTarget *This, FLOAT dpiX, FLOAT dpiY)
PURE;
STDMETHOD_(void, GetDpi)(ID2D1RenderTarget *This, FLOAT *dpiX, FLOAT
*dpiY) PURE;
-
