Function _abs64() is available since msvcr80.dll on 64-bit systems and
since msvcr90.dll on 32-bit systems. It is also available on 64-bit version
of msvcrt.dll system library. Function llabs() is available since
msvcr100.dll and function imaxabs() since msvcr120.dll.
For older msvcrt versions whi
On Monday 19 December 2022 16:04:23 LIU Hao wrote:
> 在 2022/12/19 00:31, Pali Rohár 写道:
> > ---
> > mingw-w64-tools/genstubdll/sample/ms.def | 1416 --
> > 1 file changed, 1416 deletions(-)
> > delete mode 100644 mingw-w64-tools/genstubdll/sample
Hello! I think that this patch was not applied yet.
On Tuesday 06 December 2022 22:17:23 Pali Rohár wrote:
> moldname content is already included in all other msvcrt def files. This
> allows applications to use moldname aliases defined in msvcrt-common.def.in
> also when linking with
On Wednesday 21 December 2022 15:00:34 Martin Storsjö wrote:
> I guess I'd need to build mingw-w64-crt with -flto in order to reproduce the
> situation at hand though.
Yes, that is needed.
I was thinking about adding a new configure flag --enable-lto which
will do it for easier LTO builds.
On Wednesday 21 December 2022 14:54:13 Martin Storsjö wrote:
> On Sat, 17 Dec 2022, LIU Hao wrote:
>
> > 在 2022-12-17 20:01, Pali Rohár 写道:
> > > It would be nice if somebody who understand these patterns write some
> > > comment what is the real purpose of the fi
On Friday 23 December 2022 22:25:57 LIU Hao wrote:
> 在 2022-12-21 21:00, Martin Storsjö 写道:
> >
> > I believe this patch should be harmless; for regular object file based
> > linking, __attribute__((used)) shouldn't have any effect across object
> > file boundaries (it only affects what's emitted
On Friday 23 December 2022 22:20:25 LIU Hao wrote:
> 在 2022-12-04 21:49, Pali Rohár 写道:
> > Format attributes is interesting issue. Because there are already following
> > printf implementations:
> >
> > 1) C89 (without %lld) (crtdll.dll, msvcrt10.dll)
> > 2) C
On Saturday 24 December 2022 01:00:59 LIU Hao wrote:
> 在 2022-12-24 00:18, Pali Rohár 写道:
> > What is the reason? Maybe it was gcc/ld bug which this patch workarounds?
> >
>
> Generally speaking, all variables that are required to be placed in special
> sections to
On Saturday 24 December 2022 03:17:57 LIU Hao wrote:
> 在 2022-12-24 01:43, Pali Rohár 写道:
> > Ou right. They would also require __attribute__((used)) for LTO builds.
> > I just tested simple single process/thread console applications and they
> > worked.
> >
&g
On Saturday 24 December 2022 11:48:51 LIU Hao wrote:
> 在 2022-12-24 06:14, Pali Rohár 写道:
> > I just quickly tested it only in wine. Without LTO it prints "ł$"
> > (really strange, looks like some memory problem, maybe in wine?).
> >
>
> Oop
On Sunday 25 December 2022 17:21:50 LIU Hao wrote:
> 在 2022-12-25 02:19, Pali Rohár 写道:
> > This patch fixes it! And also in LTO mode it prints "test thread atexit".
> >
>
> Mostly good. Should `__xl_d` be given an attribute as well?
It is not referenced anywher
Hello! I would like to remind this thread for gcc/binutils developers.
Most of these issues are still present and cause problems for compiling
native PE binary. If you have questions or you need any other information
please let me know.
On Sunday 30 October 2022 02:06:11 Pali Rohár wrote:
> He
On Tuesday 27 December 2022 14:38:00 LIU Hao wrote:
> Variables that are required to be placed in explicit sections probably
> have special meanings, and shall not be eliminated by LTO. Preserving
> all of them might look an overkill, but should be safest.
>
> Signed-off-by: LIU Hao
> ---
> ming
On Saturday 19 November 2022 15:42:45 Pali Rohár wrote:
> On Saturday 19 November 2022 11:53:28 Pali Rohár wrote:
> > On Saturday 19 November 2022 17:12:12 LIU Hao wrote:
> > > 在 2022-11-18 23:40, Pali Rohár 写道:
> > > > GNU LD provides __ImageBase symbol since
Hello! I did another test on master branch of mingw-w64 with very simple
snprintf test.c program which does not include any header file:
typedef long unsigned int size_t;
int __cdecl snprintf(char *buffer, size_t n, const char *format, ...);
int main(int argc, char *argv[]) {
char buffer
On Thursday 29 December 2022 13:09:18 Martin Storsjö wrote:
> > > The question is now how to handle this issue? Based on this testing, I
> > > do not see what can be done. weak should not be used, LTO also (and does
> > > not work with old gcc), moving symbol to header file does not sounds
> > > li
On Tuesday 03 January 2023 11:06:26 Nick Clifton wrote:
> Hi Pali,
>
> > Hello! I would like to remind this thread for gcc/binutils developers.
> > Most of these issues are still present and cause problems for compiling
> > native PE binary. If you have questions or you need any other information
On Monday 20 February 2023 19:25:22 Pali Rohár wrote:
> On Tuesday 03 January 2023 11:06:26 Nick Clifton wrote:
> > Hi Pali,
> >
> > > Hello! I would like to remind this thread for gcc/binutils developers.
> > > Most of these issues are still present and cause pr
On Saturday 17 December 2022 15:22:11 Pali Rohár wrote:
> Currently when linking target application with LTO builds of mingw-w64
> libraries, it is needed to manually specify entry point of mingw-w64 crt
> startup function via linker flag -Wl,-e,_mainCRTStartup (for console
> executa
Documentation for _amsg_exit says:
Emits a specified runtime error message and then exits your application with
error code 255.
---
mingw-w64-crt/crt/ucrtbase_compat.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-crt/crt/ucrtbase_compat.c
b/mingw-w64-crt/crt/ucrtbase_compat.c
in
On Wednesday 12 April 2023 10:53:32 Nick Clifton wrote:
> Hi Pali,
>
> > > Hello! Just for a record, I filled individual issues to bugzilla:
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30004
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30139
> > > https://sourceware.org/bugzilla
On Sunday 04 December 2022 20:48:30 LIU Hao wrote:
> 在 2022-12-04 20:16, Pali Rohár via Gcc 写道:
> > Hello! I would like to ask gcc people, what do you think about such
> > proposed -mcrtdll= parameter?
> >
> > There are lot of unofficial gcc patches which implement t
On Thursday 29 December 2022 00:22:24 Martin Storsjö wrote:
> On Wed, 28 Dec 2022, Pali Rohár wrote:
>
> > Hello! I did another test on master branch of mingw-w64 with very simple
> > snprintf test.c program which does not include any header file:
> >
> > ty
On Friday 23 December 2022 17:21:38 Pali Rohár wrote:
> On Friday 23 December 2022 22:20:25 LIU Hao wrote:
> > 在 2022-12-04 21:49, Pali Rohár 写道:
> > > Format attributes is interesting issue. Because there are already
> > > following
> > > printf implementation
On Thursday 29 December 2022 15:14:53 Martin Storsjö wrote:
> On Thu, 29 Dec 2022, Pali Rohár wrote:
>
> > Putting extern IMAGE_DOS_HEADER __ImageBase __asm__("__image_base__");
> > into header file can cause issues for applications which define in their
> > own
On Saturday 22 April 2023 20:56:26 LIU Hao wrote:
> 在 2023-04-22 20:01, Pali Rohár 写道:
> > Now I have looked at it again... what about just for mingw-w64-crt build
> > add following CFLAG -D__ImageBase=__MINGW_LSYMBOL(_image_base__)
> >
> > It would work only for ming
GNU LD provides __ImageBase symbol since 2.19. This is standard windows
symbol and should be used instead of custom gnu _image_base__ symbol.
Detect non-existence of __ImageBase symbol at ./configure time by code done
by Martin Storsjö in commit eeea20fccc42b30988b49a63413b62fa21cb33a2. And
for co
On Friday 21 April 2023 18:23:28 Pali Rohár wrote:
> On Sunday 04 December 2022 20:48:30 LIU Hao wrote:
> > 在 2022-12-04 20:16, Pali Rohár via Gcc 写道:
> > > Hello! I would like to ask gcc people, what do you think about such
> > > proposed -mcrtdll= parameter?
&g
On Friday 21 April 2023 18:38:34 Pali Rohár wrote:
> On Thursday 29 December 2022 00:22:24 Martin Storsjö wrote:
> > On Wed, 28 Dec 2022, Pali Rohár wrote:
> >
> > > Hello! I did another test on master branch of mingw-w64 with very simple
> > > snprintf test.c p
On Friday 21 April 2023 18:46:01 Pali Rohár wrote:
> On Friday 23 December 2022 17:21:38 Pali Rohár wrote:
> > On Friday 23 December 2022 22:20:25 LIU Hao wrote:
> > > 在 2022-12-04 21:49, Pali Rohár 写道:
> > > > Format attributes is interesting issue. Because there
Trying to use or link DllMain symbol from some random system DLL library is
in most cases a mistake. So hide all DllMain definitions from all def files.
---
mingw-w64-crt/lib-common/acledit.def | 1 -
mingw-w64-crt/lib-common/htui.def | 1 -
mingw-w64-crt/lib-common/keymgr.def | 1 -
mingw-
If application does not specify its own DllEntryPoint function then the
default DllEntryPoint provided by libmingwex library should be used. And
not from some random system DLL library.
---
mingw-w64-crt/lib64/fxsdrv.def | 1 -
mingw-w64-crt/lib64/wiaservc.def | 1 -
2 files changed, 2 deletions
---
mingw-w64-crt/crt/crtdll.c | 2 +-
mingw-w64-crt/crt/crtexe.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
index 0f08a1a50d78..88450ce9f74f 100644
--- a/mingw-w64-crt/crt/crtdll.c
+++ b/mingw-w64-crt/crt/crtdll
* Include C++ mangled symbols
* Include Windows NT 3.51+ symbols
* Extend comment about different versions
* Update list of symbols which do not have prototypes yet
---
mingw-w64-crt/lib32/crtdll.def.in | 152 ++
1 file changed, 29 insertions(+), 123 deletions(-)
diff
All commented lines refers to non-underscore aliases for underscored
variant of functions. Aliases for some reasons are not prevent, e.g.
because some aliases are defined in other files (CRT_fp10.c and CRT_fp8.c).
---
mingw-w64-crt/def-include/msvcrt-common.def.in | 15 ---
1 file chan
Header file time.h already redirects function call gmtime() to _gmtime32().
So if object file compiled with time.h is linked with e.g. libmsvcrt40.a
import library then it is needed to add redirection from _gmtime32 symbol
to gmtime symbol into libmsvcrt40.a library to ensure that application
would
On Tuesday 09 May 2023 22:29:31 LIU Hao wrote:
> Our conclusion is that, in order to reduce possible UCRT dependency, moving
> inline definitions out of headers makes sense; but the other part, such as
> duplication of functions, will not be accepted.
Ok, so does it mean that the one change with t
On Wednesday 28 February 2024 23:24:25 Martin Storsjö wrote:
> On Wed, 28 Feb 2024, Pali Rohár wrote:
>
> > All commented lines refers to non-underscore aliases for underscored
> > variant of functions. Aliases for some reasons are not prevent, e.g.
> > because some alia
On Thursday 29 February 2024 10:16:47 Martin Storsjö wrote:
> On Thu, 29 Feb 2024, Pali Rohár wrote:
>
> > On Wednesday 28 February 2024 23:24:25 Martin Storsjö wrote:
> > > On Wed, 28 Feb 2024, Pali Rohár wrote:
> > >
> > > > All commented lines refers
On Sunday 03 March 2024 23:38:57 Martin Storsjö wrote:
> On Sun, 3 Mar 2024, Pali Rohár wrote:
>
> > Ok, do you need me to resend this patch? Or would you fix this one
> > missing semicolon during applying patch?
>
> I can fix the missing semicolon.
>
> > A
On Thursday 29 February 2024 22:07:40 LIU Hao wrote:
> 在 2024-02-29 04:25, Pali Rohár 写道:
> > On Tuesday 09 May 2023 22:29:31 LIU Hao wrote:
> > > Our conclusion is that, in order to reduce possible UCRT dependency,
> > > moving
> > > inline definitions out o
On Monday 11 March 2024 13:14:02 LIU Hao wrote:
> 在 2024-03-09 23:58, Pali Rohár 写道:
> > The point is that this one change allows to have object file with
> > function calls to _scprintf or _snprintf to be CRT independent.
>
> Let me guess, you have an object file (mayb
On Wednesday 28 February 2024 23:13:33 Martin Storsjö wrote:
> (Separately, we probably should remove other similar exported symbols like
> DllRegisterServer as well? And from looking at your patch, e.g. pscript5,
> unidrv, look like something that should not be an import library at all.
> I've cle
On Monday 11 March 2024 19:02:09 LIU Hao wrote:
> 在 2024-03-11 15:52, Pali Rohár 写道:
> > I know, but I'm trying to achieve it by small steps. For _scprintf it
> > should fix this issue as mingw library starts providing required symbol
> > for linking object files. Or do
On Saturday 23 March 2024 22:22:03 LIU Hao wrote:
> 在 2024-03-23 18:43, Pali Rohár 写道:
> > On Monday 11 March 2024 19:02:09 LIU Hao wrote:
> > > 在 2024-03-11 15:52, Pali Rohár 写道:
> > > > I know, but I'm trying to achieve it by small steps. For _scprintf it
>
On Monday 25 March 2024 13:59:49 LIU Hao wrote:
> 在 2024-03-24 23:17, Pali Rohár 写道:
> > I see... The problem is that inline version of that function in stdio.h
> > conflicts with non-inline version in ucrt__scprintf.c file.
> >
> > One option how to avoid this proble
The original msvcrt20.dll version from Visual C++ 2.0 does not contain some
symbols, which are present in the version from Visual C++ 2.1 Upgrade. Also
Win32s version of msvcrt20.dll from Visual C++ 2.0 does not contain all
symbols as full version. Follow up Visual C++ 2.2 Upgrade version have not
The original msvcrt40.dll version from Visual C++ 4.0 does not contain some
symbols, which are present in the version from Visual C++ 4.1 Upgrade. Also
Win32s version of msvcrt40.dll from Visual C++ 4.0 does not contain all
symbols as full version. Follow up Visual C++ 4.2 Upgrade switches from
msv
Some symbols from original Microsoft Visual C++ 4.0 msvcrt40.dll library
are not available in Windows NT-based OS systems versions. Disable these
symbol exports as they are not usable on any recent system.
---
mingw-w64-crt/lib32/msvcrt40.def.in | 23 ---
1 file changed, 12 ins
I386 symbols __CxxLongjmpUnwind, _adj_fdiv_m*, _adj_fdivr_m* and
_seh_longjmp_unwind have @8 size suffix in all msvcrt.dll versions,
including original MSVC 4.2, 5.0, 6.0 and also in Windows 98, ME and also
in all NT versions (4.0, 2000, XP up to 10).
Without @SIZE suffix are these symbols only in
Checked with Windows XP x64 and also with Windows 10 x64 versions of msvcrt.dll.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index d5788b2777b
It is available in Windows XP x64, but was removed in Windows Vista x64.
So disable its usage for X64.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
ind
In msvcrt.def.in file are already defined mangled C++ symbols for X64 and
ARM32 versions of msvcrt.dll, so add also them for I386 version.
These symbols are present in Visual C++ 4.2 version of msvcrt.dll and same
set of symbols are in Visual C++ 5.0 and 6.0 versions.
---
mingw-w64-crt/lib-common
They are present in msvcrt.dll since Windows Vista.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index 460a1bab097b..5b2f4ddb2f08 100644
--- a/mingw-w6
These aliases are automatically added by including msvcrt-common.def.in file.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 2 --
1 file changed, 2 deletions(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index 126097187f69..5dc55e06b166 100644
---
Symbol wcsnlen was first introduced in Windows Vista version of msvcrt.dll
and mingw-w64 already provides replacement implementation in libmingwex. So
always use the replacement implementation on I386 and X64 and do not export
it. Also remove DATA keyword and use it in the same way as other wc*
sym
---
mingw-w64-crt/lib-common/msvcrt.def.in | 8
1 file changed, 8 insertions(+)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index 2bd70dd59182..3057afc2bb33 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-commo
Symbols __buffer_overrun, __lc_clike, __security_error_handler,
__set_buffer_overrun_handler, _CRT_RTC_INIT, _set_security_error_handler
and _set_purecall_handler are not available in any examined I386 version of
msvcrt.dll (up to Windows 10).
Reason why there are defined in lib-common/msvcrt.def.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 4
1 file changed, 4 insertions(+)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index 3ed4b66c7281..2bd70dd59182 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-common/ms
---
mingw-w64-crt/lib-common/msvcrt.def.in | 14 ++
1 file changed, 14 insertions(+)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index 3057afc2bb33..818d5149b156 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/l
---
mingw-w64-crt/lib-common/msvcrt.def.in | 136 -
1 file changed, 88 insertions(+), 48 deletions(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index 818d5149b156..71a6efcde3c9 100644
--- a/mingw-w64-crt/lib-common/msvcrt
---
mingw-w64-crt/lib-common/msvcrt.def.in | 50 --
1 file changed, 32 insertions(+), 18 deletions(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index 7e407891435d..cf29518e3314 100644
--- a/mingw-w64-crt/lib-common/msvcrt
---
mingw-w64-crt/lib-common/msvcrt.def.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index 71a6efcde3c9..7e407891435d 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/l
Library msvcrt.dll was used by Visual C++ versions 4.2 - 6.0 and is also
part of the Windows system starting with NT 4.0 and 98.
Currently the file msvcrt.def.in contains mix of all symbols in semi
alphabetical order, with ad-hoc symbol aliases which some are not exported
by any msvcrt.dll version
dli.szDll is of LPCSTR type, which is always const char* (and not wchar_t*).
So instead of LoadLibrary() (which may take wchar_t* if _UNICODE macro is
defined by compiler) use LoadLibraryA() (which always takes char*).
---
mingw-w64-crt/misc/delayimp.c | 2 +-
1 file changed, 1 insertion(+), 1 del
Symbols _getdllprocaddr, _heapadd, _heapused, _loaddll and _unloaddll are
available also in Windows XP x64 but were removed in Windows Vista x64 and
not present in any later Windows x64 version. So do not export these
symbols for X64.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 10 +-
1 f
---
mingw-w64-crt/lib-common/msvcrt.def.in | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index d03b79314c12..a6f6da184274 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64
Symbol __CxxCallUnwindDelDtor is not available in any X64 version of
msvcrt.dll library. So do not export it on X64.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msv
Symbol tanhf is available since Windows Vista x64. It is not available on
any 32-bit x86 version. So move this symbol from ARM-only section into
since-Vista section.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/lib-com
Windows XP x64 does not provide 32-bit time functions. Those are provided
on X64 systems since Windows Vista x64.
Main function symbols (those without suffixes) are 64-bit on all Windows
x64 systems.
So remove aliasing of X64 "time" symbol to "_time64" symbol as it is not
needed.
Symbol "_diffti
On Friday 05 April 2024 00:02:02 Martin Storsjö wrote:
> On Mon, 1 Apr 2024, Pali Rohár wrote:
>
> > ---
> > mingw-w64-crt/lib-common/msvcrt.def.in | 136 -
> > 1 file changed, 88 insertions(+), 48 deletions(-)
> >
> > diff --git a/mi
---
mingw-w64-crt/lib-common/msvcrt.def.in | 50 --
1 file changed, 32 insertions(+), 18 deletions(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index 7b2660d2f879..cb9b25dd854f 100644
--- a/mingw-w64-crt/lib-common/msvcrt
Library msvcrt.dll was used by Visual C++ versions 4.2 - 6.0 and is also
part of the Windows system starting with NT 4.0 and 98.
Currently the file msvcrt.def.in contains mix of all symbols in semi
alphabetical order, with ad-hoc symbol aliases which some are not exported
by any msvcrt.dll version
Windows XP x64 does not provide 32-bit time functions. Those are provided
on X64 systems since Windows Vista x64.
Main function symbols (those without suffixes) are 64-bit on all Windows
x64 systems.
So remove aliasing of X64 "time" symbol to "_time64" symbol as it is not
needed. This removes als
For I386 and X64 they are present in msvcrt.dll since Windows Vista.
And Martin Storsjö pointed that ARM64 version of msvcrt.dll also contains
them.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 2 --
1 file changed, 2 deletions(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-
mingw-w64-crt provides x86 replacement for _fseeki64 and _get_errno.
Fixes commit 2924b5733903a15520f4a430a2c0c3f38ac098e9.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/li
Symbols _getdllprocaddr, _heapadd, _heapused, _loaddll and _unloaddll are
available also in Windows XP x64 but were removed in Windows Vista x64 and
not present in any later Windows x64 version. So do not export these
symbols for X64.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 10 +-
1 f
Symbol __CxxCallUnwindDelDtor is not available in any X64 version of
msvcrt.dll library. So do not export it on X64.
Fixes commit 2924b5733903a15520f4a430a2c0c3f38ac098e9.
---
mingw-w64-crt/lib-common/msvcrt.def.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/
On Thursday 04 April 2024 23:43:33 Martin Storsjö wrote:
> On Mon, 1 Apr 2024, Pali Rohár wrote:
>
> > They are present in msvcrt.dll since Windows Vista.
> > ---
> > mingw-w64-crt/lib-common/msvcrt.def.in | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
&
On Friday 05 April 2024 00:23:22 Martin Storsjö wrote:
> On Mon, 1 Apr 2024, Pali Rohár wrote:
>
> > Library msvcrt.dll was used by Visual C++ versions 4.2 - 6.0 and is also
> > part of the Windows system starting with NT 4.0 and 98.
> >
> > Currently the file msv
On Friday 05 April 2024 10:29:26 Martin Storsjö wrote:
> On Thu, 4 Apr 2024, Pali Rohár wrote:
>
> > Windows XP x64 does not provide 32-bit time functions. Those are provided
> > on X64 systems since Windows Vista x64.
> >
> > Main function symbols (those witho
Commit c52f1eb09901e038ceb7012730e7cf3395d65a78 incorectly stated that
_strtoi64 and _strtoui64 symbols are available since the first release of
msvcrt.dll library (part of MS Visual C++ 4.2).
But only the symbol _atoi64 mentioned in that commit is available since
the first msvcrt.dll release.
Sy
On Saturday 06 April 2024 01:01:32 Martin Storsjö wrote:
> On Fri, 5 Apr 2024, Pali Rohár wrote:
>
> > > As this patchset depends a bit on some of the unapplied parts of the
> > > previous set, I'll defer applying it until all parts o the previou
---
Per request from email
https://sourceforge.net/p/mingw-w64/mailman/message/58756761/
I'm sending a change which completely removes those 3 inline functions.
It should be applied after the change "Add non-inline variant of UCRT
_scprintf, _snprintf and _snscanf functions" from email attachment
For non-msvcrtos builds are global variables __MINGW_IMP_SYMBOL(_scprintf)
__MINGW_IMP_SYMBOL(_vscprintf) not changing, they are constant.
So define _scprintf and _vscprintf functions as direct alias to
emu_scprintf and emu_vscprintf functions instead of via indirect
unconditional jump or function
Symbols __p__fileinfo, _ctype, _fileinfo, _ftime, _futime, _mbscat,
_mbscpy, _mbsdup, _strcmpi, _utime, _wutime, difftime, swprintf, vswprintf,
__buffer_overrun, __security_error_handler, __set_buffer_overrun_handler,
_set_security_error_handler and _wctype are not present in any variant of
msvcr80
All symbols are extracted from the latest version of msvcr80.dll library
which is Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package
MFC Security Update available for download at page:
https://www.microsoft.com/download/details.aspx?id=26347
---
mingw-w64-crt/lib32/msvcr80.def.in | 5
ove example is:
buf=12 ret=9
Which is correct now.
Would you consider fixing snprintf() in mingw-w64?
Similarly also vsnprintf() can be fixed:
#define vsnprintf(str, size, format, ap) ( (((size_t)(size) > 0) ?
(_vsnprintf((str), (size), (format), (ap)), ((char *)str)[(size_t)(size)-1] =
I386 symbols __CxxLongjmpUnwind, _adj_fdiv_m*, _adj_fdivr_m* and
_seh_longjmp_unwind have @SIZE suffix in I386 version of msvcr80.dll.
Fix symbol names in lib32/msvcr80.def.in file.
---
mingw-w64-crt/lib32/msvcr80.def.in | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
__lc_clike and _mbcasemap symbols are DATA in all msvcr*.dll libraries,
including I386 variant of msvcr80.dll. So fix lib32/msvcr80.def.in file.
---
mingw-w64-crt/lib32/msvcr80.def.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-crt/lib32/msvcr80.def.in
b/ming
Add I386 C++ symbols from Visual C++ 2005 SP1 I386 msvcr80.dll library.
---
mingw-w64-crt/lib32/msvcr80.def.in | 141 +
1 file changed, 141 insertions(+)
diff --git a/mingw-w64-crt/lib32/msvcr80.def.in
b/mingw-w64-crt/lib32/msvcr80.def.in
index e0d8ad569e13..90d4014e7
It looks like that lib64/msvcr80.def.in file contains X64 C++ symbols not
from the msvcr80.dll library but from the Windows XP x64 msvcrt.dll
library. X64 version of msvcrt.dll and msvcr80.dll have different C++
symbols but relatively same set of C symbols.
Replace incorrect X64 C++ symbols in lib
In all other msvcr* versions is X64 pow and powf defined as DATA. Do it
also in msvcr80.def.in.
---
mingw-w64-crt/lib64/msvcr80.def.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-crt/lib64/msvcr80.def.in
b/mingw-w64-crt/lib64/msvcr80.def.in
index 6fa6ef37c13a
---
mingw-w64-crt/lib32/msvcr80.def.in | 1443 ++--
mingw-w64-crt/lib64/msvcr80.def.in | 1311 +
2 files changed, 1376 insertions(+), 1378 deletions(-)
diff --git a/mingw-w64-crt/lib32/msvcr80.def.in
b/mingw-w64-crt/lib32/msvcr80.def.in
index 60573
X64 llabs and imaxabs are already defined as aliases to _abs64. Do same for
I386 build.
---
mingw-w64-crt/Makefile.am | 5 +
mingw-w64-crt/lib32/msvcr80.def.in | 2 ++
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
Symbols _swprintf and _vswprintf were added in Windows Vista and have same
meaning as symbols without leading underscore in msvcrt.dll. These symbols
(both with and without leading underscore) differs from C99 variant as they
do not take maxlen parameter.
For compatibility with pre-Vista systems,
On Tuesday 09 April 2024 22:24:06 LIU Hao wrote:
> A little suggestion: If I was to import these functions, I would not add
> `swprintf` due to the inconsistency. For example, MSVCR120.DLL does not
> export `swprintf`, but only `_swprintf` and two C++ overloads; C++ names are
> mangled so they can
Symbols __CxxFrameHandler2, _freea_s, _get_pgmptr and _get_wpgmptr are not
present in Windows RT 8.0 and neither in 8.1 versions of msvcrt.dll
library. So mark them as X86-only.
And additional symbol __jump_unwind is present in Windows RT 8.0 and 8.1,
so put it into Windows 8 section as ARM-only.
Symbols _assert@4 and abort@4 in all versions of msvcr70.dll have @SIZE
suffixes. Without @SIZE suffixes they are only in debug msvcr70d.dll
library versions and Itanium msvcr70.dll versions.
Visual Studio .NET 2002 version of msvcr70.dll library (7.00.9466.0)
contains additional symbol __CxxCallU
Symbols _assert@4 and abort@4 in all versions of msvcr71.dll have @SIZE
suffixes. Without @SIZE suffixes they are only in debug msvcr71d.dll
library versions and Itanium msvcr70.dll versions. But all those libraries
have different name, not compatible with msvcr71.def.in file. So update
msvcr71.def
101 - 200 of 566 matches
Mail list logo
