Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Mon, 30 Sep 2024 17:01:01 +0200
Organization: A noiseless patient Spider
Lines: 112
Message-ID: <vdeefd$29aqt$1@dont-email.me>
References: <vbd6b9$g147$1@dont-email.me>
 <2024Sep10.094353@mips.complang.tuwien.ac.at> <vckf9d$178f2$1@dont-email.me>
 <O2DHO.184073$kxD8.113118@fx11.iad> <vcso7k$2s2da$1@dont-email.me>
 <efXIO.169388$1m96.45507@fx15.iad>
 <8f031f2b5082d97582b1231a060f2b9f@www.novabbs.org>
 <8DgJO.171468$1m96.17060@fx15.iad> <vd7peh$12kpl$2@dont-email.me>
 <KWUJO.41016$vtH3.33971@fx07.iad> <86msjr2bec.fsf@linuxsc.com>
 <vdaur7$1lr7j$1@dont-email.me> <86ikue2zlr.fsf@linuxsc.com>
 <vdc9s0$1rseh$1@dont-email.me> <vde4aj$26pck$2@dont-email.me>
 <20240930173247.0000643e@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 30 Sep 2024 17:01:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="431bab09004aa83519704625a7d1958c";
	logging-data="2403165"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX182tzw3NzFNFioUF+mluC8fLApKfrK7Pio="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:UnKLz2l1RG7Zp2BW85tYdvsde1s=
Content-Language: en-GB
In-Reply-To: <20240930173247.0000643e@yahoo.com>
Bytes: 5925

On 30/09/2024 16:32, Michael S wrote:
> On Mon, 30 Sep 2024 14:07:47 +0200
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> On 29/09/2024 21:30, Thomas Koenig wrote:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>   
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>>> [...]
>>>>>> I am currently in the position of needing to take some code
>>>>>> written for Linux/Unix and get it running in MS Windows.
>>>>>>
>>>>>> My attempts to use MSVC have been frustrating, because of some
>>>>>> limitations of that environment.  The two most prominent are
>>>>>> these:  long double is only 64 bits, and there are no integer
>>>>>> types of 128 bits that I could find.
>>>>>
>>>>> Depending on what you need to to, you can give MinGW-w64 a try.
>>>>> It works either as a cross-compiler from Linux or on Windows using
>>>>> msys2 or Cygwin.
>>>>
>>>> Thank you for these suggestions.  I have started to explore
>>>> mingw but not yet the others.  Is there a difference between
>>>> mingw and mingw-w64, do you know?
>>>
>>> One is a fork of the other, I believe.
>>>    
>>
>> mingw-w64 was started as a fork of mingw, initially created to
>> support generating 64-bit binaries and because of disagreements with
>> the pace of development in mingw.
>>
>>
>>>> Also do you know if mingw
>>>> is compatible with MSVC, as long as long double is not used?
>>>
>>> I believe that Mingw-w64 uses the Windows ABI, but that is a
>>> belief, not something I know first-hand; I haven't looked
>>> at the assembly.
>>
>> There is a reasonably defined ABI for 64-bit Windows, so I think
>> there will be compatibility for most things in C.
> 
> For "most things" - yes. For 'long double' - no.
> In case of 'long double' mingw64 tools use their own conventions that
> differ both from SysV and from Win64.

I did not know that - thanks for that information.  (Though hopefully 
I'll not have to do enough C programming on Windows to find the 
information useful!)

> But at C level behavior is
> identical to x86-64 Linux.
> 
>> C++ is more
>> complicated and much more likely to have incompatibilities.
>>
>> There are approximately a hundred and one different C ABI's and
>> calling conventions for 32-bit Windows, since MS never actually
>> defined one, so things are a bit of a mess there.  (DLL calling
>> conventions are clearer.)
>>
>> I believe the two most popular ways of running "Linux-like" software
>> and gcc on Windows are using WSL (which is more of a virtualisation
>> layer),
> 
> WSL (now often referred as WSL1) is not a virtualization layer.
> WSL2 is indeed a Linux running in virtual machine +
> integration features for convenience.
> 

I was thinking of current WSL, which would presumably be WSL2.  I have 
not used it myself, but I have a customer who does, and who simply calls 
it WSL.  But perhaps I should use "WSL2" to be clear.

> WSL1 is the worst possible place to run Linux programs that depend on
> long double having higher precision. That's because when WSL1 kernel
> starts a new process it sets precision of x87 co-processor to 52 bits,
> which is different from default settings on just about any other x86-64
> Linux. Of course, the process can change the settings, but for that the
> programmer would have to be aware that the problem exists. Which is
> rare.
> 
> WSL2 doesn't have this problem, but it is supported only on relatively
> new versions of Windows.
> 
> So, for older versions of Windows if one wants to run Linux binaries
> 'as is' and to get the same behavior of long doable as in original then
> one is advised  to run Linux in less-integrated VMs, like Virtual Box
> or MS's own HyperV.
> 

I just run them on Linux :-)

But while none of this affects me, it might affect customers or others 
that I deal with, so it is good to know.

>> and mingw-64 for the compiler target (with either gcc or
>> clang) and msys2 as an environment and source of *nix utilities and
>> libraries. mingw/msys is considered old and limited (32-bit only),
>> while Cygwin is considered slow and clunky by many.
>>
> 
> And cygwin console is quite inconvenient.
> 
>> At least, that is my understanding.
>>
>>
> 
>