Cygwin x86 on Windows 10 ARM64

[Corinna Vinschen]

On Jul 12 07:46, David Allsopp wrote:
> 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?

https://sourceware.org/cygwin-apps/ has a list of Cygwin-specific
projects hosted on cygwin.com.  The base-files project is maintained
by Achim Gratz.  Please send patches to the cygwin-apps mailing list.

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

This looks like a bug in the emulator.  You may want to contact
Microsoft.

Nevertheless, we can use the current buggy reply to our advantage:
We know we're running in an emulator.  The value of wProcessorArchitecture
returned by GetNativeSystemInfo should never be 0.  6, 9, 12 are ok,
but 0???

So, if the GetNativeSystemInfo returns 0 we can still skip the
warning.  For completeness, I'd like to see the output of `uname -a'
in Cygwin, though.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20180712/94ebd26d/attachment.sig>