Re: kernel32.dll breakage (was Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1)
On Aug 21 19:04, Chris Sutcliffe wrote: On 21/08/2010 3:47 PM, Chris Sutcliffe wrote: On 21/08/2010 3:35 PM, Corinna Vinschen wrote: Chris [Sutcliffe], can we please revert this change for now? It breaks building Win32 apps, if the link order prefers kernel32.a over advapi32.a. Done. Thanks. Are you sure that only CreateProcessAsUserW is affected? In a word, no. I'll have to go through the file function by function checking against the other def files.. sigh. Thanks to power of Cygwin and shell scripting, I've created a script that I will be checking in to w32api (CheckConflicts.sh) that executes a brute force check of the contents of one file against the contents of another. Simple but hopefully affective. Nice :) Corina -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
On Aug 22 10:57, Angelo Graziosi wrote: Larry Hall wrote: Corinna Vinschen wrote: - Improve performance of stat and a few other functions. ls(1) should be up to 30% faster I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'. When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files. Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects. The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM. Try a recent snapshot: http://cygwin.com/snapshots/ I have tried cygwin1-20100822.dll.bz2, but same results. :( The first time (no cache 'effects') I do $ time ls -lrt /usr/bin the results are: CYGWIN_NT-5.1 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin time ls -lrt /usr/bin real0m16.531s user0m0.108s sys 0m0.421s CYGWIN_NT-5.1 1.7.6(0.230/5/3) 2010-08-16 16:06 i686 Cygwin real1m3.171s user0m0.155s sys 0m0.702s CYGWIN_NT-5.1 1.7.6s(0.231/5/3) 20100822 02:25:11 i686 Cygwin real1m4.218s user0m0.280s sys 0m0.609s I can't reproduce such a problem and I don't have AVG9 (virus scanner?). The effect is unfortunate, but the only important thing which has changed in 1.7.6 in terms of readdir and stat is the fact that the code tries to reduce the number of NtCreateFile/NtOpenFile calls by reusing a handle already opened on the file or directory before. I don't know what Cygwin can do about it, other than dropping the speedup entirely. Always assuming this is the real cause. There's no good reason that AVG9 hangs on anything Cygwin opens at all. There are only *very* few cases in which a handle is opened without allowing to share the file, and if so, it's never doing that for longer than the respective function call. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
Corinna Vinschen wrote: I can't reproduce such a problem and I don't have AVG9 (virus scanner?). Am I indiscreet if I ask you what AV are you using? Just a curiosity... Anyway thanks for clarification. Ciao, Angelo. -- 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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
Larry Hall wrote: Corinna Vinschen wrote: - Improve performance of stat and a few other functions. ls(1) should be up to 30% faster I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'. When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files. Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects. The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM. Try a recent snapshot: http://cygwin.com/snapshots/ I have tried cygwin1-20100822.dll.bz2, but same results. :( The first time (no cache 'effects') I do $ time ls -lrt /usr/bin the results are: CYGWIN_NT-5.1 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin time ls -lrt /usr/bin real0m16.531s user0m0.108s sys 0m0.421s CYGWIN_NT-5.1 1.7.6(0.230/5/3) 2010-08-16 16:06 i686 Cygwin real1m3.171s user0m0.155s sys 0m0.702s CYGWIN_NT-5.1 1.7.6s(0.231/5/3) 20100822 02:25:11 i686 Cygwin real1m4.218s user0m0.280s sys 0m0.609s Ciao, Angelo. -- 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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
On 8/20/2010 8:56 PM, Angelo Graziosi wrote: Corinna Vinschen wrote: - Improve performance of stat and a few other functions. ls(1) should be up to 30% faster I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'. When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files. Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects. The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM. Try a recent snapshot: http://cygwin.com/snapshots/ -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
Larry Hall wrote: Corinna Vinschen wrote: - Improve performance of stat and a few other functions. ls(1) should be up to 30% faster I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'. When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files. Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects. The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM. Try a recent snapshot: http://cygwin.com/snapshots/ I have tried cygwin1-20100820.dll.bz2 and cygwin-inst-20100820.tar.bz2, but it is even worse: Cygwin.bat DOES NOT start at all and Windows complains with a message like this: ...Cannot find entry point CreateProcessAsUserW in KERNEL32.DLL... So I have tried with the DLL suggested by Corinna in [*]: Cygwin.bat starts, but it shows the same problems I am flagging. Ciao, Angelo. --- [*] http://cygwin.com/ml/cygwin/2010-08/msg00630.html -- 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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
On Aug 21 14:18, Angelo Graziosi wrote: Larry Hall wrote: Corinna Vinschen wrote: - Improve performance of stat and a few other functions. ls(1) should be up to 30% faster I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'. When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files. Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects. The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM. Try a recent snapshot: http://cygwin.com/snapshots/ I have tried cygwin1-20100820.dll.bz2 and cygwin-inst-20100820.tar.bz2, but it is even worse: Cygwin.bat DOES NOT start at all and Windows complains with a message like this: ...Cannot find entry point CreateProcessAsUserW in KERNEL32.DLL... The problem is, there *is* an entry point CreateProcessAsUserW in the Win32 DLL kernel32.dll. At least on NT-based systems. What strikes me as weird is that kernel32.dll usually is stored with its name in all lowercase letters on NT-based systems. The fact that you see an all uppercase KERNEL32.DLL looks like you have such a DLL in your path, possible from Windows 95/98/Me, possibly installed by some third party stuff, at some point which is found earlier in the DLL search path than the lowercase kernel32.dll in C:\Windows\System32. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
On Aug 21 15:48, Corinna Vinschen wrote: On Aug 21 14:18, Angelo Graziosi wrote: Larry Hall wrote: Corinna Vinschen wrote: - Improve performance of stat and a few other functions. ls(1) should be up to 30% faster I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'. When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files. Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects. The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM. Try a recent snapshot: http://cygwin.com/snapshots/ I have tried cygwin1-20100820.dll.bz2 and cygwin-inst-20100820.tar.bz2, but it is even worse: Cygwin.bat DOES NOT start at all and Windows complains with a message like this: ...Cannot find entry point CreateProcessAsUserW in KERNEL32.DLL... The problem is, there *is* an entry point CreateProcessAsUserW in the Win32 DLL kernel32.dll. At least on NT-based systems. What strikes me as weird is that kernel32.dll usually is stored with its name in all lowercase letters on NT-based systems. The fact that you see an all uppercase KERNEL32.DLL looks like you have such a DLL in your path, possible from Windows 95/98/Me, possibly installed by some third party stuff, at some point which is found earlier in the DLL search path than the lowercase kernel32.dll in C:\Windows\System32. Oh, and, the call to CreateProcessAsUserW in cygwin1.dll is *old*, as in May 2008. The former call to CreateProcessAsUserA is in Cygwin for over 10 years. However, just to be sure I installed the cygwin1-20100820 snapshot DLL on my W7 box and it works fine. This is quite certainly a local problem. Btw., after downloading cygwin1-20100820.dll.bz2 and bunzipping it, did you make sure the executable bits are set (chmod +x cygwin1-20100820.dll)? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
Corinna Vinschen wrote:
Btw., after downloading cygwin1-20100820.dll.bz2 and bunzipping it, did
you make sure the executable bits are set (chmod +x cygwin1-20100820.dll)?
Obviously, it is the first thing I thought and checked. To summarize, I
did the following:
wget http://cygwin.com/snapshots/cygwin1-20100820.dll.bz2
bunzip2 cygwin1-20100820.dll.bz2
chmod +x cygwin1-20100820.dll
and the same for 20100814, 20100816, 20100818 snapshots, and for the DLL
you propose here
http://cygwin.com/ml/cygwin/2010-08/msg00630.html
Then from a DOS box (but also with Explorer)
cd \cygwin-2\bin
rename cygwin1.dll cygwin1.dll.orig
copy ..\tmp\cygwin1-20100814.dll cygwin1.dll
...
With 20100814, 20100816, 20100818 snapshots and newer-cygwin1.dll,
Cygwin.bat starts and works.
With 20100820 snapshot Cygwin.bat does not start and Windows says
(literally):
Impossibile trovare il punto d'ingresso CreateProcessAsUserW della
procedura nella libreria di collegamento dinamico KERNEL32.dll
which Google translates as
Can not find entry point CreateProcessAsUserW procedure in the dynamic
link library KERNEL32.dll
As you can see a mystery...
The fact that you see an all uppercase KERNEL32.DLL
looks like you have such a DLL in your path, possible from Windows
95/98/Me, possibly installed by some third party stuff, at some point
which is found earlier in the DLL search path than the lowercase
kernel32.dll in C:\Windows\System32.
Really the Windows messages says 'KERNEL32.dll' with 'dll' in lowercase,
and beside this, searching ('all directories visible') 'kernl32', I find
this:
--+ 1 root Nessuno 1028608 16 apr 2007
/WinXP/WINDOWS/$NtServicePackUninstall$/kernel32.dll
-rwxrwx---+ 1 Administrators SYSTEM 1033728 21 mar 2009
/WinXP/WINDOWS/system32/kernel32.dll
-rwx--+ 1 root Nessuno 1033728 14 apr 2008
/WinXP/WINDOWS/ServicePackFiles/i386/kernel32.dll
-rwx--+ 1 root Nessuno 1033728 21 mar 2009
/WinXP/WINDOWS/system32/dllcache/kernel32.dll
rwx---+ 1 root SYSTEM 1029120 5 lug 2006
/WinXP/WINDOWS/$hf_mig$/KB917422/SP2QFE/kernel32.dll
--+ 1 root Nessuno 1030144 16 apr 2007
/WinXP/WINDOWS/$hf_mig$/KB935839/SP2QFE/kernel32.dll
--+ 1 root Nessuno 1035776 21 mar 2009
/WinXP/WINDOWS/$hf_mig$/KB959426/SP3QFE/kernel32.dll
(WinXP is a symlink to /cygdrive/c)
Thanks,
Angelo.
--
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
kernel32.dll breakage (was Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1)
On Aug 21 18:04, Angelo Graziosi wrote: wget http://cygwin.com/snapshots/cygwin1-20100820.dll.bz2 bunzip2 cygwin1-20100820.dll.bz2 chmod +x cygwin1-20100820.dll [...] With 20100820 snapshot Cygwin.bat does not start and Windows says (literally): [...] Can not find entry point CreateProcessAsUserW procedure in the dynamic link library KERNEL32.dll As you can see a mystery... Not anymore. I could reproduce the problem on XP, but not on W7. This reminded me of a checkin to w32api from yesterday. The kernel32.def file, which is used to create the kernel32.a inport library for linking against kernel32.dll has been regenerated on a Windows 7 system. The problem is that CreateProcessAsUserW was never available in kernel32.dll, but in advapi32.dll(*). However, with the new kernel32.def, CreateProcessAsUserW is now exported by kernel32.a as well. Apparently kernel32.dll *does* export CreateProcessAsUserW now under Windows 7. However, *officially*, the CreateProcessAsUserW symbol is still provided by advapi32.dll. Chris [Sutcliffe], can we please revert this change for now? It breaks building Win32 apps, if the link order prefers kernel32.a over advapi32.a. In theory, shouldn't the gendef script drop symbols from kernel32.def which are defined in advapi32.dll? That would fix the problem, afaics. As for Cygwin, apparently we can workaround this issue by simply changing the link order in our Makefile. I checked in a matching patch, which fixes this issue for me on old systems like Windows XP. Please test the next developers snapshot. Corinna (*) Yes, I talked nonsense in my previous reply. advapi32, not kernel32. I should have seen the discrepancy immediately. Sorry about that! -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: kernel32.dll breakage (was Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1)
On 21/08/2010 2:58 PM, Corinna Vinschen wrote: Not anymore. I could reproduce the problem on XP, but not on W7. This reminded me of a checkin to w32api from yesterday. The kernel32.def file, which is used to create the kernel32.a inport library for linking against kernel32.dll has been regenerated on a Windows 7 system. The problem is that CreateProcessAsUserW was never available in kernel32.dll, but in advapi32.dll(*). However, with the new kernel32.def, CreateProcessAsUserW is now exported by kernel32.a as well. Apparently kernel32.dll *does* export CreateProcessAsUserW now under Windows 7. However, *officially*, the CreateProcessAsUserW symbol is still provided by advapi32.dll. Chris [Sutcliffe], can we please revert this change for now? It breaks building Win32 apps, if the link order prefers kernel32.a over advapi32.a. Done. In theory, shouldn't the gendef script drop symbols from kernel32.def which are defined in advapi32.dll? That would fix the problem, afaics. That would be ideal, but I'm not sure what the capabilities of gendef are in this respect. Cheers! 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
Re: kernel32.dll breakage (was Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1)
On Aug 21 15:23, Chris Sutcliffe wrote: On 21/08/2010 2:58 PM, Corinna Vinschen wrote: Not anymore. I could reproduce the problem on XP, but not on W7. This reminded me of a checkin to w32api from yesterday. The kernel32.def file, which is used to create the kernel32.a inport library for linking against kernel32.dll has been regenerated on a Windows 7 system. The problem is that CreateProcessAsUserW was never available in kernel32.dll, but in advapi32.dll(*). However, with the new kernel32.def, CreateProcessAsUserW is now exported by kernel32.a as well. Apparently kernel32.dll *does* export CreateProcessAsUserW now under Windows 7. However, *officially*, the CreateProcessAsUserW symbol is still provided by advapi32.dll. Chris [Sutcliffe], can we please revert this change for now? It breaks building Win32 apps, if the link order prefers kernel32.a over advapi32.a. Done. Thanks. Are you sure that only CreateProcessAsUserW is affected? In theory, shouldn't the gendef script drop symbols from kernel32.def which are defined in advapi32.dll? That would fix the problem, afaics. That would be ideal, but I'm not sure what the capabilities of gendef are in this respect. I'm curious, where is that gendef script? For some reason it isn't part of the w32api sources in CVS. Wouldn't it make sense to check it in as well? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: kernel32.dll breakage (was Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1)
On 21/08/2010 3:35 PM, Corinna Vinschen wrote: Chris [Sutcliffe], can we please revert this change for now? It breaks building Win32 apps, if the link order prefers kernel32.a over advapi32.a. Done. Thanks. Are you sure that only CreateProcessAsUserW is affected? In a word, no. I'll have to go through the file function by function checking against the other def files.. sigh. In theory, shouldn't the gendef script drop symbols from kernel32.def which are defined in advapi32.dll? That would fix the problem, afaics. That would be ideal, but I'm not sure what the capabilities of gendef are in this respect. I'm curious, where is that gendef script? For some reason it isn't part of the w32api sources in CVS. Wouldn't it make sense to check it in as well? Nope, it's already part of Cygwin: http://cygwin.com/cgi-bin2/package-cat.cgi?file=gendef%2Fgendef-1.0-svn2931-1grep=gendef.exe Cheers! 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
Re: kernel32.dll breakage (was Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1)
On Aug 21 15:47, Chris Sutcliffe wrote: On 21/08/2010 3:35 PM, Corinna Vinschen wrote: Chris [Sutcliffe], can we please revert this change for now? It breaks building Win32 apps, if the link order prefers kernel32.a over advapi32.a. Done. Thanks. Are you sure that only CreateProcessAsUserW is affected? In a word, no. I'll have to go through the file function by function checking against the other def files.. sigh. In theory, shouldn't the gendef script drop symbols from kernel32.def which are defined in advapi32.dll? That would fix the problem, afaics. That would be ideal, but I'm not sure what the capabilities of gendef are in this respect. I'm curious, where is that gendef script? For some reason it isn't part of the w32api sources in CVS. Wouldn't it make sense to check it in as well? Nope, it's already part of Cygwin: http://cygwin.com/cgi-bin2/package-cat.cgi?file=gendef%2Fgendef-1.0-svn2931-1grep=gendef.exe Uh, *that* gendef. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: kernel32.dll breakage (was Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1)
On 21/08/2010 3:47 PM, Chris Sutcliffe wrote: On 21/08/2010 3:35 PM, Corinna Vinschen wrote: Chris [Sutcliffe], can we please revert this change for now? It breaks building Win32 apps, if the link order prefers kernel32.a over advapi32.a. Done. Thanks. Are you sure that only CreateProcessAsUserW is affected? In a word, no. I'll have to go through the file function by function checking against the other def files.. sigh. Thanks to power of Cygwin and shell scripting, I've created a script that I will be checking in to w32api (CheckConflicts.sh) that executes a brute force check of the contents of one file against the contents of another. Simple but hopefully affective. Cheers! 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
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
Corinna Vinschen wrote: - Improve performance of stat and a few other functions. ls(1) should be up to 30% faster I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'. When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files. Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects. The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM. Ciao, Angelo. -- 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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
On Aug 18 22:00, Buchbinder, Barry (NIH/NIAID) [E] wrote: Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:16 AM What changed since Cygwin 1.7.5: - Cygwin handles the current working directory entirely on its own. The Win32 current working directory is set to an invalid path to be out of the way. This affects calls to the Win32 file API (CreateFile, etc.). See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api ^ In case you ever copy and paste the link, htdocs/ needs to be deleted for it to work. Ouch! Thank you for the hint. Actually that htdocs is a part of the URL to the Cygwin docs on my private web server. I hope I don't screw up again in the next announcement... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:16 AM What changed since Cygwin 1.7.5: - Cygwin handles the current working directory entirely on its own. The Win32 current working directory is set to an invalid path to be out of the way. This affects calls to the Win32 file API (CreateFile, etc.). See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api ^ In case you ever copy and paste the link, htdocs/ needs to be deleted for it to work. Thanks for all you do for the cygwin community. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
[ANNOUNCEMENT] Updated: cygwin-1.7.6-1
Hi Cygwin friends and users, I just released 1.7.6-1. This release fixes a bunch of bugs, and introduces a few new features. It also contains a change which will affect calling native Win32 API functions from Cygwin applications. I would like to urge you to have another look into the documentation at http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html. It contains a couple of improvements and the description for new features and changes from old behaviour. What's new since Cygwin 1.7.5: == - Add new mount options dos and ihash to allow overriding Cygwin default behaviour on broken filesystems not recognized by Cygwin. See http://cygwin.com/cygwin-ug-net/using.html#mount-table and http://cygwin.com/cygwin-ug-net/using-utils.html#mount - Add new mount option bind to allow remounting parts of the POSIX file hirarchy somewhere else. See http://cygwin.com/cygwin-ug-net/using.html#mount-table and http://cygwin.com/cygwin-ug-net/using-utils.html#mount - Ttys and ptys are handled as securable objects using file-like permissions and owner/group information. chmod and chown now work on ttys/ptys. A new mechanism is used to propagate pty handles safely to other processes, which does not require to use Cygserver. - Pass on coresize settings made with setrlimit(2). This allows shells to disable creating stackdump files in child processes via `ulimit -c 0' in bash or `limit coredumpsize 0' in tcsh. - Locale categories contain all localization strings additionally as wide-char strings. locale(1) prints these values just as on Linux. nl_langinfo(3) allows to fetch them. See file:///usr/include/langinfo.h - New interfaces mkostemp(3) and mkostemps(3). See file:///usr/include/stdlib.h - New virtual file /proc/filesystems. - clock_gettime(3) and clock_getres(3) accept CLOCK_MONOTONIC. - Several small additions to header files. What changed since Cygwin 1.7.5: - Cygwin handles the current working directory entirely on its own. The Win32 current working directory is set to an invalid path to be out of the way. This affects calls to the Win32 file API (CreateFile, etc.). See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api - Change the way a process is made process group leader in case we're started from a non-Cygwin process. This isn't foolproof and may need more work. - Workaround a BLODA problem in rename(2) which otherwise results in annoying errors. - Add more workarounds for broken filesystems which either don't grok reopening a file by handle (NWFS) or which are not capable of handling filenames with leading spaces or trailing dots or spaces (NWFS, Netapp). - Don't try to evaluate reparse points (junctions) on remote filesystems as symlinks. - Improve performance of stat and a few other functions. ls(1) should be up to 30% faster on some drives. - Speed up signal delivery slightly. - Improve error output in strace. - cygwin_conv_path now drops the \\?\ prefix from short paths it returns with CCP_POSIX_TO_WIN_W. Bugfixes since Cygwin 1.7.5: - Fix problem where pseudo-relocs were getting applied twice, resulting in a crash. - Fix a crash when accessing /proc/registry* - Avoid that connect on a not yet established AF_LOCAL/AF_UNIX socket misinterprets the socket file as non-socket. - Fix stdin/out/err handle permissions when called from a non-Cygwin process. - Fix codeset problem in internal handling of process name. - Fix abbreviated month names for japanese and korean locale. - Fix calls to gettimeofday after call to settimeofday. - Fix REG_MULTI_SZ handling in /proc/registry* - Honor cygwin username even if it only differs by case from Windows username. - Fix potential memory leak when accessing // or //server directories. - Fix using a wrong handle when checking for files inaccessible to current user. - Fix erroneous handling of devices in path checking. - Fix potential crash in exec(2) if parent uses file locking. - Return useful error code when writing beyond free space on disk. - Fix longstanding bug where pipe() would inappropriately reuse open fd's. - Fix several signal races which caused SEGVs. - Fix long-standing bug when trying to open an already opened pipe via /proc/$PID/fd/... - Fix a potential crash when calling mount -a. - Fix bug in math functions lround(), llround(), lrint(), llrint(). Have fun, Corinna *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://cygwin.com/lists.html#unsubscribe-simple Please read *all* of the information
