winetricks icon indicating copy to clipboard operation
winetricks copied to clipboard

win7sp1 is huge

Open zfigura opened this issue 3 years ago • 7 comments

Both architectures together take up 1.5 GB, which is a lot. It'd be nice if we didn't have to save that whole 1.5 GB in cache.

I'm opening an issue here to throw out a proposal or two wrt making it smaller. Feel free to close if none of these are to your liking.

My use case (which admittedly is very unusual) for this redist in particular is that I like to use winetricks directshow and then run crosstests against native DLLs without a whole Windows installation. This means that I do want to be able to frequently install quartz/qcap/etc. into a new prefix.

Idea 1: Instead of caching the whole redist, cache the DLLs winetricks might extract from it and throw away the binary.

The full list is: amstream, dxdiagn, esent, gdiplus, iertutil, mf, mfc40, mfc40u, msdelta, msftedit, oleaut32, pdh, prntvpt, qasf, qcap, qdvd, qedit, quartz, secur32, urlmon, usp10, webio, wininet, xmllite.

I think that should come out to about 40-50 MB total (it's 21 MB for x64; didn't check x86). That actually seems reasonable to cache. Of course it means that we'll need to redownload the whole redist if we ever extract another file from it, but that seems reasonable enough to me.

Idea 2: Shrink that even further by only caching the requested DLLs. This does mean redownloading the redist potentially more often, but it honestly seem that unreasonable to me either. Most of the above DLLs aren't commonly useful, and I think the ones that are generally aren't useful in combination with others, except for the directshow ones. On the other hand, this frees a lot less space relative to idea 1, so it's probably not worthwhile anyway.

zfigura avatar Dec 22 '20 21:12 zfigura

Howdy Zeb,

Been thinking it over, I don't like the idea of throwing away the cache by default, but I'm open to a compromise solution around idea 1. I.e., have helper_win7sp1 check for the cached dll, and if that's not present, check for the full redist, and if that's not available, download it. From there, I'm not sure what's the best way forward. Just brainstorming, but my initial thoughts would be to extract the dll(s) to the win7sp1 cache, and then copy from there to the prefix/regsvr/etc. Maybe warn the user that they can then delete the redist if they wan to save space.

If a user then runs the same command again, the dll is cached and is copied again. If the user wants a different dll, it would then go through the same logic (and for me/most users, would extract from the existing redist, for you or anyone else who saved space, would download again, cache the new dlls, and warn again).

I run winetricks/winetricks-test a fair amount, don't really want that to get lost all the time (particularly when someone sends a PR to add a new dll from that list ;)).

austin987 avatar Jan 08 '21 09:01 austin987

I think that solution seems like a good compromise; I'd be happy with it at least. I'll look into writing a patch.

zfigura avatar Jan 11 '21 01:01 zfigura

I have noticed that as well. This week I needed to download win7sp1 (550 MB or something close to that) just to use a DLL from inside of it that was 30 kilobytes.
Here's the way I see things: you guys worry about not distributing files that could be considered "pirate" distributing, and that's a legitimate worry to have, I agree. But in the end you're using these files just the same. Wouldn't be easier to maintain a separate repository only with copies of these files that you need? It seems to me like if Wine was really a problem to Microsoft and to the authorities, the project wouldn't have lasted as long as it is doing for so many years.
I feel like this is the same non-issue as the "mp3 and codecs" debacle from few years ago on most major Linux distributions. After 2016 or so they realized it was a non-issue so they started including the pre-installed audio/video codecs with linux distros. And nobody cared. Literally nobody cared. It was a non-issue.

DwarfFighterCleric avatar Feb 02 '21 01:02 DwarfFighterCleric

The binaries themselves typically have licenses allowing redistribution, individual files do not.

I for one don't want to risk dealing with Microsoft's lawyers, particularly for potential infringement on a site hosted by them. In particular for something that I do as a hobby, without corporate legal cover.

austin987 avatar Feb 02 '21 01:02 austin987

pi@raspberrypi:~ $ du -sh ~/.cache/winetricks/win7sp1
538M	/home/pi/.cache/winetricks/win7sp1

I dont have Windows 7 installed, just bits of it that are installed from the "DLL Section" (see #1752).

there is another issue/thread about storing "old microsoft programs" (#1696), if (programable?) server space is found, either the binary could be extracted allowing individual (dll) files to be grabbed, or an interface to a url that returned the extracted (dll) file directly from an extraction process (more horsepower, RAM(?) and time needed to serve these)

The main issue I see with both of these, is the need to record individual (dll) file SHA checksums, which already makes winetricks (script) pretty big. if the security & integrity of the individual files could be maintained (say by extracting and burning to CD or DVD that was then mounted as a regular FileSystem download) there would be no need for the (dll) file checksums

as I mentioned in the other thread, if someone took the time to talk with Archive.Org, I am sure there may be a way to do this where "Microsoft gives there blessing" (because they are no longer supported, out of liscence binding, etc - we can hope - or maybe because they sponsor a MS retro server at Archive.Org for url downloads)

notes:

  • there are often time I cant get to web.archive.org but I can get to archive.org (where they store the speciality downloads)
  • the OP goes for alot of the base fonts which come from the PowerPointViewer download (which breaks for me atm)

paulwratt avatar May 16 '21 10:05 paulwratt

It seems to me like if Wine was really a problem to Microsoft and to the authorities, the project wouldn't have lasted as long as it is doing for so many years.

The signs of legal pressure are abundant over winehq.org - A beautiful combination of treading lightly with a defiant grin. You can be certain that Microsoft considers it a problem. Wine is the only project that enables Windows binaries to run on Linux. Steam uses it. CrossOver and Lutris use it. Even ReactOS uses it. Outside of those, you just have Windows guest VMs, which means you're still running Windows. If any of the core developers slipped up and mentioned having directly reverse engineered a windows binary or had seen windows source code in the past, that would be bad news for Wine. It wouldn't kill it entirely, but Valve would be force to stop using it, and the main Linux distros might even stop officially supporting it.

biorpg avatar May 24 '21 07:05 biorpg

I'm not sure if anyone knows this, but the binaries are still up on Windows Update. Not sure if they're system generated and if the file name changes between downloads or at intervals tho. Also, not sure how long it's going to stay up on the site. 32-bit Win7 SP1: http://download.windowsupdate.com/msdownload/update/software/svpk/2011/02/windows6.1-kb976932-x86_c3516bc5c9e69fee6d9ac4f981f5b95977a8a2fa.exe 64-bit Win7 SP1: http://download.windowsupdate.com/msdownload/update/software/svpk/2011/02/windows6.1-kb976932-x64_74865ef2562006e51d7f9333b4a8d45b7a749dab.exe

RAMChYLD avatar Aug 16 '21 20:08 RAMChYLD