Open pschulz opened 10 years ago
The current curl needs to be updated anyway, it uses OpenSSL/1.0.1f, so it needs to be patched. :/
I'll look into it, unless someone beats me to it with a pull request of course.
Is this a joke? Why are you still using XP?
No, it is not a joke. Some big enterprises still use it and their migration plan says, that we still have to support XP until mid of 2015...
Install GOW .7.0. Copy the curl.exe out of bin
Install/upgrade to GOW .8.0. Replace the new curl.exe with the old curl.exe, since obviously they are different files.
You get all the goodness of .8.0, and your curl still works in XP.
That's exactly what I did, nevertheless it does not solve the cause (only if XP is meant to be the cause ;-) ) and also no fix for heartbleed. Additionally I double checked the issue and found out that WER.DLL and IESHIMS.DLL are not the problem (they are just delay-loaded dependencies and that's fine). I don't know what the real cause is and I also do not want to find it out.
But I found a solution at http://www.paehl.com/open_source/?CURL_7.36.0with the additional the patch for OpenSSL 1.0.1g. It ships with the usual suspects of SSL DLLs (ssleay32,dll and libeay32.dll). Does anybody know if the current bins in GoW do depend on the current version of them which could lead to a conflict or do you believe it is safe? I am not able to test all the commands. So feedback is appreciated.
This is the version output of the suggested binary: curl 7.36.0 (i386-pc-win32) libcurl/7.36.0 OpenSSL/1.0.1g zlib/1.2.7 libssh2/1.4.3 librtmp/2.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM SSL SSPI libz
IDN and SPNEGO is missing, but I contacted Dirk and ask if it is possible to build another version with these features enabled.
Pull request follows asap.
This version and other alternatives can be found at http://curl.haxx.se/download.html#Win32
Okay, that seems to become a problem, because wget does not work anymore with the new libeay32.dll.
Couldn't we use this project to write HowTos about how to compile certain tools on Windows (without cygwin and that stuff) instead of just doing some pseudo package management? Does anybody know which dll in the bin folder is still used by which executable?
curl 7.36.0 (i386-pc-win32) libcurl/7.36.0 OpenSSL/1.0.1g zlib/1.2.7
libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s
rtmp rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM SSL SSPI libz
@bytehead- Thanks for the OpenSSL hint, it is also fixed
@bmatzelle If you want to solve any DLL conflicts in the future, there is an easy recipe: Assume you want to add / modify new_binary.exe plus some DLLs that conflict with any other files in /bin:
@ECHO OFF
"%~dp0%~n0\%~n0.exe" %*
Convention: The batch and the folder must just have the same name as the executable (without the .exe extension). So you can use the same batch for all your executables if you want to.
By the nature that executables on Windows always try to find their linked DLLs in the same directory that contains the executable, you are safe for all time.
I have a Baby Cygwin
It is only 7.1 MB and comes with a pretty good selection of commands.
If people have an interest I can get it up to date and add more commands as needed.
If anybody is interested, you can download and test the patched version from https://github.com/pschulz/gow/releases/tag/v0.8.1
The 0.8.1 setup is defect, because it does not contain the curl subdirectory. I'm going to fix it soon.
@bmatzelle What's the reason why the NSI only includes exe, dll, bat and vbs files? Wouldn't it be easier to take the bin/* as it is?
@pschulz There was initially but it probably isn't a requirement anymore.
Fixed it in pschulz/gow@bdcad70 Also part of #143 now. Installer: https://github.com/pschulz/gow/releases/tag/v0.8.2
Hi,
when I use curl, I get a message box on WIndows XP saying that "curl.exe is not a valid Win32 application" (okay I get a german message, but I think the translation should match).
Switching back to 0.7.0 fixed it.
Dependency walker says, it depends on IESHIMS.DLL and WER.DLL, which are never part of Windows XP. It exactly matches the situation as described here: http://stackoverflow.com/questions/2465111/dependency-walker-reports-ieshims-dll-and-wer-dll-missing