Release v3.4

_posts/2022-03-21-why-not-p3.md

@@ -48,7 +48,7 @@ After numerous disagreements with that contributor, including but not limited to
 
 It is widely known (and even shown in the cover of our [v3.0 release post](/2021/12/01/86box-v3-0.html)\) that with a new enough Super Socket 7 or Pentium II setup, you can actually run Windows 7 on 86Box. But "running" is a **massive overstatement**: Windows versions beyond XP were originally designed for much newer hardware than 86Box can emulate at full speed on modern computers, even if you take Microsoft's official minimum requirements into account. Windows Vista and 7 were never meant to even boot on Pentium 1 systems, but Microsoft was pandering to the <a href="https://www.google.com/search?q=%22Vortex86%22+%22Windows+7%22" title="Vortex86 is a Pentium 1-class CPU from the Windows 7 era">embedded computing industry</a> at the time by avoiding intentionally breaking support for these old CPUs, and <a href="http://web.archive.org/web/20110814164028/http://support.microsoft.com/kb/980358" title="KB980358 fixes a BSOD when booting Windows 7 RTM on a Pentium 1">sometimes even fixing it in updates</a>. This changed with Windows 8, which required a late model Pentium 4 with the SSE2 instruction set and NX bit feature at a bare minimum; Windows 7 also eventually received updates which required a Pentium III with SSE at a minimum.
 
-As a result of this, we've been getting many requests to emulate newer CPUs so that 86Box can "run Windows 8 and 10". Even if such CPUs were to be implemented, the user experience would be **extremely painful**; as outlined earlier, there is no host system in existence which can consistently keep up with the fastest CPUs we already emulate, let alone faster ones. Running newer versions of Windows on 86Box is just as much of a questionable endeavor as it is on an equivalent real system: it's a fun experiment maybe worth making a [YouTube video](https://www.youtube.com/watch?v=Zs8-rQKvptM) about, and nothing more. Everything will be so slow you won't even want to open a web browser (if they run at all due to CPU requirements). Just stick to Windows 98 or 2000, maybe XP if your host system is capable; for newer versions, **virtualizers exist**, you know.
+As a result of this, we've been getting many requests to emulate newer CPUs so that 86Box can "run Windows 8 and 10". Even if such CPUs were to be implemented, the user experience would be **extremely painful**; as outlined earlier, there is no host system in existence which can consistently keep up with the fastest CPUs we already emulate, let alone faster ones. Running newer versions of Windows on 86Box is just as much of a questionable endeavor as it is on an equivalent real system: it's a fun experiment maybe worth making a [YouTube video](https://www.youtube.com/watch?v=Zs8-rQKvptM) about, and nothing more. Everything will be so slow you won't even want to open a web browser (if they run at all due to CPU requirements). Just stick to Windows 98, maybe 2000 or XP if your host system is capable; for newer versions, **virtualizers exist**, you know.
 
 While we have fixed emulation bugs explicitly related to newer Windows versions (`STI` interrupt blocking during `SYSENTER`/`SYSEXIT`, incrementing of `RDTSC` in dynamic recompiler mode, etc.), it was all done on **principle**: there might be another older operating system or application out there which runs into the same bug. Theoretically, you don't need to be running Windows XP to stumble upon incorrect `STI` behavior, or Windows 7 to hit a division by zero caused by `RDTSC` returning the same value twice.
 

_posts/2022-04-20-86box-v3-4.md

@@ -0,0 +1,66 @@
+---
+layout: post
+title: "86Box v3.4"
+description: "Release for April 2022, now with macOS support."
+authors: ["richardg867"]
+image: "/assets/images/v3.4/hero.png"
+---
+
+{% include imageheading.html url="/assets/images/v3.4/hero.png" separator=" " %}
+
+This is the April 2022 update to 86Box, bringing **macOS support**, bugfixes and other behind-the-scenes work. As always, you can [download 86Box v3.4 from GitHub](https://github.com/86Box/86Box/releases/tag/v3.4).
+
+<hr />
+
+## Now with macOS
+
+Continuing on the cross-platform development effort started during [v3.0]({% post_url 2021-12-01-86box-v3-0 %}#linux) and first released for Linux on [v3.2]({% post_url 2022-02-16-86box-v3-2 %}#now-with-linux), we now provide **Intel macOS** builds of 86Box. These should work on macOS High Sierra 10.13 and newer, natively on Intel Macs and through Rosetta 2 on Apple Silicon Macs. [dob205](https://github.com/dob205) was our main macOS tester, while [**jgilje**](https://github.com/jgilje), [**Cacodemon345**](https://github.com/Cacodemon345) and other contributors did the OS integration work.
+
+As with Linux, there is currently no 86Box manager for macOS, but you can manage emulated machines by **making copies** of `86Box.app`; the `roms/` directory (containing the ROM set) must be placed next to the .app ([example](/assets/images/v3.4/roms.png)\), and the emulated machine's files will be saved next to the .app as well.
+
+### But where's Apple Silicon?
+
+We haven't forgotten about our promise for Apple Silicon support. Tests done by the community show that the M1 and M1 Pro are among **the best CPUs** you can currently get for running 86Box natively, and Rosetta 2 can leave quite a bit of performance on the table.
+
+As it turns out, a cross-platform project like 86Box is **nearly impossible** to compile for Apple Silicon Macs without **actual hardware**. While the aforementioned community testers managed to compile and run 86Box for Apple Silicon on their own M1 machines, we cannot replicate that in a way we can distribute through [Jenkins](https://ci.86box.net/job/86Box/) or regular releases, since we only have access to Intel hardware; while tools like [Homebrew](https://brew.sh) and [MacPorts](https://www.macports.org) can compile for Intel on Apple Silicon systems, they can't do the opposite.
+
+Apple hardware is expensive. While their chips provide good performance for the money, the machines are still costly upfront, and **we can't afford them**. Renting a Mac Mini from a hosting company also costs more than our entire hosting bill, and while there is one such company out there providing free M1 hardware to open source projects, their offering is **not available to us**. If you want native 86Box on Apple Silicon to become a reality, consider [making a donation](https://paypal.me/86Box) or [joining our Patreon](https://www.patreon.com/86box); contributing will help us get our hands on that hardware in one way or another.
+
+<hr />
+
+## Changelog
+
+### Emulator
+
+* Added provisions for **system-wide ROM directories** on all platforms (to be documented soon)
+* Added **32-bit x86** architecture to Linux builds
+* Fixed crash on startup caused by **missing disk image files**
+* Fixed **keyboard input** when the mouse is not captured
+* Fixed mouse input with **Remote Desktop** on Windows
+* Fixed occasional crash with a `do_seg_load()` message
+* Fixed incorrect executable path displayed on the **stdout log** on Linux
+* Updated translation: **Portuguese (Portugal)**
+
+### User interface
+
+* Fixed **emulated screen size** being off by one pixel on some Linux systems
+* Fixed creation of **differencing VHD** disk images
+* Fixed **Settings button** incorrectly enabled on network cards with no settings
+
+### Machines
+
+* Temporarily removed the **Compaq Deskpro 386** while we figure out what went wrong with it on v3.3; the functionally-equivalent **Compaq Portable III (386)** can be used instead
+
+### Hardware
+
+* **Sound**
+  * Fixed playback start delay issues with certain drivers on the **C-Media CMI8738**
+  * Changed **FluidSynth** to fall back to the system soundfont if none is set on Linux
+* **Network**
+  * Slightly improved **PCap** performance on Linux
+
+### Known issues
+
+* **Mouse input** does not work properly on some Linux hosts, especially when dragging with a button held down. This issue dates back to v3.2, but it can now be worked around by starting 86Box from a terminal with the `EMU86BOX_MOUSE` environment variable to `evdev` (and making sure your user is part of the `input` group or otherwise has the right permissions to access `/dev/input/event*`), for example: `EMU86BOX_MOUSE=evdev ./86Box-Linux-....AppImage`
+* The host mouse cursor may **escape the 86Box window** when using the aforementioned workaround
+* While mouse movement through **Remote Desktop** on Windows hosts was fixed, it still isn't perfect

index.md

@@ -17,7 +17,7 @@ Features
 
 <a name="downloads" />Downloads
 -------------------------------
-The latest stable version of 86Box is **v3.3**, which was released on March 18, 2022, and is available from our [GitHub repository](https://github.com/86Box/86Box/releases/tag/v3.3).
+The latest stable version of 86Box is **v3.4**, which was released on April 20, 2022, and is available from our [GitHub repository](https://github.com/86Box/86Box/releases/tag/v3.4).
 
 We also offer [nightly builds](https://ci.86box.net/job/86Box), which are built from the latest source code, but may not be as stable and/or optimized as stable builds.
 
@@ -26,7 +26,7 @@ Minimum system requirements and recommendations
 * Intel Core 2 or AMD Athlon 64 processor
 * Windows version: Windows 7 Service Pack 1, Windows 8.1 or Windows 10
 * Linux version: Ubuntu 16.04, Debian 9.0 or other distributions from 2016 onwards
-* macOS version (currently nightly builds only): macOS 10.13 High Sierra
+* macOS version: macOS High Sierra 10.13
 * 4 GB of RAM
 
 Performance may vary depending on both host and guest configuration. Most emulation logic is executed in a single thread; therefore, systems with better IPC (instructions per clock) generally should be able to emulate higher clock speeds.