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.
