Added checks for Windows Subsystem for Linux on Windows 10 #33
Conversation
|
I've mulled on this one a bit...it's tricky because it's like is OS the
runtime or actual OS...maybe if I add a "underLying" class or what not...
…On Fri, Aug 3, 2018 at 9:45 AM Whitey ***@***.***> wrote:
The new Windows Subsystem for Linux allows guest Linux OS's to seamlessly
masquerade as an actual Linux host. However, these guests have the ability
to run both Windows and Linux binaries - necessitating a need to determine
if the underlying OS is actually Windows-based.
This code has been tested in MinGW32, CygWin, macOS, Ubuntu, Ubuntu on
WSL, Kali on WSL, and Windows 10.
------------------------------
You can view, comment on, or merge this pull request online at:
#33
Commit Summary
- added new underlying check
- Merge remote-tracking branch 'upstream/master'
File Changes
- *M* lib/os.rb <https://github.com/rdp/os/pull/33/files#diff-0> (5)
Patch Links:
- https://github.com/rdp/os/pull/33.patch
- https://github.com/rdp/os/pull/33.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#33>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAw0JWMlvy5V_EgmFzHNWeTfwG6wKFMks5uNHAlgaJpZM4VuN_h>
.
|
|
Yeah this is an odd one because of how WSL works. Normally, Cygwin executables either have hooks for the Cygwin DLL or they're compiled from source under the Cygwn environment. This means that there is an environment limitation that would be helpful for Ruby to be aware of. WSL, however, is like a seamless super-set of both native Linux and Windows NT executable types. Normally, I would have left the existing behavior as-is since it wasn't really wrong to determine that the environment was Linux. Unfortunately, I'm using these changes to identify a special edge case for browser automation. These changes allow me to use a sane implementation of Ruby while enabling the ability to detect the existence of Microsoft web browser resources. |
|
maybe a new method hmm
…On Mon, Oct 15, 2018 at 7:30 AM Whitey ***@***.***> wrote:
Yeah this is an odd one because of how WSL works. Normally, Cygwin
executables either have hooks for the Cygwin DLL or they're compiled from
source under the Cygwn environment. This means that there is an environment
limitation that would be helpful for Ruby to be aware of. WSL, however, is
like a seamless super-set of both native Linux and Windows NT executable
types.
Normally, I would have left the existing behavior as-is since it wasn't
*really* wrong to determine that the environment was Linux.
Unfortunately, I'm using these changes to identify a special edge case for
browser automation. These changes allow me to use a sane implementation of
Ruby while enabling the ability to detect the existence of Microsoft web
browser resources.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#33 (comment)>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AAAw0DlmPcfVn1ymWtcqGj-mKN0Ar5SRks5ulI4OgaJpZM4VuN_h>
.
|
|
Maybe a method that detects the type of binary formats that can be executed in the current environment? |
|
I like that...
On Wednesday, October 17, 2018, Whitey ***@***.***> wrote:
Maybe a method that detects the type of binary formats that can be
executed in the current environment?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.<
|
|
I've been thinking about this for a while and have since looked to the official documentation to see how these types of environments determine whether Windows PE executables can be run. According to the Interoperability Documentation, the key determining factor is provided by the Would it be acceptable to modify this submission to key off of this WSL interop process? My intent with this change would be to determine whether Windows executable resources would be available within an environment that appeared to be Linux-based. |
|
I like your idea of a new method "windows exe's can run" or what not...wait
should that include wine? maybe just cygwin and wsl for now? :)
…On Tue, Mar 19, 2019 at 3:44 PM Whitey ***@***.***> wrote:
I've been thinking about this for a while and have since looked to the
official documentation to see how these types of environments determine
whether Windows PE executables can be run. According to the Interoperability
Documentation <https://docs.microsoft.com/en-us/windows/wsl/interop>, the
key determining factor is provided by the
/proc/sys/fs/binfmt_misc/WSLInterop file existing and being set to
enabled. In fact, setting this to a "disabled" state will prevent any
Windows PE code from running in the subsystem at all.
Would it be acceptable to modify this submission to key off of this WSL
interop process?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#33 (comment)>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AAAw0JWt71FMTScd4gDglq2QB_ye-rErks5vYVojgaJpZM4VuN_h>
.
|
I think Wine could eventually be included, I would just have to find a reliable way to determine that it is installed. WSL is a bit of a special case, though. What differentiates WSL from Wine is that there is no API call translation going on since the host offers native Windows resources. It's also distinct in that the presence of the WSL service implies that the user has at least a minimum installation of Windows binaries at their disposal (for instance, users can run tools such as regedt32.exe, net.exe, ipconfig.exe, etc...). The Linux environment under WSL blends so extremely well into Windows that users may as well settle for the fact that the OS is, in fact, a bare metal Linux machine. In this case, I think treating WSL like an OS feature set akin to 64-bit capability rather than an 'underlying' OS is a better philosophical approach than my original implementation. In my personal use case, this is extremely important because I use a platform-agnostic Ruby application to run browser automation on Linux, macOS, and Windows hosts. By having my Windows hosts running WSL, it's much easier to port over proper behavior from my existing Linux-specific methods. This allows me to behave and log activity as though it's I'm still in a Linux context, but launch Windows-only browsers such as Internet Explorer and Edge for testing. Definitely makes my implementation easier to maintain. |
|
maybe a new method is_wsl? :)
…On Thu, Mar 21, 2019 at 8:49 AM Whitey ***@***.***> wrote:
I like your idea of a new method "windows exe's can run" or what
not...wait should that include wine? maybe just cygwin and wsl for now? :)
… <#m_-7594663160987626906_>
On Tue, Mar 19, 2019 at 3:44 PM Whitey ***@***.***> wrote: I've been
thinking about this for a while and have since looked to the official
documentation to see how these types of environments determine whether
Windows PE executables can be run. According to the Interoperability
Documentation https://docs.microsoft.com/en-us/windows/wsl/interop, the
key determining factor is provided by the
/proc/sys/fs/binfmt_misc/WSLInterop file existing and being set to enabled.
In fact, setting this to a "disabled" state will prevent any Windows PE
code from running in the subsystem at all. Would it be acceptable to modify
this submission to key off of this WSL interop process? — You are receiving
this because you commented. Reply to this email directly, view it on GitHub
<#33 (comment) <#33 (comment)>>,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAw0JWt71FMTScd4gDglq2QB_ye-rErks5vYVojgaJpZM4VuN_h
.
I think Wine could eventually be included, I would just have to find a
reliable way to determine that it is installed.
WSL is a bit of a special case, though. What differentiates WSL from Wine
is that there is no API call translation going on since the host offers
native Windows resources. It's also distinct in that the presence of the
WSL service implies that the user has at least a minimum installation of
Windows binaries at their disposal (for instance, users can run tools such
as regedt32.exe, net.exe, ipconfig.exe, etc...). The Linux environment
under WSL blends so extremely well into Windows that users may as well
settle for the fact that the OS *is*, in fact, a bare metal Linux
machine. In this case, I think treating WSL like an OS feature set akin to
64-bit capability rather than an 'underlying' OS is a better philosophical
approach than my original implementation.
In my personal use case, this is extremely important because I use a
platform-agnostic Ruby application to run browser automation on Linux,
macOS, and Windows hosts. By having my Windows hosts running WSL, it's much
easier to port over proper behavior from my existing Linux-specific
methods. This allows me to behave and log activity as though it's I'm still
in a Linux context, but launch Windows-only browsers such as Internet
Explorer and Edge for testing. Definitely makes my implementation easier to
maintain.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#33 (comment)>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AAAw0LP5JEAB5sFPLsy6vVPPRZdXByWAks5vY5v8gaJpZM4VuN_h>
.
|
The new Windows Subsystem for Linux allows guest Linux OS's to seamlessly masquerade as an actual Linux host. However, these guests have the ability to run both Windows and Linux binaries - necessitating a need to determine if the underlying OS is actually Windows-based.
This code has been tested in MinGW32, CygWin, macOS, Ubuntu, Ubuntu on WSL, Kali on WSL, and Windows 10.