On 2024-03-25 21:59, Christopher Meng via Cygwin wrote:
> Hi, I have a Cygwin mirror available at: Contact: i...@cicku.me Mirror URL:
> https://mirrors.cicku.me/cygwin Please consider this as an official request
> to add to the mirror list. Thank you!
You know, there are lots of mirrors of Cygwi
On 2024-02-07 11:57, Jon Turney via Cygwin wrote:
> A new version of Setup (2.930) has been uploaded to:
>
> https://cygwin.com/setup-x86_64.exe (64 bit version)
> https://cygwin.com/setup-x86.exe (32 bit version)
>
> Changes compared to 2.929:
>
> - Add some hardening against "DLL hijack
On 2024-02-04 21:22, Suman Chakraborty via Cygwin wrote:
> 1. Executive Summary:
>
> The vulnerability pertains to not finding
> the profapi.dll, CFGMGR32.dll, edputil.dll, urlmon.dll, SspiCli.dll,
> Wldp.dll, MPR.dll, ServicingCommon.dll, TextShaping.dll, CRYPTBASE.DLL,
> PROPSYS.dll and insecu
On 2024-01-24 05:11, Corinna Vinschen via Cygwin wrote:
> Is anybody willing to give this a whirl? We have a good year until
> the next major release...
As far as the problem of not allocating per-mutex kernel objects,
this can be done by implementing futex.
Linux has futexes, mainly for solving
On 2024-01-24 03:55, Takashi Yano via Cygwin wrote:
> Are there any code examples that use PTHREAD_MUTEX_INITIALIZER
> with pthread_mutex_destroy()?
I don't think I've seen one.
I think they are rare in the field, precisely because
PTHREAD_MUTEX_INITIALIZER is mainly used in C code to
"initialize
On 2024-01-19 20:18, Takashi Yano via Cygwin wrote:
> And I tried to observe the pthread_mutex_xxx() call. Then found the
> test case does like:
>
> #include
> int main()
> {
> for (;;) {
> pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
> pthread_mutex_lock(&m);
> pthread_mutex_unlo
On 2024-01-02 16:11, Takashi Yano via Cygwin wrote:
> Perhaps, the off-by-one is for EOF as you guess.
I doubt it. If EOF were out of range of char, it would have to be -129 or less,
so that -127 would look even more wrong.
I see EOF is just -1. That value will also be produced by '\xFF', or "\xf
On 2024-01-02 15:25, Takashi Yano via Cygwin wrote:
> On Tue, 02 Jan 2024 14:18:15 -0800
> Kaz Kylheku via Cygwin wrote:
>> I noticed that this macro, defined in winsup/cygwin/local_includes/path.h:
>>
>> #define isdrive(s) (isalpha (*(s)) && (s)[1] == ':&#x
Hi All,
I noticed that this macro, defined in winsup/cygwin/local_includes/path.h:
#define isdrive(s) (isalpha (*(s)) && (s)[1] == ':')
is being used with arguments of type char, like dereferenced "char *" pointers.
Unless the isalpha implementation is robust against this, it should be
i
On 2023-12-21 04:16, Martin Wege via Cygwin wrote:
> On Wed, Dec 20, 2023 at 6:21 PM Kaz Kylheku via Cygwin
> wrote:
>>
>> On 2023-12-17 22:22, Dan Shelton via Cygwin wrote:
>> > It would be nice if someone from the Cygwin authors could assist me in
>>
On 2023-12-17 22:22, Dan Shelton via Cygwin wrote:
> It would be nice if someone from the Cygwin authors could assist me in
> figuring out why this happens.
Cygwin is famously slow; this is nothing new. We are grateful
for Cygwin because it makes stuff work at all; if it were blazing
fast that wou
Hi all!
I was just wondering; have any of you ever tried to build a
resource-only DLL using the Cygwin toolchain environment?
I mean, starting with a .rc file, build a .res, and then link it into a
working resource-only DLL?
I know that adding resources to executables is perfectly possible;
Initial conditions:
0:BLACKBOX:~/txr$ rm testfile
0:BLACKBOX:~/txr$ touch testfile
0:BLACKBOX:~/txr$ chmod = testfile
0:BLACKBOX:~/txr$ ls -l testfile
-- 1 kaz kaz 0 Dec 24 13:23 testfile
Now, light up all the bits, like a Christmas tree---appropriate
for December 24:
0:BLAC
On 2020-07-08 04:47, Mark Hansen wrote:
You got us reading three posts, so we're fully invested in your issue,
and then
you don't share the answer? That's just cruel :)
I'm invested in the amusement of the whole procession, but all the while
I'm thinking that command substitution inside a for
On 2020-04-08 14:13, Ben Kamen wrote:
Well then.
This certainly turned out to be all sorts of interesting discussion. :)
I for one also can say it's nice to have a cygwin environment over DOS
if I'm forced to a CLI on Windows.
Most of my days are spent on Linux -- but it looks like I have som
On 2020-04-08 13:58, David Rothenberger wrote:
On 4/8/2020 1:50 PM, Kaz Kylheku via Cygwin wrote:
On 2020-04-04 11:58, Åke Rehnman via Cygwin wrote:
I have a major use case for Cygwin for providing remote access
to Windows. Using a non-Cygwin utility called "RunAsService.EXE",
I turne
On 2020-04-04 11:58, Åke Rehnman via Cygwin wrote:
On 2020-04-04 16:32, Kaz Kylheku via Cygwin wrote:
On 2020-04-04 02:00, Ben wrote:
Is there something else I'm missing?
That by cross-compiling for your targets on Cygwin instead of a real
POSIX OS, you will something like double
On 2020-04-04 02:00, Ben wrote:
Is there something else I'm missing?
That by cross-compiling for your targets on Cygwin instead of a real
POSIX OS, you will something like double your compile times, if not
more.
Why would you involve Cygwin in a development activity whose target
isn't POSI
18 matches
Mail list logo
