On 2025-03-10, bart <
bc@freeuk.com> wrote:
On 10/03/2025 10:58, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
>
I think nobody does. There's always been some sort of mystique
surrounding 'gcc' on Windows.
>
'MinGW' supposedly 'Minimalist Gnu on Windows'. In that case I wouldn't
like to see the full-scale one..
"Minimalist" is not about size of the compiler. Rather, it is
about possible support routines. For "hosted implementation" C
mandates presence of C library and there is a lot of functions
not in C standard, but included in libraries of C compilers.
There is also question of operating system support, complicated
by fact that Windows is different than other systems. Cygwin
solved those issues by offering Posix emulation and a sizable
collection os libraries. MinGW is minimalist in the sense
that it provides very little own libraries and mainly uses
what is provide by Windows.
>
I still don't get this stuff.
>
I get the impression that a port of gcc to Windows is not simply about
building C programs, but building C programs that use a lot of features
from Linux.
That is basically right. These tools can be used to write a Windows-only
program from scratch, but they are oriented toward cross-platform.
If so, then that's the wrong approach. There are various lesser
compilers which know nothing about mingw or posix of anything of the
sort. (For example, lccwin32, DMC, PellesC, I think Tiny C; I can't
speak for MSVC.)
What is the wrong approach though? Say you have a large program
that is oriented toward POSIX or Linux, and you'd like to get
it working on Windows with as much functionality as possible.
Now what?
(Note that the requirements in such a situation can easily rule out
MinGW or MinGW64, too.)
To put it differenly, you could compile program in one computer
and get relatively small program which runs OK on different
Windows machines because libraries it needs are already present.
This is quite different compared to Cygwin, where you need to
install Cygwin libraries before normal Cygwin program can run
(I write about normal programs because actual compiler in
Cygwin and Mingw used to be the same and with some tweaks one
could use Cygwin compiler to produce MinGW execuatbles).
>
I'm not interested in whatever Cygwin or Mingw are about. If I were to
use libraries not part of the OS, then it would be ones like SDL2 to get
interesting things done. Not try and emulate bits of Linux that I'd
never heard of.
Obviously, someone with a view toward creating a cross-platform program
which can be used on free operating systems would probably evaluate the
situation a bit differently. They would have to be prepared to become
familiar with some bits they have not heard of.
It used to be that you would have to write significant parts of
a cross-platform application twice: for POSIX and Win32.
There are ways to reduce the work. You can have some abstraction which
hides both platforms. You can make one platform look like the other:
have a POSIX implementation on Windows, or Win32 on POSIX.
If you're mostly a Windows programs who's not heard of various bits of
Linux, but you'd like your stuff usable by Linux users, you can probably
just, oh, validate that your stuff runs under Wine:
https://winehq.orgWine is in some ways the "opposite" of what we have been talking about
in these threads. With, say, Cygwin, I can port a POSIX program to
Windows, without having to are about bits of Windows I've never heard
of. Wine lets a Windows developer get their program running on one of a
number of Unix-like operating systems, without caring about bits of them
they have never heard of. Cygwin translates POSIX library funtion calls
into Win32. Wine translates Win32 calls into POSIX.
If you don't like either option, you can use something else: some
OS abstraction layer, and so on.
The SDL library you mention is such a layer, just for graphics and
interactive input.
Parts of the ISO C library provide a basic OS abstraction layer:
like malloc for memory, and stdio for file and other I/O.
If we want to write some game or graphics demo, which needs keyboard
or mouse input, pixel output, and needs to read and write some files,
we can probably get away with SDL, plus just <stdio.h>: fopen, fread,
getc, ...
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca