* Re: [TUHS] Groff on Windows (for PDF output)?
2020-07-23 20:51 ` Grant Taylor via TUHS
@ 2020-07-23 22:35 ` John Cowan
2020-07-24 0:13 ` Clem Cole
1 sibling, 0 replies; 6+ messages in thread
From: John Cowan @ 2020-07-23 22:35 UTC (permalink / raw)
To: Grant Taylor; +Cc: TUHS main list
[-- Attachment #1: Type: text/plain, Size: 2716 bytes --]
On Thu, Jul 23, 2020 at 4:52 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:
> Do you have any idea how Windows Subsystem for Linux compares to Cygwin?
> For this use case and / or in general?
>
Very short version:
First, Windows is a layered OS. At the bottom is the NT Executive, a
fairly conventional kernel. Running on top of that is the Win32 subsystem
(note that this name is used for both 32-bit and 64-bit windows). Peers of
Win32 have existed in the past, notably an OS/2 subsystem and a
Posix-compatible third-party subsystem.
Cygwin is a shim DLL that provides a Posix environment to programs running
in the Win32 layer of Windows. It is fairly source-code compatible with
Linux. Cygwin programs and ordinary Windows programs can coexist freely.
In particular, they share the same filesystems, and Cygwin programs
understand both Posix and Windows pathnames (where C: is mapped to
/cygdrive/c). Most Cygwin APIs are implemented using Win32 APIs, but some
require NT Executive APIs.
WSL version 1 is a Linux kernel emulator running on the NT Executive. It
is binary-compatible with Linux (but not with 32-bit Linux programs) as a
result, and gets special services from the Executive, including lightweight
processes. (Win32 processes are very heavyweight, which makes long shell
scripts like ./configure quite slow on Cygwin.) There is an X server
called Cygwin/X; any other X server for Windows can also be used.
Interoperation allows WSL1 to mount Win32 file systems and exec() Win32
programs (the lightweight process is upgraded to a Win32 process). WSL1
and Win32 share the same TCP and UDP port space. Unfortunately, a WSL1
program that tries to invoke a Linux kernel operation not yet supported by
the emulator will crash. The Linux file system is stored in a dedicated
section of the Win32 file system; files stored there can be read by Win32
programs but not written. There is no X server, but once again Cygwin/X or
alternatives can be used on the Win32 side.
WSL version 2, which is very new, is an ultra-lightweight VM that can run a
Linux kernel. This means that all kernel services are automatically
provided. The filesystem is a virtual disk formatted as ext4, which gives
WSL2 much better local filesystem performance than WSL1. The same
interoperations exist as for WSL1, except that the VM has a different IP
address from the Win32 system, so ports are not shared. The filesystems
are fully shared through the 9P2000 (yes!) protocol, allowing Linux to
mount Win32 filesystems and vice versa. Unfortunately the 9P support is
not exposed to users.
This may indeed be the year of Linux on the (Windows) desktop.
(Comments and corrections always welcome.)
[-- Attachment #2: Type: text/html, Size: 3286 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TUHS] Groff on Windows (for PDF output)?
2020-07-23 20:51 ` Grant Taylor via TUHS
2020-07-23 22:35 ` John Cowan
@ 2020-07-24 0:13 ` Clem Cole
2020-07-25 14:45 ` John Cowan
1 sibling, 1 reply; 6+ messages in thread
From: Clem Cole @ 2020-07-24 0:13 UTC (permalink / raw)
To: Grant Taylor; +Cc: TUHS main list
[-- Attachment #1: Type: text/plain, Size: 7132 bytes --]
On Thu, Jul 23, 2020 at 4:52 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:
> On 7/23/20 12:33 PM, Doug McIlroy wrote:
> > I must admit, tough, that this approach will be pretty onerous if
> > you do not want Cygwin for any other reason.
>
> Do you have any idea how Windows Subsystem for Linux compares to Cygwin?
> For this use case and / or in general?
>
The short answer is that Cygwin can never work as well as WSL because it's
layered on top of Windows and has to map. So the API is inherently only as
good as what Windows presents to the user. Which is often good enough...
but it is incomplete and different workarounds are needed.
When I was as DEC I was involved with the whole story ... so let me pull
much of the rest of the answer from my Quora answer to is 'Windows POSIX
compliant'[1].
The long answer is this…. In the late 1990’s US Gov with the FIPS-151
standard, required all systems sold to the US Government be “POSIX”
compliant [details of much of this is spelled out in John Quarterman's
book UNIX,
POSIX, and Open Systems
<https://books.google.com/books?id=87dQAAAAMAAJ&q=FIPS%2B151&dq=FIPS%2B151&hl=en&sa=X&ved=0ahUKEwio56j-49XQAhVBKWMKHYhUAmIQ6AEIKzAB>
]. At one time after the publishing of FIPS-151, the US Air Force tender a
bid that DEC and Microsoft wanted to chase with NT/Alpha. Microsoft/DEC
(having only completed that *.1 interface with their POSIX subsystem), and did
win the tender. Unisys sued saying that *.1 only subsystem, was not the
spirit of the requirement. Microsoft’s defense was that they had built the
API and that they were enabling 3rd parties to do the userspace work since
their own user space was Windows and its Win32API. In the end,
Microsoft/DEC was allowed to proceed provided a 3rd party appeared to fill
that hole by some date (I’ve forgotten the details). In effect, they were
required to produce a fully functioning POSIX based NT system by said date.
To meet the requirement, Microsoft cut a deal with a small firm (Softway
Systems - our old friend from Univ of Toronto, Steve Walhi for other
old-time-Unix folks) to develop the same which was released as Softway’s
“Interix” product. Which in fact, did not suck
For real UNIX types like me, Steve and the team made Windows bear-able and
frankly has fewer 'strangeness' that later/other UNIX for windows efforts
because the Softway solution actually lives side-by-side with Windows as an
NT client, so it calls the NT uKernel directly. *i.e.* it does not use the
Window API under the covers (Cygin, UWIN, *et al* - sit on top of the
Win32S so are ultimately limited to what features and conventions Windows
provide under the covers).
The Softway folks actually had sources to NT from Microsoft and added some
missing APIs (for instance NT’s file system has always support hard and
softlinks, but Win32S does not have calls to create them). The fixes/changes
were then taken back and released in Windows updates as needed. The original
commands were primarily taken from FreeBSD and Gnu as needed, and all of
the “open source” requirements were met - in that anything that Softway had
taken with a GPL was made available (which was only userspace code, such as
gcc and its libraries).
Because it is a microkernel, the POSIX subsystem and NT share the native
file system. A problem is that UNIX (Posix) file permissions are not as
refined as NT's, so there are things that the subsystem can not do, because
it does not have a mechanism to do it. But it means, that as a user, you
could compile run POSIX code as expected without any real mapping. So primary
issue when “porting” code from a “real UNIX” such as Solaris, Tru64, or a
Linux distro; tended to be that the NT file system supports a different
security model than POSIX requires and POSIX APIs do not have ways of
supporting some of those features.
Eventually, Microsoft bought Steve and the Softway folks and brought the
Interix product in-house, released it as SFU - Services for Unix, and later
renamed it SUA - Subsystem for UNIX-based Applications. However, in Windows
8, SUA was depreciated and then later removed it from Windows 8.1.
Starting with Windows 10, Microsoft (re)released it as WSL - Windows
Subsystem for Linux, which resurrected the subsystem, but working with
Canonical, make the API a Linux API and the commands based on Linux (Debian)
versions instead of FreeBSD. The Linux kernel emulation was “clean room”
and based on the earlier code, so none of that is tainted by the GPL. But
anything in userspace that uses GPL is again available for download per the
GPL licenses. You can recompile locally, although I believe that intentions
were that userspace binaries from an Ubuntu 14.04 image are supposed to be
able to run as-is under the subsystem. Changes in userspace code were really
to make the command interact in a manner that is easier to utilize the base
NTFS and live reasonably on the same uKernel side-by-side with a Win10
subsystem.
Also remember POSIX never defined X-windows, so that was always
interesting. When Interix was released there were a number of X-Windows
systems for NT. Those days, Hummingbird was the most popular. However,
Softway (and later Microsoft) was always careful to ensure that it did not
matter which X subsystem you ran. Today the Cygwin/X is what most people
use if you need to use X under Windows (NT). Since WSL runs side-by-side,
it all 'just works' (and I say, don't suck).
So coming back to it, WSL tends to have fewer 'rough edges' than Cygwin
because it really is UNIX (Linux) under the covers, not trying to force
Windows into doing its will by trying to map UNIX (Linux) into Win32S (or
Win64). But, in all cases, UWIN, Cygwin or WSL, the file namespace is the
same and shared (*i.e.* one disk file system), although windows are needed
to support some (permission) style operations that POSIX never defined. My
experience with the subsystem, if you plan to run it, then I would also
recommend not using some of the NT file system (well Culter/VMS-ism to be
more specific) additions, as UNIX (Linux) programs can get confused. [But
a few of us ex-DEC Unix types have fought with Culter about those
differences since the 1980s, so that's nothing new].
Anyway, my own experience is IF you have to use Windows 10, WSL pretty much
'just works.' We do a lot a Linux and Windows mixed work at Intel, and
many (??most??) people turn it on and stopped using MKS/UWIN/Cygwin if they
had to deal with Windows 10.
That said, my personal solution for a number of years is to try to not use
Windows at all, and run Mac OS, which is a different set of issues but at
least for a old-time UNIX guy, less troublesome.
Clem
[1] https://www.quora.com/Is-Windows-POSIX-compliant/answer/Clem-Cole which
might be worth reading the comments. Basically the guys at Microsoft have
pointed out I tell the story as it happened, which is not surprising since
I was a player on the DEC side when it all went down.
[-- Attachment #2: Type: text/html, Size: 14597 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread