Cygwin x86 on Windows 10 ARM64

Cygwin x86 on Windows 10 ARM64

[David Allsopp]

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

Everything's up-to-date and I also tried it with the 2018-06-29 cygwin1.dll
snapshot.

Very happy to test things and poke around, I'd just need some pointers, if
you'll excuse the pun.


David


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin x86 on Windows 10 ARM64

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

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.

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

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.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Cygwin x86 on Windows 10 ARM64

[Brian Inglis]

On 2018-07-10 07:04, 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?

C:\ > mklink /d /h C:\Windows\SysWOW64\drivers\etc C:\Windows\System32\drivers\etc
Note: args reversed from ln

> Try if C:\Windows\Sysnative\drivers\etc works.  That should be the
> easiest way to fix the issue in the script.

SysNative does not exist under x64 - could check arch dependent, or dir
dependent: check for hardcoded `cygpath -W`/SysNative/drivers/etc/ dir (unless
there is a standard SysNative folder id or env var I can't find), then fall back
to `cygpath -S`/drivers/etc/.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Cygwin x86 on Windows 10 ARM64

[David Allsopp]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3074 bytes --]

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

\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB

Re: Cygwin x86 on Windows 10 ARM64

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2974 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: Cygwin x86 on Windows 10 ARM64

[David Allsopp]

Corinna Vinschen wrote:
> 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.

Thanks - will do!

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

Indeed - I can't install the fast ring insider build on this machine (driver problem <sigh>) but I'm now trying the slow ring instead.

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

Seems reasonable!

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

CYGWIN_NT-10.0-WOW Envy 2.11.0(0.327/5/3)  i686 Cygwin


David

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Cygwin x86 on Windows 10 ARM64

[David Allsopp]

David Allsopp wrote:
> Corinna Vinschen wrote:

<snip>

> > This looks like a bug in the emulator.  You may want to contact
> > Microsoft.
> 
> Indeed - I can't install the fast ring insider build on this machine
> (driver problem <sigh>) but I'm now trying the slow ring instead.

And, FWIW, the same behaviour 10.0.17692.1004, so I guess treating 0 as meaning "x86 on arm64" is probably the way forward!


David


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin x86 on Windows 10 ARM64

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On Jul 12 13:33, David Allsopp wrote:
> David Allsopp wrote:
> > Corinna Vinschen wrote:
> 
> <snip>
> 
> > > This looks like a bug in the emulator.  You may want to contact
> > > Microsoft.
> > 
> > Indeed - I can't install the fast ring insider build on this machine
> > (driver problem <sigh>) but I'm now trying the slow ring instead.
> 
> And, FWIW, the same behaviour 10.0.17692.1004, so I guess treating 0 as meaning "x86 on arm64" is probably the way forward!

Latest snapshot on https://cygwin.com/snapshots/ has a matching patch.


HTH,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Cygwin x86 on Windows 10 ARM64

[Brian Inglis]

On 2018-07-10 03: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?
> 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.

Do C:\Windows\{System32,SysNative,Sys*}\drivers\etc exist under the emulator?
What does "cygpath -SU" show?

> The other is that all Cygwin binaries are emitting the "Could not compute
> FAST_CWD pointer" warning.

It is just a warning and everything should run normally: what would normally be
an ntdll entry point on x86 is probably a thunk or trampoline to
arm64(ISA)/aarch64(mode)/armv8(design) code.

> Everything's up-to-date and I also tried it with the 2018-06-29 cygwin1.dll
> snapshot.
> 
> Very happy to test things and poke around, I'd just need some pointers, if
> you'll excuse the pun.

Someone with deep knowledge of W10 will have to advise on that.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Cygwin x86 on Windows 10 ARM64

[David Allsopp]

Brian Inglis wrote:
> On 2018-07-10 03: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?
> > 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.
> 
> Do C:\Windows\{System32,SysNative,Sys*}\drivers\etc exist under the
> emulator?
> What does "cygpath -SU" show?

cygpath -SU gives /proc/cygdrive/c/Windows/SysWOW64

Checking within C:\Windows\SysWOW64\cmd.exe (i.e. x86 cmd):

C:\Windows\System32\drivers\etc exists and contains expected files
C:\Windows\Sysnative\drivers\etc exists and contains expected files (looks identical to System32, as you'd hope)
C:\Windows\SysArm32\drivers does not contain an etc directory (but wasn't referenced)
C:\Windows\SysWOW64\drivers didn't contain an etc directory (I created one to silence the error)

So perhaps on WOW64 it would be worth falling back to Sysnative if etc isn't found? Or even just using Sysnative by default in WOW64?

> > The other is that all Cygwin binaries are emitting the "Could not
> > compute FAST_CWD pointer" warning.
> 
> It is just a warning and everything should run normally: what would
> normally be an ntdll entry point on x86 is probably a thunk or trampoline
> to
> arm64(ISA)/aarch64(mode)/armv8(design) code.

Does it potentially make anything slower? (being slightly lazy - I could look at the code and see precisely what it's for).


David


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin x86 on Windows 10 ARM64

[Andrey Repin]

Greetings, David Allsopp!

> Brian Inglis wrote:
>> On 2018-07-10 03: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?
>> > 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.
>> 
>> Do C:\Windows\{System32,SysNative,Sys*}\drivers\etc exist under the
>> emulator?
>> What does "cygpath -SU" show?

> cygpath -SU gives /proc/cygdrive/c/Windows/SysWOW64

> Checking within C:\Windows\SysWOW64\cmd.exe (i.e. x86 cmd):

> C:\Windows\System32\drivers\etc exists and contains expected files
> C:\Windows\Sysnative\drivers\etc exists and contains expected files (looks identical to System32, as you'd hope)
> C:\Windows\SysArm32\drivers does not contain an etc directory (but wasn't referenced)
> C:\Windows\SysWOW64\drivers didn't contain an etc directory (I created one to silence the error)

> So perhaps on WOW64 it would be worth falling back to Sysnative if etc
> isn't found? Or even just using Sysnative by default in WOW64?

I'd suggest using Sysnative unconditionally, and fall back to System32 if
Sysnative not found.

A better approach would be to make Cygwin trickery aware and just address real
directories instead of fake ones.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365743.aspx


-- 
With best regards,
Andrey Repin
Wednesday, July 11, 2018 0:27:31

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin x86 on Windows 10 ARM64

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]

On Jul 11 00:36, Andrey Repin wrote:
> Greetings, David Allsopp!
> 
> > Brian Inglis wrote:
> >> On 2018-07-10 03: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?
> >> > 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.
> >> 
> >> Do C:\Windows\{System32,SysNative,Sys*}\drivers\etc exist under the
> >> emulator?
> >> What does "cygpath -SU" show?
> 
> > cygpath -SU gives /proc/cygdrive/c/Windows/SysWOW64
> 
> > Checking within C:\Windows\SysWOW64\cmd.exe (i.e. x86 cmd):
> 
> > C:\Windows\System32\drivers\etc exists and contains expected files
> > C:\Windows\Sysnative\drivers\etc exists and contains expected files (looks identical to System32, as you'd hope)
> > C:\Windows\SysArm32\drivers does not contain an etc directory (but wasn't referenced)
> > C:\Windows\SysWOW64\drivers didn't contain an etc directory (I created one to silence the error)
> 
> > So perhaps on WOW64 it would be worth falling back to Sysnative if etc
> > isn't found? Or even just using Sysnative by default in WOW64?
> 
> I'd suggest using Sysnative unconditionally, and fall back to System32 if
> Sysnative not found.


Did anybody notice my reply from 8 hours earlier?
https://cygwin.com/ml/cygwin/2018-07/msg00091.html


> A better approach would be to make Cygwin trickery aware and just address real
> directories instead of fake ones.
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365743.aspx

That would break existing scripts.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: Cygwin x86 on Windows 10 ARM64

[David Allsopp]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2386 bytes --]

Corinna Vinschen wrote:
> On Jul 11 00:36, Andrey Repin wrote:
> > Greetings, David Allsopp!
> >
> > > Brian Inglis wrote:
> > >> On 2018-07-10 03: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?
> > >> > 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.
> > >>
> > >> Do C:\Windows\{System32,SysNative,Sys*}\drivers\etc exist under the
> > >> emulator?
> > >> What does "cygpath -SU" show?
> >
> > > cygpath -SU gives /proc/cygdrive/c/Windows/SysWOW64
> >
> > > Checking within C:\Windows\SysWOW64\cmd.exe (i.e. x86 cmd):
> >
> > > C:\Windows\System32\drivers\etc exists and contains expected files
> > > C:\Windows\Sysnative\drivers\etc exists and contains expected files
> > > (looks identical to System32, as you'd hope)
> > > C:\Windows\SysArm32\drivers does not contain an etc directory (but
> > > wasn't referenced) C:\Windows\SysWOW64\drivers didn't contain an etc
> > > directory (I created one to silence the error)
> >
> > > So perhaps on WOW64 it would be worth falling back to Sysnative if
> > > etc isn't found? Or even just using Sysnative by default in WOW64?
> >
> > I'd suggest using Sysnative unconditionally, and fall back to System32
> > if Sysnative not found.
> 
> 
> Did anybody notice my reply from 8 hours earlier?
> https://cygwin.com/ml/cygwin/2018-07/msg00091.html

Yes! I answered Brian's first because it didn't involve downloading anything, then I tried the snapshot you'd kindly provided - but it doesn't work, for weird reasons, and I'm still looking into exactly why in order to give a helpful reply as to why!

Sorry for the lag...


David
\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ