My Journey of Running WineHQ

The Problems with Homebrew

The Next Option (only option)

Debugging Wine

Building a Disk Image for My OS

The Conclusion 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 levelprograms like kernels and cross platform development. I am recently writing code for my Valecium OSproject and also trying to get WineHQ running on a Mac without Rosetta2(for aarch64 Windows apps), which I think are some common use situationsfor low level and cross platform development. My target for Wine on Mac is that I can have a working Wine 11. WithWine able to run aarch64 Windows executables on my host, and not useRosetta, while also enabling 64-bit executables. Originally, I thought it was easy as to just download it from Homebrewand run it right out of the box, but I was wrong. Very wrong... Note: I don't use Crossover because the public repositoryonly supports Wine 9 The first problem I encountered with Homebrew was that it gave me awarning saying 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 reasonI did not do so was because Wine had a large dependency chain, and Idon't want to install everything again on MacPorts since I have Homebrewalready. The next logical option for me was to just compile from source, Ialready have all the dependencies, and the only thing I have to specifyis –-enable-win64 –-with-mingw and set the Bison path to myHomebrew Bison. But Autoconf wants a LLVM MinGW toolchain, while the Homebrew MinGWtoolchain was only for GCC, and I also had to compile LLVM MinGW myselfby usingMstorsjo's LLVM MinGWcompiling script which was very and got this working, and surprisinglythe entire set of toolchain was only 300MB. Finally, Autoconf passed smoothly with no problem, and I was imaginingthe next steps will be the same, but no. Make did compile all the things, and generated the final Wineexecutable, but when I try to run it with a built-in application likenotepad, the process will die instantly, after I launched it. So I wentto the Interent to search for answers. 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 appsthat 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 tospend that much time modifying the source code, so I decided to findother ways. Until this blog was published, I still did not get Wine running on myMac. 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, theydon'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 Macbecause Apple decided to reduce the compatibility on low level tools. Another very needed tool was not supported, Libguestfs. This is notApple's fault, but only because it needs a Linux kernel to operate, andit depends on the host's Linux kernel, which Macs do not have, andmaking it not operate on Macs very good although Mac is marked as"supported". And finally is fuse filesystems, is a key thing. The guestmount fusefilesystem does not work, and the fuse filesystem support from 2efsprogsalso does not work for Macs. Macfuse is the only option. So, I shared my journey on the 2 things I tried to do on a Mac aboutprogramming, and unfortunately they failed, and it was all for reasonsthat you cannot really solve without a very large effort that I don'treally 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 hostileto these type of development, and you can know this by a series ofaction they did. Deprecated OpenGL, X11 support, Single User Mode,OpenSSH, Bash, Unix directory access (/System is under SIP), forcesignatures to execute excutables, and deprecating Rosetta in thefuture. Not all of them are Apple's fault, I understand that Apple is tryingto create a "safe" environment for people that are not developers, orjust having an operating system for normal daily tasks. And I appreciatethat 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. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse