| From: James Knott via talk <talk@gtalug.org> | On 2020-01-23 11:42 AM, D. Hugh Redelmeier via talk wrote: | > This means that it will ill-become them to legally stomp on WINE. | > That's a Good Thing. But it isn't working to improve WINE. | | 'The Wine 5.0 update | <https://source.winehq.org/git/wine.git/blob_plain/wine-5.0:/ANNOUNCE> takes | advantage of this two-way street, introducing Portable Executable (PE) | modules, which are built in the Windows binary PE file format that's used in | executables and DLLs. | | According to Wine developers, now the "PE binaries are copied into the Wine | prefix instead of the fake DLL files", making the prefix look "more like a | real Windows installation, at the cost of some extra disk space."' | | Where do you think that PE stuff came from? PE is an executable format. Just like ELF. <https://en.wikipedia.org/wiki/Portable_Executable> So the PE Binaries are just those from the program you are trying to run or part of the WINE system. (If I remember correctly, there is a temptation to copy some DLLs from Windows to support certain features but I think that would probably a copyright violation. I don't see anything saying that Microsoft now authorizes this.) WINE is using a different way of plumbing these bits of object code. I haven't noticed any of this containing a contribution from Microsoft. For example, the WINE Announcement says: - Most modules are built in PE format (Portable Executable, the Windows binary format) instead of ELF when the MinGW compiler is available. This helps various copy protection schemes that check that the on-disk and in-memory contents of system modules are identical. I read that to mean "Most WINE modules". In other words, WINE is using a new representation for the compiled version of its own modules. I infer that the MinGW compiler is able to produce PE modules. Without source code MinGW isn't a way to get PE modules. And WINE probably doesn't have access to source for MS programs or libraries.