Re: Hippo icon for cygwin...
On Sat, Dec 5, 2009 at 4:06 AM, Charles Wilson wrote: > for your enjoyment. It's based on public domain art; this version > released under a creative commons license (CC-BY-SA 3.0) which is GPL > compatible. > > If ya'll like it, I might put it into cygicons.dll eventually. > > -- > Chuck > I like it. Oh and by the way. The file never got bzip compressed. It is just a standard tar archive. For decompression if you use cygwin tar then leave out the -j parameter so it doesn't bother trying. For native archive manager drop the .bz2 extension. ;) -- 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: Hippo icon for cygwin...
On Dec 5 04:06, Charles Wilson wrote: > for your enjoyment. It's based on public domain art; this version > released under a creative commons license (CC-BY-SA 3.0) which is GPL > compatible. > > If ya'll like it, I might put it into cygicons.dll eventually. It's absolutely cute! But... what is that second hippo doing in the background? 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: nasm -- what format does cygwin use?
Dave Korn wrote: Tim Prince wrote: If running inside cygwin, you let the cygwin developers make the choice, which the binutils as will select automatically (PE-i386?). --- They didn't choose, or I wouldn't be asking the question. The util and build are using different names with 'flavors' for variations on the basics. Linda, my reading of the "nasm -hf" output suggests you'd want the win32 output format. If you check the generated .o files it using "objdump -h" you should see "file format pe-i386", which is right. After you've got .o files, you'll still need to link them; hopefully your makefiles will work with cygwin's LD easily enough. --- win32 was my guess as well. Since the prior choice when this thing was build for cygwin was gnuwin, (gnu on windows), I was pretty sure that has to be something like win32. I knew Eric Blakes answer was hopelessly unhelpful and just trying to wind me up since PE-coff isn't even on the list (though coff is), but that would be too generic if the previous name was something as specific as gnuwin, but win32...well that give a win32 object. Which is sorta what cygwin links with I think...just not the win32 libraries. For COFF, it describes that as being used by DJGPP for DOS, and that just sounds way different. Well, all I can do as try, at least I have a reasoned plurality at this point, which among programmers working with windows (let alone a *nix environment on windows like cygwin...) is saying something...:-) Who knows if it will work. I was jut trying to build the unix version of 7z on cygwin, since the cygwin version I have installed doesn't work due to a missing library -- dunno what happened to the file, but something under a 'codec' subdir in /usr/lib/p7zip/Codecs was being referenced, and that dir's empty. But I also noticed I have the windows version in /prog64/7-zip, which has the added bonus of being notably faster as it's 64-bit native code. But it would be nice to have the same utils on my linux and cygwin. Thanks for the reasoned and thoughtful answer (whether it's right or wrong) :-) -linda -- 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: [1.7] getgroups regression?
On Dec 4 22:48, Eric Blake wrote: > Meanwhile, is sorting and/or pruning duplicate getgroups results something > that > cygwin should consider doing? POSIX is explicit that the result is a > mathematical set, and that two processes can have the same set membership but > different orders based on the sequence of events that created those two > processes. But will Linux ever list a duplicate, even if duplicates appear > in /etc/group? Probably not. I assume the job of getgroups() is much easier on Linux. It just has to list the gids in the group list. Cygwin fetches the /etc/group file and verifies for each entry if its SID is in the process token. Avoiding dups requires YA loop in the loop, I don't think it's actually worth the effort. 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: [1.5.17] sshing doesnt work for pub/priv key. Password works. Win2003
On Dec 4 16:45, Robert Westendorp wrote: > Hi, > > I'm having an issue ssh'ing into a cygwin box. Did you consider upgrading Cygwin and OpenSSH to the latest versions? 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
[ANNOUNCEMENT] [1.7] Updated: perl-5.10.1-1
perl has been updated to 5.10.1-1 for the upcoming cygwin -1.7 release.
Important Changes since the last perl-5.10.0-5:
- for cygwin-1.7 and gcc-4 only
- added Win32CORE to the dll to enable libtool compilation (Yaakov).
This is a fragile hack but survived all attempts to break it so far.
perl-5.10 cygwin notes:
-
This release is binary incompatible with the old 5.8 releases,
but compatible to all 5.10.x releases. That's why we named the main
perl DLL /bin/cygperl5_10.dll and not cygperl5_10_0.dll.
The requirements for the special perl link driver ld2 and perlld had
been removed.
Cygwin mount point information is now accessible, esp. text/binary
detection.
Some modules have been added to vendor_perl, but most of the old vendor
modules moved to CORE.
Included are Bundle::CPAN, CPAN::Reporter, XML::LibXML and several
Test modules.
Note: Installed modules (e.g. via CPAN) in site_perl have higher
precedence than vendor_perl modules. So you can easily update these via
CPAN.
See http://www.perl.org/
ChangeLog: http://perldoc.perl.org/perldelta.html
Cygwin README: http://perldoc.perl.org/perlcygwin.html
Vendor patches for 5.10.1-1:
* CYG11 Empty .bs files are not generated anymore
* CYG12 no archlib in otherlibdirs
* CYG14 Dynaloader
* CYG15 static-Win32CORE
* CYG17 utf8-paths
* CYG21 LibList-Kid.patch
* CYG22 cygwin-1.7 hints
* CYG23 544-stat
* CYG24 build man pages
* Bug#55162 File::Spec::case_tolerant performance
* disable ExtUtils::MakeMaker::Coverage in Sys-Syslog
The patch "CYG25 use same image-base when exchanging privlib dlls" was
reverted as it was too fragile. This means that updating core modules
into arch might still require a rebaseall, esp. the Compress::Raw modules.
Update recommendations from 5.8:
---
Since 5.10 is not installed in parallel to 5.8 (it is possible, but not
with this package), all your old 5.8 modules will need to be reinstalled
for 5.10.
Your old 5.8 modules are not deleted, just not accessible to 5.10.
Non-binary packages can be used by adding /usr/lib/perl5/site_lib/5.8 to
your @INC, but the below procedure is recommended to get the latest
version for each installed package.
This will not harm most of your previous 5.8 modules in case you want to
switch back to 5.8, just the /bin scripts might get overwritten.
BEFORE INSTALLATION of 5.10 !
# get the list of installed 5.8 modules
$ perl -MExtUtils::Installed \
-e'print join("\n", new ExtUtils::Installed->modules)' > module.list
AFTER INSTALLATION of 5.10 !
# install all previous modules for 5.10
$ cpan `cat module.list`
Detailed NEWS from README
-
5.10.1-1
- first cygwin-1.7 release, with gcc-4. Binary incompatible to any
cygwin-1.5 perl-5.10.0 release.
- added CYG23-544-stat.patch to fix a -w stat() if being a member of
the group 544 Administrators.
- added CYG24-man.patch to generate man pages for ExtUtils::MakeMaker
modules. Accessing the section 3 pages this will need a man update.
- prepared a debuginfo package with the symbols exported to
/usr/lib/debug, but the symbols are NOT picked by gdb yet.
- forced chmod +x usr/bin/*
- vendor_perl modules added:
Net-IP-1.25 Text-Glob-0.08 Number-Compare-0.01 File-Find-Rule-0.30
Data-Compare-1.2101 CPAN-Checksums-2.02 File-Remove-1.42
File-chmod-0.32
Params-Util-1.00 Test-Script-1.03 CPAN-Inject-0.11 Socket6-0.23
IO-Socket-INET6-2.56
- vendor_perl modules updated:
Pod-Simple-3.08 Test-Pod-1.40 Pod-Coverage-0.20
Compress-Raw-Bzip2-2.021 IO-Compress-2.021 File-Temp-0.22
Archive-Zip-1.30
Term-ReadLine-Gnu-1.19 XML-NamespaceSupport-1.10 XML-SAX-0.96
XML-LibXML-1.69
Proc-ProcessTable-0.45 YAML-0.70 File-Copy-Recursive-0.38
IPC-Run3-0.043
IO-CaptureOutput-1.1101 File-HomeDir-0.86
- installsitescript and installsitebin changed from /usr/bin to
/usr/local/bin
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 and answer all of the questions.
*** 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://sources.redhat.com/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available
starting at this URL.
--
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
[ANNOUNCEMENT] [1.7] Updated: perl-Win32-GUI-1.06-3
I've updated perl-Win32-GUI to against the new perl-5.10.1-1 for cygwin-1.7 and gcc-4. NEWS: = No NEWS. CHANGES: None. DESCRIPTION: Win32::GUI is a Perl extension allowing creation of native Win32 GUI applications. UPDATE: === 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. Save it and run setup, answer the questions and pick up the package name from the 'Libs' category (it should already be selected). DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
[ANNOUNCEMENT] [1.7] Updated: perl-libwin32-0.28-3
All cygwin perl packages have been promoted to 5.10.1-1 for cygwin-1.7. perl-libwin32-0.28-3 follows. Project description: A useful bundle of Win32 Perl extensions. Port Changes: * Rebuilt for perl-5.10.1 under cygwin-1.7 with gcc-4 (archname: i686-cygwin) * Reverted the patches to use the external iodbc module. We are using the standard Windows ODBC modules now. I didn't follow the changes in the last upstream release 0.29 to just use the CPAN bundle and let CPAN do the rest. Included modules (no changes): Win32API::File, Win32API::Net, Win32API::Registry, Win32::ChangeNotify, Win32::Clipboard, Win32::Console, Win32::Event, Win32::EventLog, Win32::File, Win32::FileSecurity, Win32::IPC, Win32::Internet, Win32::Job, Win32::Mutex, Win32::NetAdmin, Win32::NetResource, Win32::ODBC, Win32::OLE, Win32::PerfLib, Win32::Pipe, Win32::Process, Win32::Registry, Win32::Semaphore, Win32::Service, Win32::Shortcut, Win32::Sound, Win32::TieRegistry and Win32::WinError. 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 and answer all of the questions and Click on "Exp" to get the Experimental branch for the new perl. If you have questions or comments, please send them to the Cygwin mailing list at: -- *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: [1.7] cygwin2 performance issue during compilation with autotools
I really would have love to investigate why it is slow; but atm, i have no more ideas ... For the only remark done far from now, i don't have any duplicates in PATH but cygcheck must be bugged or it finds informations setted elsewhere than in environment and that i'm not aware of. The install is clean, and barely default. I tried to reinstall the cygwin environment a bunch of times, as it could be a 'pebcak' problem. It must not, afterall, because the slowness is always there. There must be also another bug with the 'gcc' and 'cpp' not found because i have the gcc-4 packages installed and 'cc' and 'cpp' and 'gcc' are there, in /usr/bin eg. $ which gcc /usr/bin/gcc So, cygwin2 is a big stopper now. 6min on cyg1, 30 on cyg2. 5x slower. If i translate that to running applications, it can significate that the applications could be also 5x slower if they use the same functionalities which are used by the build systems (fork()?). They have been installed the same way except the target directory, so, even if things can change between releases, i must have reproduced the bug somehow. -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF signature.asc Description: OpenPGP digital signature
Re: Hippo icon for cygwin...
On 2009-12-05 09:06Z, Charles Wilson wrote: > for your enjoyment. It's based on public domain art; this version > released under a creative commons license (CC-BY-SA 3.0) which is GPL > compatible. Might this file: 1a652c4c8c31b80c85d6cbc2b4093060 *hippo.ico be somehow malformed? My computer BSODs every time I try to view it in 'irfanview'. This has happened three times in a row. I tried opening the icon file in gimp-2.2.4, which crashed with: winicon.exe caused an Access Violation at location 00402795 in module winicon.exe Reading from location 0008. (no BSOD). Yet the icon displays successfully in 'windows explorer'. An .ico file actually can cause an application to crash: http://securitytracker.com/alerts/2007/Jun/1018202.html That tracker says ms planned to patch the problem, but right now I'm using XP SP1, so I wouldn't have that patch. -- 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: Hippo icon for cygwin...
Greg Chicares wrote: > Might this file: > 1a652c4c8c31b80c85d6cbc2b4093060 *hippo.ico > be somehow malformed? My computer BSODs every time I try to view > it in 'irfanview'. This has happened three times in a row. BSOD? Well, *any* BSOD is by definition a bug inside ring 0 (e.g. the core Windows kernel, or a graphics driver. So, it isn't *.ico's fault. Still, it'd be good to avoid... > I tried opening the icon file in gimp-2.2.4, which crashed with: > winicon.exe caused an Access Violation at location 00402795 > in module winicon.exe Reading from location 0008. > (no BSOD). Yet the icon displays successfully in 'windows explorer'. That's a pretty old version of gimp... > An .ico file actually can cause an application to crash: > http://securitytracker.com/alerts/2007/Jun/1018202.html > That tracker says ms planned to patch the problem, but right now > I'm using XP SP1, so I wouldn't have that patch. Hmmm. Well, the .ico contains the *vista*-approved sizes: 256x256 32bit RGBA .png-compressed 64x64 32bit RGBA 48x48 32bit RGBA 48x48 8bit 256-color indexed (1bit transparency) 48x48 4bit 16-color indexed (1bit transparency) 32x32 32bit RGBA 32x32 8bit 256-color indexed (1bit transparency) 32x32 4bit 16-color indexed (1bit transparency) 24x24 32bit RGBA 24x24 8bit 256-color indexed (1bit transparency) 24x24 4bit 16-color indexed (1bit transparency) 16x16 32bit RGBA 16x16 8bit 256-color indexed (1bit transparency) 16x16 4bit 16-color indexed (1bit transparency) Supposedly, the 256x256 png-compressed size should be ignored on platforms that do not support it -- but maybe that's causing your problem. Try the attached version, which omits the 256x256 resolution. -- Chuck hippo_xp.ico.gz Description: application/gzip -- 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: Hippo icon for cygwin...
Charles Wilson wrote: Greg Chicares wrote: Might this file: 1a652c4c8c31b80c85d6cbc2b4093060 *hippo.ico be somehow malformed? My computer BSODs every time I try to view it in 'irfanview'. This has happened three times in a row. irfanview handles it fine on my box (XP). -- 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: nasm -- what format does cygwin use?
On Sat, Dec 05, 2009 at 01:44:14AM -0800, Linda Walsh wrote: >I knew Eric Blakes answer was hopelessly unhelpful and just trying to >wind me up since PE-coff isn't even on the list (though coff is), That's a rather paranoid way of looking at someone's attempts to help you. Eric was, unsurprisingly, right in noting that the binary format for executables on Windows is "PE/COFF". Look it up. cgf -- 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: Hippo icon for cygwin...
On Sat, Dec 5, 2009 at 9:27 AM, Charles Wilson wrote: > Greg Chicares wrote: >> Might this file: >> 1a652c4c8c31b80c85d6cbc2b4093060 *hippo.ico >> be somehow malformed? My computer BSODs every time I try to view >> it in 'irfanview'. This has happened three times in a row. > > BSOD? Well, *any* BSOD is by definition a bug inside ring 0 (e.g. the > core Windows kernel, or a graphics driver. So, it isn't *.ico's fault. > > Still, it'd be good to avoid... > Not necessarily. A BSOD can be caused by any faulty driver, application, or service in the system. It can also be caused by faulty hardware. Bad ram will cause memory corruption and make programs or drivers fail to run properly. I have diagnosed BSOD errors before and tracked them down to both faulty ram and faulty hard drives. Using windbg to identify the culprit helps. Robert Pendell shi...@elite-systems.org CAcert Assurer "A perfect world is one of chaos." -- 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: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX
Eliot Moss wrote: Any progress? Well, I still don't have it working. But I did learn some rather startling things about ash.exe and cygwin1.dll. As always, this will seem overlong. But I've worked in the IT industry for 28 years, and I've learned that it's always the one datum you don't mention that contains the key to the problem solution. I have a tool called ProcessExplorer which shows me a much richer information set than does windows's task manager. In particular, it lets me search all running processes for file handles or DLLs containing a given string. So after I reconstituted the input files, I began to run through your process, monitoring closely to see which DLLs got opened as I did. So before I ran cmd.exe, I opened ProcessExplorer and searched for the strings "cyg" and "bash." ProcessExplorer find no instance of those strings among the running process's DLLs or handles. Then I opened the cmd.exe window: Microsoft Windows [Version 6.1.7600] Copyright (c) 2009 Microsoft Corporation. All rights reserved. And repeaded the ProcessExplorer test. As before, it shows no handles or DLLs containing the strings "cyg" or "bash". Now cd to c:\cygwin, C:\Users\Ed>cd \cygwin\ and a ProcessExplorer search for string "cyg" finds the following: Handle or DLL substring:cyg === Process PID TypeHandle or DLL - cmd.exe 5460Handle C:\cygwin Harmless. That's just cmd.exe's handle for the cygwin directory. Now start ash from within cmd.exe window with "bin\ash.exe": C:\cygwin>bin\ash.exe $ pwd / $ And the ProcessExplorer search for string "cyg" shows the following quite disappointing results: Handle or DLL substring:cyg === Process PID TypeHandle or DLL - ash.exe 3444DLL C:\cygwin\bin\ash.exe ash.exe 3444DLL C:\cygwin\bin\cygwin1.dll ash.exe 3444Handle C:\cygwin ash.exe 3444Handle \BaseNamedObjects\cygwin1S5-c5e39b7a9d22bafb ash.exe 3444Handle \BaseNamedObjects\cygwin1S5-c5e39b7a9d22fafb\shared.5 ash.exe 3444Handle \Sessions\1\BaseNamedObjects\cygwin1S5-c5e39b7a9d22bafb ash.exe 3444Handle \BaseNamedObjects\cygwin1S5-c5e39b7a9d22bafb\S-1-5-21-960314295-2209531045-2725553256-1000.1 ash.exe 3444Handle \BaseNamedObjects\cygwin1S5-c5e39b7a9d22bafb\tty_list:mutex.0 ash.exe 3444Handle \BaseNamedObjects\cygwin1S5-c5e39b7a9d22bafb\cygpid.3444 ash.exe 5460Handle C:\cygwin Now exit ash: $ exit C:\cygwin> and ProcessExplorer's search on string "cyg" reverts to looking precisely as it did prior to firing up ash.exe: Handle or DLL substring:cyg === Process PID TypeHandle or DLL - cmd.exe 5460Handle C:\cygwin Now for completeness's sake, and not as an exercise in grasping at straws, I now retried the above from the cmd.exe window WITHOUT cd'ing to the \cygwin directory (No, I can't think of any reason why it should work differently, either. I was just looking for anomalies.). Performing the ProcessExplorer search for string "cyg" again shows us almost the exact same results as the last time we ran ash.exe, disappointing results: Handle or DLL substring:cyg === Process PID TypeHandle or DLL - ash.exe 4368DLL C:\cygwin\bin\ash.exe ash.exe 4368DLL C:\cygwin\bin\cygwin1.dll ash.exe 4368Handle \BaseNamedObjects\cygwin1S5-c5e39b7a9d22bafb ash.exe 4368Handle \BaseNamedObjects\cygwin1S5-c5e39b7a9d22fafb\shared.5 ash.exe 4368Handle \Sessions\1\BaseNamedObjects\cygwin1S5-c5e39b7a9d22bafb ash.exe 4368Handle \BaseNamedObjects\cygwin1S5-c5e39b7a9d22bafb\S-1-5-21-960314295-2209531045-2725553256-1000.1 ash.exe 4368Handle \BaseNamedObjects\cygwin1S5-c5e39b7a9d22bafb\tty_list:mutex.0 ash.exe 4368Handle \BaseNamedObjects\cygwin1S5-c5e39b7a9d22bafb\cygpid.3444 And as a final test, and because I am a masochist, I decided to see if things worked differently if I launched ash.exe by double-clicking its icon from within a Windows Explorer window. The results were the same as running ash.exe from within cmd.exe: Handle or DLL substring:cyg === Process PID TypeHandle or DLL - explorer.exe 1576Handle C:\cygwin explorer.exe 1576Handle C:\cygwin explorer.exe 1576Handle C:\cygwin\bin explorer.exe 1576Handle C:
handle invalid running native console app from cygwin shell
I'm trying to run a boo script from a cygwin bash shell. http://boo.codehaus.org/ booish runs fine from cmd or powershell but from bash I get an error. I thought maybe then I could do cmd /c booish but this doesn't work either. Any idea how I can workaround the issue? $ booish Welcome to booish, an interactive interpreter for the boo programming language. Running boo 0.9.2.3383 on CLR 2.0.50727.4927. Enter boo code in the prompt below (or type /help). Unhandled Exception: System.IO.IOException: The handle is invalid. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.__Error.WinIOError() at System.Console.set_CursorVisible(Boolean value) at Boo.Lang.Interpreter.InteractiveInterpreter2.ConsoleLoopEval() at Booish2Module.Main(String[] argv) -- 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: handle invalid running native console app from cygwin shell
Update: I discovered that if I remove tty from CYGWIN variable the problem is fixed. However, emacs doesn't work correctly if its not set (C-x C-c is interpreted as C-x C-g). So it seems that your kinda damned if you do damned if you don't. -- Forwarded message -- From: Kurt Harriger Date: Sat, Dec 5, 2009 at 12:40 PM Subject: handle invalid running native console app from cygwin shell To: cygwin@cygwin.com I'm trying to run a boo script from a cygwin bash shell. http://boo.codehaus.org/ booish runs fine from cmd or powershell but from bash I get an error. I thought maybe then I could do cmd /c booish but this doesn't work either. Any idea how I can workaround the issue? $ booish Welcome to booish, an interactive interpreter for the boo programming language. Running boo 0.9.2.3383 on CLR 2.0.50727.4927. Enter boo code in the prompt below (or type /help). Unhandled Exception: System.IO.IOException: The handle is invalid. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.__Error.WinIOError() at System.Console.set_CursorVisible(Boolean value) at Boo.Lang.Interpreter.InteractiveInterpreter2.ConsoleLoopEval() at Booish2Module.Main(String[] argv) -- 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: handle invalid running native console app from cygwin shell
On 12/5/2009 3:16 PM, Kurt Harriger wrote: I discovered that if I remove tty from CYGWIN variable the problem is fixed. However, emacs doesn't work correctly if its not set (C-x C-c is interpreted as C-x C-g). That's only an issue if you use the Cygwin console, which isn't the best environment for emacs anyway. Try a different terminal, like mintty for instance. Ken -- 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: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX
Ed Gaines wrote: Any reason I can't run the rebase and peflags commands from with cmd.exe? Are they "pure" windows executables, in other words? I can't stand it. In order to answer my own question cited above, I went back and ran a cmd.exe window as administrator, and then tried to run rebase from within it: C:\cygwin>bin\rebase -d -b 0x6100 -o 0x2 -v -T dll_so.in > rebase.out ./bin/cyglsa64.dll: fixing bad relocations FixImage (./bin/cyglsa64.dll) failed with last error = 13 Okay, I expected that. It happened last time, too. So I edited the dll_so.in file (with notepad) and removed cyglsa64.dll, and reran the above rebase command. And got a result that I did NOT, expect: C:\cygwin>bin\rebase -d -b 0x6100 -o 0x2 -v -T dll_so.in > rebase.out ReBaseImage (./bin/cygwin1.dll) failed with last error = 6 As before, I searched for open cygwin dlls before and after running rebase. I couldn't find any at all. I tried searching for these dlls DURING the rebase, but unfortunately the rebase command completes before the dll search completes. So even though the dll search never found cygwin1.dll, I can't say for sure that cygwin1.dll was NEVER in use during the process. I'm just about ready to concede that, for whatever reason, I can't run cygwin and BitDefender simultaneously on my Win 7 box. Period. -- Ed -- 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: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX
On 12/5/2009 3:41 PM, Ed Gaines wrote: As before, I searched for open cygwin dlls before and after running rebase. I couldn't find any at all. I tried searching for these dlls DURING the rebase, but unfortunately the rebase command completes before the dll search completes. So even though the dll search never found cygwin1.dll, I can't say for sure that cygwin1.dll was NEVER in use during the process. Rebase is a Cygwin application and needs cygwin1.dll. You can see that by using cygcheck: $ cygcheck rebase Found: C:\cygwin-1.7\bin\rebase.exe C:\cygwin-1.7\bin\rebase.exe C:\cygwin-1.7\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll That's why the instructions that you quoted in your first message in this thread (http://cygwin.com/ml/cygwin/2009-12/msg00159.html) said to run rebase on a *copy* of cygwin1.dll. Ken -- 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: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX
Ok, I was wrong about ash (not) using cygwin1.dll. Running ldd on rebase and peflags reveals that they use it too, which pretty much says that they are cygwin apps. However, it also shows that the preferred load address, on my system anyway, for cygwin1.dll is 0x6100. That explains the starting point for my -d rebasing -- to go below cygwin1.dll. cygwin1.dll has its base set when it is built. There may be some way to rebase it, but I don't know what it is, though I expect that there is a Windows tools for doing it if it matters. It was not necessary for me. Checking my scripts, I eliminate cygwin1.dll from the list of dlls, and ash.exe and peflags.exe from the list of exes. Could probably remove rebase.exe as well, but it did not seem to matter. It *is* important that ash does *not* load some other big dlls related to C libraries, which bash tends to want. These in particular: cygintl-8.dll => /usr/bin/cygintl-8.dll (0x58f7) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5906) cygreadline7.dll => /usr/bin/cygreadline7.dll (0x5732) cygncurses-9.dll => /usr/bin/cygncurses-9.dll (0x6db8) cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x5c1e) (Part of the output from ldd /bin/bash.) Hope there's something here that helps ... Eliot -- 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: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX
Is BitDefender on the BLODA list? It may be wedging itself in, between cygwin and Windows, redoing various Windows system calls -- but in a way that defeats cygwin ... Cheers -- EM -- 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: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX
Eliot Moss wrote: Ok, I was wrong about ash (not) using cygwin1.dll. Running ldd on rebase and peflags reveals that they use it too, which pretty much says that they are cygwin apps. Thanks. I was beginning to think I'd lost my mind... However, it also shows that the preferred load address, on my system anyway, for cygwin1.dll is 0x6100. That explains the starting point for my -d rebasing -- to go below cygwin1.dll. Interesting. That explains the 0x6100 -- it's certainly not arbitrary! cygwin1.dll has its base set when it is built. There may be some way to rebase it, but I don't know what it is, though I expect that there is a Windows tools for doing it if it matters. Well, what BitDefender recommended, and what had always worked until the last time I upgraded Cygwin 1.7, was the following: 1) Turn off BitDevender's Advanced Virus Control (AVC); 2) Open a cmd.exe window; 3) Run the following commands in that window: cd c:\cygwin\bin copy cygwin1.dll cygwin_orig.dll copy cygwin1.dll cygwin_tmp.dll rebase -b 0x3500 cygwin_tmp.dll copy cygwin_tmp.dll cygwin1.dll 4) Reenable AVC. In other words, they're explicitly using the cygwin rebase command to move cygwin1.dll's load address to 0x3500. Which I assume is far, far away from whatever BitDefender library is interfering with it. As I say, that worked find up until my last upgrade. After I ran the above steps on that upgraded Cygwin distro, all the windows and most of the commands worked. But piping output among various cygwin commands (and even the find -exec flag) began failing if the amount of info being piped from one command to the other was more than a line or two. That's when I searched through the cygwin forum to try and find something a little more sophisticated than the above -- on the assumption that perhaps I was experiencing a mis-match between where the cygwin1.dll library was now loaded and where some other unknown library expected it to be. Naive perhaps, but I didn't think I had time to research the relationships among the various components of cygwin. As it turned out, I had several days -- the time I spent attacking it in a whack- a-mole fashion :-) It was not necessary for me. Checking my scripts, I eliminate cygwin1.dll from the list of dlls, and ash.exe and peflags.exe from the list of exes. Could probably remove rebase.exe as well, but it did not seem to matter. It *is* important that ash does *not* load some other big dlls related to C libraries, which bash tends to want. These in particular: cygintl-8.dll => /usr/bin/cygintl-8.dll (0x58f7) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5906) cygreadline7.dll => /usr/bin/cygreadline7.dll (0x5732) cygncurses-9.dll => /usr/bin/cygncurses-9.dll (0x6db8) cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x5c1e) Didn't see any of those in the ProcessExplorer output, so I guess I'm golden :-) (Part of the output from ldd /bin/bash.) Hope there's something here that helps ... Eliot Quiet a bit, actually. I was beginning to think I'd lost my mind there for awhile :-) Again, thank you for all your assistance. After that last experience, I blew away my cygwin distro, and I'm reinstalling it now. Once that's finished I'll give your method another go and see what happens! Regards, -- Ed -- 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: nasm -- what format does cygwin use?
Christopher Faylor wrote: > On Sat, Dec 05, 2009 at 01:44:14AM -0800, Linda Walsh wrote: >> I knew Eric Blakes answer was hopelessly unhelpful and just trying to >> wind me up since PE-coff isn't even on the list (though coff is), > > That's a rather paranoid way of looking at someone's attempts to help > you. Eric was, unsurprisingly, right in noting that the binary format > for executables on Windows is "PE/COFF". Look it up. Eric's answer was correct, just not relevant, but I don't for one moment think it was deliberately unhelpful, I just think he misunderstood what Linda's question was driving at. Linda's response makes sense if you assume that Eric was responding directly to what she actually was asking about; Eric's response wasn't meant to be rude, but it wasn't entirely paranoid of Linda to take it that way because it could seem to be brusque. Never forget how poor the bandwidth of email is w.r.t. communicating tone and emotional inflection - and that's advice for everyone, including me :) cheers, DaveK -- 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
[OT] Re: Hippo icon for cygwin...
Robert Pendell wrote: > Using windbg to identify the culprit helps. Yes, anything else is pointless speculation; these kinds of crashes are way too esoteric to waste time guessing at. Enable full crash dumps in the system preferences, install windbg, trigger the crash, then (after rebooting) open memory.dmp in windbg; the output of "analyze -v" should tell you at once which driver was on top of the stack and so should be suspected. If you're lucky, you'll see the driver name on the BSoD and won't have to go to such lengths, but if it's a level or two up the stack when the crash happens, you'll need a debugger to show you the relevant module name. cheers, DaveK -- 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: Hippo icon for cygwin...
On 2009-12-05 14:27Z, Charles Wilson wrote: > Greg Chicares wrote: >> Might this file: >> 1a652c4c8c31b80c85d6cbc2b4093060 *hippo.ico >> be somehow malformed? My computer BSODs every time I try to view >> it in 'irfanview'. This has happened three times in a row. > > BSOD? Well, *any* BSOD is by definition a bug inside ring 0 (e.g. the > core Windows kernel, or a graphics driver. So, it isn't *.ico's fault. Yes, apparently it's an XP SP1 kernel defect: in 'win32.sys', PAGE_FAULT_IN_NONPAGED_AREA, STOP 0x0050. I also tried the original .ico on an XP SP2 machine, which produced a different BSOD. That machine was set to reboot itself upon BSOD, so I didn't have time to record the message; but the program name began with 'ati', so it was almost certainly a graphics driver. But those are defects in ring-zero programs, so it's their job to avoid crashing no matter what .ico file is handed to them. The resulting vulnerability is their fault--not the .ico's fault. BTW, both these machines have no known hardware problems, and recent full runs of memtest86 indicate that their RAM is fine. > Still, it'd be good to avoid... > >> I tried opening the icon file in gimp-2.2.4, which crashed with: >> winicon.exe caused an Access Violation at location 00402795 >> in module winicon.exe Reading from location 0008. >> (no BSOD). Yet the icon displays successfully in 'windows explorer'. > > That's a pretty old version of gimp... It's a native msw build that was released 2005-03-03: quite old, I agree. Still, I'm probably not the only person running Cygwin on a 2005-vintage system, so it's good to isolate the problem... >> An .ico file actually can cause an application to crash: >> http://securitytracker.com/alerts/2007/Jun/1018202.html >> That tracker says ms planned to patch the problem, but right now >> I'm using XP SP1, so I wouldn't have that patch. > > Hmmm. Well, the .ico contains the *vista*-approved sizes: Okay, yet many large-corporation IT departments are sticking with XP for the foreseeable future, even for brand-new machines. And apparently the vista-sized icons aren't gracefully ignored by XP (SP1 at least), no matter what ms may say. BTW, the graphics drivers on the SP2 machine were current when I checked them for updates about two weeks ago. > Supposedly, the 256x256 png-compressed size should be ignored on > platforms that do not support it -- but maybe that's causing your > problem. Try the attached version, which omits the 256x256 resolution. This new .ico works fine in every graphics program I can find, even on the XP SP1 machine--specifically including the two programs that failed with the original icon. -- 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: Hippo icon for cygwin...
Greg Chicares wrote: > but the program name began with 'ati' There's your problem, right there. cheers, DaveK -- 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: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX
Sounds good. If you're starting from 0x3500 you might be able to go from the end of cygwin1.dll upward. You could also try ldd on BitDefender and see if ti tell you anything about the dlls it loads and where they typically want to go Best -- EM -- 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
