Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
pschulz opened this issue Apr 17, 2014 · 13 comments · May be fixed by #143
Open

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

pschulz opened this issue Apr 17, 2014 · 13 comments · May be fixed by #143

Comments

@pschulz
Copy link

pschulz commented Apr 17, 2014

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-
Copy link

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

@bmatzelle
Copy link
Owner

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

@ghost
Copy link

ghost commented May 6, 2014

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

@pschulz
Copy link
Author

pschulz commented May 6, 2014

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-
Copy link

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
Copy link
Author

pschulz commented May 6, 2014

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
Copy link
Author

pschulz commented May 6, 2014

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 pschulz linked a pull request May 6, 2014 that will close this issue
@pschulz
Copy link
Author

pschulz commented May 6, 2014

#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
Copy link

ghost commented May 6, 2014

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
Copy link
Author

pschulz commented May 8, 2014

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

@pschulz
Copy link
Author

pschulz commented May 13, 2014

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
Copy link
Owner

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

@pschulz
Copy link
Author

pschulz commented May 17, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants