Jeremy Newman : WWN 408
Jeremy Newman
jnewman at winehq.org
Fri Dec 3 10:18:31 CST 2021
Module: website
Branch: master
Commit: a513721d10894df4261dace3feae4baabbc462c3
URL: https://source.winehq.org/git/website.git/?a=commit;h=a513721d10894df4261dace3feae4baabbc462c3
Author: Jeremy Newman <jnewman at codeweavers.com>
Date: Fri Dec 3 10:17:52 2021 -0600
WWN 408
---
news/en/2021120301.xml | 12 +++++++++++
wwn/en/wn20211203_408.xml | 55 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 67 insertions(+)
diff --git a/news/en/2021120301.xml b/news/en/2021120301.xml
new file mode 100644
index 00000000..3dc6ef00
--- /dev/null
+++ b/news/en/2021120301.xml
@@ -0,0 +1,12 @@
+<news>
+ <date>December 3, 2021</date>
+ <title>World Wine News Issue 408</title>
+ <body>
+ <a href="{$root}/wwn/408">WWN Issue 408</a> was released today.
+ <ul>
+ <li><a href="{$root}/wwn/408#Tryptophan and Turkey OR The Curious Case of Wine and PE">Tryptophan and Turkey OR The Curious Case of Wine and PE</a></li>
+ <li><a href="{$root}/wwn/408#Conversion to PE Files">Conversion to PE Files</a></li>
+ <li><a href="{$root}/wwn/408#Code Freeze">Code Freeze</a></li>
+ </ul>
+ </body>
+</news>
diff --git a/wwn/en/wn20211203_408.xml b/wwn/en/wn20211203_408.xml
new file mode 100755
index 00000000..839b839a
--- /dev/null
+++ b/wwn/en/wn20211203_408.xml
@@ -0,0 +1,55 @@
+<kc>
+ <title>Wine Traffic</title>
+ <author contact="mailto:wwn at winehq.org">Cressida Silver</author>
+ <issue num="408" date="12/03/2021"/>
+ <intro>
+ <p>
+ This is the 408th issue of the World Wine News publication. Its main goal is to inform you of what's going on around Wine.
+ Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer.
+ Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code,
+ but it can optionally use native system DLLs if they are available. You can find more info at <a href="http://www.winehq.org">www.winehq.org</a>
+ </p>
+ </intro>
+
+
+ <section title="Tryptophan and Turkey OR The Curious Case of Wine and PE" subject="" archive="" posts="">
+ <p>
+ I realize that the 408th issue of WWN is arriving a week late. I blame Thanksgiving and all that <a href="https://en.wikipedia.org/wiki/Tryptophan#Turkey_meat_and_drowsiness">
+ Tryptophan in turkey</a> for missing my deadline last Friday. I don't care that Wikipedia says it is a myth. Why else would I be so tired after eating several plates of
+ turkey, stuffing, mashed potatoes, corn, and candied yams?
+ </p>
+
+ <p>
+ No need to debate, I ate the turkey and I got tired. Seems like a simple case of cause and effect.
+ </p>
+ </section>
+
+ <section title="Conversion to PE Files" subject="Wine Overview" archive="" posts="">
+ <p>
+ On Windows, all system libraries are Portable Executable (PE) files. Before version 5.0, Wine provided its implementation of Windows libraries and <i>.so</i> (ELF or MachO) files in such a way that they behaved like PE files. Though effective in many scenarios, a need for a 32on64 solution and some lingering compatibility issues prompted changes to this format.
+ Beginning in Wine 5.0, most modules were built in PE instead of Executable and Linkable File (ELF) format. The PE binaries were copied into the Wine prefix, not the DLL files, making it look more like a Windows installation. Several core DLLs (e.g., NTDLL, KERNEL32, GDI32, and USER32) were converted to PE in Wine 6.0.
+
+ More closely resembling a Windows installation improves the functionality of applications using Digital Right Management (DRM) schemes that require on-disk system module content to be identical to the in-memory content. However, PE files can't link directly to Unix libraries. For this reason some modules in Wine have both PE and <i>.so</i> libraries. This allows the PE library to call into its <i>.so</i> library, which can then perform the Unix call. This process is like an OS syscall or kernel call, and it's treated as such.
+ </p>
+
+ <p>
+ Another class of applications that benefit from this are Windows debuggers, which don't expect non-PE modules. Conversion to PE means that debuggers now understand Wine built-in modules and the execution of native libraries is hidden from the debuggers using syscall interface.
+ </p>
+
+ <p>
+ Let's get back to the 32on64 issue. It was a prominent reason for the PE conversion. The goal is for Wine to execute 32-bit code in 64-bit Unix, and not require 32-bit host libraries. In such cases, there will be only the 64-bit versions of Wine Unix libraries, but both 64-bit and 32-bit PE libraries. Whenever a 32-bit application calls a Unix function, it will use a mechanism built around syscall interface to switch between 64-bit and 32-bit mode. This architecture also makes it possible to support other multi-arch scenarios. Furthermore, this architecture will also solver an issue arising when macOS and Windows both attempt to use the %gs base register for threading support. There are hacks currently in place for this, but they are not reliable. A clean separation of Unix and PE code with a syscall interface will potentially make it possible to switch between Unix and Windows %gs base.
+ </p>
+
+ </section>
+
+ <section title="Code Freeze" subject="Wine Code Freeze" archive="" posts="">
+ <p>
+ Save the date. The Wine code freeze is set to begin on December 10th, 2021. This means Wine 7.0 is just around the corner. Happy Holidays, indeed!
+ </p>
+
+ <p>
+ P.S. With Wine 7.0, very few (but tricky!) modules will remain unconverted to PE.
+ </p>
+
+ </section>
+</kc>
More information about the wine-cvs
mailing list