The Unix Heritage Society mailing list
 help / color / Atom feed
* Re: [TUHS] Groff on Windows (for PDF output)?
@ 2020-07-23 18:33 Doug McIlroy
  2020-07-23 20:51 ` Grant Taylor via TUHS
  0 siblings, 1 reply; 6+ messages in thread
From: Doug McIlroy @ 2020-07-23 18:33 UTC (permalink / raw)
  To: tuhs

Echoing other answers, I regularly use groff in Cygwin.
If you're into Unix/Linux, Cygwin is a great tool with a
remarkably clean installation process. I use default
PostScript output by choice, because I can tinker with
PostScript but not with PDF. ps2pdf (available from
Cygwin) has always worked when I need PDF.

I must admit, tough, that this approach will be pretty
onerous if you do not want Cygwin for any other
reason. And I should add that PoscScript requires a
special viewer; I use gsview.

Doug

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [TUHS] Groff on Windows (for PDF output)?
  2020-07-23 18:33 [TUHS] Groff on Windows (for PDF output)? Doug McIlroy
@ 2020-07-23 20:51 ` Grant Taylor via TUHS
  2020-07-23 22:35   ` John Cowan
  2020-07-24  0:13   ` Clem Cole
  0 siblings, 2 replies; 6+ messages in thread
From: Grant Taylor via TUHS @ 2020-07-23 20:51 UTC (permalink / raw)
  To: tuhs


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

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?



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 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
  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

* Re: [TUHS] Groff on Windows (for PDF output)?
  2020-07-24  0:13   ` Clem Cole
@ 2020-07-25 14:45     ` John Cowan
  2020-07-25 14:55       ` Clem Cole
  0 siblings, 1 reply; 6+ messages in thread
From: John Cowan @ 2020-07-25 14:45 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Grant Taylor


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

On Thu, Jul 23, 2020 at 8:15 PM Clem Cole <clemc@ccc.com> wrote:


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

Historically that was true, but no longer.  Since 2000, more and more
direct calls to the NT Executive have appeared in the cygwin1.dll source:
there are about a thousand of them now, invoking about 90 different
Executive APIs.  Such features as flock(), mmap(), and reading from block
devices cannot be done in Win32 and use the Executive directly.
Unfortunately, it also makes Cygwin a bit more brittle to Microsoft
changes, as the NT Executive API is permanently unstable.  So far, Corinna
and friends are keeping up nicely.

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

Thanks for the history!

BTW, when you say "Win32S" you mean "Win32".  Win32S  was a long-obsolete
package to let 32-bit Windows apps run on 16-bit Windows if they didn't try
to do too much.

(Which reminds me that in my list of subsystems running on the NT
Executive, I forgot to mention WoW64, which provides a 32-bit WIn32
environment on the 64-bit Windows kernel, and is used to keep 32-bit
Windows apps running.)


> Anyway, my own experience is IF you have to use Windows 10, WSL pretty
> much 'just works.'
>

I agree.  However, I have spent much of my career on corporate Windows
boxen, which are often locked down to prevent you from installing
things, including WSL.  Because Cygwin bypasses the regular Windows install
system, it flies under the radar.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
You escaped them by the will-death and the Way of the Black Wheel.
I could not.  --Great-Souled Sam

[-- Attachment #2: Type: text/html, Size: 3203 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [TUHS] Groff on Windows (for PDF output)?
  2020-07-25 14:45     ` John Cowan
@ 2020-07-25 14:55       ` Clem Cole
  0 siblings, 0 replies; 6+ messages in thread
From: Clem Cole @ 2020-07-25 14:55 UTC (permalink / raw)
  To: John Cowan; +Cc: TUHS main list, Grant Taylor


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

On Sat, Jul 25, 2020 at 10:45 AM John Cowan <cowan@ccil.org> wrote:

>
>
> BTW, when you say "Win32S" you mean "Win32".  Win32S  was a long-obsolete
> package to let 32-bit Windows apps run on 16-bit Windows if they didn't try
> to do too much.
>

Can't speak for today.  At one point the S stood for Standard/Stable.  That
used to be a Culter-ism IIRC -- it was what was guaranteed to ISVs to be
there.  If you used anything else, Microsoft could (and did) pull the rug
out from under you.

They added a bunch of new APIs and new stuff from 64 bits to et al.   When
Interix was done, all that they could guarantee was Cutler's interface.

I agree.  However, I have spent much of my career on corporate Windows
> boxen, which are often locked down to prevent you from installing
> things, including WSL.  Because Cygwin bypasses the regular Windows install
> system, it flies under the radar.
>
WSL should not have that problem these days for the exact reasons you
mentioned, as you were correct that SFU/SUA did tend to be something that
IT depts did not understand like (it was free but it was separate
install).  But WSL is just one of the standard options in Windows10 ever
system can have it.  You just have to enable it in the control panel and it
will automatically do everything in a manner that should not be an issue to
IT folks.   Although it does require >>local<< admin privileges on the
machines to enable.; IIRC.

[-- Attachment #2: Type: text/html, Size: 2725 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, back to index

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-23 18:33 [TUHS] Groff on Windows (for PDF output)? Doug McIlroy
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
2020-07-25 14:55       ` Clem Cole

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git