在 2021-03-02 03:43, Paul Ausbeck 写道:
gcc x86_64-w64-mingw32 can find and open absolute filenames or directory names beginning
/driveletter/ when they are mentioned directly on the invoking command line. However, such filenames
or include directories mentioned in @response files aren't found. To
When I use GCC on Windows, I generally use MSYS2, a MinGW version of CMake
that I installed with its package manager, and I use the "MSYS Makefiles"
CMake generator.
If you're using a Cygwin or MSYS2 shell, you should be aware that those
shells do some transformations to the command line to conver
I noticed that the NoFence() variation of the Interlocked atomic functions in
the Windows headers are missing. or at least I can't find them. In particular I
was looking for InterlockedExchangeNoFence() and InterlockedOrNoFence().
Here's a link with the full list:
https://docs.microsoft.com/en-u
Second try on this, first attempted rejected:
gcc x86_64-w64-mingw32 can find and open absolute filenames or directory names
beginning /driveletter/ when they are mentioned directly on the invoking
command line. However, such filenames or include directories mentioned in
@response files aren't
gcc x86_64-w64-mingw32 can find and open absolute filenames or directory names
beginning /driveletter/ when they are mentioned directly on the invoking
command line. However, such filenames or include directories mentioned in
@response files aren't found. To be found, files or directories menti
On 2021-03-09 15:24, Jacek Caban wrote:
Hi Steve,
On 09.03.2021 15:03, Steve Lhomme wrote:
.../include/windows.foundation.collections.idl | 6 --
mingw-w64-headers/include/windows.foundation.idl | 8
2 files changed, 8 insertions(+), 6 deletions(-)
window
Hi Steve,
On 09.03.2021 15:03, Steve Lhomme wrote:
.../include/windows.foundation.collections.idl| 6 --
mingw-w64-headers/include/windows.foundation.idl | 8
2 files changed, 8 insertions(+), 6 deletions(-)
windows.foundation.collections.idl is imported
See
-
https://docs.microsoft.com/en-us/uwp/api/windows.system.threading.timerelapsedhandler
-
https://docs.microsoft.com/en-us/uwp/api/windows.system.threading.timerdestroyedhandler
-
https://docs.microsoft.com/en-us/uwp/api/windows.system.threading.workitemhandler
---
.../include/windows.syste
See
https://docs.microsoft.com/en-us/uwp/api/windows.foundation.typedeventhandler-2
---
mingw-w64-headers/include/windows.foundation.idl | 7 ++-
mingw-w64-headers/include/windows.storage.idl| 3 ---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-headers/include/
AsyncOperationCompletedHandler is also a parameterized type that needs to be
defined besides each IAsyncOperation variant.
Despite what the IAsyncOperation documentation [1] says, it doesn't implement
IAsyncInfo.
[1]
https://docs.microsoft.com/en-us/uwp/api/windows.foundation.iasyncoperation-1
-
It's now supported by widl.
---
mingw-w64-headers/include/windows.storage.idl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-headers/include/windows.storage.idl
b/mingw-w64-headers/include/windows.storage.idl
index 44566bd1d..bad75958d 100644
--- a/mingw-w64-hea
They are not actually runtime classes but sealed classes. The current widl
doesn't understand this keyword so we pretend they are runtime classes. It
generates the same code.
The IStorageFile interface is described at [1].
The IStorageFileStatics is the interface to use to access the static method
The casing was wrong in 2c428051a1717b643c26049b67e5d6acc22d994f.
Also use IAsyncAction with its proper namespace, no need to use a dummy
IInspectable.
---
mingw-w64-headers/include/windows.foundation.idl | 2 +-
mingw-w64-headers/include/windows.storage.idl | 15 +++
.../includ
It's an structure that needs to be used with the proper namespace.
See https://docs.microsoft.com/en-us/uwp/api/windows.foundation.timespan
---
.../include/windows.foundation.idl| 5 +
.../include/windows.system.threading.idl | 20 ++-
2 files changed, 11 ins
They are not actually runtime classes, but it tricks widl into producing
correct code (and class string).
ApplicationData is a sealed class implementing some interfaces [1]
KnownFolders is a static class implementing multiple interfaces [2].
[1] https://docs.microsoft.com/en-us/uwp/api/windows.st
IDataReader is a helper class to read data from an input stream [1].
IDataReaderFactory is the interface to use to get the constructor of the
"Windows.Storage.Streams.DataReader" class [2] with RoGetActivationFactory().
IInputStream is an interface used to read asynchronously data [3].
IRandomAc
It's not supposed to be in the Windows.Foundation namespace [1].
It's supposed to be defined in a separate IDL/header but we can define it here.
[1]
https://docs.microsoft.com/en-us/windows/win32/api/eventtoken/ns-eventtoken-eventregistrationtoken
---
mingw-w64-headers/include/windows.foundatio
See
https://docs.microsoft.com/en-us/uwp/api/windows.storage.applicationdatasetversionhandler
---
mingw-w64-headers/include/windows.storage.idl | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/mingw-w64-headers/include/windows.storage.idl
b/mingw-w64-headers/inc
It's a parameterized interface that should be defined in
windows.foundations.collections. And then we don't need a local declaration.
---
mingw-w64-headers/include/windows.storage.idl | 4
1 file changed, 4 deletions(-)
diff --git a/mingw-w64-headers/include/windows.storage.idl
b/mingw-w64-
---
mingw-w64-headers/include/windows.foundation.idl | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/mingw-w64-headers/include/windows.foundation.idl
b/mingw-w64-headers/include/windows.foundation.idl
index 7bcc5f69c..0c140ee4a 100644
--- a/mingw-w64-headers/incl
This is properly declared in windows.foundation.collections.idl since
c0fa4d755413c4541bdad32f07025f4a53e6bd07.
---
mingw-w64-headers/include/windows.foundation.idl | 9 -
1 file changed, 9 deletions(-)
diff --git a/mingw-w64-headers/include/windows.foundation.idl
b/mingw-w64-headers/inc
It's in the .NET System namespace which translates to the Windows.Foundation
namespace in winrt interfaces.
---
.../include/windows.foundation.collections.idl| 6 --
mingw-w64-headers/include/windows.foundation.idl | 8
2 files changed, 8 insertions(+), 6 deletion
---
mingw-w64-headers/include/windows.foundation.idl | 9 +
1 file changed, 9 insertions(+)
diff --git a/mingw-w64-headers/include/windows.foundation.idl
b/mingw-w64-headers/include/windows.foundation.idl
index 0c140ee4a..581aa1ec5 100644
--- a/mingw-w64-headers/include/windows.foundatio
After addition in 7253105a2e54e83f59506df7e5da6350308b615f.
---
mingw-w64-headers/Makefile.am | 1 +
mingw-w64-headers/Makefile.in | 1 +
2 files changed, 2 insertions(+)
diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am
index 09b657273..b67fbf3d6 100644
--- a/mingw-w64-h
No need to declare it anywhere else.
---
.../include/windows.foundation.collections.idl | 6 --
mingw-w64-headers/include/windows.foundation.idl| 4
mingw-w64-headers/include/windows.storage.idl | 3 +--
3 files changed, 5 insertions(+), 8 deletions(
---
.../include/windows.foundation.collections.idl| 11 +++
1 file changed, 11 insertions(+)
diff --git a/mingw-w64-headers/include/windows.foundation.collections.idl
b/mingw-w64-headers/include/windows.foundation.collections.idl
index bc2d26694..2bd0c8201 100644
--- a/mingw-w64-
It's an enum [1] in the Windows.Foundation namespace but in the generated
header it's not supposed to have the AsyncStatus_ prefix nor the namespace.
So it's equivalent to a global enum.
It's supposed to be declared in a separate IDL/header but we can declare it
here.
[1]
https://docs.microsoft.
27 matches
Mail list logo
