Re: [Mingw-w64-public] Problems when building NT kernel drivers with GCC / LD

2022-10-30 Thread ralph engels via Gcc
i think most of it stems from binutils tools being geared towards linux 
driver development ? and since noone before has shown much interrest in 
developing drivers for windows using the gnu tools. I also think that 
there might be some pitfalls -> incompatible exception models for one 
(most mingw based compilers today use dwarf unwinders for 32 bit maybe a 
few who use sjlj) the problem with that is that atleast 32 bit windows 
cannot do anything with this exception model sjlj is a little better in 
that regard but still. If done in pure C or asm it could work if those 
options were avaliable but it does limit the scope i think.


Den 30-10-2022 kl. 08:06 skrev Martin Storsjö:

On Sun, 30 Oct 2022, Pali Rohár wrote:


* LD --dynamicbase is not working correctly. If used for PE executables
 (not dynamic libraries) then it does *not* generate relocation info.
 And without relocation info in PE binary, it is not possible to
 relocate base address. Which makes dynamic base non-working.


I don't know about the rest, but this one sounds familiar to me. But 
IIRC this one was fixed semi-recently (1-2 years ago), while making 
--dynamicbase the default.


I think it was fixed in this binutils commit:

commit 514b4e191d5f46de8e142fe216e677a35fa9c4bb
Author: Jeremy Drake 
Date:   Thu Aug 27 12:58:27 2020 +0100

    Change the default characteristics of DLLs built by the linker to 
more secure settings.


This commit is included in binutils 2.36 and later.

// Martin

___
Mingw-w64-public mailing list
mingw-w64-pub...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library

2022-11-20 Thread ralph engels via Gcc
Mmm yeah i newer seen problems with missing msvcrt.dll either going back 
as far as win9x there was some other missing runtimes but not that 
particular one.


Den 20-11-2022 kl. 16:58 skrev Eli Zaretskii:

Date: Sun, 20 Nov 2022 16:44:08 +0100
From: Pali Rohár 
Cc: gcc@gcc.gnu.org, mingw-w64-pub...@lists.sourceforge.net


Installing a redistributable is a nuisance, and dependence on non-system
libraries might make the program non-free.

On new windows versions they may be preinstalled (depends on newness of
windows version).

I'm talking about older ones.  It is customary nowadays to build on Windows
11 and then run on Windows 8.


And if your application uses features unavailable in
older (or default) crt versions then this make application code
simplifier. Also redistributable packages are in most cases installed by
Windows update mechanism, which could be marked as system library. But
well, this is more license discussion than development discussion...

I mentioned that because people might inadvertently build GPL'ed GNU
software using this option, and violate the GPL without knowing it.  This is
relevant to those who read this list and port GNU software to MS-Windows.


Note that with this option, you can also choose older version than the
default one (WinXP msvcrt.dll). So e.g. you can choose msvcrt20.dll or
crtdll.dll for older Windows version.

Using the OS default MSVCRT already gets me that, at zero cost.

Here "OS default MSVCRT" means Windows XP MSVCRT.DLL.

On older windows versions there is no pre-installed MSVCRT.DLL. There
is MSVCRT20.DLL or CRTDLL.DLL (based on oldness of windows version). So
it is not at zero cost, you have yo either do that nuisance and install
MSVCRT.DLL as you write above or switch to older CRT version which is in
OS preinstalled.

I never saw any problems with programs linked against MSVCRT.DLL, on all
versions of Windows from XP up to Windows 10.  None.


___
Mingw-w64-public mailing list
mingw-w64-pub...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public