Re: is Vax addressing sane today

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.
>
>