Re: Windows XP Support

[Peter A. Castro]

On Mon, 11 Jan 2016, Erik Soderquist wrote:


Date: Mon, 11 Jan 2016 15:26:39 -0500
From: Erik Soderquist
Subject: Re: Windows XP Support


Greetings, Erik,


On Mon, Jan 11, 2016 at 2:59 PM, cyg Simple wrote:

Arguments like this is the reason I had to spend years searching through
COBOL code for 2 digit years.  Old habits seem hard to die.  Either
upgrade or forever pay the penalty yourself to keep the old code running.


Actually I agree wholeheartedly, which is why I I'll make my own
frozen mirror, and deal with whatever happens after that myself.
Since these environments are frozen and isolated, I have not had any
problems.  This is also something I only do for my own personal
environments; I won't consider it for public production.


I believe Corinna mentioned (and I will re-interate here) that the
"Cygwin Time Machine" is at your service.  It contains every(*) snapshot 
(circa) release of Cygwin, should you happen to need something from the 
past.  I don't tend to advertise this much, but it is publicly available. :)


(*) well, as far back as v1.3.12-4 (2002/08/13/043102)


-- Erik


--
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
"Cats are just autistic Dogs" -- Dr. Tony Attwood

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Problems with lxml package

[Christian-Manuel Röderer]

Dear list,

is anyone else experiencing problems with the current versions of the
lxml package for python 3 (python-lxml-3.2.3-1 and
python-lxml-3.4.4-1, 64 bit)? It seems to install correctly (and so do
the dependencies) but then it seems to be incomplete:

$ python3.4
Python 3.4.3 (default, May  5 2015, 17:58:45)
[GCC 4.9.2] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import lxml
>>> from lxml import etree
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No such file or directory

Help and hints much appreciated,

Chris

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Error "exit code=-1073741819" while upgrading Cygwin remotely through sshd

[Ronald Pina]

Hello

I am trying to upgrade Cygwin on Win7 remotely through sshd, using
some small scripts but without success it always show:

  Changing gid back to original
  running: c:\cygwin\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash"
  abnormal exit: exit code=-1073741819
  running: c:\cygwin\bin\bash.exe --norc --noprofile
"/etc/postinstall/000-cygwin-post-install.sh"
  abnormal exit: exit code=-1073741819

While, i can update it the same way using a local cygwin terminal.

The taken task are :

1. First, send a command to remote shell to start a batch script on a
new independent cmd window as follow and it kills all opened cygwin
processes like bash.

 cmd /c start "C:\Users\Administrator\Downloads\call_setup.bat" && for
i in$(ps -e | awk '{print $1}' | sort) ; do kill -9 $i ; done

2. call_setup.bat calls another batch file which starts the upgrading
process as follow, and i have read on another thread from Corinna that
first it needs to installing only the cygwin1.dll from
http://cygwin.com/snapshots/x86/cygwin1-20151112.dll.xz and then
perform the upgrade:

net stop sshd
xcopy /y "C:\Users\Administrator\Downloads\cygwin1.dll" "C:\cygwin\bin"
"C:\Users\Administrator\Downloads\setup-x86.exe" -q -n -N -d -g -A -R
"c:\cygwin" -L -l "C:\Users\Administrator\Downloads" -P openssh,rsync
 net start sshd

Any help appriciated

Thanks in advance !

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Question about incorrect System path from cygpath with case-sensitivity enabled

[Corinna Vinschen]

On Jan 10 22:54, Bryan Henry wrote:
> Hi Corinna,
> 
> Sorry for the delay getting back to you. I tested out the cygpath
> binary from the latest snapshot and confirmed that it fixes my issue.
> Thank for you making the change!

You're welcome.  Thanks for testing.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[newlib-cygwin] select(2): Drop checking descriptors in case of immediate timeout.

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=20ddde2f552afedf7ef662bb21fec7a56f50040f

commit 20ddde2f552afedf7ef662bb21fec7a56f50040f
Author: Corinna Vinschen 
Date:   Mon Jan 11 10:36:33 2016 +0100

select(2): Drop checking descriptors in case of immediate timeout.

* select.cc (select): Call sel.poll only if sel.wait returned
select_ok.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/select.cc | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc
index b4c3778..fa6859c 100644
--- a/winsup/cygwin/select.cc
+++ b/winsup/cygwin/select.cc
@@ -189,12 +189,17 @@ select (int maxfds, fd_set *readfds, fd_set *writefds, 
fd_set *exceptfds,
  UNIX_FD_ZERO (readfds, maxfds);
  UNIX_FD_ZERO (writefds, maxfds);
  UNIX_FD_ZERO (exceptfds, maxfds);
- /* Set bit mask from sel records even in case of a timeout so we
-don't miss one.  This also sets ret to the right value >= 0,
-matching the number of bits set in the fds records. */
- ret = sel.poll (readfds, writefds, exceptfds);
- if (!ret && res != select_stuff::select_set_zero)
-   res = select_stuff::select_loop;
+ if (res == select_stuff::select_set_zero)
+   ret = 0;
+ else
+   {
+ /* Set bit mask from sel records.  This also sets ret to the
+right value >= 0, matching the number of bits set in the
+fds records.  if ret is 0, continue to loop. */
+ ret = sel.poll (readfds, writefds, exceptfds);
+ if (!ret)
+   res = select_stuff::select_loop;
+   }
}
   /* Always clean up everything here.  If we're looping then build it
 all up again.  */

Re: cygwin.dll: bug with select on Windows console

[Corinna Vinschen]

On Jan 10 05:04, John Hood wrote:
> On 1/9/2016 9:41 AM, Corinna Vinschen wrote:
> >I fixed the code and took the opportunity to clean it up a little using
> >>basically the (fixed) patch I proposed two days ago.
> >>
> >>I've just uploaded new developer snapshots tohttps://cygwin.com/snapshots/
> >>and a new test release 2.4.0-0.17 which contain this fix.  Please give any
> >>of them a try.
> I built from git master.  Both the test program and mosh appear to be seeing
> correct behavior from select() now.

Thanks for testing.  Can you re-test with current git master?  I reverted
one aspect of my change for performance.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Windows XP Support

[Andrey Repin]

Greetings, Warren Young!

> On Jan 10, 2016, at 4:52 PM, Juan Miguel Navarro Martínez wrote:
>> 
>> No software version can live forever

> Indeed, not even Linux.

> There’s a thread over on the CentOS mailing list right now started by
> someone who’s trying to get something working on CentOS 3, which is about
> three years younger than Windows XP, but which dropped out of support in
> 2010.  The answer is the same: no one’s going to help you, and if it breaks, 
> you get to keep the pieces.

It all nice and dandy from a blind standpoint.
But if you open eyes, you'll see, that if a new release makes environment
unusable, no amount of pushing and arguing would make people accept it.
This is what happened to Win8. This is what happened to Unity.
And to many other smaller programs.


-- 
With best regards,
Andrey Repin
Tuesday, January 12, 2016 08:12:19

Sorry for my terrible english...

Re: Problems with lxml package

[Yaakov Selkowitz]

On 2016-01-11 16:58, Christian-Manuel Röderer wrote:

is anyone else experiencing problems with the current versions of the
lxml package for python 3 (python-lxml-3.2.3-1 and
python-lxml-3.4.4-1, 64 bit)?


Those are for Python 2.7.  For Python 3.4 you need python3-lxml.

--
Yaakov

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

cygmagic-1.dll - access violation by accessing the lib via python

[Holger Bast]

Hi there,
I'm using a python wrapper (python-magic, 
https://github.com/ahupp/python-magic) checking some filetypes in a small 
script. The wrapper works fine under Unix-like system, but I got an access 
violation error under cygwin. I already tried an older version of file 
including libmagic from the gnuwin32-project and this one works fine - aside 
it's completely outdated ;)
This issue was already identified on the issue tracker of the python-wrapper 
but I don't think that this error is a problem of the wrapper  (see 
https://github.com/ahupp/python-magic/issues/76). I found some python wrappers 
on the cygwin mirrors (python-magic-5.24-1.tar.xz) but these also produce the 
same error.

Ok, here the script I used:

requirements: python 2.7 and python-magic

import magic

mage = magic.Magic(mime=True)
filetype = mage.from_file("testfile.odt")
print filetype


Output:

Traceback (most recent call last):
  File "C:/Users/aronadaal/PycharmProjects/libmagic-test/magictest.py", line 3, 
in 
mage = magic.Magic(mime=True)
  File "C:\Python27\lib\site-packages\magic.py", line 59, in __init__
self.cookie = magic_open(self.flags)
WindowsError: exception: access violation writing 0x
Exception AttributeError: "Magic instance has no attribute 'cookie'" in > ignored

Notice: You can ignore the last message regarding the "cookie"-variable. The 
filehhandler is stored inside it during the initialization. That's ok.

Bye, aronadaal

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Windows XP Support

[Erik Soderquist]

On Mon, Jan 11, 2016 at 2:59 PM, cyg Simple wrote:
> Arguments like this is the reason I had to spend years searching through
> COBOL code for 2 digit years.  Old habits seem hard to die.  Either
> upgrade or forever pay the penalty yourself to keep the old code running.

Actually I agree wholeheartedly, which is why I I'll make my own
frozen mirror, and deal with whatever happens after that myself.
Since these environments are frozen and isolated, I have not had any
problems.  This is also something I only do for my own personal
environments; I won't consider it for public production.

-- Erik

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Pipes Again -- a simple test case

[Corinna Vinschen]

On Jan  8 17:30, Corinna Vinschen wrote:
> On Jan  8 17:12, Houder wrote:
> > On 2016-01-08 16:19, Corinna Vinschen wrote:
> > >On Jan  4 10:24, Houder wrote:
> > >>On 2016-01-04 09:52, Marco Atzeri wrote:
> > >>>On 04/01/2016 09:03, Houder wrote:
> > Hi Corinna,
> > 
> > I have been looking for an STC to show why cmp fails on Cygwin (and to
> > show the
> > difference between Cygwin and Linux).
> > 
> > The STC below creates a pipe (pipe() is used), followed by calls to
> > fstat() and
> > stat() for both the read end and the write end of the pipe.
> > 
> > (I also tested with popen()/pclose(): same result)
> > 
> > Regards,
> > Henri
> > >
> > >Thanks for the STC.  However, given how this stuff works internally,
> > >I have no good solution off the top of my head.  I played with various
> > >ideas but to no avail.  I add this to my TODO list, but I probably
> > >won't have a quick solution :(
> > >
> > >
> > >Thanks,
> > >Corinna
> > >
> > >
> > >P.S: It would be really helpful if you could stick to the original
> > > thread and simply use "reply-to" once a discussion has started.
> > > It's very confusing having to connect the various threads.  Thanks.
> > 
> > Perhaps David B. can be helped by a Cygwin-specific patching to "cmp"? Eric?
> > 
> > ... replacing the call to fstat() by a call to stat() ...
> > (as shown in https://cygwin.com/ml/cygwin/2015-12/msg00348.html)
> > 
> > By the way, thank you for reporting back to "us" about this. I already
> > feared that a "general" solution would have to wait ... You have already
> > too much on your plate.
> > 
> > As a final point, I also tested FIFOs and (unix domain) sockets.
> > 
> > FIFOs pass the test, sockets do not.
> 
> Yes, that's expected.  The underlying hack^Wmethod is the same for sockets
> and pipes, while FIFOs have a real path on a real filesystem and thus have
> a real inode number to fetch in stat/fstat.

I applied a patch to make this work.  Please give the latest developer
snapshot from https://cygwin.com/snapshots/ a try.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Windows XP Support

[Corinna Vinschen]

On Jan 10 13:12, Herbert Stocker wrote:
> Hi,
> 
> i have read that beginning this month Cygwin wants to drop support
> for Windows XP.  Though the home page and FAQ entry 12 do not talk
> about this. Are they out of date or is WinXP still supported?

So far, nothing has changed, XP is still supported.  I intend to pull
the plug at one point this year, but it also depends on how much time I
have.  Continuing support for XP and Server 2003 is really becoming a
burden.  It requires to code and maintain workarounds which are not
required anymore in newer OSes, so I really would like to get rid of
that stuff.

> - If there is no support anymore for Win XP (SP3), is there a reposi-
>   tory around, where one can download the last version of Cygwin that
>   supported WinXP (SP3)?

Not yet, but the Cygwin time machine might be what you're looking for
in future:

  http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[newlib-cygwin] Return unique inode numbers when calling stat/fstat on pipes and IP sockets

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=a10d96923188977446ebd84323b47f7085fb5cb4

commit a10d96923188977446ebd84323b47f7085fb5cb4
Author: Corinna Vinschen 
Date:   Mon Jan 11 12:35:41 2016 +0100

Return unique inode numbers when calling stat/fstat on pipes and IP sockets

* fhandler.h (class fhandler_base): Convert unique_id to int64_t.
(fhandler_base::set_ino): New protected inline method.
(fhandler_base::get_unique_id): Convert to int64_t.
(fhandler_base::set_unique_id): New inline method taking int64_t.
(fhandler_pipe::fstat): Declare.
(fhandler_pipe::init): Take extra parameter.
(fhandler_pipe::create): Ditto.
* fhandler_socket.cc (fhandler_socket::init_events): Set inode 
number
to serial number.
(fhandler_socket::fstat): Set device to DEV_TCP_MAJOR.  Create 
st_ino
from get_ino.
* include/cygwin/signal.h (struct _sigcommune): Replace
_si_pipe_fhandler with _si_pipe_unique_id.
* pinfo.h (_pinfo::pipe_fhandler): Take unique id instead of HANDLE.
* pinfo.cc (commune_process): Accommodate change to 
_si_pipe_unique_id.
(_pinfo::commune_request): Ditto.
(_pinfo::pipe_fhandler): Ditto.
* pipe.cc (fhandler_pipe::init): Take unique id as argument and set
inode number and unique_id from there.
(fhandler_pipe::open): Rework to find any matching pipe from unique
id in filename.
(fhandler_pipe::get_proc_fd_name): Create filename using inode 
number.
(fhandler_pipe::create): Generate and return unique id from process 
pid
and pipe_unique_id.  In outer method, call init with additional 
unique
id as parameter.
(fhandler_pipe::fstat): New method.
(pipe_worker): Accommodate using 64 bit inode number in filename.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/fhandler.h  |  11 ++--
 winsup/cygwin/fhandler_socket.cc  |   5 +-
 winsup/cygwin/include/cygwin/signal.h |   2 +-
 winsup/cygwin/pinfo.cc|  10 ++--
 winsup/cygwin/pinfo.h |   2 +-
 winsup/cygwin/pipe.cc | 100 +++---
 winsup/cygwin/release/2.4.0   |   3 +
 7 files changed, 88 insertions(+), 45 deletions(-)

diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index adb8441..8bcf83f 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -182,8 +182,9 @@ class fhandler_base
   size_t rabuflen;
 
   /* Used for advisory file locking.  See flock.cc.  */
-  long long unique_id;
+  int64_t unique_id;
   void del_my_locks (del_lock_called_from);
+  void set_ino (ino_t i) { ino = i; }
 
   HANDLE read_state;
 
@@ -304,7 +305,7 @@ class fhandler_base
   const char *get_win32_name () { return pc.get_win32 (); }
   virtual dev_t get_dev () { return get_device (); }
   ino_t get_ino () { return ino ?: ino = hash_path_name (0, 
pc.get_nt_native_path ()); }
-  long long get_unique_id () const { return unique_id; }
+  int64_t get_unique_id () const { return unique_id; }
   /* Returns name used for /proc//fd in buf. */
   virtual char *get_proc_fd_name (char *buf);
 
@@ -319,6 +320,7 @@ class fhandler_base
   int open_null (int flags);
   virtual int open (int, mode_t);
   virtual void open_setup (int flags);
+  void set_unique_id (int64_t u) { unique_id = u; }
   void set_unique_id () { NtAllocateLocallyUniqueId ((PLUID) _id); }
 
   int close_with_arch ();
@@ -731,13 +733,14 @@ public:
   int open (int flags, mode_t mode = 0);
   int dup (fhandler_base *child, int);
   int ioctl (unsigned int cmd, void *);
+  int __reg2 fstat (struct stat *buf);
   int __reg2 fstatvfs (struct statvfs *buf);
   int __reg3 fadvise (off_t, off_t, int);
   int __reg3 ftruncate (off_t, bool);
-  int init (HANDLE, DWORD, mode_t);
+  int init (HANDLE, DWORD, mode_t, int64_t);
   static int create (fhandler_pipe *[2], unsigned, int);
   static DWORD create (LPSECURITY_ATTRIBUTES, HANDLE *, HANDLE *, DWORD,
-  const char *, DWORD);
+  const char *, DWORD, int64_t *unique_id = NULL);
   fhandler_pipe (void *) {}
 
   void copyto (fhandler_base *x)
diff --git a/winsup/cygwin/fhandler_socket.cc b/winsup/cygwin/fhandler_socket.cc
index 21bc731..094cc65 100644
--- a/winsup/cygwin/fhandler_socket.cc
+++ b/winsup/cygwin/fhandler_socket.cc
@@ -594,6 +594,7 @@ fhandler_socket::init_events ()
InterlockedIncrement (_serial_number);
   if (!new_serial_number)  /* 0 is reserved for global mutex */
InterlockedIncrement (_serial_number);
+  set_ino (new_serial_number);
   RtlInitUnicodeString (, sock_shared_name (name, 
new_serial_number));
   InitializeObjectAttributes (, , OBJ_INHERIT | OBJ_OPENIF,
   

Re: Windows XP Support

[Warren Young]

On Jan 11, 2016, at 4:52 AM, Corinna Vinschen  wrote:
> 
> Continuing support for XP and Server 2003 is really becoming a
> burden.  It requires to code and maintain workarounds which are not
> required anymore in newer OSes, so I really would like to get rid of
> that stuff.

I seem to recall you saying that Vista added a fork-like facility to the kernel 
which might let Cygwin implement a copy-on-write fork(2).  Would dropping XP 
support allow that?

If so, that would probably speed Cygwin up quite a bit in many common use 
cases: running autoconf configure scripts, Makefiles, etc.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Windows XP Support

[Erik Soderquist]

On Mon, Jan 11, 2016 at 9:38 AM, wilson wrote:
> I'd like to say a sincere thank you to Corina (and the rest of the team) for
> supporting XP for this long, and I hope she stays so busy the issue of
> removing XP support never becomes a priority. :)

I rather expect it will more be a matter of a bug fix or enhancement
that would require significant additional coding to maintain XP/2003
support will be the trigger for cutting off XP/2003 support.

-- Erik

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Windows XP Support

[Warren Young]

On Jan 10, 2016, at 5:12 AM, Herbert Stocker  wrote:
> 
> WinXP is still a good OS.

That was only true while Microsoft was maintaining it.  Now there are many 
known security vulnerabilities which will never be patched.

I expect there are other problems with it, too, like incorrect time zone 
support in parts of the world that have changed their time zone rules since the 
discontinuation of support.

> Especially for virtual machines, because of its low memory foot print.

No argument, but memory and disk usage can’t be the primary concern.  If that’s 
all we’re concerned with, we’d still be running Windows NT 3.51.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Pipes Again -- a simple test case

[Henri]

Corinna Vinschen  cygwin.com> writes:
> Can you please provide the socket testcase?

Trying to send you what you ask for (using gmane.org, I have to copy/paste)

- t_stat3.c:
/*\
*  Copyright (C) Michael Kerrisk, 2014.   *
* *
* This program is free software. You may use, modify, and redistribute it *
* under the terms of the GNU Affero General Public License as published   *
* by the Free Software Foundation, either version 3 or (at your option)   *
* any later version. This program is distributed without any warranty.*
* See the file COPYING.agpl-v3 for details.   *
\*/

/* Listing 15-1 */ // t_stat.c -- heavily modified

#define _BSD_SOURCE /* Get major() and minor() from  */
#include 
#include 
#include 
//#include "file_perms.h"
//#include "tlpi_hdr.h"

#include   /* Standard I/O functions */
#include  /* Prototypes of commonly used library functions,
   plus EXIT_SUCCESS and EXIT_FAILURE constants */
#include  /* Prototypes for many system calls */
#include  /* Commonly used string-handling functions */

static void
displayStatInfo(const struct stat *sb)
{
printf("File type:");

switch (sb->st_mode & S_IFMT) {
case S_IFREG:  printf("regular file\n");break;
case S_IFDIR:  printf("directory\n");   break;
case S_IFCHR:  printf("character device\n");break;
case S_IFBLK:  printf("block device\n");break;
case S_IFLNK:  printf("symbolic (soft) link\n");break;
case S_IFIFO:  printf("FIFO or pipe\n");break;
case S_IFSOCK: printf("socket\n");  break;
default:   printf("unknown file type?\n");  break;
}

printf("Device containing i-node: (%lx)   major=%lu   minor=%lu\n",
(long) sb->st_dev, (long) major(sb->st_dev), (long)
minor(sb->st_dev));

printf("I-node number:%llx - decimal: %llu\n", sb->st_ino,
sb->st_ino);

if (S_ISCHR(sb->st_mode) || S_ISBLK(sb->st_mode))
printf("  Device number (st_rdev):  major=%ld; minor=%ld\n",
(long) major(sb->st_rdev), (long) minor(sb->st_rdev));

printf("File size:%lld bytes\n", (long long) sb->st_size);
}

void errExit(const char *format, ...);

#include 
#include 

int
main()
{
char symlnk[64];

pid_t pid = getpid();

int sfd[2];

for (int f = 0; f < 2; f++) // step over the 1st and 2nd socket
{
if (!f) {
sfd[f] = socket(AF_UNIX, SOCK_STREAM, 0);
//sfd[f] = socket(AF_INET, SOCK_STREAM, 0);
if (sfd[f] == -1)
errExit("socket");
} else {
sfd[f] = socket(AF_UNIX, SOCK_STREAM, 0);
//sfd[f] = socket(AF_INET, SOCK_STREAM, 0);
if (sfd[f] == -1)
errExit("socket");
}
}

struct stat sb[2]; // one buffer for the 1st socket, one for the 2nd
int f;

char target[128];
ssize_t num;

printf("1st socket\n");
f = 0;
if (sprintf(symlnk, "/proc/%d/fd/%d", pid, sfd[f]) <= 0)
errExit("sprintf");
printf("... %s (symbolic link to the socket)\n", symlnk);

if ( (num = readlink( (const char *)symlnk, target, 128) ) == -1)
   errExit("readlink");
if (num < 128) {
target[num] = '\0';
printf("... %s (target of symbolic link to the socket)\n", target);

printf("... using  stat() on symbolic link: %s\n", symlnk);
//if (stat(target, sb + f) != 0) // not possible: target is NOT a
filename ...
if (stat(symlnk, sb + f) != 0)
errExit("stat");
displayStatInfo(sb + f);

printf("... using fstat()\n");
memset(sb + f, 0, sizeof(struct stat) ); // CLEAR
if (fstat(sfd[f], sb + f) != 0)
errExit("fstat");
displayStatInfo(sb + f);
}

#if 1
printf("\n2nd socket\n");
f = 1;
if (sprintf(symlnk, "/proc/%d/fd/%d", pid, sfd[f]) <= 0)
errExit("sprintf");
printf("... %s (symbolic link to the socket)\n", symlnk);

if ( (num = readlink( (const char *)symlnk, target, 128) ) == -1)
   errExit("readlink");
if (num < 128) {
target[num] = '\0';
printf("... %s (target of symbolic link to the socket)\n", target);

printf("... using  stat() on symbolic link: %s\n", symlnk);
//if (stat(target, sb + f) != 0) // not possible: target is NOT a
filename ...
if (stat(symlnk, sb + f) != 0)
errExit("stat");
displayStatInfo(sb + f);

printf("... using fstat()\n");
memset(sb + f, 0, sizeof(struct stat) ); // CLEAR
if (fstat(sfd[f], sb + f) != 0)
errExit("fstat");

Re: Cannot Run Executable Files

[Mark Hansen]

On 1/11/2016 7:41 AM, Warren Young wrote:

On Jan 9, 2016, at 2:11 AM, Zac G. Al Wakeel  wrote:



 For the archives, would you say which software was causing the problem?


 I was using Avast, free software.


Then I recommend uninstalling it and switching to Windows Defender.  I predict 
that your problems will not return.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple




I use AVG which also has a free version 
(http://free.avg.com/us-en/free-antivirus-download).

Once in a while, it tries to "vault" a cygwin executable. I just tell it to put 
it back
and leave it alone. There's probably a way to tell it to just ignore the whole 
cygwin
directory, but the problem has not come up enough to warrant looking up how to 
do this.

Good luck.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: Windows XP Support

[Jon Beniston]

Windows XP still accounts for about 10% of desktop users... Similar to the 
total number of Mac users.

Maybe some browser OS stats from cygwin.com would be illuminating.

Jon



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cannot Run Executable Files

[Warren Young]

On Jan 9, 2016, at 2:11 AM, Zac G. Al Wakeel  wrote:
> 
>> For the archives, would you say which software was causing the problem?
> 
> I was using Avast, free software. 

Then I recommend uninstalling it and switching to Windows Defender.  I predict 
that your problems will not return.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Windows XP Support

[wilson]

On Jan 10 13:12, Herbert Stocker wrote:

Hi, i have read that beginning this month Cygwin wants to drop support 
for Windows XP. Though the home page and FAQ entry 12 do not talk 
about this. Are they out of date or is WinXP still supported?


So far, nothing has changed, XP is still supported. I intend to pull
the plug at one point this year, but it also depends on how much time I
have. Continuing support for XP and Server 2003 is really becoming a
burden.


The Cygwin support for XP is very much appreciated as the latest Windows 
releases are not really ready for prime time office work yet.  Windows 
10 is making some headway in this respect.


I'd like to say a sincere thank you to Corina (and the rest of the team) 
for supporting XP for this long, and I hope she stays so busy the issue 
of removing XP support never becomes a priority. :)


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Pipes Again -- a simple test case

[Henri]

Corinna Vinschen  cygwin.com> writes:

> > > As a final point, I also tested FIFOs and (unix domain) sockets.
> > > 
> > > FIFOs pass the test, sockets do not.
> > 
> > Yes, that's expected.  The underlying hack^Wmethod is the same for sockets
> > and pipes, while FIFOs have a real path on a real filesystem and thus have
> > a real inode number to fetch in stat/fstat.
> 
> I applied a patch to make this work.  Please give the latest developer
> snapshot from https://cygwin.com/snapshots/ a try.

Thank you!

Down with flue on this side. Did a quick verification (32-bits Cygwin).
Pipes look good. The problem with cmp apperas to be gone.
Sockets still leave wanting, as shown here:

@@ ./t_henri
1st socket
... /proc/4896/fd/3 (symbolic link to the socket)
... socket:[252] (target of symbolic link to the socket)
... using  stat() on symbolic link: /proc/4896/fd/3
File type:socket
Device containing i-node: (1e)   major=30   minor=0
I-node number:38037da0d28c3faf - decimal: 4036207820734742447
File size:0 bytes
... using fstat()
File type:socket
Device containing i-node: (1e)   major=30   minor=0
I-node number:1 - decimal: 1
File size:0 bytes

2nd socket
... /proc/4896/fd/4 (symbolic link to the socket)
... socket:[272] (target of symbolic link to the socket)
... using  stat() on symbolic link: /proc/4896/fd/4
File type:socket
Device containing i-node: (1e)   major=30   minor=0
I-node number:38037da2d3885eb1 - decimal: 4036207829341200049
File size:0 bytes
... using fstat()
File type:socket
Device containing i-node: (1e)   major=30   minor=0
I-node number:2 - decimal: 2
File size:0 bytes
@@ 

Regards,
Henri


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Windows XP Support

[Warren Young]

On Jan 10, 2016, at 4:52 PM, Juan Miguel Navarro Martínez 
 wrote:
> 
> No software version can live forever

Indeed, not even Linux.

There’s a thread over on the CentOS mailing list right now started by someone 
who’s trying to get something working on CentOS 3, which is about three years 
younger than Windows XP, but which dropped out of support in 2010.  The answer 
is the same: no one’s going to help you, and if it breaks, you get to keep the 
pieces.

And CentOS (RHEL, really) is the longest-supported open source Linux OS distro 
available.  SLES matches it, but there is no open source rebuild like CentOS is 
to RHEL; openSUSE only has a 3- or 4-year support cycle for its Evergreen 
releases.

Theoretically, some group of motivated developers could fork CentOS 3 and 
continue to maintain it indefinitely, but I haven’t seen the idea suggested on 
the mailing list.

My point is that even when the sources are freely available, it’s practically 
impossible to get developers to support ancient code.  There has to be a 
motivation, which is the support contract length in the case of the LTS 
Linuxes.  Once that runs out, the software developers are retasked.

The same is true over in Redmond.  The only difference is that there isn’t an 
open source version of Windows, so we can only speculate whether a sufficiently 
strong developer community could form around it to support it past the EOL date.

I suspect that’s the real reason Microsoft refuses to open source Windows: 
they’re worried that such a maintenance effort could form.  If there were a 
community-supported version of Windows XP, they’d have an even harder time 
getting people to adopt modern versions of Windows.  It would effectively fork 
the Windows platform.

Bottom line: it’s long past time to get off XP.  The Cygwin developers should 
not be expected to expend any additional effort to maintain XP compatibility.

> Linux Kernel LTS support is 2-3 years, for Debian is 1 year after
> release of next stable version, Ubuntu is 5 years and 9 months for STS
> and both LinuxMint and Trisquel 5 years as well.

RHEL/CentOS and SLES both have 10 year support cycles.

> At least Windows XP got 13 years of support and since Windows Vista its
> 10 years.

XP support was supposed to run for 10 years, too, but got pushed back twice due 
to customer base foot-dragging, IIRC.

Windows 8.1 extended support is scheduled to run for 10 years.  If you want to 
add in 8.0, that comes to 11.

Windows 10 is also scheduled for 10 years of extended support.

You can’t hold back the tide.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[newlib-cygwin] Fix previous fix for generating unique inode numbers for sockets

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=27086d628e814b7b73a5c858ff2d9138c22d5543

commit 27086d628e814b7b73a5c858ff2d9138c22d5543
Author: Corinna Vinschen 
Date:   Mon Jan 11 19:10:45 2016 +0100

Fix previous fix for generating unique inode numbers for sockets

* fhandler.h (fhandler_base::get_plain_ino): New inline method.
Add comment to explain what it's supposed to be used for.
* fhandler_socket.cc (fhandler_socket::get_proc_fd_name): Create
filename using inode number.
(fhandler_socket::fstat): Generate inode number from filename if
ino is not set (that's the case in a stat(2) call).
* pipe.cc: Throughout, use get_plain_ino when appropriate.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/fhandler.h |  2 ++
 winsup/cygwin/fhandler_socket.cc |  6 --
 winsup/cygwin/pipe.cc| 12 ++--
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index 8bcf83f..d94f38d 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -304,6 +304,8 @@ class fhandler_base
   const char *get_name () const { return pc.get_posix (); }
   const char *get_win32_name () { return pc.get_win32 (); }
   virtual dev_t get_dev () { return get_device (); }
+  /* Use get_plain_ino if the caller needs to avoid hashing if ino is 0. */
+  ino_t get_plain_ino () { return ino; }
   ino_t get_ino () { return ino ?: ino = hash_path_name (0, 
pc.get_nt_native_path ()); }
   int64_t get_unique_id () const { return unique_id; }
   /* Returns name used for /proc//fd in buf. */
diff --git a/winsup/cygwin/fhandler_socket.cc b/winsup/cygwin/fhandler_socket.cc
index 094cc65..7d3efad 100644
--- a/winsup/cygwin/fhandler_socket.cc
+++ b/winsup/cygwin/fhandler_socket.cc
@@ -250,7 +250,7 @@ fhandler_socket::~fhandler_socket ()
 char *
 fhandler_socket::get_proc_fd_name (char *buf)
 {
-  __small_sprintf (buf, "socket:[%lu]", get_socket ());
+  __small_sprintf (buf, "socket:[%lu]", get_plain_ino ());
   return buf;
 }
 
@@ -939,7 +939,9 @@ fhandler_socket::fstat (struct stat *buf)
   if (!res)
{
  buf->st_dev = FHDEV (DEV_TCP_MAJOR, 0);
- buf->st_ino = (ino_t) get_ino ();
+ if (!(buf->st_ino = get_plain_ino ()))
+   sscanf (get_name (), "/proc/%*d/fd/socket:[%lld]",
+(long long *) >st_ino);
  buf->st_mode = S_IFSOCK | S_IRWXU | S_IRWXG | S_IRWXO;
  buf->st_size = 0;
}
diff --git a/winsup/cygwin/pipe.cc b/winsup/cygwin/pipe.cc
index 4ec4fa4..4ccfef6 100644
--- a/winsup/cygwin/pipe.cc
+++ b/winsup/cygwin/pipe.cc
@@ -142,7 +142,8 @@ fhandler_pipe::open (int flags, mode_t mode)
   __seterrno ();
   goto out;
 }
-  init (nio_hdl, fh->get_access (), mode & O_TEXT ?: O_BINARY, fh->get_ino ());
+  init (nio_hdl, fh->get_access (), mode & O_TEXT ?: O_BINARY,
+   fh->get_plain_ino ());
   cfree (fh);
   CloseHandle (proc);
   return 1;
@@ -181,7 +182,7 @@ fhandler_pipe::ftruncate (off_t length, bool allow_truncate)
 char *
 fhandler_pipe::get_proc_fd_name (char *buf)
 {
-  __small_sprintf (buf, "pipe:[%D]", get_ino ());
+  __small_sprintf (buf, "pipe:[%D]", get_plain_ino ());
   return buf;
 }
 
@@ -422,8 +423,7 @@ fhandler_pipe::fstat (struct stat *buf)
   if (!ret)
 {
   buf->st_dev = FH_PIPE;
-  /* Don't use get_ino, it doesn't return 0 but a hash instead. */
-  if (!(buf->st_ino = get_unique_id ()))
+  if (!(buf->st_ino = get_plain_ino ()))
sscanf (get_name (), "/proc/%*d/fd/pipe:[%lld]",
 (long long *) >st_ino);
 }
@@ -447,9 +447,9 @@ pipe_worker (int filedes[2], unsigned int psize, int mode)
   cygheap_fdnew fdin;
   cygheap_fdnew fdout (fdin, false);
   char buf[sizeof ("/dev/fd/pipe:[9223372036854775807]")];
-  __small_sprintf (buf, "/dev/fd/pipe:[%D]", fhs[0]->get_ino ());
+  __small_sprintf (buf, "/dev/fd/pipe:[%D]", fhs[0]->get_plain_ino ());
   fhs[0]->pc.set_posix (buf);
-  __small_sprintf (buf, "pipe:[%D]", fhs[1]->get_ino ());
+  __small_sprintf (buf, "pipe:[%D]", fhs[1]->get_plain_ino ());
   fhs[1]->pc.set_posix (buf);
   fdin = fhs[0];
   fdout = fhs[1];

[newlib-cygwin] Revert "autoload.cc: Drop using full paths for system DLLs"

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=b4cf3f454d8c2a05d6956fbc1eae3942d2f1730a

commit b4cf3f454d8c2a05d6956fbc1eae3942d2f1730a
Author: Corinna Vinschen 
Date:   Mon Jan 11 18:46:01 2016 +0100

Revert "autoload.cc: Drop using full paths for system DLLs"

This reverts commit 4b104ce07070e32363a217a554441a8b4df69d12.

The DLLs always guaranteed to be loaded from the system dir are only
those in the KnownDLLs list.  We're using some DLLs not in that list on
all supported OSes, thus we need to make sure to use full paths.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/autoload.cc | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/winsup/cygwin/autoload.cc b/winsup/cygwin/autoload.cc
index e14647c..836597d 100644
--- a/winsup/cygwin/autoload.cc
+++ b/winsup/cygwin/autoload.cc
@@ -420,15 +420,18 @@ std_dll_init ()
 {
   fenv_t fpuenv;
   fegetenv ();
+  WCHAR dll_path[MAX_PATH];
   DWORD err = ERROR_SUCCESS;
   int i;
+  /* http://www.microsoft.com/technet/security/advisory/2269637.mspx */
+  wcpcpy (wcpcpy (dll_path, windows_system_directory), dll->name);
   /* MSDN seems to imply that LoadLibrary can fail mysteriously, so,
 since there have been reports of this in the mailing list, retry
 several times before giving up. */
   for (i = 1; i <= RETRY_COUNT; i++)
{
  /* If loading the library succeeds, just leave the loop. */
- if (dll_load (dll->handle, dll->name))
+ if (dll_load (dll->handle, dll_path))
break;
  /* Otherwise check error code returned by LoadLibrary.  If the
 error code is neither NOACCESS nor DLL_INIT_FAILED, break out
@@ -441,10 +444,15 @@ std_dll_init ()
}
   if ((uintptr_t) dll->handle <= 1)
{
- if ((func->decoration & 1))
+ /* If LoadLibrary with full path returns one of the weird errors
+reported on the Cygwin mailing list, retry with only the DLL
+name.  Only do this when the above retry loop has been exhausted. 
*/
+ if (i > RETRY_COUNT && dll_load (dll->handle, dll->name))
+   /* got it with the fallback */;
+ else if ((func->decoration & 1))
dll->handle = INVALID_HANDLE_VALUE;
  else
-   api_fatal ("unable to load %W, %E", dll->name);
+   api_fatal ("unable to load %W, %E", dll_path);
}
   fesetenv ();
 }

Re: Pipes Again -- a simple test case

[Corinna Vinschen]

On Jan 11 16:13, Henri wrote:
> Corinna Vinschen  cygwin.com> writes:
> > Can you please provide the socket testcase?
> 
> Trying to send you what you ask for (using gmane.org, I have to copy/paste)

Thanks!  I applied a patch and created a new developer snapshot.  I'll
also upload a new cygwin test release later today.  That's hopefully the
last one.  I intend to release end of this week.


Thanks again,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.18

[Corinna Vinschen]

Hi Cygwin friends and users,


I released TEST version 2.4.0-0.18 of Cygwin.  This is the last test
release if nothing unexpected happens.  I plan to release officially
on Friday.


What's new:
---

- New, unified implementation of POSIX permission and ACL handling.  The
  new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and
  they allow to inherit the S_ISGID bit.  ACL inheritance now really
  works as desired, in a limited, but theoretically equivalent fashion
  even for non-Cygwin processes.

  To accommodate standard Windows ACLs, the POSIX permissions of the
  owner and all other users in the ACL are computed using the Windows
  AuthZ API.  This may slow down the computation of POSIX permissions
  noticably in some circumstances, but is generally more correct.  The
  new code also ignores SYSTEM and Administrators group permissions when
  computing the MASK/CLASS_OBJ permission mask on old ACLs, and it
  doesn't deny access to SYSTEM and Administrators group based on the
  value of MASK/CLASS_OBJ when creating the new ACLs.

  The new code now handles the S_ISGID bit on directories as on Linux:
  Setting S_ISGID on a directory causes new files and subdirs created
  within to inherit its group, rather than the primary group of the user
  who created the file.  This only works for files and directories
  created by Cygwin processes.

- New mount type "usertemp" which allows to mount a POSIX directory to
  the Windows per-user temporary directory.

- cygpath has a new -U option, which creates cygdrive paths using the
  unambiguous /proc/cygdrive prefix.

- New API: rpmatch.


What changed:
-

- Align setfacl(1) usage a bit closer to the usage on Linux.  Rename -d option
  to -x, --substitute to --set.  Add --no-mask and --mask options.  Allow to
  use the -b and -k option combined to allow reducing an ACL to only reflect
  standard POSIX permissions.

- Fix (numeric and monetary) decimal point and thousands separator in
  fa_IR and ps_AF locales to be aligned with Linux.

- utmpname/utmpxname are now defined as int functions as on Linux.
  Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00320.html


Bug Fixes
-

- Not a bug fix as such, but a workaround for new behaviour in Windows 10
  version 1511 64 bit.  This version introduces a problem which existed in
  a similar variation (just vice versa) in XP and Server 2003 64 bit as well.
  An unexpected stack arrangement when starting a 64 bit Cygwin application
  from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork.
  Addresses: https://cygwin.com/ml/cygwin/2015-12/msg3.html

- Replaced old, buggy strtold implementation with well-tested gdtoa version
  from David M. Gay.
  Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00205.html

- Fix handling of relative paths in native symlinks if the target is in a
  drive's root dir or one level below.
  Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00277.html

- Fix a SEGV when calling `kill -l 0'.
  Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00430.html

- Fix a race condition in signal handling.
  Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00387.html

- Fix a potential crash reading invalid passwd and group entries from
  /etc/passwd and /etc/group.
  Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00170.html

- Cygpath(1) now tries to correct the case of system directories when
  returned as POSIX paths.
  Addresses: https://cygwin.com/ml/cygwin/2016-01/msg2.html

- *Always* zero out descriptor arrays when returning from select due to
  timeout, per POSIX.
  Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00332.html

- Return unique inode numbers when calling stat/fstat on pipes and IP sockets.
  Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00310.html


Have fun,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Windows XP Support

[Corinna Vinschen]

On Jan 11 09:25, Warren Young wrote:
> On Jan 11, 2016, at 4:52 AM, Corinna Vinschen  
> wrote:
> > 
> > Continuing support for XP and Server 2003 is really becoming a
> > burden.  It requires to code and maintain workarounds which are not
> > required anymore in newer OSes, so I really would like to get rid of
> > that stuff.
> 
> I seem to recall you saying that Vista added a fork-like facility to
> the kernel which might let Cygwin implement a copy-on-write fork(2).
> Would dropping XP support allow that?

Unfortunately not.  Effectively I begged for it on the Windows MSDN
forums and in private communication with Microsoft, but to no avail
for technical reasons.

The fork-like function (called RtlCloneUserProcess) does not work
reliably with Win32 processes.  The problem is not the function itself,
but the way certain Win32 DLLs are initialized at startup.  The DLL
initialization code won't do the right thing anymore in the child
process and thus stuff doesn't work in the child.  E.g., the connection
to the console Window is broken in the child and no AllocConsole or
AttachConsole call will resurrect it.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Windows XP Support

[cyg Simple]

On 1/11/2016 12:05 PM, Erik Soderquist wrote:
> On Sun, Jan 10, 2016 at 6:52 PM, Juan Miguel Navarro Martínez wrote:
>> No software version can live forever, ... 
> 
> Personally, I have to disagree with this statement, or at least offer
> an amendment...
> 
> I have some things still running in DOS 5 in a virtual machine because
> that is the most effective environment to run them in, and I don't
> expect any future OS to change that.  Does this mean I have these
> accessible to the outside world?  Absolutely not.  So while I do see
> use cases for very long outdated packages, I will also agree these use
> cases are not mainstream by any means, and if your use case does
> warrant an old package, appropriate measures to isolate the old
> packages also need to be taken.
> 

Arguments like this is the reason I had to spend years searching through
COBOL code for 2 digit years.  Old habits seem hard to die.  Either
upgrade or forever pay the penalty yourself to keep the old code running.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple