Ok, for one thing, I did all the research for that EFI booting method on my own. I have not once laid eyes on your code for that, I spent hours on the Intel EFI shells and scripting page (https://software.intel.com/en-us/articles/efi-shells-and-scripting) learning the EFI shell commands and the like. I noticed that a file, "apfs.efi", was located in the /usr/standalone/i386 directory of a High Sierra install. Figuring that was an efi driver, I tested that theory by experimenting using it in rEFInd. I installed rEFInd to my ESP and placed apfs.efi in rEFInd's drivers directory. Sure enough, this allowed rEFInd to detect the APFS volume, so I decided to try the same in an EFI shell. I then loaded up a shell and ran "load fs0:/apfs.efi" after placing it in the ESP of the disk. Noticing that this worked after running "map -r", which refreshes the available filesystems in the EFI, I thought of simply calling S/L/CS/boot.efi from the shell. Sure enough, that booted OS X. Then, while writing the script, I ran into a snag where I would get a "Can't read from file - Media changed" error. That's when I found, after more research, for the necessity of "set -v efishellmode 1.1.2" and "connect -r", and using map -n instead of map -r. (found on this webpage). Adding those commands to the script fixed that issue, so I finished it up and released it as a solution. Once again, I did all the research for this MY SELF, and it is purely a coincidence that we arrived at the same conclusion. So please, do not accuse me of ripping off your work, as I did not (how would I have gotten it anyways? You never posted it publicly). And, I notice you point out that, because I named the file "startup.nsh", you imply that I stole your source file. Well, if you didn't realize, that's what the startup script HAS to be named for the EFI shell to execute it. I could go on all day outlining the researching and experimenting process I went through with every other component to my patcher, and none of it involves looking at, or even downloading any piece of software you have linked on this forum.An Open Letter to the Unsupported Mac Community
Hello! I'm Foxlet, one of the developers in the unsupported Mac community who made tools such as AUSEnabler, NightEnabler, newCore, FetchMacOS, and APFSBoot, and have been working on getting High Sierra to work on unsupported Macs as of the latest.
Even when Apple may not be supporting the latest macOS on older, but still capable machines, it's exciting to see many users on the MacRumors community helping to get around the limitations of the installer and the operating system to give new life to these older machines. It's also a great learning experience for those unfamiliar with macOS's underlaying technologies, and generally it's just fun.
I want to talk about two things: Honesty and openness. It's at the very core of what drives many of the users here to develop the tools to enable these machines to work. We learn from each other through openness and communication, and everyone gets to fairly pitch in their work in improving the tools that allow these Macs to run macOS. One example of a community that has done this well is the Hackintosh Community, but even them can have one or two people with the problems that are to be noted.
As of recently, many of you have noticed that I have not recently released any tools or spoken much in the forums. Some may have thought I was in a hiatus or that I had become disinterested in macOS High Sierra. I would like to take this time to explain why I have been seemingly inactive recently.
If you have recently gotten a copy of the macOS High Sierra Patcher with dosdude1's latest technique for booting APFS without a helper partition, I would like you to open the app's Package Contents, and navigate to Contents/Resources/macOS Post Install.app/Contents/Resources. Inside the Resources folder exists a file called startup.nsh. This is the primary script that powers that APFS boot technique.
I would've liked to commend dosdude1 for the time taken to research and develop that technique, had it actually been his work alone. Unfortunately, that isn't the case. What is actually the case is that said APFS boot technique isn't his original work at all. If you were to look at the credits for the application and his recent posts, you might be inclined to believe it was his work. What is actually true is that the real author is never mentioned at all. This is where honesty is involved.
Namely, one of the projects mentioned above, APFSBoot, has a script that controls the boot logic for APFS under EFI. Said script starts a little like this:
Note line number 8 in the source code. It seems like an important line. In reality, it doesn't serve much of an effect to the application. It merely a driver double check. Someone who was aware of the implication would've probably never included that line at all. However, someone who wasn't completely informed but had seen the source code to APFSBoot would've copied it without a second look.
In either case, my source code included that line, and the seemingly original technique by dosdude1 included the very same dummy line, followed by slightly modified version of the logic that is included in APFSBoot itself, as to get around possible suspicion. Notably, APFSBoot had yet to be released except to a small group of users, so this is even more concerning as it was done without permission.
This isn't the only concerning part of the technologies previously included in dosdude1's series of patchers. If you've seen the new macOS download feature in his patcher, you might have noticed that it pulled the installation data from Apple directly. In a similar story, it appears to be original work, but in reality, it merely copies the techniques shown in FetchMacOS. Further examples include the technique of using El Capitan as an installer base (in newCore), and even earlier than that, the AUSEnabler technique had been included (albeit with credit) in his patcher, but without permission or source code. I had to ask dosdude1 to remove it after the fact.
This leads to the second point in the letter, openness. His tool is useful and relatively user friendly, but in the aspect of explaining what is patched in the system or documentation of the techniques used, it falls short. His tool is closed source, and at first sight it would be somewhat difficult to understand how exactly the program is setting up an macOS Installer. All of the releases for newCore, FetchMacOS, and APFS have had source code included as an inherent part of how the program is written, even going back to AUSEnabler being in AppleScript as to be easily readable by the user.
Even with openness, I have gone a bit further by never asking for donations. It is all for the community to enjoy and further share the tools with the same openness of the original. Unfortunately, dosdude1 has been taking donations for his patcher, which is fine by itself, but knowing that much of it is taken from an uncredited author, it seems odd that monetary support is going to the person who never truly developed those techniques at all.
In the end, this is the experience I expected to encounter with some of the developers in this community. I originally only wanted to get my personal MacBook Pro to work with the latest macOS, and to help the rest of the community in these developments.
Due to this situation, I have decided to no longer release any remaining tools in the set, and while I would like to help the rest of the community in this forum, I don't think it's appropriate to do so if it will mean that it will be taken without really giving back the same knowledge.
Honesty and openness. I would very much like if dosdude1 would consider those qualities even more, because in the end, it is the community who helps one another.
Thanks for reading.
(tl;dr: macOS High Sierra Patcher took code and techniques from FetchMacOS, APFSBoot, and newCore, while leaving it uncredited and dosdude1 claiming it his own).
Last edited:
