These DLLs are available out of the box on arm32 and arm64 since
Windows 11.
However these DLLs themselves are only the main interface (containing
the fallback, essentially unusable, OpenGL 1.1 GDI implementation);
without a separate ICD (installable client driver), it's near useless.
Currently (Dec 2021), such a driver (implementing OpenGL on top of
D3D12) is installable in the "OpenCL and OpenGL Compatibility Pack" in
Microsoft Store (but it's only available for regular third party
applications if you install the Windows Insider version of it).
And even then, it's not necessarily available for all architectures.
(In a brief test, it seems like the driver is available for i686 and
aarch64 processes, but not for x86_64 or armv7).
By providing these import libraries, we risk that people porting
software to Windows 10 on ARM accidentally end up making binaries that
use OpenGL, which don't load on Windows 10, only on Windows 11.
(Earlier, they got clear link errors showing that these libraries
really aren't available for these architectures.)
For some projects with existing support for Windows 10 on ARM, the
fact that OpenGL is unavailable is handled by entirely disabling
building of intermediate wrapper libraries such as glew or libepoxy;
then the main application only detects the presence of glew or
libepoxy, and disables OpenGL functionality if not found. (This has
been tested with VLC, where the glew dependency already is hardcoded
to not be built for these targets, so this doesn't change anything for
the build output of VLC.)
As an additional measure, one could consider adding version guards
in the OpenGL headers, making the declarations unavailable when
targeting an older version of Windows that don't have the functions.
That would allow applications to detect whether it's available or
not depending on what Windows version they target. However, that
doesn't seem to be necessary right now.
Signed-off-by: Martin Storsjö <martin@martin.st>
There was a version already present as libquery.a for a couple of
arches, but the Windows SDK provides identical libquery.a and
libntquery.a, and the DLL on Windows 10 20H2 and 21H1 has much
fewer exports than the pre-existing def file.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was done with the following commands:
sed -Ei 's/^_(str|wcs)lwr\>.*$/&\n\1lwr == _\1lwr/' `grep -Elr '\<_strlwr\>' mingw-w64-crt`
git checkout mingw-w64-crt/lib-common/api-ms-win-crt-string-l1-1-0.def
Signed-off-by: Liu Hao <lh_mouse@126.com>
library name is libhtmlhelp.a but functions exported from hhcrtl.ocx
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: Liu Hao <lh_mouse@126.com>
Use the shared one for lib64 and libarm64, and add a new def file for
lib32.
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Use the shared one for lib64 and libarm64, and add a new def file for
lib32.
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
These can't really be considered crt functions, they just
lexicographically happened to be in the same range in ntdll.def
originally.
Signed-off-by: Martin Storsjö <martin@martin.st>
The removed lines seem to have been added blindly(?) by syncing
in functions that exist in the x86 versions of ntdll.dll in
ce5078c95f and
c26aade157.
Signed-off-by: Martin Storsjö <martin@martin.st>
also move the related _DATA variable to libarm32/Makefile.am
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: Liu Hao <lh_mouse@126.com>
These were generated using the following commands:
_files=$(find . -name "msvcr*.def*")
sed -Ei '/^__ms_fwprintf/d' $_files
sed -Ei 's/^(v?[fs]?w?printf)$/\1\n__ms_\1 == \1/' $_files
sed -Ei 's/^([fs]?w?scanf)$/\1\n__ms_\1 == \1/' $_files
This adds an exhaustive list of functions provided by MSVCRT.DLL
from Windows XP SP3.
These symbols make it possible to request MS behavior even when
<stdio.h> is included and __USE_MINGW_ANSI_STDIO is defined to 1.
Signed-off-by: Liu Hao <lh_mouse@126.com>
These DLLs might not have been present in the version of windows
where libarm32 was dumped from originally, but they're available
in current versions of Windows 10, for both arm32 and arm64.
Signed-off-by: Martin Storsjö <martin@martin.st>
Our `frexpl()` prior to this commit did not handle infinities and NaNs
correctly. These functions now return the source value verbatim.
The `frexp()` function from all MSVCR* DLLs returns a NaN if the first
argument is an infinity. We override it in our CRT.
Signed-off-by: Liu Hao <lh_mouse@126.com>
This provides access to DirectComposition functions
dcomp.h is updated to expose thoses functions
Signed-off-by: Pierre Lamot <pierre@videolabs.io>
Signed-off-by: Martin Storsjö <martin@martin.st>
Two functions that existed in lib64 but didn't exist in the libarm32
(AuthziQueryAuditPolicy, AuthziSetAuditPolicy, that probably only
existed in older windows version), were added to the shared file
which otherwise is the libarm32 version (dumped from a Windows 8.x
version).
Signed-off-by: Martin Storsjö <martin@martin.st>
The arm32 version of this def file was a superset of the functions
in lib64, except for entry points that aren't used for linking.
Signed-off-by: Martin Storsjö <martin@martin.st>
This adds def files for all the api-ms-win-crt-* dll files. I've tried to
add all the manual modifications from ucrtbase.def.in into these files, so
that linking to libucrt.a should work pretty much the same as linking to
libucrtbase.a, but ending up linking to the api sets dlls.
Signed-off-by: Martin Storsjö <martin@martin.st>
Install the import library for msvcrt.dll under the name libmsvcrt-os.a,
and install the one that is chosen as default as libmsvcrt.a
(which is what all toolchains link to implicitly).
Signed-off-by: Martin Storsjö <martin@martin.st>
Use the lib64 version of the def file for this - nothing in the
def file seems like it would be architecture specific.
CMake has some linking tests where it by default links a number of
"standard libraries", and -lwinspool are among them. Make sure
this library at least exists, in order not to fail such tests
pointlessly.
Signed-off-by: Martin Storsjö <martin@martin.st>
The def file existed for libarm32 before (originally in the libarm32
directory, later shared into lib-common), but wasn't actully built
for libarm32, only for lib64.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some math functions were marked DATA (to avoid linking to them, when
libmingwex provides a replacement) in lib64. Keep that annotation
only while targeting x86 platforms, for the math functions that we
don't provide for arm (where we intend to link to msvcrt for them).
Signed-off-by: Martin Storsjö <martin@martin.st>
Keeping all function definitions from both previous versions, since
there's no clear indication that they would be architecture specific.
Signed-off-by: Martin Storsjö <martin@martin.st>
Base the new one on the libarm32 one, which has got more/newer functions.
Include functions that seem to be specific to 64 bit mode (*_UserFree64,
*_UserMarshal64, *_UserSize64, *_UserUnmarshal64) only when building for
win64.
Signed-off-by: Martin Storsjö <martin@martin.st>
Keep functions from both versions that were missing on the other
ones.
Include *Ums* functions only for x86_64, based on annotations
in kernel32.spec in wine.
Keep manually commented out functions as they were. Include
__chkstk on arm though.
Signed-off-by: Martin Storsjö <martin@martin.st>
All functions seem to be architecture independent except one.
Keep MD5Update marked as DATA, as it was in lib64 before.
Signed-off-by: Martin Storsjö <martin@martin.st>
Include the C++ function definitions only on x86_64, since they were
only present in the lib64 def file.
Signed-off-by: Martin Storsjö <martin@martin.st>
In these cases, use the libarm32 version for both. None of the
differences should be architecture specific.
Signed-off-by: Martin Storsjö <martin@martin.st>
In these cases, use the lib64 version for both. None of the differences
should be architecture specific.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since the mingw C++ runtime isn't compatible with the MSVC C++
runtime (and uses a completely different name mangling), these
def files aren't of much use.
Signed-off-by: Martin Storsjö <martin@martin.st>
These defs only export DLL hooks, and one of the following entry points:
- GetProxyDllInfo
- GetResourceString
- InitHelperDll
- ServiceEntry
- ServiceMain
Signed-off-by: Martin Storsjö <martin@martin.st>
