This is the mail archive of the
cygwin
mailing list for the Cygwin project.
RE: Cygwin x86 on Windows 10 ARM64
- From: David Allsopp <david at allsopps dot net>
- To: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Thu, 12 Jul 2018 07:46:47 +0000
- Subject: RE: Cygwin x86 on Windows 10 ARM64
- References: <20180710130410.GL27673@calimero.vinschen.de>
Corinna Vinschen wrote:
> On Jul 10 10:51, David Allsopp wrote:
> > I've been trying out the x86 emulation in Microsoft's ARM64 version of
> > Windows 10 1803.
> >
> > I had two issues with Cygwin x86. The first, which is simple, is that
> > Windows doesn't by default create C:\Windows\SysWOW64\drivers\etc
> > which causes /etc/postinstall/base-files-mketc.sh to exit with an
> > error all the time. I wonder if there's a possible workaround to make
> that less intrusive?
>
> Try if C:\Windows\Sysnative\drivers\etc works. That should be the easiest
> way to fix the issue in the script.
It does indeed. Certainly seems like a good fallback (if not possible default, although I'm sure someone out there takes advantage of a different hosts file between 32-bit and 64-bit!!). I'm happy to tweak the script if you can remind me where its repo is?
> > The error message implies that it may have computed the wrong
> > directory, which it hasn't - it's just that the directory doesn't exist.
> >
> > The other is that all Cygwin binaries are emitting the "Could not
> > compute FAST_CWD pointer" warning.
>
> Nothing we can do about, unless somebody dives into assembler code on such
> a system. If the code switches to ARM64 early, this could be tricky.
The machine I'm using is only for testing on this platform - I can grant access to it if it'd be worth looking into?
> As a workaround I pushed a patch to check for running in WOW64 under
> ARM64. The warning is skipped then. The already existing fallback code
> should work most of the time. Just give the latest developer snapshot
> from https://cygwin.com/snapshots/ a try.
OK, so this is very weird - both GetNativeSystemInfo and GetSystemInfo are returning 0 in both wProcessorArchitecture and wReserved (and FWIW 586 in dwProcessorType). This is with GCC 6.4.0 (i686-w64-mingw32-gcc) and with Microsoft's own **x86** Cl (19.15.26629.1 in VS 2017.8 Preview 4). My test program is simply:
#define WINVER 0x0A00
#define _WIN32_WINNT 0x0A00
#include <windows.h>
#include <stdio.h>
int main(void) {
SYSTEM_INFO si;
GetNativeSystemInfo(&si);
printf("si.wProcessorArchitecture = %d\n", si.wProcessorArchitecture);
printf("si.wReserved = %d\n", si.wReserved);
printf("si.dwProcessorType = %d\n", si.dwProcessorType);
GetSystemInfo(&si);
printf("si.wProcessorArchitecture = %d\n", si.wProcessorArchitecture);
printf("si.wReserved = %d\n", si.wReserved);
printf("si.dwProcessorType = %d\n", si.dwProcessorType);
}
However, when built with Microsoft's ARM64 CL, I get wProcessorArchitecture == 12, as expected. I'm currently on Windows 10.0.17134.137 (1803). I've just switched the machine to the Fast Insider Ring to see if it's the same.
The PROCESSOR_ARCHITEW6432 variable is at least ARM64!
David