Re: [groff] Loss of MSVC support

[Keith Marshall]

On 12/02/19 23:19, Eric S. Raymond wrote:
> Keith Marshall:
>>> There has been no work on that support since 2005, 12 years ago.
>>
>> So, it has been stable for 12 years (actually 14 years); that does
>> *not* mean that it is no longer relevant, yet you want to turn
>> around and destroy it?
> 
> No. By report, Microsoft's APIs change often enough that I assume any
> code not refreshed in 12 years will be *broken.*

I don't know whence you are getting this, but you do seem to be
seriously ill-informed.  While it is true that new APIs are added, from
time to time, and it may be true that, within the non-free MSVC runtime
ecosystem, some of the older APIs may be *described* as deprecated, (and
may even occasionally be withdrawn), this is definitively *not* true of
the MSVCRT.DLL, and Windows-API components of the underlying OS, (which
may be used by free compilers, *without* violating the GPL, whereas the
non-free runtime components specific to MSVC cannot).  In the latter
case, 20+ year old APIs remain stable *today*, and, unless there is
significant advantage to be gained from adoption of a newer alternative,
there is really no reason to change anything.

>>> Since then, MINGW and the DeLorie compiler have offered
>>> generally satisfactory support for programs in groff's class.
>>> Indeed, Microsoft itself has much improved its support for the
>>> POSIX API and now has a stdlib.h header.
>>
>> Huh?  What has that to do with *anything*?  MSVC has had a
>> stdlib.h header *forever* ... i.e. since MSVC version 1.0
>> originally appeared. It has, and never has had, anything to do with
>> POSIX/C99 compatibility;
> 
> I think the Open Group would disagree with you on this.
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdlib.h.html

That's an entirely specious argument!  The requirement that a POSIX
conforming implementation must provide stdlib.h is not commutative;
Microsoft have always provided stdlib.h, even with their MS-DOS C
compilers, (dating back to the mid-1980s, and thus pre-dating not only
MSVC, but even Windows itself); in no way does this imply that either
MS-DOS, or MS-Windows could, by any stretch of the imagination, be
classified as a POSIX conforming system.

> You seem to be saying that we *cannot* require C99/POSIX conformance
> from toolchains on target systems without critical breakage.

That's exactly what I'm saying.  POSIX requires fork(2); Windows doesn't
support it.  Where groff sets up a pipeline, using fork(2) and exec(3),
with I/O hook-up performed between, Windows *must* perform the I/O
hook-up in the parent, then call spawn(), (or the significantly uglier
CreateProcess()), to invoke the child, and then revert the effect of the
I/O hook-up in the parent.  There is no other way of getting around this
Windows limitation; that's the purpose of the bulk of groff's
Windows-specific code, and the spawn() API has remained substantially
unchanged, in over 20 years.

> How does the build recipe work under Winows? Does it run shell and m4?

How it works with MSVC, or with DJGPP, I don't know.  For MinGW, it uses
the conventional GNU build model, (in MinGW's MSYS environment).  The
issue isn't with the build recipe; it's with the absence of POSIX API
support within the runtime environment of the compiled code.  MinGW
cannot mitigate this; the code has to be written to accommodate it.

-- 
Keith.