Re: [TUHS] Groff on Windows (for PDF output)?

[Clem Cole <clemc@ccc.com>]

[-- 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 --]