Hold off any new binutils release for one more upstream patch? [was Re: [1.7] rebaseall doesn't solve the problem]
Corinna Vinschen wrote: If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? Well of course it's possible :) but looks like it would need a patch to ld. I'm going to be AFK most of this weekend, so please ping me Monday and I'll roll it up then. cheers, DaveK
Re: Hold off any new binutils release for one more upstream patch? [was Re: [1.7] rebaseall doesn't solve the problem]
On Feb 28 11:06, Dave Korn wrote: Corinna Vinschen wrote: If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? Well of course it's possible :) but looks like it would need a patch to ld. I'm going to be AFK most of this weekend, so please ping me Monday and I'll roll it up then. No worris, I have to test that first, anyway :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Uploading gcc-3.4.4-999 now.
The package is ready to go, so I'm uploading and announcing it now; gcc-4 alternatives will then drop right into place when 4.3.2-2 is ready. In case there are problems I'm going to leave 3.4.4-3 as prev:, but after a little while I'll remove it and revert to having 3.3.3-3 as prev, as currently. cheers, DaveK
Re: -query not working on cygwin/windows
km4hr writes: At cygwin shell prompt I enter netstat -na |grep 600* I get this: UDP0.0.0.0:6000 *:* UDP0.0.0.0:6001 *:* UDP0.0.0.0:6002 *:* ..etc.. netstat -na | grep 177 returns nothing. I get the above responses whether my Windows firewall is on or off. Also, why does netstat say UDP in the above responses? I specifically enabled these ports as TCP in the Windows firewall configuration screen. I configured port 177 just like ports 6000-6005. But it never shows up in netstat -na. Why? If you're OK with turning off Windows Firewall, do that, to remove one potential area of networking conflict. Leave it off until you get things working and then add it back in afterwards. Having the Firewall open a port just means that some program on your PC trying to listen on that port will actually receive traffic from the network. If the port is closed the program might be able to listen on that port but it won't receive anything because the Firewall has blocked the traffic to it. Netstat is showing you something different: the ports that are currently being listened on by running programs. Use the '-o' option to netstat to have it print the Windows pids of the listening programs. E.g., 'netstat -ano'. Sometimes Cygwin pids are different from Windows pids for reasons not important here. Use the Windows Task Manager to identify Cygwin processes from Windows pids if necessary. I don't know why your netstat display shows UDP. If I were to speculate, I'd say you mistakenly enabled UDP rather than TCP in the Firewall and the X Server was able to open listening sockets for UDP datagrams. There's no 177 in your netstat display because there probably isn't any program currently running to listen on that port. Do you have to start xdmcp manually? I don't know how that works. I just know that I see TCP for ports 6000 and up when I run the Cygwin X server. ..mark -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server causing IE lockups
But I have put this on the back-back burner for now. My work-around is to only use X for when I need gnuplot and then I exit from X. I have just disabled the clipboard transfer for TightVNC and it seems I have no more issue. F. Bron -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [1.7] Editing in /etc
Looks like it's related to some issue reading stdin... I executed vim
in debug mode ('vim -D passwd') and got the following:
Fixed... I messed up the permissions in my /dev directory.
Sorry for the noise.
Chris
--
Chris Sutcliffe
http://emergedesktop.org
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [1.7] rebaseall doesn't solve the problem
On Feb 27 16:21, Charles Wilson wrote: Corinna Vinschen wrote: [...] I'm wondering if that's a result of ASLR in Vista. The document http://taossa.com.nyud.net:8080/archive/bh08sotirovdowd.pdf [...] [...] If so, there's nothing Cygwin can do against that. In the long run, only a native fork() implementation would help. Well, maybe not! From the document you referenced: Since Windows relies on relocations instead of position independent code, a DLL must be loaded at the same address in each process that uses it to allow the physical memory used by the DLL to be shared. To facilitate this behaviour, a global bitmap called _MiImageBitMap is used to represent the address space from 0x5000 to 0x7800. The bitmap is 0x2800 bits in length with each bit representing 64KB of memory. As each DLL is loaded, its position is recorded by setting the appropriate bits in the bitmap to mark the memory where the DLL is being mapped. When the same DLL is loaded in another process, its section object is reused and it is mapped at the same virtual addresses. So, by marking a particular (or all but cygwin1.dll?) DLL as ASLR-compatibile, we may be able to coerce the Windows runtime loader into ensuring that the DLLs are loaded at the same memory location for all concurrent processes (unless the parent has filled up the space from 0x5000 to 0x7800, and so is forced to put an ASLR-compatible DLL somewhere else that is not tracked by _MiImageBitMap). I wrote a little utility to explicitly mark a DLL as ASLR-compatible. Using it on Cwd.dll -- the offending one in my situation -- I was able to eliminate the problem! Way cool, Chuck. Especially the fact that this tool can also mark executables with the TS-aware flag (doesn't make sense for DLLs, afaik). This helps to test if setting this flag in Cygwin binaries will allow Cygwin to run on 2008 with TS without disabling DEP. If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? That would also allow to drop the ugly TS hack I added to Cygwin 1.7. All newly built binaries would have the flag set already, and older binaries could be tweaked with the aslr utility. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Info about OS by command in Cygwin
Hello, by which Cygwin/bash command can I get detailed information about the Operating System, e. g. about the Windows version (XP? SP?)? Trying with the Windows command ver I've got the error -bash: ver: command not found. Thomas Wiedmann -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Info about OS by command in Cygwin
Thomas Wiedmann wrote: by which Cygwin/bash command can I get detailed information about the Operating System, e. g. about the Windows version (XP? SP?)? Trying with the Windows command ver I've got the error -bash: ver: command not found. 'uname' and '/proc/version' show the Windows version number (NT-5.0=2000, 5.1=XP, 5.2=2003, 6.0=Vista) but not the SP version. The 'ver' is a cmd.exe builtin command and can also be run from bash: $ uname CYGWIN_NT-5.1 $ cat /proc/version CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2008-06-12 19:34 $ cmd /c ver Microsoft Windows XP [Version 5.1.2600] Hope this helps, Christian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Editing in /etc
Chris wrote: Fixed... I messed up the permissions in my /dev directory. There may be issues with editing some files in /etc... I think of /etc/hosts, OK... a symlink to a Windows file. Editing it, you have to be careful with preserving its ownership (including group) and permissions from the Windows point of view. I have been using the cygwin tools from a Windows Admin cmd: c:\cygwin\bin\chown SYSTEM:SYSTEM hosts c:\cygwin\bin\getfacl hosts.bak | c:\cygwin\bin\setfacl -f - hosts Marc -- View this message in context: http://www.nabble.com/-1.7--Editing-in--etc-tp22257197p22261804.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] End-of-life/Updated: gcc-3.4.4-999
A new release of gcc, version 3.4.4-999, has been uploaded to sourceware.org, and will appear on your local mirror after it next refreshes. The old GCC-3.4.4 compiler has reached end of life, and is being retired. This is the final release of GCC series 3 on Cygwin; future development will focus on GCC-4 on Cygwin-1.7. To aid with backward-compatibility, the old compiler is being retained, but will be demoted from system default, and GCC-4 promoted. The purpose of this release is to move the compiler into its legacy status. This release is a straight rebuild from source of the existing gcc-3.4.4-3, with no source modifications, but with packaging script changes to enable 'alternatives' switching between the use of GCC-3 and GCC-4. The scripts will install alternatives switching for GCC-3, but still leave it as the system default, so no change in behaviour should be seen. The next release of GCC-4 will install alternatives groups for GCC-4, and switch it to be the system default compiler. --ooOOOoo-- PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST. --ooOOOoo-- OBTAINING THE RELEASE = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup.exe, fill in all of the options, and make appropriate choices on the Select Packages screen. Because this is a full current version release, any gcc packages you currently have installed will be automatically selected to update, but you'll need to select the Devel category to see gcc and friends if you don't have them already installed. NEWS From the README: -- version 3.4.4-999 --- 2009-02-28 * Final release ever of Cygwin series 3 GCC. Release bumped to ridiculously high number to indicate end-of-line. * Functionally identical to 3.4.4-3, but repackaged to use alternatives system, and synchronised with new release of version 4 also using alternatives system, to work around GNAT failure to respect --program-suffix, and allow easy co-installation and default selection of either version. -- version 3.4.4-3 --- 2006-09-25 * Promoted experimental release to current. * Implemented workaround for g77 library installation bug (PR17725/PR17726/PR21792). -- version 3.4.4-2 --- 2006-07-20 * Experimental release of gcc-3.4.4-2 to fix PR24196, which has been causing problems passing std::string instances to dlls. Implemented the patch by Paolo Carlini rather than using --enable-fully-dynamic-string. * Restored and updated GNU Pascal, but highly experimental and not seriously tested yet. * Updated build script, but one problem remains: /usr/src must be mounted in managed mode when setup.exe is used to install the sources, or they must be copied from there to a managed directory before building. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] rebaseall doesn't solve the problem
Corinna Vinschen wrote: Way cool, Chuck. Especially the fact that this tool can also mark executables with the TS-aware flag (doesn't make sense for DLLs, afaik). This helps to test if setting this flag in Cygwin binaries will allow Cygwin to run on 2008 with TS without disabling DEP. Well, the tool would need a little tweaking I think. Right now it skips any image (DLL or exe) that does not contain relocations. If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2), so we can get aslr integerated into rebase, and the rebaseall changes tested. Should I also add a switch to rebaseall that means: ONLY alsr, NO rebasing. There's already a flag that allows you to add .exe's to the rebase list -- but you can't remove dll's and .so's from the list. Maybe the aslr functionality is different enough -- and useful in enough contexts that differ from rebasing -- that instead of incorporating 'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script? That would also allow to drop the ugly TS hack I added to Cygwin 1.7. All newly built binaries would have the flag set already, and older binaries could be tweaked with the aslr utility. That would be nice. However, ONLY exe's linked with cygwin1.dll should be marked this way, right? Not cygcheck, strace, and whatever other few exes we might find in the cygwin installation lists. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Info about OS by command in Cygwin
Christian Franke wrote: 'uname' and '/proc/version' show the Windows version number (NT-5.0=2000, 5.1=XP, 5.2=2003, 6.0=Vista) but not the SP version. The 'ver' is a cmd.exe builtin command and can also be run from bash: Also, /usr/lib/csih/winProductName.exe (Note that this is technically a native, not cygwin, application, so you need to strip '\r' from the result if you're using it in a script). I probably need to update it to recognize the new Windows 7 codes... -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] rebaseall doesn't solve the problem
On 2/28/09, Charles Wilson wrote: Maybe the aslr functionality is different enough -- and useful in enough contexts that differ from rebasing -- that instead of incorporating 'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script? +1 for that suggestion. It's doing something completely different. It will only work on systems with ASLR, which IIUC excludes XP SP1 and 2000. Even where it will work, rebasing might still be required if there are too many DLLs for _MiImageBitMap to track them all. Where it does work completely, the rebasing part of rebaseall should be unneeded, right? All of that seems to speak to a desire to have it available as a separate script, though maybe having a flag for rebaseall to call that script would be useful. Hope I didn't misunderstand any of this discussion... :-) ~Matt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] rebaseall doesn't solve the problem
On Sat, Feb 28, 2009 at 01:47:16PM -0500, Charles Wilson wrote: Corinna Vinschen wrote: Way cool, Chuck. Especially the fact that this tool can also mark executables with the TS-aware flag (doesn't make sense for DLLs, afaik). This helps to test if setting this flag in Cygwin binaries will allow Cygwin to run on 2008 with TS without disabling DEP. Well, the tool would need a little tweaking I think. Right now it skips any image (DLL or exe) that does not contain relocations. If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2), so we can get aslr integerated into rebase, and the rebaseall changes tested. Should I also add a switch to rebaseall that means: ONLY alsr, NO rebasing. There's already a flag that allows you to add .exe's to the rebase list -- but you can't remove dll's and .so's from the list. Maybe the aslr functionality is different enough -- and useful in enough contexts that differ from rebasing -- that instead of incorporating 'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script? It should be trivial to add this to binutils. Doesn't it ultimately belong in ld and (maybe) objcopy? I can add this now but I don't think it should be the default just yet. That would also allow to drop the ugly TS hack I added to Cygwin 1.7. All newly built binaries would have the flag set already, and older binaries could be tweaked with the aslr utility. That would be nice. However, ONLY exe's linked with cygwin1.dll should be marked this way, right? Not cygcheck, strace, and whatever other few exes we might find in the cygwin installation lists. Do the exes themselves need this bit as well as the dlls? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] rebaseall doesn't solve the problem
Christopher Faylor wrote: It should be trivial to add this to binutils. Doesn't it ultimately belong in ld and (maybe) objcopy? Well, I'm sure it would be useful there. However, just as ld can create a DLL with a user-specified image base, yet we still have a separate special purpose utility for rebasing them, it makes sense that ld can create an exe or dll with a specific pe_dll_characteristics flag, but a separate single-purpose utility to modify it is also useful. I really don't want Q. Random User to try and run objcopy confusing options on his entire installation... I can add this now but I don't think it should be the default just yet. Agree. BTW, this was mentioned on the binutils list about two years ago, but nothing ever came of it: http://sourceware.org/ml/binutils/2007-02/msg00046.html Do the exes themselves need this bit as well as the dlls? From what I understand, ASLR makes sense for both DLLs and EXEs -- but only if the image has relocations (most DLLs, and PIE exectuables). TS-Aware makes sense only for EXEs according to Corinna. NX could be applied to any DLL or EXE (I think). My mistake in the existing alsr code was to always skip if no relocations -- so since we don't have PIE exes, you can't currently set the TS or NX flags on ordinary exes with the tool. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] rebaseall doesn't solve the problem
On Feb 28 13:47, Charles Wilson wrote: Corinna Vinschen wrote: Way cool, Chuck. Especially the fact that this tool can also mark executables with the TS-aware flag (doesn't make sense for DLLs, afaik). This helps to test if setting this flag in Cygwin binaries will allow Cygwin to run on 2008 with TS without disabling DEP. Well, the tool would need a little tweaking I think. Right now it skips any image (DLL or exe) that does not contain relocations. Uh, ok. In that case, yes, it needs some tweaking. Actually, maybe the tool should really be named differently. Something suggesting that it in general changes Win32-related PE/COFF header flags. ASLR and TS-aware are just some of them, in theory. If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2), so we can get aslr integerated into rebase, and the rebaseall changes tested. Yes, sure. I have to test if the TS-aware flag makes any difference on a 2K8 TS machine anyway. I think (and hope) that this flag will persuade tsappcmp.dll into igoring an executable instead of scrambling its page executable protection flags. If so, we should really set this flag in all applications. Well, not that I gave up the idea that Microsoft should fix that bug in tsappcmp.dll in the first place... Should I also add a switch to rebaseall that means: ONLY alsr, NO rebasing. There's already a flag that allows you to add .exe's to the rebase list -- but you can't remove dll's and .so's from the list. Makes sense to me. That would also allow to drop the ugly TS hack I added to Cygwin 1.7. All newly built binaries would have the flag set already, and older binaries could be tweaked with the aslr utility. That would be nice. However, ONLY exe's linked with cygwin1.dll should be marked this way, right? Not cygcheck, strace, and whatever other few exes we might find in the cygwin installation lists. Hmm, I'm not sure about that one. At least only EXEs should be marked TS-aware automatically. The flag has no meaning on DLLs, afaik. *Iff* the TS-aware flag helps to avoid tsappcmp.dll entirely, it's a big help in all cases. Cygwin applications are TS-aware by default anyway. If somebody actually manages to write a non-TS-aware Cygwin application, I'd say this guy should reset the TS-aware flag manually. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] rebaseall doesn't solve the problem
On Feb 28 14:51, Christopher Faylor wrote: On Sat, Feb 28, 2009 at 01:47:16PM -0500, Charles Wilson wrote: Corinna Vinschen wrote: If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2), [...] Maybe the aslr functionality is different enough -- and useful in enough contexts that differ from rebasing -- that instead of incorporating 'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script? It should be trivial to add this to binutils. Doesn't it ultimately belong in ld and (maybe) objcopy? Yes, that should be done in ld. I can add this now but I don't think it should be the default just yet. If the TS-aware flag actually helps to avoid the tsappcmp.dll bug, then I think the flag should be set by ld by default for Cygwin apps. That would be nice. However, ONLY exe's linked with cygwin1.dll should be marked this way, right? Not cygcheck, strace, and whatever other few exes we might find in the cygwin installation lists. Do the exes themselves need this bit as well as the dlls? Only exes require the TS-aware bit. Two interesting snippets from MSDN: http://msdn.microsoft.com/en-us/library/cc834995(VS.85).aspx http://msdn.microsoft.com/en-us/library/01cfys9z.aspx The first one actually explains that the overhead of loading a compatibility DLL can be avoided by using the TS-aware flag. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] rebaseall doesn't solve the problem
Corinna Vinschen wrote: Uh, ok. In that case, yes, it needs some tweaking. Actually, maybe the tool should really be named differently. Something suggesting that it in general changes Win32-related PE/COFF header flags. ASLR and TS-aware are just some of them, in theory. I'm open to suggestions. peimgflags? Currently, aslr only manipulates the OPT_IMG_HEADER:DllCharacteristics field (which is a misnomer, because some of the values apply to exe's). We might also want to be able to set IMAGE_FILE_AGGRESIVE_WS_TRIM in the IMAGE_FILE_HEADER:Characteristics field for things like sshd. As currently coded, it *appears* that neither rebase nor aslr adapt to the (slightly different) 64bit pe format. Actually, I think only rebase is affected by this, because the variations in the format occur past the OPT_IMG_HEADER:DllCharacteristics offset. I don't have a 64 bit machine to test on, so I'll have to pass on fixing the imagehelper library used by rebase... The differences are minor; larger field sizes for some values (and therefore different field offsets for values past them). Just compare and contrast IMAGE_OPTIONAL_HEADER32 and IMAGE_OPTIONAL_HEADER64 in w32api/winnt.h. From dlltool: /* NumberOfRvaAndSizes. */ #ifdef pe_use_x86_64 num_entries = pe_get32 (dll, opthdr_ofs + 92 + 4 * 4); #else num_entries = pe_get32 (dll, opthdr_ofs + 92); #endif #ifdef pe_use_x86_64 export_rva = pe_get32 (dll, opthdr_ofs + 96 + 4 * 4); export_size = pe_get32 (dll, opthdr_ofs + 100 + 4 * 4); #else export_rva = pe_get32 (dll, opthdr_ofs + 96); export_size = pe_get32 (dll, opthdr_ofs + 100); #endif but I don't think #ifdefs are the way to go. We want to be able to manipulate 64bit images on a 32bit machine, and vice versa -- based on the value of the IMAGE_FILE_HEADER:Machine field. IMAGE_FILE_MACHINE_I386 0x014c x86 IMAGE_FILE_MACHINE_IA64 0x0200 Itanium IMAGE_FILE_MACHINE_AMD640x8664 x64 Then again, maybe this isn't all that important, as the only 64-bit image we have is cyglsa64.dll -- and my patch to rebaseall forces it to skip that one anyway. Everything else in the cygwin distro is strictly 32 bits. I have to test if the TS-aware flag makes any difference on a 2K8 TS machine anyway. I think (and hope) that this flag will persuade tsappcmp.dll into igoring an executable instead of scrambling its page executable protection flags. If so, we should really set this flag in all applications. Well, not that I gave up the idea that Microsoft should fix that bug in tsappcmp.dll in the first place... Ha! Should I also add a switch to rebaseall that means: ONLY alsr, NO rebasing. There's already a flag that allows you to add .exe's to the rebase list -- but you can't remove dll's and .so's from the list. Makes sense to me. Or a separate aslrall (peimgflags(?)_all) script...it would share a lot of code with rebaseall, but it's not really all THAT big a script. The reason I didn't do that originally was I wanted to reuse the same (generated) filelist in each case. But, it seems that the flexibility in having aslrall(?) make its own file list -- which may include exe's as well as dll's -- is more important. That would also allow to drop the ugly TS hack I added to Cygwin 1.7. All newly built binaries would have the flag set already, and older binaries could be tweaked with the aslr utility. That would be nice. However, ONLY exe's linked with cygwin1.dll should be marked this way, right? Not cygcheck, strace, and whatever other few exes we might find in the cygwin installation lists. Hmm, I'm not sure about that one. At least only EXEs should be marked TS-aware automatically. The flag has no meaning on DLLs, afaik. *Iff* the TS-aware flag helps to avoid tsappcmp.dll entirely, it's a big help in all cases. Cygwin applications are TS-aware by default anyway. If somebody actually manages to write a non-TS-aware Cygwin application, I'd say this guy should reset the TS-aware flag manually. Oh, ok. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] rebaseall doesn't solve the problem
Corinna Vinschen wrote: Only exes require the TS-aware bit. Two interesting snippets from MSDN: http://msdn.microsoft.com/en-us/library/cc834995(VS.85).aspx But in order to set this flag without problems cropping up, you must satisfy: * The application does not run as a system service (that is, LUID=System). This probably isn't an issue for cygwin-1.7 and beyond, given the changes in how services are installed. (Dang, I need to release an updated csih...) * The application does not write to the HKEY Local Machine registry hive for user specific data or configuration. Hmm. regtool? /proc/registry? Either way, you lose. If we go one way, then you can't use regtool or /proc/registry to manipulate the virtualized registry entries, if you're trying to fix something related to a non-TS (windows) app. If we go the other way, then you can't use regtool or /proc/registry to manipulate the real non-virtualized registry. Ditto for virtualized vs. non-virtualized /Program\ Files, /Windows, etc. THERE's the reason to keep an old cygwin-1.5 installation laying around! g http://msdn.microsoft.com/en-us/library/01cfys9z.aspx /TSAWARE is not valid for drivers, VxDs, or DLLs. Yep, need to fix aslr.exe to not do that. Also, I think I might use aslr to set the flag on my copy of NotePad++. I hate having to install the syntax colorizer plugins into both my and admin's virtualized Program Files directory...for every update... -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
maximum number of concurrent network connections
Hello, I am trying to write a asynchronous server using python's asyncore/asynchat library and running it under cygwin. It runs perfectly for upto 353 concurrent hosts connected to it, but is unable to connect to anymore hosts trying to connect to it. Is there a limit on the number of concurrent sockets an application can have open? Am I hitting that limit, and if so is there a way of modifying this limit. This is on server 2008 with cygwin 1.7. I am happy to provide any other diagnostic information as needed. Thank you, Sameer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
End-of-life/Updated: gcc-3.4.4-999
A new release of gcc, version 3.4.4-999, has been uploaded to sourceware.org, and will appear on your local mirror after it next refreshes. The old GCC-3.4.4 compiler has reached end of life, and is being retired. This is the final release of GCC series 3 on Cygwin; future development will focus on GCC-4 on Cygwin-1.7. To aid with backward-compatibility, the old compiler is being retained, but will be demoted from system default, and GCC-4 promoted. The purpose of this release is to move the compiler into its legacy status. This release is a straight rebuild from source of the existing gcc-3.4.4-3, with no source modifications, but with packaging script changes to enable 'alternatives' switching between the use of GCC-3 and GCC-4. The scripts will install alternatives switching for GCC-3, but still leave it as the system default, so no change in behaviour should be seen. The next release of GCC-4 will install alternatives groups for GCC-4, and switch it to be the system default compiler. --ooOOOoo-- PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST. --ooOOOoo-- OBTAINING THE RELEASE = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup.exe, fill in all of the options, and make appropriate choices on the Select Packages screen. Because this is a full current version release, any gcc packages you currently have installed will be automatically selected to update, but you'll need to select the Devel category to see gcc and friends if you don't have them already installed. NEWS From the README: -- version 3.4.4-999 --- 2009-02-28 * Final release ever of Cygwin series 3 GCC. Release bumped to ridiculously high number to indicate end-of-line. * Functionally identical to 3.4.4-3, but repackaged to use alternatives system, and synchronised with new release of version 4 also using alternatives system, to work around GNAT failure to respect --program-suffix, and allow easy co-installation and default selection of either version. -- version 3.4.4-3 --- 2006-09-25 * Promoted experimental release to current. * Implemented workaround for g77 library installation bug (PR17725/PR17726/PR21792). -- version 3.4.4-2 --- 2006-07-20 * Experimental release of gcc-3.4.4-2 to fix PR24196, which has been causing problems passing std::string instances to dlls. Implemented the patch by Paolo Carlini rather than using --enable-fully-dynamic-string. * Restored and updated GNU Pascal, but highly experimental and not seriously tested yet. * Updated build script, but one problem remains: /usr/src must be mounted in managed mode when setup.exe is used to install the sources, or they must be copied from there to a managed directory before building. cheers, DaveK -- Can't think of a witty .sigline today
