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.

On 29/01/2024 16:03, bart wrote:
> By 'Build System', I mean a convenient or automatic way to tell a
> compiler which source and library files comprise a project, one that
> doesn't involve extra dependencies.
>
> This proposal comes under 'convenient' rather than 'automatic'. (I did
> try an automatic scheme in the past, but that only worked for specially
> written projects.)

This is a summary of the module scheme in my two main languages:

https://github.com/sal55/langs/blob/master/Modules24.md

The idea for this lite C version came from that, in listing the project
files at the start of the now /only/ module submitted to the compiler.

That C scheme needs revising, and could also use some ideas of Thiago
Adams in being able to work with other compilers like this:

gcc xxx.c -oxxx && xxx # build with gcc

mcc xxx # build with mcc

With mcc, xxx is the lead module. With gcc/etc, it's not clear what xxx
is; it might need to be a fixed file 'build.c' configured for this
project, as otherwise the extra support module name and project lead
name will clash.

It needs a bit more thought...

For for the time being, I'm sticking with my '#pragma module' scheme
which seems to work fine for the projects I've tried it on:

mcc lua
mcc bbx
mcc cjpeg

etc. What more could you want? This is beautifully simple.