On Fri, 9 Feb 2024 15:49:45 +0000, bart wrote:

> Some people here seem to think that POSIX is an essential part of C, yet
> windows.c is not considered part of C on Windows.

Precisely. C was born on Unix. “Unix®” as such may be dead, but its
successor, POSIX, can be seen as basically the greatest run-time library
for C.

If Windows NT had not been created by a Unix hater, you would be having
much less trouble with it.

On Fri, 9 Feb 2024 20:55:19 +0000, bart wrote:

> That looks quite chummy to me, and even nepotic.

It’s your choice to be on the outside, looking in.

Come ... join us ...

bart <bc@freeuk.com> writes:
> On 09/02/2024 18:25, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
[...]
>>> Some people here seem to think that POSIX is an essential part of C,
>> I don't recall anyone other than you thinking that.
>
> It's mentioned a LOT. Half the open source programs I try seem to use
> calls like 'open' instead of 'fopen', suggesting that the author
> seemed to think such a function is standard C, or that can be used as
> though it was standard.

Rather, I'd say it suggests that the author doesn't care about
portability to non-POSIX systems, which is perfectly sensible if the
program depends on POSIX-specific features anyway. Similarly, plenty of
C and C++ code depends on Windows features.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 2024-02-09, bart <bc@freeuk.com> wrote:
>> MSVCRT.DLL is not documented for public use; when you link to it,
>> you're sticking a fork into the proverbial toaster. UCRT is different.
>>
>
> What exactly to you mean by UCRT; ucrtbase.dll?
>
> That's missing a few useful things, like '_getmainargs' (used to get
> argn, argv for main()), and obscure functions like 'printf'.

I believe printf is in there.

_getmainargs isn't; that's in a VC run time library.

> Meanwhile, if I look at programs such as gcc.exe, as.exe, ld.exe, not
> only do THEY import msvcrt.dll, but the EXEs produced by gcc.exe do so too.

Umm, no; you must be talking specifically about the MinGW ones.

> So they didn't get the memo.

They got the memo. The issue is that even though MSVCRT.DLL is
undocumented, it constitutes a "system library". This is important.

The GNU Public license prohibits programs from being linked to
proprietary code --- but it has an exception for system libraries
(libraries that are part of the target platform where the program runs).

Using MSVCRT.DLL is like sticking a fork in the toaster, but all those
programs being linked to MSVCRT.DLL means the GPL isn't violated.

Compilers under Cygwin don't link to MSVCRT.DLL --- including the ones
in the Cygwin MingW package. (Yes, Cygwin has a package of MinGW
compilers. If you have Cygwin, you just install that, and then you can
build MinGW programs. The built programs probably still link to
MSVCRT.DLL as far as I know. Cygwin itself uses this MinGW compiler
package for compiling some of its components, like the setup.exe program
and I think the cygwin1.dll also.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-02-09, bart <bc@freeuk.com> wrote:
> It's mentioned a LOT. Half the open source programs I try seem to use
> calls like 'open' instead of 'fopen', suggesting that the author seemed
> to think such a function is standard C, or that can be used as though it
> was standard.

Open source programs tend to use POSIX functions because POSIX is
associated with open source.

The most successful open source operating systems we have are all
POSIX-based. Open source programs target open source platforms.
It's a no-brainer.

If you need functionality beyond what is in ISO C, POSIX is more
portable than the alternatives.

For instance, suppose we would like to write a cross-platform programs
that works with serial ports. It has to control baud rate, framing, and
whether hardware handshaking is enable and all that.

If we write that using the POSIX API in <termios.h>, it can easily
be made to run on Linux, Windows, Mac, BSD, ...

If we use the Win32 API for serial control, it will run on Windows.
Maybe on Linux using Wine, and ReactOS, ...

In the TXR project, I use <termios.h> to put the TTY in raw mode for the
editing features in the REPL, together with ANSI escape sequences.
This works fine on Windows: there is a termios implementation in Cygwin,
as well as a translation layer that converts ANSI escapes to
Win32 Console API calls. I can ship this stand-alone without Cygwin and
it runs fine in a cmd.exe Window.

I'd be silly not to use POSIX, because then I would have to write
that separately for Windows.

Among other things I can do in POSIX (including on Windows) is use poll
for all file descriptors, including sockets.

I can open a FILE * stream on a socket using fdopen(fd, "...mode...").

POSIX is the most widely implemented operating system interface
standard.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 09/02/2024 21:56, Kaz Kylheku wrote:
> On 2024-02-09, bart <bc@freeuk.com> wrote:
>>> MSVCRT.DLL is not documented for public use; when you link to it,
>>> you're sticking a fork into the proverbial toaster. UCRT is different.
>>>
>>
>> What exactly to you mean by UCRT; ucrtbase.dll?
>>
>> That's missing a few useful things, like '_getmainargs' (used to get
>> argn, argv for main()), and obscure functions like 'printf'.
>
> I believe printf is in there.

Not under my ucrtbase.dll if that's the right file. If it was there, it
would go somewhere in here:

2332 00031F90 204688 Fun pow
2333 00033630 210480 Fun powf
2334 00058740 362304 Fun putc
2335 00080BE0 527328 Fun putchar
2336 00059660 366176 Fun puts

I suspect this is used by MS programs which may have their own wrappers
around 'printf'.

> _getmainargs isn't; that's in a VC run time library.
>
>> Meanwhile, if I look at programs such as gcc.exe, as.exe, ld.exe, not
>> only do THEY import msvcrt.dll, but the EXEs produced by gcc.exe do so too.
>
> Umm, no; you must be talking specifically about the MinGW ones.

I'm talking about lots of binaries, for example:

raylib.dll
opengl.dll
sdl2.dll
sqlite3_32.dll
s7.exe
tcc.exe
nim.exe
nasm.exe

>> So they didn't get the memo.
>
> They got the memo. The issue is that even though MSVCRT.DLL is
> undocumented, it constitutes a "system library". This is important.

If they got rid of it, half the programs that run under Windows would
stop working.

> The GNU Public license prohibits programs from being linked to
> proprietary code --- but it has an exception for system libraries
> (libraries that are part of the target platform where the program runs).
>
> Using MSVCRT.DLL is like sticking a fork in the toaster, but all those
> programs being linked to MSVCRT.DLL means the GPL isn't violated.
>
> Compilers under Cygwin don't link to MSVCRT.DLL --- including the ones
> in the Cygwin MingW package. (Yes, Cygwin has a package of MinGW
> compilers. If you have Cygwin, you just install that, and then you can
> build MinGW programs. The built programs probably still link to
> MSVCRT.DLL as far as I know. Cygwin itself uses this MinGW compiler
> package for compiling some of its components, like the setup.exe program
> and I think the cygwin1.dll also.)
>

I'm no idea what the point of CYGWIN is. Never have done either. What
does it bring to the table? Presumably to make some programs that
originate on Linux feel more at home, instead of making the effort to
make them more portable.

On 09/02/2024 21:56, Kaz Kylheku wrote:
> On 2024-02-09, bart <bc@freeuk.com> wrote:
>>> MSVCRT.DLL is not documented for public use; when you link to it,
>>> you're sticking a fork into the proverbial toaster. UCRT is different.
>>>
>>
>> What exactly to you mean by UCRT; ucrtbase.dll?
>>
>> That's missing a few useful things, like '_getmainargs' (used to get
>> argn, argv for main()), and obscure functions like 'printf'.
>
> I believe printf is in there.

Not under my ucrtbase.dll if that's the right file. If it was there, it
would go somewhere in here:

2332 00031F90 204688 Fun pow
2333 00033630 210480 Fun powf
2334 00058740 362304 Fun putc
2335 00080BE0 527328 Fun putchar
2336 00059660 366176 Fun puts

I suspect this is used by MS programs which may have their own wrappers
around 'printf'.

> _getmainargs isn't; that's in a VC run time library.
>
>> Meanwhile, if I look at programs such as gcc.exe, as.exe, ld.exe, not
>> only do THEY import msvcrt.dll, but the EXEs produced by gcc.exe do so too.
>
> Umm, no; you must be talking specifically about the MinGW ones.

I'm talking about lots of binaries, for example:

raylib.dll
opengl.dll
sdl2.dll
sqlite3_32.dll
s7.exe
tcc.exe
nim.exe
nasm.exe

>> So they didn't get the memo.
>
> They got the memo. The issue is that even though MSVCRT.DLL is
> undocumented, it constitutes a "system library". This is important.

If they got rid of it, half the programs that run under Windows would
stop working.

> The GNU Public license prohibits programs from being linked to
> proprietary code --- but it has an exception for system libraries
> (libraries that are part of the target platform where the program runs).
>
> Using MSVCRT.DLL is like sticking a fork in the toaster, but all those
> programs being linked to MSVCRT.DLL means the GPL isn't violated.
>
> Compilers under Cygwin don't link to MSVCRT.DLL --- including the ones
> in the Cygwin MingW package. (Yes, Cygwin has a package of MinGW
> compilers. If you have Cygwin, you just install that, and then you can
> build MinGW programs. The built programs probably still link to
> MSVCRT.DLL as far as I know. Cygwin itself uses this MinGW compiler
> package for compiling some of its components, like the setup.exe program
> and I think the cygwin1.dll also.)
>

I'm no idea what the point of CYGWIN is. Never have done either. What
does it bring to the table? Presumably to make some programs that
originate on Linux feel more at home, instead of making the effort to
make them more portable.

On 2024-02-09, bart <bc@freeuk.com> wrote:
> On 09/02/2024 21:56, Kaz Kylheku wrote:
>> On 2024-02-09, bart <bc@freeuk.com> wrote:
>>>> MSVCRT.DLL is not documented for public use; when you link to it,
>>>> you're sticking a fork into the proverbial toaster. UCRT is different.
>>>>
>>>
>>> What exactly to you mean by UCRT; ucrtbase.dll?
>>>
>>> That's missing a few useful things, like '_getmainargs' (used to get
>>> argn, argv for main()), and obscure functions like 'printf'.
>>
>> I believe printf is in there.
>
> Not under my ucrtbase.dll if that's the right file. If it was there, it
> would go somewhere in here:
>
> 2332 00031F90 204688 Fun pow
> 2333 00033630 210480 Fun powf
> 2334 00058740 362304 Fun putc
> 2335 00080BE0 527328 Fun putchar
> 2336 00059660 366176 Fun puts

Hmm. Lots of hits for identifiers containing printf:

$ strings ucrtbase.dll | grep printf
__conio_common_vcprintf
__conio_common_vcprintf_p
__conio_common_vcprintf_s
__conio_common_vcwprintf
[ SNIP ]
__stdio_common_vfprintf
__stdio_common_vfprintf_p
[ SNIP ]
__stdio_common_vfprintf_s
__stdio_common_vfwprintf
__stdio_common_vfwprintf_p
[ SNIP ]
_get_printf_count_output
[ SNIP ]
_o___conio_common_vcprintf
[ SNIP]
_o___stdio_common_vfwprintf_p
[ SNIP]
_set_printf_count_output

> I suspect this is used by MS programs which may have their own wrappers
> around 'printf'.

This seems to be documented:

"In Visual Studio 2015 The printf and scanf family of functions were
declared as inline and moved to the <stdio.h> and <conio.h> headers."

https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=msvc-170

I'm guessing that these inline functions call one of those symbols
found above, like maybe __stdio_common_vfprintf?

>> only do THEY import msvcrt.dll, but the EXEs produced by gcc.exe do so too.
>>
>> Umm, no; you must be talking specifically about the MinGW ones.
>
> I'm talking about lots of binaries, for example:
>
> raylib.dll
> opengl.dll
> sdl2.dll
> sqlite3_32.dll
> s7.exe
> tcc.exe
> nim.exe
> nasm.exe
>
>>> So they didn't get the memo.
>>
>> They got the memo. The issue is that even though MSVCRT.DLL is
>> undocumented, it constitutes a "system library". This is important.
>
> If they got rid of it, half the programs that run under Windows would
> stop working.

I suspect, mainly just these fledgling ports of unix cruft to Windows.

Most of the Windows world wouldn't notice.

> I'm no idea what the point of CYGWIN is. Never have done either. What
> does it bring to the table? Presumably to make some programs that
> originate on Linux feel more at home, instead of making the effort to
> make them more portable.

The effort is significant. Many things have to be coded twice.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

bart <bc@freeuk.com> writes:
> On 09/02/2024 21:56, Kaz Kylheku wrote:
>> On 2024-02-09, bart <bc@freeuk.com> wrote:
[...]
>>> So they didn't get the memo.
>> They got the memo. The issue is that even though MSVCRT.DLL is
>> undocumented, it constitutes a "system library". This is important.
>
> If they got rid of it, half the programs that run under Windows would
> stop working.

Who suggested getting rid of it?

[...]

> I'm no idea what the point of CYGWIN is. Never have done either.

Are you asking?

> What
> does it bring to the table? Presumably to make some programs that
> originate on Linux feel more at home, instead of making the effort to
> make them more portable.

It provides an environment, running under Windows, that resembles a
typical Linux desktop environment. I use it every day myself, because
that's a valuable thing for me. If it's not valuable for you, that's
fine. (I also use WSL for some things.)

I use a lot of programs that happen to rely on a POSIX interface.
Cygwin lets those programs run under Windows. Modifying those programs
to work more directly under Windows would be a tremendous amount of work
that nobody is going to do.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 09/02/2024 23:12, Kaz Kylheku wrote:
> On 2024-02-09, bart <bc@freeuk.com> wrote:

>> I'm no idea what the point of CYGWIN is. Never have done either. What
>> does it bring to the table? Presumably to make some programs that
>> originate on Linux feel more at home, instead of making the effort to
>> make them more portable.
>
> The effort is significant. Many things have to be coded twice.
>

Well, you need to support both OSes.

My stuff uses one module in the language library which is OS-specific.

At one point I had three versions for three OS targets. It is
effectively a mini cross-platform wrapper around some OS functions.

So for example, to get the address of a function in a shared library
given an instance handle to the library, the Windows version is:

export func os_getdllprocaddr(int hinst, ichar name)ref void=
GetProcAddress(cast(hinst), name)
end

The Linux version is this:

export func os_getdllprocaddr(int hlib, ichar name)ref void=
dlsym(cast(int(hlib)), name)
end

(The third one was OS-neutral. Neither GetProcAddress or dlsym were
available, but to be able to run some programs, 20 or so addresses of
common functions in the C library were hardcoded in a table.)

It is then just a question of including the right OS-specific module.

If rendered to C source code, there would be one .c version for Linux,
and one for Windows, since I dislike using conditional blocks.

Or sometimes (using that third version) a single .c file worked for
both, but with limited functionality. It was for demos.

As I understand your view, you want the Linux program to just call
dlsym(), and need all these subsystems on Windows to make it appear as
though that was natively available.

On 09/02/2024 23:41, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> On 09/02/2024 21:56, Kaz Kylheku wrote:
>>> On 2024-02-09, bart <bc@freeuk.com> wrote:
> [...]
>>>> So they didn't get the memo.
>>> They got the memo. The issue is that even though MSVCRT.DLL is
>>> undocumented, it constitutes a "system library". This is important.
>>
>> If they got rid of it, half the programs that run under Windows would
>> stop working.
>
> Who suggested getting rid of it?
>
> [...]
>
>> I'm no idea what the point of CYGWIN is. Never have done either.
>
> Are you asking?
>
>> What
>> does it bring to the table? Presumably to make some programs that
>> originate on Linux feel more at home, instead of making the effort to
>> make them more portable.
>
> It provides an environment, running under Windows, that resembles a
> typical Linux desktop environment. I use it every day myself, because
> that's a valuable thing for me. If it's not valuable for you, that's
> fine. (I also use WSL for some things.)
>
> I use a lot of programs that happen to rely on a POSIX interface.
> Cygwin lets those programs run under Windows.

Run or build? If you have a binary, then having a way to run that on a
different OS under some emulation layer is fair enough.

Some people run Windows programs under Linux, or even Macs (although
I've never had much luck with 'wine' myself).

But it seems to be a lot more than that; I can't say more as it's so
long since I tried to use it.

On 2024-02-09, bart <bc@freeuk.com> wrote:
> On 09/02/2024 23:41, Keith Thompson wrote:
>> I use a lot of programs that happen to rely on a POSIX interface.
>> Cygwin lets those programs run under Windows.
>
> Run or build? If you have a binary, then having a way to run that on a
> different OS under some emulation layer is fair enough.

It's both. Cygwin provides the build environment with all the tools,
plus the run-time environment also.

Cygwin isn't an emulation layer. It's a run-time library. The main
one is cygwin1.dll. A Cygwin program uses that as its C run time,
instead of ucrtbase.dll or msvcrt.dll.

Nothing is "emulated". The library has various POSIX functions in it, and
those are implemented in terms of the Win32 APIs.

Microsoft's libraries also have some features like this. For instance,
Microsoft has POSIX-like functions (with leading underscores added) like
_popen, and _dup and whatnot. Cygwin removes the underscores and does a
much more thorough job of implementing many more functions, with greater
fidelity.

I maintain a very useful fork of the Cygwin run-time called Cygnal.

Cygnal took a pretty low amount of effort do develop. From time to
time I rebase it to the current Cygwin.

Cygnal claws back some of the "too POSIXY" conventions in the Cygwin
run-time, making it suitable as a run-time library for "native" Windows
programs. Cygnal programs won't suprise Windows users with foreign
conventions, or certain broken behaviors due to being run outside of the
Cygwin installation.

All the changes are documented in a table presented in the home page?

https://www.kylheku.com/cygnal/

> Some people run Windows programs under Linux, or even Macs (although
> I've never had much luck with 'wine' myself).

Cygwin won't run Linux programs on Windows; it's not like Wine.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-02-09, bart <bc@freeuk.com> wrote:
> On 09/02/2024 23:12, Kaz Kylheku wrote:
>> On 2024-02-09, bart <bc@freeuk.com> wrote:
>
>>> I'm no idea what the point of CYGWIN is. Never have done either. What
>>> does it bring to the table? Presumably to make some programs that
>>> originate on Linux feel more at home, instead of making the effort to
>>> make them more portable.
>>
>> The effort is significant. Many things have to be coded twice.
>>
>
> Well, you need to support both OSes.
>
> My stuff uses one module in the language library which is OS-specific.
>
> At one point I had three versions for three OS targets. It is
> effectively a mini cross-platform wrapper around some OS functions.
>
> So for example, to get the address of a function in a shared library
> given an instance handle to the library, the Windows version is:
>
> export func os_getdllprocaddr(int hinst, ichar name)ref void=
> GetProcAddress(cast(hinst), name)
> end
>
> The Linux version is this:
>
> export func os_getdllprocaddr(int hlib, ichar name)ref void=
> dlsym(cast(int(hlib)), name)
> end

With cygwin, the Linux and Windows version is:

dlsym(handle, name);

And that's just a small thing.

How would you write serial control? Say the task is to open a serial
port, set the baud rate to 115200 kbps, 8N1 parity, 8-bit-clean raw
mode, and send a few bytes?

There is a POSIX way to do this, and so I have to write the code just
once, if I have a POSIX library on all the target machines.

Or, say, recursively walk a directory tree. I write the POSIX way to do
it, just once.

Create a hardlink: link(this, that). Will create an NTFS hard link
on Windows.

> As I understand your view, you want the Linux program to just call
> dlsym(), and need all these subsystems on Windows to make it appear as
> though that was natively available.

Well, yes; just like a Visual C program can call printf, as if printf
were natively available in Windows. Or call ShellExecuteEx() so that it
magically looks like Windows can natively "launch" a .PDF or .HTML file
in the same way it can run an .EXE.

That's how abstraction works!

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

bart <bc@freeuk.com> writes:
> On 09/02/2024 23:41, Keith Thompson wrote:
[...]
>> I use a lot of programs that happen to rely on a POSIX interface.
>> Cygwin lets those programs run under Windows.
>
> Run or build? If you have a binary, then having a way to run that on a
> different OS under some emulation layer is fair enough.

Cygwin deons't run Linux binaries, but Cygwin has development tools (gcc
et al) similar to what's typically available on Linux. Cygwin is not a
Linux emulation layer. It's a POSIX environment running under Windows.

See <https://cygwin.com/>, particularly the "What..." section at the top.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Fri, 09 Feb 2024 16:33:04 -0800, Keith Thompson wrote:

> Cygwin ... [is] a POSIX environment running under Windows.

And in some ways, more capable than Microsoft’s native-based efforts along
the same lines.

On 2024-02-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 09 Feb 2024 16:33:04 -0800, Keith Thompson wrote:
>
>> Cygwin ... [is] a POSIX environment running under Windows.
>
> And in some ways, more capable than Microsoft’s native-based efforts along
> the same lines.

Cygwin programs are just Win32 programs, and can be deployed without
a Cygwin installation. They are just .exe files that depend on
one or more DLLs from Cygwin, and not an entire OS layer.

Cygwin programs can use Win32 functions: you can call fork() and
CreateWindow() in one file.

Ther is also a project (maintained by me) which offers a patched
cygwin1.dll that suppresses certain POSIX conventions in the way a
program interacts with the environment. This is particularly suitable
for deploying programs built under Cygwin as stand-alone Windows
programs.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

bart <bc@freeuk.com> writes:
>On 09/02/2024 18:25, Scott Lurndal wrote:
elopment
>> environments exist.
>>
>>> Some people here seem to think that POSIX is an essential part of C,
>>
>> I don't recall anyone other than you thinking that.
>
>It's mentioned a LOT. Half the open source programs I try seem to use
>calls like 'open' instead of 'fopen', suggesting that the author seemed
>to think such a function is standard C, or that can be used as though it
>was standard.
>
>While here (https://en.wikipedia.org/wiki/C_POSIX_library):

Never heard of the "C POSIX library". The wiki page is just a list
of header files that are present in both C standards and POSIX standards.

On Fri, 9 Feb 2024 21:56:50 -0000 (UTC)
Kaz Kylheku <433-929-6894@kylheku.com> wrote:

> On 2024-02-09, bart <bc@freeuk.com> wrote:
> >> MSVCRT.DLL is not documented for public use; when you link to it,
> >> you're sticking a fork into the proverbial toaster. UCRT is
> >> different.
> >
> > What exactly to you mean by UCRT; ucrtbase.dll?
> >
> > That's missing a few useful things, like '_getmainargs' (used to
> > get argn, argv for main()), and obscure functions like 'printf'.
>
> I believe printf is in there.
>
> _getmainargs isn't; that's in a VC run time library.
>
> > Meanwhile, if I look at programs such as gcc.exe, as.exe, ld.exe,
> > not only do THEY import msvcrt.dll, but the EXEs produced by
> > gcc.exe do so too.
>
> Umm, no; you must be talking specifically about the MinGW ones.
>
> > So they didn't get the memo.
>
> They got the memo. The issue is that even though MSVCRT.DLL is
> undocumented, it constitutes a "system library". This is important.
>
> The GNU Public license prohibits programs from being linked to
> proprietary code --- but it has an exception for system libraries
> (libraries that are part of the target platform where the program
> runs).
>
> Using MSVCRT.DLL is like sticking a fork in the toaster, but all those
> programs being linked to MSVCRT.DLL means the GPL isn't violated.
>

Today Mingw64 provides two separate gcc programming environments.
One is based on old MSVCRT.DLL, probably from 2013 and other based on
ucrt. One installation package is called mingw-w64-x86_64-gcc and other
called mingw-w64-ucrt-x86_64-gcc.

On Fri, 09 Feb 2024 15:41:57 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> bart <bc@freeuk.com> writes:
> > On 09/02/2024 21:56, Kaz Kylheku wrote:
> >> On 2024-02-09, bart <bc@freeuk.com> wrote:
> [...]
> >>> So they didn't get the memo.
> >> They got the memo. The issue is that even though MSVCRT.DLL is
> >> undocumented, it constitutes a "system library". This is
> >> important.
> >
> > If they got rid of it, half the programs that run under Windows
> > would stop working.
>
> Who suggested getting rid of it?
>
> [...]
>
> > I'm no idea what the point of CYGWIN is. Never have done either.
>
> Are you asking?
>
> > What
> > does it bring to the table? Presumably to make some programs that
> > originate on Linux feel more at home, instead of making the effort
> > to make them more portable.
>
> It provides an environment, running under Windows, that resembles a
> typical Linux desktop environment. I use it every day myself, because
> that's a valuable thing for me. If it's not valuable for you, that's
> fine. (I also use WSL for some things.)
>
> I use a lot of programs that happen to rely on a POSIX interface.
> Cygwin lets those programs run under Windows. Modifying those
> programs to work more directly under Windows would be a tremendous
> amount of work that nobody is going to do.
>

I didn't encounter situation in which, given the choice, I would prefer
cygwin over msys2 at least for decade. I still have to use cygwin with
Altera/Intel Nios2 development environment (non-pro variant), because
there is no alternative. I don't like it at all.

On Sat, 10 Feb 2024 02:26:55 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Fri, 09 Feb 2024 16:33:04 -0800, Keith Thompson wrote:
>
> > Cygwin ... [is] a POSIX environment running under Windows.
>
> And in some ways, more capable than Microsoft’s native-based efforts
> along the same lines.

Many basic things, like file I/O and creation of processes is several
time slower under cygwin than under native Windows.

On Sat, 10 Feb 2024 20:17:26 +0200, Michael S wrote:

> On Sat, 10 Feb 2024 02:26:55 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Fri, 09 Feb 2024 16:33:04 -0800, Keith Thompson wrote:
>>
>> > Cygwin ... [is] a POSIX environment running under Windows.
>>
>> And in some ways, more capable than Microsoft’s native-based efforts
>> along the same lines.
>
> Many basic things, like file I/O and creation of processes is several
> time slower under cygwin than under native Windows.

Nevertheless, it manages to get some things working properly, like poll/
select on pipes.