* Crossover/PlayonMac/Linux winhttp download problem

[JP Ford]

Okay, after following this process:

• removing the Possible Duplicates plugin and all related files and downloads from ..\ProgramData\CalicoPie\plugins

• removing the *winhttp library installed by POL interface

• Opening the Wine Config for the FH virtual instance and installing the winhttp library from the Wine interface.

• Open the FH virtual instance and run PLugins... Import the Possible Duplicates plugin

• Run the plugin... click okay to download the prerequisite files

The plugin ran perfectly after installing the winhttp library via the Wine config only and not using the POL interface or "helper".

I did notice that the Wine interface did not download anything at all. It was literally 1) select the library, 2) click Apply and then close the Wine config and restart the FH instance. It leads me to wonder why POL nbeeds to download anything OR if the fact that it was previously downloaded affected the process??

I'm thinking I may need to do that again with a truly fresh virtual instance...

[Valkrider]

Joel

I suspect POM & POL actually downloads and installs winhttp permanently (or any of the other 500 or so addons) and enables them on first download. If they are then disabled I suspect that is all that happens not a deletion of the download. What the Wine config does is to enable the added library that has been previously downloaded and installed.

[JP Ford]

Okay, nuked that virtual instance and started over from scratch = vanilla Wine instance with vanilla FH install.

1. Installing the winhttp library via the Wine configuration interface... (never downloaded anything, just apply and close.)
2. Start up FH, install plugin and run. Plugin did not work, failed in FH with ubiquitous download error.
3. Removed the winhttp in Wine config. Install winhttp via the POL config & helper interface (Install components). This time the install was instant, leading me to assume that POL only needs to download this library once.
4. Confirmed that library was installed in Wine Config (it was and with the same asterisk as noted previously)
5. Loaded up FH and ran plugin.
6. Plugin successfully downloads prerequisite files and runs as normally after about 60 secs .

It also appears from this thread that POL and others may be downloading this file from the internet archive, which is why it is a) dropping connections and b) slow as molasses.

I am unclear as to what the diff is between the Wine config install and the POL install. Clearly, there is something different. I think as a matter of course, using the POL helper interface is more likely to result in success. I also wonder if one could simply download and install that library executable file directly in the Wine virtual instance? I confirmed the file is available at this link: http://web.archive.org/web/201601290538 ... SP4_EN.EXE

PS. I have screenshots of 90% of this process, if anybody wants them.

[Valkrider]

I also wonder if one could simply download and install that library executable file directly in the Wine virtual instance? I confirmed the file is available at this link: http://web.archive.org/web/201601290538 ... SP4_EN.EXE

I tried this in Crossover and got the wrong version message. If only Codeweavers would tell me what file is required then I could probably find it like you did.

[JP Ford]

Joel

I suspect POM & POL actually downloads and installs winhttp permanently (or any of the other 500 or so addons) and enables them on first download. If they are then disabled I suspect that is all that happens not a deletion of the download. What the Wine config does is to enable the added library that has been previously downloaded and installed.

Well, now that just makes sense.

[tatewise]

May I leave it to you two guys to try and figure out the best working solution for installing winhttp in Crossover, POL, POM and WINE itself, so we can document what works in the FHUG KB.

Might it be possible to capture a winhttp download that installs into WINE and thus works for all emulators?
Then we could save that winhttp download in the FHUG KB for use with any WINE scenario?

[Valkrider]

Might it be possible to capture a winhttp download that installs into WINE and thus works for all emulators?

The POM way does not work in Crossover as there is a file incompatibility. So we have to continue in the old way with manual downloads and installs in Crossover.

This is the latest response from Crossover

So i chatted with a couple of our developers, they both expressed no knowledge of any updated service pack. I explained the overall issue which intern they said that crossover uses a wine implementation of winhttp. Is the problem indeed an issue with winhttp in crossover? It is also suspect PlayOnMac uses a recipe that pulls some kind of native.dll, if that can be isolated maybe obtaining that .dll may help.

So it looks like they don't know how POM is doing it or what dll is required.

[tatewise]

Firstly, I tried to follow the download link to the W2KSP4_EN.EXE installation file Joel mentioned and got redirected to the Wayback Machine where the download failed.

I wonder if the following devious technique would work?
Use POL/POM to install the winhttp library so that it gets listed in WINE with an asterisk.
We know that version of *winhttp works fine.
If Crossover is then run with that WINE configuration does it support winhttp?
Or are you saying that is incompatible?

[JP Ford]

Firstly, I tried to follow the download link to the W2KSP4_EN.EXE installation file Joel mentioned and got redirected to the Wayback Machine where the download failed.

Per discussion here, try

Code: Select all

ftp://ftp.fu-berlin.de/pc/security/ms-patches/win2000/Service_Packs/usa/W2KSP4_EN.EXE

It works for me, just downloaded it.

That said, I read another thread that POL only uses the W2KSP4_EN.EXE "...to extract files" which leads me to wonder if that particular executable is not actually installed, but rather it contains the necessary files for the winhttp library and this is just how it is accessed.

All of this is beginning to feel like chasing my tail. Both POL and POM will install winhttp library and make FH functional. The only real issues is that the download source seems to be a bit "iffy" or is seriously choked, which results in dropped failed downloads, probably due to dropped connections (or switching to different repos?). With both, repeatedly clicking the retry option does eventually work. Maybe that is just the reality that POL/POM users are left with right now?

[JP Ford]

As an aside, I just tried to install the W2KSP4_EN.EXE into a clean Windows 7 Wine instance and it failed with a "different hardware" error. During that process, it asked for a location to extract files. However, it removed all the extracted files once it failed. I suspect it does that no matter what the outcome as part of routine cleanup. I have no idea how to extract from a Windows executable. I'll take a look and see what i find.


See this link: https://wikidll.com/download/25510.

I have no idea as to the validity of these files, but it does result in a zip containing file winhttp.dll FWTW.

(004).png (28.61 KiB) Viewed 9454 times

[JP Ford]

And, just to muddy the waters a bit more, here is a filelisting of a fresh, vanilla instance of a virtual Windows7 created with wine and POL.... winhttp.dll is already there and in SysWOW folders as well... ?

My suspicion is that the default winhttp.dll does not work under wine and that POL/POM must download a tweaked or updated one in order to get it working... That may be why the Wine configurration does not download anythign but the POL configuration does.

(003).png (12.6 KiB) Viewed 9454 times

[tatewise]

It is largely smoke & mirrors to me, but here are my limited suggestions.

I guess the complaints about wrong version or hardware are due to the service pack being for Windows 2000 but you are running in a Windows 7 bottle.

I think the W2KSP4_EN.EXE file is a self-extracting installation ZIP file.
So on execution, it unpacks all the files (including winhttp.dll), then copies them to appropriate folders, and finally installs them, which I suspect involves registering them in the Windows Registry.
See https://support.microsoft.com/en-us/hel ... a-dll-file and many others on the same topic.

So just having the winhttp.dll file sitting in a folder is not enough. It must also be registered in the Windows Registry.
POL/POM presumably know the 'magic' to download a compatible winhttp.dll file and register it correctly.

[Valkrider]

@Mike

How about coming at this from another angle.

What about a plugin for Mac users that contains the libraries and installs them regardless? Then any plugins should just work without having to download any libraries as they will already be present.

[tatewise]

@Colin
Novel idea but unfortunately not a solution.
Plugins can only contain plain text, but most of the library modules involve binary DLL files.
Several Plugins download their own data files and thus need winhttp c.f. how_to:family_historian_v6_on_crossover_wine#plugin_data_downloads|> Plugin Data Downloads.
The Check Installed Plugins Against the Store and many of my Plugins check the FH Plugin Store so need winhttp.

[ColeValleyGirl]

Mike, I think Colin was suggesting a one time plugin that downloads all the libraries, so that any other plugins can run secure in the knowledge that the libraries exist (or rather, use loadrequire and pass over the download code which therefore doesn't need to deal with non-Windows environments). One plugin to bind them all...

[tatewise]

That is what I was talking about. It is not possible. Plugins cannot incorporate non-text/binary files.
They also cannot download the library modules without winhttp.
Maybe I misunderstand what you are suggesting. How does one Plugin download all the libraries without winhttp?

[ColeValleyGirl]

For a given environment, the kb can say:

1. Install winhttp this way (based on whichever environment is in question)
2. Run this plugin (which installs all libraries that other plugins might install)

Other plugins could then carry on regardless rather than having to code around things.

[tatewise]

OK, how would 2. Run this plugin (which installs all libraries that other plugins might install) actually work?
How can it install libraries? If you can get that to work, I take my hat off to you, and we can call a halt to this thread.
Sorry, but you keep saying the same thing, but do not explain what download mechanism such a Plugin would use.

What we could do is put ALL the library modules into one comprehensive ZIP file, which is manually downloaded and its contents unpacked into the Plugins folder.

[Valkrider]

@Mike

Given what you have said about plugins not being able to do this, it is something that i wasn't aware of.

I will dust off my Python knowledge and see if I can knock-up a simple programme for the Mac to do this with one zip file. It won't be any time soon though.

I am working through a couple of other options with the Codeweavers support at the moment to see if we can finally get winhttp installed in Crossover. But I have run into some 32bit vs 64bit bottle issues so probably need to create a new bottle.

[ColeValleyGirl]

Once winhttp is enabled (and I recognize that's still problematic, to achieve it reliably, and a manual step) a plugin that runs loadrequire for every library in turn would do the job.

[tatewise]

Helen, I don't see the point.
If winhttp can be installed in all Mac/Linux/WINE environments, then it is identical to the Windows environment, so such a Plugin would be applicable to Windows too, but it has never been proposed for Windows.
Why would it be so beneficial to a Mac/Linux/WINE environment and not a Windows environment?

Whenever a Plugin needs a library it downloads it once when first run, and never does so again.
Any other Plugin needing the same library uses the installed copy. So libraries only get downloaded once anyway.

BUT none of the above represents a problem. It is getting winhttp installed that IS the problem.

[Valkrider]

@Mike

Just a thought what process does FH itself use for updates? The reason for asking is that Crossover copes happily with updating versions of FH say from 6.2.x to 6.2.7. Why can't plugins use the same method and not use winhttp.

Still working with Codeweavers about the winhttp issue though.

[ColeValleyGirl]

Is ftp an option?

[tatewise]

We would have to ask Calico Pie what FH uses, but as suggested by Helen, it may be ftp.

A quick check in C:\Windows\System32\ and C:\Windows\SysWOW64\ lists ftp.exe and msieftp.dll.
We would have to experiment with something like local ftp = luacom.CreateObject("ftp.application") or perhaps os.execute(ftp,...)?

Does Crossover/POL/POM have an ftp component installed by default?

[ColeValleyGirl]

I think socket has ftp support as well?

We'll need a site with anonymous ftp access to test...