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