Clang doesn't support the ms_printf/scanf and gnu_printf/scanf
format attributes, only plain "printf" and "scanf".
We already expand e.g. __MINGW_PRINTF_FORMAT (which differs depending
on __USE_MINGW_ANSI_STDIO) into plain "printf" for Clang, since
015e637b4b. However, a number
of functions explicitly declared either gnu or ms style formats,
which caused these functions to not get any format string diagnostics.
This fixes https://github.com/llvm/llvm-project/issues/68995,
which reported that no warnings are produced for mismatched
printf/scanf format strings, when compiling with Clang, with
a toolchain targeting msvcrt (i.e. in practice using
__USE_MINGW_ANSI_STDIO enabled).
Signed-off-by: Martin Storsjö <martin@martin.st>
Prefer declaring these attributes with such macros, rather than
spelling out the full attribute.
These macros were added in 73e50d0577
in 2013, but haven't been used in mingw-w64 headers since (although
they may have been used in user code).
These macros, which expand to the full attribute, differ slightly
from the other preexisting macros (which are used quite widely)
like __MINGW_PRINTF_FORMAT, which expand only to the type string
"gnu_printf", "ms_printf" or "printf".
However as we do have these existing macros in this form, for
declaring a specific form of these format attributes, take them into
use where applicable.
Signed-off-by: Martin Storsjö <martin@martin.st>
Prior to 1652e9241b, the time.h
inline functions always were static. Due to reexporting such
symbols in C++20 modules (for the C++23 std module), the reexported
symbols must not be static, so the inline functions were changed
from static inline to __mingw_ovr, which practically is static
inline in C mode, but regular inline in C++ mode.
By using regular inline in C++ mode, each use of the functions
can (but doesn't need to) emit an external symbol for the
inline function, and the callers may either call that function
or inline the body of the function.
This can have two potential issues; if different translation units
are configured differently (with the _USE_32BIT_TIME_T define),
but both use the same external symbol for it, the linker will only
keep one of them (as they're both inline, and supposed to be the
same). In practice, this is rare for _USE_32BIT_TIME_T though.
Secondly, such an external symbol may conflict with the actual
import library. Such a case was reported at
https://github.com/mstorsjo/llvm-mingw/issues/427.
(Practically, the issue there was that some built object files
defined an external "_time" symbol, i.e. regular "time" with i386
cdecl underscore prefix, from the non-static inline functions. The
object also files reference _time32 with dllimport, which via the
weak aliases produced by llvm-dlltool end up pulling in the
__imp__time symbol, which also brings in a conflicting "_time" symbol.)
In short - inline functions can be problematic. Where possible,
it's less problematic to use asm(), via __MINGW_ASM_CALL(), to
redirect calls directly towards the right function.
This has a slight drawback, that this ends up calling the thunks
(as the declarations lack dllimport), while we previously could
inline the call directly to a dllimported function (avoiding the
thunk, fetching the target address via the __imp_ prefixed symbol).
We could, easily, add the dllimport attributes on these declarations,
but that triggers a GCC bug for how those symbol names are mangled
on i386, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984. (The
bug seems to be noted and mentioned as early as 2007, in
https://sourceware.org/pipermail/cygwin/2007-February/154845.html,
but it doesn't seem to have been fixed since.)
Signed-off-by: Martin Storsjö <martin@martin.st>
We should prefer using a macro which doesn't declare functions
as static inline in C++ mode.
This macro was added in bc6a874889,
without an explanation of why it was added.
Signed-off-by: Martin Storsjö <martin@martin.st>
When building the C++23 std modules, at least with libc++, the
C++ module needs to reexport a number of standard C functions.
The regular libc++ headers (the ones used even if not using
C++ modules) do this, essentially:
namespace std {
using ::ctime;
}
Thus reexporting the regular C function ctime within the std
namespace.
When building libc++ as a module, this function gets emitted as
part of the C++ std module, like this:
export namespace std {
using std::ctime;
}
This tries to export the function as part of the C++ module. In the
case of our inline functions, this errors out if the inline functions
are static inline:
<prefix>/share/libc++/v1/std/ctime.inc:20:14: error: using declaration referring to 'ctime' with internal linkage cannot be exported
20 | using std::ctime;
| ^
<prefix>/x86_64-w64-mingw32/include/time.h:267:29: note: target of using declaration
267 | static __inline char *__CRTDECL ctime(const time_t *_Time) { return _ctime64(_Time); }
| ^
Therefore, prefer using the __mingw_ovr macro for these inline
declarations. This macro expands to regular plain (non-static)
inline in C++ mode, while it still expands to static inline in C mode.
Signed-off-by: Martin Storsjö <martin@martin.st>
This redefining of the macro was added in
824ceb1d12, without an explanation
of why that was done.
If we really do need to use a different inline declaration for
these functions, we should use a different macro, so we don't
alter the meaning of the __mingw_ovr define after including
swprintf.inl or wchar.h.
This practically has the effect, that these inlines are declared
as regular "inline" instead of "static __inline__" when built
in C++ mode with a GCC compatible compiler. This matches how
the __mingw_ovr macro is defined and used for many other inline
functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
We already have non-inline versions of these functions; use the
non-inline version consistently, to avoid potential cases of
inconsistency.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since Windows SDK 8.0, `STRSAFE_NO_DEPRECATE` no longer has an effect. It's
still defined by some headers, but the check in 'strsafe.h' has been removed.
Those macros that match POSIX names have been moved to 'dontuse.h', so we do
the same.
Previously, inclusion of <strsafe.h> before <windows.h> could cause errors like
In file included from C:/msys64/mingw64/include/windows.h:70,
from test.c:2:
C:/msys64/mingw64/include/winbase.h:1499:37: error: expected identifier or '(' before 'LPSTR'
1499 | WINBASEAPI LPSTR WINAPI lstrcpyA (LPSTR lpString1, LPCSTR lpString2);
| ^~~~~
because the semicolon in the macro `lstrcpyA` affects not only invocations, but
also declarations. Those semicolons have been removed since Windows SDK 8.0, so
we remove them as well. This allows including 'strsafe.h' before 'windows.h'.
The macro `DEPRECATE_SUPPORTED` controls how deprecated functions are to be
deprecated. In Microsoft headers, existence of it deprecates those functions
with `#pragma deprecated`, and absense of it exposes macros which rename them
to non-existent ones, so any use of them results in errors such as
ccYRG0RL.o:test.c:(.text+0x1c): undefined reference to `strcpy_instead_use_StringCbCopyA_or_StringCchCopyA'
collect2.exe: error: ld returned 1 exit status
To match the behavior of Windows SDK, we define those renaming macros only if
`DEPRECATE_SUPPORTED` isn't defined, like in 'pathcch.h'. Unfortunately, GCC
does not support `#pragma deprecated`, so no warning will be issued if
`DEPRECATE_SUPPORTED` is defined by including 'winnt.h' or 'windows.h' before
'strsafe.h'. This may be improved in the future.
Reported-by: Julian Waters <tanksherman27@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
This should match latest Windows SDK except for `strtold_l()` and `wcstold_l()`.
The Microsoft implementations produce 64-bit numbers that do not match the GNU
ABI, and we at the moment do not have locale-aware implementations.
Signed-off-by: LIU Hao <lh_mouse@126.com>
This prevents bogus warnings or build aborts (-Werror) if Windows
includes are used on Cygwin.
Signed-off-by: Christian Franke <christian.franke@t-online.de>
Signed-off-by: LIU Hao <lh_mouse@126.com>
Clang 18.x was meant to implement __cpuidex (a version was merged
during the development of Clang 17.x, but it was reverted and backed
out before Clang 17.x was completed) - however it was never merged
before Clang 18.x was branched after all. For further history of
the earlier changes within mingw-w64, see
0605217f5d and
2b6c924761.
Postpone this change to Clang 19 for now.
This fixes building software that uses __cpuidex with Clang 18.
Hopefully it can either be merged in Clang well in advance before
Clang 19 gets branched, or this issue revisited again long before
that.
Signed-off-by: Martin Storsjö <martin@martin.st>
This should have less critical effect on code generation compared
to marking RtlCaptureContext as returns_twice, but can avoid
compiler warnings in some cases (although I don't have such
a case at hand right now).
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows the compiler to generate correct code to resume
execution when returning to this point later.
Signed-off-by: Martin Storsjö <martin@martin.st>
getopt.h is transitively included by unistd.h, which means that
users who include unistd.h (also potentially unintentionally as
a transitive dependency) won't be able to get "optreset" declared,
if they do e.g. this:
#include <unistd.h>
#define _BSD_SOURCE
#include <getopt.h>
This recently broke building LLDB with latest nightly libc++ headers,
as libc++ headers would end up including unistd.h, while LLDB
later would define _BSD_SOURCE right before including getopt.h.
For definitions like _BSD_SOURCE, the most failsafe solution
generally is to define them before including any header, to avoid
this kind of issue. However, allowing getopt.h to react to
being reincluded with _BSD_SOURCE defined, is quite straightforward.
This allows fixing a recent LLDB build break reported at
https://github.com/llvm/llvm-project/issues/76050.
Signed-off-by: Martin Storsjö <martin@martin.st>
Add a missing comma; move `STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL`
and `STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DTS` outside `#ifdef _INC_MMREG` so
they match Windows SDK 10.0.22621.0.
This closes https://github.com/mingw-w64/mingw-w64/issues/40.
Signed-off-by: LIU Hao <lh_mouse@126.com>
On UCRT, there are separate -f suffixed math functions that can
be faster than doing the regular version that operates on doubles
and just truncate the results to float.
Signed-off-by: Martin Storsjö <martin@martin.st>
The constant PF_ARM_V83_LRCPC_INSTRUCTIONS_AVAILABLE was
added in winnt.h in upstream WinSDK 10.0.22621.0.
Signed-off-by: Martin Storsjö <martin@martin.st>
The DWORD reason corresponds to an "unsigned long", not an "unsigned".
This is also how it's defined in the Windows SDK.
Signed-off-by: LIU Hao <lh_mouse@126.com>
The version of d3d12.idl in vkd3d has been completed further now,
and has been synced back to Wine; restore mingw-w64-headers to
include this header in future syncs from wine.
Signed-off-by: Martin Storsjö <martin@martin.st>
This only changes a few minor stylistic details compared to what
was merged before, that was pointed out during review in vkd3d.
Signed-off-by: Martin Storsjö <martin@martin.st>
In 2b6c924761, we changed so that
we don't provide __cpuidex for Clang 17 or newer, as Clang itself
provided that as a builtin.
The __cpuidex builtin was added in Clang during the course of
development of Clang 17, but it was reverted before version 17 was
released (it was added initially in
2df77ac20a1ed996706b164b0c4ed5ad140f635f, in llvm-project, on May 24th,
but later reverted in f3baf63d9a1ba91974f4df6abb8f2abd9a0df5b5 on August
4th, which also was cherrypicked to the 17.x release branch).
Clang 17 isn't formally released yet, but it has been agreed to
not reland the change within the 17.x release series - in
https://reviews.llvm.org/D157115#4561681.
In current git main of llvm-project, the __cpuidex builtin isn't
yet readded, but it is being planned and it seems likely to
be readded before version 18 gets released in 6 months; thus
bump the version to 18 instead of removing the condition entirely.
Relanding it is being discussed in https://reviews.llvm.org/D158348.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is the latest version of vkd3d_d3d12.idl from
https://gitlab.winehq.org/wine/vkd3d, plus some additions that still
are under review at
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/332, with
slight adjustments to the include lines at the top.
Remove d3d12.idl from the list of files that manually are synced
from main wine, as d3d12.idl there is lacking lots of declarations.
Ideally the d3d12.idl in wine will be brought up to sync at some point,
but for now, exclude this header and sync it manually from vkd3d
instead.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes the following compiler error in chromium.
ntddser.h: At global scope:
ntddser.h:368:9: error: 'PHYSICAL_ADDRESS' does not name a type; did you mean 'PNC_ADDRESS'?
368 | PHYSICAL_ADDRESS PortAddress;
| ^~~~~~~~~~~~~~~~
| PNC_ADDRESS
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
Required for chromium.
chromium/media/gpu/windows/dxva_video_decode_accelerator_win.cc:1477:15:
error: use of undeclared identifier 'CLSID_MSVPxDecoder'
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
This fixes the following compiler error with chromium.
media/audio/win/core_audio_util_win.cc: In static member function 'static std::string media::CoreAudioUtil::GetAudioControllerID(IMMDevice*, IMMDeviceEnumerator*)':
media/audio/win/core_audio_util_win.cc:710:35: error: 'PKEY_Device_InstanceId' was not declared in this scope
710 | FAILED(properties->GetValue(PKEY_Device_InstanceId,
| ^~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
There's an intrinsic version in the kernel32 library. But it's not supposed
to be used with UCRT builds.
RtlSecureZeroMemory is not found in -O0 + UCRT builds without this fix.
In the Windows SDK it's a forced inline version no matter what.
(and there's an ARM version)
Signed-off-by: LIU Hao <lh_mouse@126.com>
It's usually an inline function doing native CPU calls. It's also unrestricted
in the Windows SDK since Windows 8, as well as SecureZeroMemory.
Signed-off-by: LIU Hao <lh_mouse@126.com>
Fixes regression from 3638d5e9a6 reported https://bugzilla.mozilla.org/show_bug.cgi?id=1847683.
Those guards are not present in Wine and Windows SDK for a reason: if INITGUID is changed, it should be reflected in DEFINE_PROPERTYKEY macro.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
This got referenced after 95433fd59d,
even if there was no definition of that type.
This unbreaks 32 bit builds that include dbghelp.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
In older MSVC versions that had a __MACHINEI macro, it was defined
to only expand on Intel 32 and 64 bit x86.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is required for rpcs3 project which defines DBGHELP_TRANSLATE_TCHAR.
Also this fixes the following compiler error.
error: cannot convert 'CHAR*' {aka 'char*'} to 'LPWSTR' {aka 'wchar_t*'}
error: 'SymGetLineFromAddrW' was not declared in this scope
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
The old condition is strictly equivalent to `__MACHINEX86X_NOWIN64` so I
believe it was a typo. As its name suggests, it should denote x86 or x86_64,
and not Itanium i.e. it should be empty when neither x86 nor x86_64, or on
Itanium.
Signed-off-by: LIU Hao <lh_mouse@126.com>
This also fixes the following error.
wlanapi.h:18:44: note: expanded from macro 'WLAN_NOTIFICATION_SOURCE_ALL'
^
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
Define QOS_FLOWID before it is used. This fixes the following errors.
In file included from ../../../../../b/src/3rdparty/chromium/net/socket/udp_socket_win.h:14:
qos2.h:87:3: error: unknown type name 'PQOS_FLOWID'
PQOS_FLOWID FlowId
^
qos2.h:112:3: error: unknown type name 'QOS_FLOWID'
QOS_FLOWID FlowId,
^
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
This fixes the following errors.
In file included from ../../../../../b/src/3rdparty/chromium/net/socket/udp_socket_win.h:14:
qos2.h:60:3: error: unknown type name 'UINT32'
UINT32 RTT;
^
qos2.h:77:3: error: unknown type name 'USHORT'; did you mean 'SHORT'?
USHORT MajorVersion;
^
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
These two headers were reimplmented in previous 3638d5e9a6 commit.
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
These files have been reimplemented with a more permissive license than their predecessors.
Signed-off-by: Dustin Gadal <dustin.gadal@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
These files will be reimplemented with a more permissive license in a subsequent patch.
Signed-off-by: Dustin Gadal <dustin.gadal@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
UCRT version of tmpnam() returns absolute path and L_tmpnam has to be
defined to accomodate that.
Fixes buffer overflow in various software when building with UCRT.
Fixes: https://sourceforge.net/p/mingw-w64/bugs/915/
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
The API's are allowed in windowsapp since 19H1 and are allowed by the WACK.
Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP
but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the
WACK this always works.
Signed-off-by: LIU Hao <lh_mouse@126.com>
The API's are allowed in windowsapp since RS4 and are allowed by the WACK.
Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP
but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the
WACK this always works.
CMS_DH_KEY_INFO is needed by CryptSetKeyParam().
Signed-off-by: LIU Hao <lh_mouse@126.com>
Microsoft::WRL::ComPtr::Attach should take ownership of an interface and
must therefore not increment the reference count of the attached
interface pointer.
This patch fixes this issue, and makes the MINGW64 implementation
behave the same way as the implementation shipped with the Microsoft
SDK.
Fixes: #892 Microsoft::WRL::ComPtr::Attach leaks references
Signed-off-by: Jøger Hansegård <joger.hansegard@qt.io>
Signed-off-by: LIU Hao <lh_mouse@126.com>
It is not allowed in older SDK. It won't compile or won't link. The target DLL
will likely not have the function, so it should not be used when targetting older
Windows 10 versions in UWP mode.
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 18362 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.
We already have api-ms-win-core-kernel32-legacy-l1-1-1
in windowsapp.
[1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-kernel32-legacy-l1-1-1dll
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 19041 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL api-ms-win-core-file-l1-2-0 will likely not have the
function, so it should not be used when targeting older Windows 10 versions
in UWP mode.
We now have api-ms-win-core-file-l1-2-0 in windowsapp.
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 19041 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL api-ms-win-core-file-l1-1-0 will likely not have the
function, so it should not be used when targeting older Windows 10 versions
in UWP mode.
The API entries have been added to api-ms-win-core-file-l1-1-0.
Signed-off-by: LIU Hao <lh_mouse@126.com>
* VirtualFree is always available in UWP
* VirtualAlloc is only available since 19H1/18362 SDK
* VirtualAllocEx is only available since 20H1/19041 SDK
They are all found in api-ms-win-core-memory-l1-1-0 which is in mincore
and windowsapp. It's one of the target DLLs [1]
[1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-memory-l1-1-0dll
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 18362 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.
We already have api-ms-win-core-libraryloader-l1-2-1 in mincore and windowsapp.
[1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-libraryloader-l1-2-1dll
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 19041 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.
We already have api-ms-win-core-file-l2-1-0 in mincore and windowsapp.
[1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-file-l2-1-0dll
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 19041 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.
We already have api-ms-win-core-heap-l1-1-0 and api-ms-win-core-heap-l1-2-0
in mincore and windowsapp.
[1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-heap-l1-2-0dll
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 18362 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.
We already have api-ms-win-core-heap-l1-1-0 and api-ms-win-core-heap-l1-2-0
in mincore and windowsapp.
[1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-heap-l1-2-0dll
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 18362 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.
We already have api-ms-win-core-handle-l1-1-0 in mincore and windowsapp.
[1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-handle-l1-1-0dll
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 19041 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.
We already have api-ms-win-core-errorhandling-l1-1-0 in mincore and windowsapp.
[1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-errorhandling-l1-1-0dll
Signed-off-by: LIU Hao <lh_mouse@126.com>
It is not allowed in older SDK. It won't compile or won't link. The target DLL
will likely not have the function, so it should not be used when targetting older
Windows 10 versions in UWP mode.
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 19041 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.
We already have api-ms-win-core-libraryloader-l1-2-0 in mincore and windowsapp.
[1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-libraryloader-l1-2-0dll
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 18362 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL api-ms-win-core-registry-l1-1-0 will likely not have the
function, so it should not be used when targeting older Windows 10 versions
in UWP mode.
We now have api-ms-win-core-registry-l1-1-0 in windowsapp.
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 18362 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.
We already have api-ms-win-core-libraryloader-l1-2-0 in mincore and windowsapp.
[1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-libraryloader-l1-2-0dll
Signed-off-by: LIU Hao <lh_mouse@126.com>
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 18362 Windows SDK.
It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.
We already have api-ms-win-core-file-l2-1-0 in mincore and windowsapp.
[1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-file-l2-1-0dll
Signed-off-by: LIU Hao <lh_mouse@126.com>
Just like GCC 11 got this function, Clang 17 also got an implementation
of it - thus skip our version to avoid conflicts.
Signed-off-by: Martin Storsjö <martin@martin.st>
Contrary to what the documentation says, it's available in the Windows SDK,
both in the headers and when linking with WindowsApp.lib.
Signed-off-by: LIU Hao <lh_mouse@126.com>
While these are standard C11 functions, Microsoft docs say they operate
on strings in UTF-8, instead of strings in the encoding determined by the
current locale. The MSVCRT `mbstate_t`, being an `int`, is too small for
implementations of these functions.
This commit ensures these functions are only declared for UCRT; when
targeting MSVCRT only the typedefs are available.
Reference: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/c16rtomb-c32rtomb1?view=msvc-170
Signed-off-by: LIU Hao <lh_mouse@126.com>
Also add enums for interpreting some fields in the arm64 pdata.
These have been present in WinSDK since 10.0.19041.0.
Curiously, there's no similar structs for interpreting
the ARM xdata (but the format is well documented, just like
for ARM64).
Signed-off-by: Martin Storsjö <martin@martin.st>
We've had a definition of IMAGE_ARM64_RUNTIME_FUNCTION_ENTRY since
0f9569488b in 2018, but we missed
the definition of the generic IMAGE_RUNTIME_FUNCTION_ENTRY to
point to the arch specific version of it.
The shorter names RUNTIME_FUNCTION and PRUNTIME_FUNCTION already
are typedefs for IMAGE_ARM64_RUNTIME_FUNCTION_ENTRY though.
Signed-off-by: Martin Storsjö <martin@martin.st>
