bmatzelle / gow

Unix command line utilities installer for Windows.
https://github.com/bmatzelle/gow/wiki
6.57k stars 366 forks source link

GoW 0.8.0: curl is not a valid Win32 application on Windows XP #135

Open pschulz opened 10 years ago

pschulz commented 10 years ago

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

bytehead- commented 10 years ago

The current curl needs to be updated anyway, it uses OpenSSL/1.0.1f, so it needs to be patched. :/

bmatzelle commented 10 years ago

I'll look into it, unless someone beats me to it with a pull request of course.

ghost commented 10 years ago

Is this a joke? Why are you still using XP?

pschulz commented 10 years ago

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...

bytehead- commented 10 years ago

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.

pschulz commented 10 years ago

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

pschulz commented 10 years ago

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?

pschulz commented 10 years ago

143 fixes this issue:

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:

  1. Create a folder "bin/new_binary"
  2. Place the new files there
  3. create "bin/new_binary.bat" with this content:
@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.

ghost commented 10 years ago

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.

pschulz commented 10 years ago

If anybody is interested, you can download and test the patched version from https://github.com/pschulz/gow/releases/tag/v0.8.1

pschulz commented 10 years ago

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?

bmatzelle commented 10 years ago

@pschulz There was initially but it probably isn't a requirement anymore.

pschulz commented 10 years ago

Fixed it in pschulz/gow@bdcad70 Also part of #143 now. Installer: https://github.com/pschulz/gow/releases/tag/v0.8.2