On Apr 17 08:37, Max Moebius via Cygwin wrote:
> Hi Brian, and thank you very much for the response!
>
> We read the announcement and that's why we decided to kindly ask, if the
> cygwin developers team would consider to make sure, that Windows Server
> 2012 (NOT R2) will be supported by cygwin un
Hi Brian, and thank you very much for the response!
We read the announcement and that's why we decided to kindly ask, if the
cygwin developers team would consider to make sure, that Windows Server
2012 (NOT R2) will be supported by cygwin until its end of support by
microsoft.
This is exactly why
On 2023-04-12 22:10, Max Moebius via Cygwin wrote:
We kindly ask to continue the Cygwin support for Windows Server 2012 until
its end of life. This will be on October 10, 2023.
https://learn.microsoft.com/en-us/lifecycle/products/windows-server-2012
As reiterated late last year in cygwin 3.4.0-
On Jan 8 04:14, NightStrike wrote:
> On Wed, Jan 5, 2022, 05:08 Corinna Vinschen
> wrote:
>
> > On Jan 3 22:40, NightStrike wrote:
> > > On Sun, Jan 2, 2022, 15:51 wrote:
> > >
> > > > While I recognize that ADS is not supported by POSIX, I was wondering
> > > > what if any support for ADS mig
On Wed, Jan 5, 2022, 05:08 Corinna Vinschen
wrote:
> On Jan 3 22:40, NightStrike wrote:
> > On Sun, Jan 2, 2022, 15:51 wrote:
> >
> > > While I recognize that ADS is not supported by POSIX, I was wondering
> > > what if any support for ADS might exist within Cygwin.
> > >
> > > The last time I
On Jan 3 22:40, NightStrike wrote:
> On Sun, Jan 2, 2022, 15:51 wrote:
>
> > While I recognize that ADS is not supported by POSIX, I was wondering
> > what if any support for ADS might exist within Cygwin.
> >
> > The last time I looked into this was probably more than a decade ago
> > but I am
On Sun, Jan 2, 2022, 15:51 wrote:
> While I recognize that ADS is not supported by POSIX, I was wondering
> what if any support for ADS might exist within Cygwin.
>
> The last time I looked into this was probably more than a decade ago
> but I am seeing (unfortunately) more usage of ADS in the Wi
Yes I recall that thread :)
Indeed, I under the pseudonym (aputerguy) was the one who INITIATED
the thread :) [I own the domain kosowksy.org which my many
personalities share]
But looks like nothing was done since, right?
Thomas Wolff wrote at about 00:06:27 +0100 on Monday, January 3, 2022:
> Am
Am 02.01.2022 um 21:50 schrieb cyg...@kosowsky.org:
While I recognize that ADS is not supported by POSIX, I was wondering
what if any support for ADS might exist within Cygwin.
The last time I looked into this was probably more than a decade ago
but I am seeing (unfortunately) more usage of ADS
On 03.08.2020 18:54, Hisham Sueyllam via Cygwin wrote:
My graphics Drivers for the Radeon 430 card and intel UHD 620 are uptodate and
the opengl extensions viewer says that opengl 4.6 is supported and opengl apps
compiled under mingw64 in MSYS2 run fine. When I tried to compile the point
sprit
On 2018-10-03 10:49, Nicolás Ojeda Bär wrote:
> On Wed, Oct 3, 2018 at 6:35 PM Andrey Repin wrote:
>>> I was wondering if it would be possible to use the recent ConPTY API
>>> https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/
Hi Andrey,
Thanks for your email. I am rather ignorant about the technical
issues, but if you take a look at the section titled
ConHost - Investing in yesterday for tomorrow
in the referenced blog post it seems to indicate quite clearly that
the new API can be used to run *existing* Console ap
Greetings, Nicolás Ojeda Bär!
> I was wondering if it would be possible to use the recent ConPTY API
>
> https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/
> to improve the compatibility of Cygwin with native Windows cons
On Jun 22 17:07, Ken Brown wrote:
> On 6/22/2015 9:25 AM, Corinna Vinschen wrote:
> >On Jun 22 08:05, Ken Brown wrote:
> >>According to the Cygwin API documentation
> >>(https://cygwin.com/cygwin-api/std-notes.html), "getitimer and setitimer
> >>only support ITIMER_REAL for now." I'm wondering whe
On 6/22/2015 9:25 AM, Corinna Vinschen wrote:
On Jun 22 08:05, Ken Brown wrote:
According to the Cygwin API documentation
(https://cygwin.com/cygwin-api/std-notes.html), "getitimer and setitimer
only support ITIMER_REAL for now." I'm wondering whether there's any chance
that support for ITIMER_
On Jun 22 08:05, Ken Brown wrote:
> According to the Cygwin API documentation
> (https://cygwin.com/cygwin-api/std-notes.html), "getitimer and setitimer
> only support ITIMER_REAL for now." I'm wondering whether there's any chance
> that support for ITIMER_PROF might be added. I have no idea what
On Sat, 28 Aug 2010, Andy Koppe wrote:
On 27 August 2010 23:31, Brennan Peter Sellner wrote:
By any chance, has support for the TIOCINQ ioctl on file descriptors (used
to check how many bytes of data are in the input buffer) been added to
Cygwin? It hadn't as of 2004:
http://sourceware.org/ml
On 27 August 2010 23:31, Brennan Peter Sellner wrote:
> By any chance, has support for the TIOCINQ ioctl on file descriptors (used
> to check how many bytes of data are in the input buffer) been added to
> Cygwin? It hadn't as of 2004:
>
> http://sourceware.org/ml/cygwin/2004-07/msg00910.html
It
On Wed, Feb 20, 2008 at 10:54 PM, Brian Dessent <[EMAIL PROTECTED]> wrote:
> hce wrote:
>
> > questions :-)). Should I just need to install setup.exe to enable me
> > to recompile the program on cygwin, or should I need to install other
> > resource as well for the compilation? I was using the m
hce wrote:
> questions :-)). Should I just need to install setup.exe to enable me
> to recompile the program on cygwin, or should I need to install other
> resource as well for the compilation? I was using the minGW for
> compilation on window at the moment.
You need to choose the necessary devel
On 2/20/08, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 20 February 2008 10:35, hce wrote:
>
> > Hi,
> >
> > I guess that
> > select() is not supported by the window, nor by minGW.
>
> Yep.
>
> > Will cygwin support select() in a fiile
> > system to read data from a serial port?
>
> Yep.
>
> > In
On 20 February 2008 10:35, hce wrote:
> Hi,
>
> I guess that
> select() is not supported by the window, nor by minGW.
Yep.
> Will cygwin support select() in a fiile
> system to read data from a serial port?
Yep.
> In cygwin, can I keep native
> read() and write() system call to a serial
Joaquín Mª López Muñoz wrote:
"Larry Hall (Cygwin)" ha escrito:
JoaquÃn Mª López Muñoz wrote:
Corinna Vinschen ha escrito:
Use `cvs annotate' to find the date when sa_sigaction has been
introduced and then check against the release dates. So, from what I
can tell, 1.5.7 should already h
"Larry Hall (Cygwin)" ha escrito:
> JoaquÃn Mª López Muñoz wrote:
> > Corinna Vinschen ha escrito:
> >
> >> Use `cvs annotate' to find the date when sa_sigaction has been
> >> introduced and then check against the release dates. So, from what I
> >> can tell, 1.5.7 should already have sa_siga
Joaquín Mª López Muñoz wrote:
Corinna Vinschen ha escrito:
On Nov 14 11:06, Joaqu?n M? L?pez Mu?oz wrote:
Hello,
The latest releases of Cygwin support include sa_sigaction member in the
structure sigaction, but older releases such as Cygwin 1.5.7 don't (I've just
checked it out with my 1.5.7
Corinna Vinschen ha escrito:
> On Nov 14 11:06, Joaqu?n M? L?pez Mu?oz wrote:
> > Hello,
> >
> > The latest releases of Cygwin support include sa_sigaction member in the
> > structure sigaction, but older releases such as Cygwin 1.5.7 don't (I've
> > just
> > checked it out with my 1.5.7 local co
On Nov 14 11:06, Joaqu?n M? L?pez Mu?oz wrote:
> Hello,
>
> The latest releases of Cygwin support include sa_sigaction member in the
> structure sigaction, but older releases such as Cygwin 1.5.7 don't (I've just
> checked it out with my 1.5.7 local copy).
>
> How can I find the exact Cygwin rele
Tony Anecito wrote:
Okay so there is no mirror that has the gettext 0.16.1
for easy install using setup.exe.
Is there some way to install that version of gettext
under cygwin?
ncftpget ftp://ftp.gnu.org/pub/gnu/gettext/gettext-0.16.1.tar.gz
tar xvzf gettext-0.16.1.tar.gz
cd gettext-0.16.1
conf
On Mar 26 14:10, James Youngman wrote:
> On 3/26/07, Eric Blake <[EMAIL PROTECTED]> wrote:
> >Corinna only replied to the cygwin list. It looks like Windows will
> >populate st_birthtime with st_ctime when reading filesystems that don't
> >support birthtime.
Er, sorry, but I didn't say that. I s
On 3/26/07, Eric Blake <[EMAIL PROTECTED]> wrote:
Corinna only replied to the cygwin list. It looks like Windows will
populate st_birthtime with st_ctime when reading filesystems that don't
support birthtime. This is a bit yucky, as it adds to the problem wrongly
being perpetuated by Microsoft
On Mar 25 21:28, James Youngman wrote:
> On 3/25/07, Eric Blake <[EMAIL PROTECTED]> wrote:
> >And part of the joy of it being a CVS development snapshot is that I can
> >give some feedback back to the cygwin developers - what would you rather
> >have stat do when btime is not available for a given
On 3/25/07, Eric Blake <[EMAIL PROTECTED]> wrote:
And part of the joy of it being a CVS development snapshot is that I can
give some feedback back to the cygwin developers - what would you rather
have stat do when btime is not available for a given file?
Set tv_sec to 0, and tv_nsec to UTIME_OM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to James Youngman on 3/25/2007 4:13 AM:
> On 3/25/07, James Youngman <[EMAIL PROTECTED]> wrote:
>> > st_birthtime (for seconds), or st_birthtim (for struct timespec)
>> > http://cygwin.com/ml/cygwin-cvs/2007-q1/msg00122.html
>
> I forgot to
Corinna Vinschen wrote:
[..] The next major Cygwin release will be able to read
native NTFS symlinks and treats them as symlinks. However, it's not
planned to utilize native NTFS symlinks when creating symlinks in Cygwin.
Actually, that sounds perfect. The main thing is to recognize them as
On Jan 28 13:38, Shankar Unni wrote:
> This article from Mark "Sysinternals" Russinovitch discusses the new
> "real" symbolic link feature in Vista ("real" in that it's classic
> Unix-style, where the symlink is interpreted on the local OS, even for
> links in mounted shares, and can refer to ei
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Shankar Unni on 1/28/2007 2:38 PM:
>
> Anyway: is any support planned in cygwin and/or coreutils for this
> feature? (specifically, supporting symlink(), S_ISLNK support in stat,
> etc.)
coreutils will do nothing special. Either cygwin
On Jan 10 10:18, David le Comte wrote:
> I'm wondering if the most general way of modifying fhandler_serial.cc
> (and cf[io]speed()?) is to do what SetCommState() is doing, ie,
> if the value that is passed is NOT equivalent to one of the Bn
> "define"s, then assume it is a literal speed and p
what I would do is have say Minicom try and talk at those rates first.
another option is to have a file like "newbaud.h" that looks like
this:
//
// newbaud.h -high speed baud rate functions
//
#IFNDEF NEWBAUD_H
#DEFINE NEWBAUD_H
David le Comte wrote:
> I am running Cygwin on a PC that is running Windows XP. My Cygwin
> version is "CYGWIN_NT-5.1" and it was downloaded and installed late last
No, it's not. The output from uname tells us nothing about which
version of Cygwin (or any of the other of dozens of packages you
On Mon, Apr 24, 2006 at 03:56:39AM +0700, Alexander J. Herrmann wrote:
>
>Charles Wilson wrote:
>
>>Corinna Vinschen wrote:
>>
>>>On Apr 21 15:09, Charles Wilson wrote:
>>>
Corinna said [in thread entitled "Windows 95 support ?"]
>Just the setup tool has some problem, apparently. Cygwi
Alexander J. Herrmann wrote:
Sleep(n) makes n second delays (Windoze) while sleep(n) make n
millisecond delays and beside this you got usleep on some systems.
No, it doesn't. I just said I had actually looked at the msdn
documentation. From
http://msdn.microsoft.com/library/default.asp?ur
Charles Wilson wrote:
Corinna Vinschen wrote:
On Apr 21 15:09, Charles Wilson wrote:
Corinna said [in thread entitled "Windows 95 support ?"]
Just the setup tool has some problem, apparently. Cygwin still runs
on 95,
>>> which will probably change at one point, since it's getting
incr
Corinna Vinschen wrote:
On Apr 21 15:09, Charles Wilson wrote:
Corinna said [in thread entitled "Windows 95 support ?"]
Just the setup tool has some problem, apparently. Cygwin still runs on 95,
>>> which will probably change at one point, since it's getting incredibly
>>> awkward to support i
On Apr 21 15:09, Charles Wilson wrote:
> Corinna said [in thread entitled "Windows 95 support ?"]
> > Just the setup tool has some problem, apparently. Cygwin still runs on 95,
> > which will probably change at one point, since it's getting incredibly
> > awkward to support it.
>
> I've a relate
Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> [I hate it when simple instructions aren't followed - I explicitly said
> that the list was the correct place for support...]
Nilgun, I won't want private mail either; keep it to the list please.
>> I am a new user for Cyg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[I hate it when simple instructions aren't followed - I explicitly said
that the list was the correct place for support...]
- Original Message
Subject: RE: support
Date: Mon, 16 Jan 2006 15:35:24 +0100
From: Yaman, Nilgun (GE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Yaman, Nilgun (GE Trans, Non-US, Non-GE) on 1/16/2006 6:45 AM:
> Hi,
>
> I am a Cygwin user and need to get support for some subjects.
> Please can you help me or advise a focal point about Cygwin?
You just found it - this list. Now wha
On Fri, 22 Apr 2005, Christopher Faylor wrote:
> On Fri, Apr 22, 2005 at 11:37:59AM -0400, Igor Pechtchanski wrote:
> >On Fri, 22 Apr 2005, lode leroy wrote:
> >>I would like to see support for dirent.d_type added to cygwin.
> >>
> >>fhandler_disk_file::readdir()
> >>{
> >>...
> >> if (buf.dwFileA
On Apr 23 07:36, Eric Blake wrote:
> But there are a number of applications out there that behave more
> efficiently if d_ino/d_type ARE properly implemented. For example, both
> coreutils and findutils are smart enough to avoid extra [l]stat()s on
> systems with working d_type when traversing dir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 4/22/2005 11:06 AM:
> Actually, thanks but I don't think we want to go down this path.
>
> Properly implementing this field would introduce the same problems as
> properly implementing d_ino. Doing this would mean a
On Fri, Apr 22, 2005 at 11:37:59AM -0400, Igor Pechtchanski wrote:
>On Fri, 22 Apr 2005, lode leroy wrote:
>>I would like to see support for dirent.d_type added to cygwin.
>>
>>fhandler_disk_file::readdir()
>>{
>>...
>> if (buf.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) {
>> dir->__d_dirent->d_
On Fri, 22 Apr 2005, lode leroy wrote:
> Hello,
>
> I would like to see support for dirent.d_type added to cygwin.
>
> fhandler_disk_file::readdir()
> {
> ...
> if (buf.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) {
>dir->__d_dirent->d_type = DT_DIR;
> } else {
>dir->__d_dirent->d_type =
On Fri, 17 Jan 2003, Richard Henderson wrote:
> On Fri, Jan 17, 2003 at 11:49:01PM +0100, Fabio Alemagna wrote:
> > Wait a minute, are you saying IA-64 implements section-relative
> > relocations? Is that for any kind of sections, or just the dwarf's ones?
>
> Any sections. See R_IA64_SECREL* i
On Fri, Jan 17, 2003 at 11:49:01PM +0100, Fabio Alemagna wrote:
> Wait a minute, are you saying IA-64 implements section-relative
> relocations? Is that for any kind of sections, or just the dwarf's ones?
Any sections. See R_IA64_SECREL* in bfd/elfxx-ia64.c.
r~
--
Unsubscribe info: http:/
Yup. That's what the main said.
Look at the pseudo op @secrel().
If you figure out how to implement this for AROS, I'd love any additional
insight you can share. I'm currently blindly stubling in gas and bfd.
On Fri, 17 Jan 2003, Fabio Alemagna wrote:
> On Fri, 17 Jan 2003, Richard Henderson
On Fri, 17 Jan 2003, Richard Henderson wrote:
> On Thu, Jan 16, 2003 at 09:18:20AM -0600, Brian Ford wrote:
> > I am still consulting the DWARF2 spec to see if gcc and gas are
> > correct in generating VMA addresses. If so, I guess I have to fix the
> > dwarf parsing code in bfd and gdb to subtra
Thanks for the response. I came to that ugly conclusion yesterday.
On Fri, 17 Jan 2003, Richard Henderson wrote:
> No, dwarf specifies a section-relative address. The issue is that,
> with the exception of IA-64, no target has section-relative relocations.
> So instead we force the VMA to zero
On Thu, Jan 16, 2003 at 09:18:20AM -0600, Brian Ford wrote:
> I am still consulting the DWARF2 spec to see if gcc and gas are
> correct in generating VMA addresses. If so, I guess I have to fix the
> dwarf parsing code in bfd and gdb to subtract the section base VMA.
No, dwarf specifies a section
On Thu, 16 Jan 2003, Brian Ford wrote:
> So, all I need to do is define ASM_OUTPUT_DWARF_OFFSET correctly in
> gcc/config/i386/cygwin.h.
>
> Does anyone have a good way to define a section relative offset in
> assembly for Cygwin, or do I need to define labels for the sections in the
> link script
On Thu, 16 Jan 2003, Christopher Faylor wrote:
> On Thu, Jan 16, 2003 at 03:58:09PM +, Nick Clifton wrote:
> >Does the PE format require that the debugging sections be loaded into
> >memory when the executable is invoked ?
>
> I didn't think that STABS debug information was loaded into memory.
On 16 Jan 2003, Nick Clifton wrote:
> Hi Brian,
>
> > My current problem is that all previous DWARF2 implementations
> > assign a VMA of zero to the .debug_* sections in the link script.
> > This violates the PE format and makes the executable unusable.
>
> I saw your post about this to the binuti
On Thu, Jan 16, 2003 at 03:58:09PM +, Nick Clifton wrote:
>Hi Brian,
>
>> My current problem is that all previous DWARF2 implementations
>> assign a VMA of zero to the .debug_* sections in the link script.
>> This violates the PE format and makes the executable unusable.
>
>I saw your post abou
Hi Brian,
> My current problem is that all previous DWARF2 implementations
> assign a VMA of zero to the .debug_* sections in the link script.
> This violates the PE format and makes the executable unusable.
I saw your post about this to the binutils list.
Does the PE format require that the deb
On 16 Jan 2003, Nick Clifton wrote:
> Hi Brian,
>
> > The coff versions of sec_to_styp_flags and styp_to_sec_flag in bfd
> > look to see if the section name begins with .debug and modify the
> > section flags appropriately. The PE versions do not even look at
> > the section name.
>
> Ahh, yes, y
Hi Brian,
> The coff versions of sec_to_styp_flags and styp_to_sec_flag in bfd
> look to see if the section name begins with .debug and modify the
> section flags appropriately. The PE versions do not even look at
> the section name.
Ahh, yes, you are right. I guess that no-one has tried to
inc
On 14 Jan 2003, Nick Clifton wrote:
> Hi Brian,
>
> > I have built gcc 3.2.1 (just --enable-languages=c so far) with
> > "#define DWARF2_DEBUGGING_INFO 1" added to config/i386/cygwin.h.
> > The resulting compiler still produces stabs by default, but will
> > accept "-gdwarf-2".
> >
> > When using
Hi Brian,
> I have built gcc 3.2.1 (just --enable-languages=c so far) with
> "#define DWARF2_DEBUGGING_INFO 1" added to config/i386/cygwin.h.
> The resulting compiler still produces stabs by default, but will
> accept "-gdwarf-2".
>
> When using "-gdwarf-2", the debug information is, I believe,
>
Please CC me on replys. I am not currently subscribed to any of these
lists.
I am interested in contributing to this endeavor, but I need help
with a few specific problems. Any pointers or information about known
issues would be greatly appreciated.
I have built gcc 3.2.1 (just --enable-languag
On Sat, Jan 04, 2003 at 05:30:15AM -, Dave Hooper wrote:
>a) If the cygwin build of gcc/gdb/gas/etc supports DWARF-2 debug
>information (it appears not but I may be overlooking something)
It doesn't.
>b) If not, is it just a matter of #defining the appropriate flags in
>/gcc/config/i386/cyg
windman J wrote in
<[EMAIL PROTECTED]>
on Fri, 3 May 2002 15:30:32 -0700 (PDT):
> Does Cygwin runs on Win2k Pro as well?
* sigh * ;-)
From the /front page/ of http://www.cygwin.com/ - near the top, too!
"The Cygwin DLL works with all non-beta versions of Windows since
Windows 95, with the exce
On Tue, Apr 30, 2002 at 07:14:46PM -0400, Yang-hua Chu wrote:
> I'm porting a network protocol (about 50K lines of code) developed in
> UNIX into cygwin, and I ran into problems when I want to open a
> multicast socket.
It's not implemented.
> If multicast
> socket is not currently implemented
71 matches
Mail list logo
