On Tue, 06 Jun 2023 at 21:45:31 +0200, Alexis Murzeau wrote:
> On 06/06/2023 12:45, Simon McVittie wrote:
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> > modern x86_64 systems
> > 2a. legacy native Linux i386 binaries
> > 2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> > complete i386 Linux library stack)
> >
>
> Windows already uses 64 bits time_t on i386 since Visual Studio 2005,
> unless _USE_32BIT_TIME_T is defined ([msvcrt-time]), and even if it is
> defined, Wine implementation of 32 bits time() will not use Linux' time_t.
>
> So I'm not sure Windows i386 binaries will be affected by a Linux-side change
> of
> time_t, unless you think about something else.
If the point you're making is this:
We have source code for the whole Wine stack, and the size of Linux time_t
used to compile/implement that stack does not affect the time_t used for
the Windows-side ABI presented to the binaries Wine runs, therefore we
could recompile all of i386 (including Wine) with a 64-bit time_t and
still be able to run 32-bit Windows binaries
then, yes, that's all true, if we assume the whole of the stack
"underneath" Wine copes gracefully with 64-bit time_t on an otherwise
ILP32 ABI (I think implementation experience from x32 might indicate
otherwise, but that'll need to be solved for a 64-bit-time_t transition
in other ILP32 architectures like armhf anyway).
However, I would argue that providing i386 as a multiarch foreign
architecture that can run 32-bit Windows binaries via Wine (2b), but can
no longer safely run 32-bit Linux binaries (2a) because they're relatively
likely to crash, is less useful than being able to have both 2a and 2b.
Do we expect users of old 32-bit Linux binary-only software to always
obtain and run the corresponding Windows software instead, via Wine,
assuming it's available? I know people like to complain about Linux not
having stable ABIs and/or troll us with comparisons to things that Windows
does better, but it would seem like a shame if the solution for (for
example) players of TF2 and Portal is "stop running the Linux version,
start running the Windows version via Wine/Proton".
> This means that Wine will probably require 32 bits Linux libraries for
> probably a long time and not only for legacy Windows binaries.
I was assuming that 32-bit Windows binaries can be considered to be
inherently legacy software at this point, even if people are still
releasing them today :-)
smcv
