Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Sun, 9 Mar 2025 18:00:26 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <20250309105459.231@kylheku.com>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vq3oag$18iv6$1@dont-email.me>
 <vq4hf2$1brf7$1@dont-email.me> <vq4l3d$1ck9e$1@dont-email.me>
 <vq4m0u$1ctpn$1@dont-email.me> <vq4n05$1d5dv$1@dont-email.me>
 <vq4om7$1dbo2$2@dont-email.me> <vq6dqh$1pskk$1@dont-email.me>
 <vq6f8p$1pmnk$1@dont-email.me> <vq6gqc$1qcp8$1@dont-email.me>
 <vq6ips$1pmnk$2@dont-email.me> <vq6j5h$1qosf$1@dont-email.me>
 <20250304092827.708@kylheku.com> <vq7g1p$1vmg5$1@dont-email.me>
 <vq94dt$2boso$1@dont-email.me> <vqcsk7$23bfo$1@paganini.bofh.team>
 <vqefn1$3flpt$1@dont-email.me> <vqeu5c$3imil$1@dont-email.me>
 <vqeun4$3iqbq$1@dont-email.me> <vqfcbe$3lkkc$1@dont-email.me>
 <871pv861ht.fsf@nosuchdomain.example.com>
 <20250308192940.00001351@yahoo.com> <vqi1ge$8jg8$1@dont-email.me>
 <vqibt3$ahu0$3@dont-email.me> <vqiibq$bq1o$7@dont-email.me>
 <20250309012626.00001276@yahoo.com>
Injection-Date: Sun, 09 Mar 2025 19:00:28 +0100 (CET)
Injection-Info: dont-email.me; posting-host="aa2b1c041ebb8b94f514b3b1a0062f8c";
	logging-data="905121"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ptwQYP1zApSQXuhf9QwBVyH5Z37pJD5w="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:hbD3l+4nm2evguejYx2CssBNrz4=
Bytes: 3831

On 2025-03-08, Michael S <already5chosen@yahoo.com> wrote:
>> Cygwin is clever. They managed to get poll/select working on pipes,
>> which is something Microsoft still cannot manage on native Windows.
>
> cygwin is very slow.

Cygwin as a whole isn't slow, but it has slow filesystem namespace
access. Such is life. There are reasons for it and it's not easy to fix.

For instance, there are situations in Windows in which a file foo.exe
and foo must be considered the same file. Or foo.lnk and foo.
Cygwin has to be on the lookout for these situations. That's the
30 second summary.

> And user interface is significantly inferior
> relatively to msys2/mingw64. Or at least it was in 2018 which happens
> to be the version of cygwin that I am using regularly as part of
> Altera/Intel Nios2 SDK.
> For me the speed and UI convinience are far more important than better
> emulation of obscure POSIX features which is probably important only
> for programs that I would not want to run regardless.

Almost any/every program you'd ever port to Windows with MinGW64
is going to be a POSIX program, which will get a better, more detailed
treatment under Cygwin.

For instance programs which use POSIX termios to put the terminal into
raw mode and use ANSI escape sequences to control the console compile
and run under Cygwin. That's like anything which uses a line editing
library like Libedit or Linenoise.

Cygwin also has a little known secret weapon: the Cygnal project;
check my signature.

With Cygnal you can compile programs on Cygwin in the normal way and
then deploy them as native applications which work with normal Windows
paths and drive letters, use a normal semicolon-separated PATH variable,
have a HOME variable that points to your Windows user profile, and popen
and system functions that use cmd.exe not /bin/sh ...
Yet all the POSIX stuff is there.

All you do is bundle your executable with cygwin1.dll from
Cygnal rather than the cygwin1.dll from your Cygwin.

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