This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Cygwin x86 on Windows 10 ARM64


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]