I know that this may make some of you disagree, but in this blog, I will
explain exactly why I don't like using a Mac to develop low level
programs like kernels and cross platform development.
I am recently writing code for my Valecium OS
project and also trying to get WineHQ running on a Mac without Rosetta2
(for aarch64 Windows apps), which I think are some common use situations
for low level and cross platform development.
My Journey of Running WineHQ
My target for Wine on Mac is that I can have a working Wine 11. With
Wine able to run aarch64 Windows executables on my host, and not use
Rosetta, while also enabling 64-bit executables.
Originally, I thought it was easy as to just download it from Homebrew
and run it right out of the box, but I was wrong. Very wrong...
Note: I don't use Crossover because the public repository
only supports Wine 9
The Problems with Homebrew
The first problem I encountered with Homebrew was that it gave me a
warning saying
Warning: wine@devel has been deprecated because it does not pass the macOS Gatekeeper check! It will be disabled on 2026-09-01.”
And as a person that does not like using things that will be deprecated,
I decided to not use homebrew to install WineHQ.
You may also want to know why I don't use MacPorts, and the only reason
I did not do so was because Wine had a large dependency chain, and I
don't want to install everything again on MacPorts since I have Homebrew
already.
The Next Option (only option)
The next logical option for me was to just compile from source, I
already have all the dependencies, and the only thing I have to specify
is –-enable-win64 –-with-mingw and set the Bison path to my
Homebrew Bison.
But Autoconf wants a LLVM MinGW toolchain, while the Homebrew MinGW
toolchain was only for GCC, and I also had to compile LLVM MinGW myself
by using
Mstorsjo's LLVM MinGW
compiling script which was very and got this working, and surprisingly
the entire set of toolchain was only 300MB.
Finally, Autoconf passed smoothly with no problem, and I was imagining
the next steps will be the same, but no.
Make did compile all the things, and generated the final Wine
executable, but when I try to run it with a built-in application like
notepad, the process will die instantly, after I launched it. So I went
to the Interent to search for answers.
Debugging Wine
After going on the Internet I found that the potential problems:
The executable was not signed, and it could not run
Wine Preloader was not able to reserve the low 4GB of memory
16KiB page sizes on Mac could not be used on with Windows apps
that uses a 4KiB page size
So I started with the first one, as it was just a single shell command,
and of course it did not work, as the same error message was returned.
The next problems were really not what I can solve as I didn't want to
spend that much time modifying the source code, so I decided to find
other ways.
Until this blog was published, I still did not get Wine running on my
Mac.
Building a Disk Image for My OS
The standard way of building a disk image also does not work on a Mac,
you can see how does it work base on my previous blog, Building Bootable Images in Userspace: Avoiding the Loop Device Trap,
they all use specific Linux commands, and although Mac is Unix, they
don't work.
GNU Parted - The standard tool for partitioning disks
Losetup - You cannot create loopback devices on Macs
Filesystems besides FAT - Mac cannot read them
GRUB - grub-install does not work
These are the very common OSDev tools, and they all does not work on Mac
because Apple decided to reduce the compatibility on low level tools.
Another very needed tool was not supported, Libguestfs. This is not
Apple's fault, but only because it needs a Linux kernel to operate, and
it depends on the host's Linux kernel, which Macs do not have, and
making it not operate on Macs very good although Mac is marked as
"supported".
And finally is fuse filesystems, is a key thing. The guestmount fuse
filesystem does not work, and the fuse filesystem support from 2efsprogs
also does not work for Macs. Macfuse is the only option.
The Conclusion
So, I shared my journey on the 2 things I tried to do on a Mac about
programming, and unfortunately they failed, and it was all for reasons
that you cannot really solve without a very large effort that I don't
really think I will take, and it was not that worth it.
And what I want to say with this blog is that Apple is still hostile
to these type of development, and you can know this by a series of
action they did. Deprecated OpenGL, X11 support, Single User Mode,
OpenSSH, Bash, Unix directory access (/System is under SIP), force
signatures to execute excutables, and deprecating Rosetta in the
future.
Not all of them are Apple's fault, I understand that Apple is trying
to create a "safe" environment for people that are not developers, or
just having an operating system for normal daily tasks. And I appreciate
that Apple is doing so, but for development.
Macs are not good for them (especially low level and cross platform),
and Apple is trying to make it so.
Top comments (0)