Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
hey @pkouame , since with your hybrid light/dark mode you're already inside the Appkit.framework Xcode's code, take a glance here:

https://developer.apple.com/documentation/appkit/nsvisualeffectview

https://stackoverflow.com/questions...style-view-with-translucent-blurry-background

It may help for yours experiments.

I've noticed that the "transparency effect" into Finder menu bar, Finder side bar, Safari Favorites background, are essentially "blur opacity", that in Mojave "light mode" OpenGL case glitch to a solid dark grey color.

I suppose that this function that handles with "blurs" could be the key:
https://developer.apple.com/documentation/appkit/nsvisualeffectview/1535468-blendingmode

edit:

Moreover, left "Vibrancy" on the side, patching the Appkit.framework, are you able to "paint" with NSColor function the finder menu bar into another color for ex. white or blue?

Or another workaround, could you try "reducing transparency" setting 0% opacity only into the finder menu bar main color? (In order to keep all the other transparencies Dock, Notification Center, Application "comic window" etc.)

I've done some attempts to isolate the transparency/opacity but I guess that these are not related to the CoreServices's "Finder.app".
Thanks - always appreciate any input on this ...
Yes, what Apple calls "vibrancy" (Dark or Light) is actually implemented using view compositing, blurs and blending modes at the opengl level (for some of our unsupported cards). All of these are combined as various "appearances". I'm currently waiting for GM as the code at this level is changing as we speak. Especially the dark/light mode appearance management methods. I thought it would be stable by now, but there have been enough changes between 7,8 and 9 (haven't looked into 10 yet) that chasing a bug is almost impossible.

What you should know is that the menu bar itself is almost completely handled in the Carbon framework. Which itself is composed of many frameworks, notably HIToolbox. There you'll find positive references to menu translucency. Mode switches in Preferences actually generate events and messages to these frameworks to switch the appearance of the top level menu bar. By the way, HIToolbox is also where the Apple logo is presented on boot, and where the logo switches contrast (if you've noticed) and backgrounds to black before login. Lots there.

I think the ultimate workaround that fixes the ugly Light Mode menu bar will have to start there. I'll crack this open again, once GM is released (hopefully sometime next week)
 
[QUOTE

I guess some issues are due to the APFS "software" EFI script patch, you'd need the risky APFS "hardware" EEPROM EFI Patch to use correctly the Mojave system update.

[/QUOTE]

@jackluke and @TimothyR734,

Does this "anomaly" apply to the Developer Preview Beta as well? Thanks.

P.S. I do not want or need to apply the "risky" APFS "hardware" EEPROM patch. I was just curious as to the anomaly. I'm fine with the re-install/patch process to update.
 
[QUOTE

I guess some issues are due to the APFS "software" EFI script patch, you'd need the risky APFS "hardware" EEPROM EFI Patch to use correctly the Mojave system update.

@jackluke and @TimothyR734,

Does this "anomaly" apply to the Developer Preview Beta as well? Thanks.

P.S. I do not want or need to apply the "risky" APFS "hardware" EEPROM patch. I was just curious as to the anomaly. I'm fine with the re-install/patch process to update.[/QUOTE]
The anomaly is you have to know your EEPROM model number as you could be presented with 2-3 choices you pick the wrong one you could brick your Mac
 
  • Like
Reactions: jackluke
@jackluke and @TimothyR734,

Does this "anomaly" apply to the Developer Preview Beta as well? Thanks.

P.S. I do not want or need to apply the "risky" APFS "hardware" EEPROM patch. I was just curious as to the anomaly. I'm fine with the re-install/patch process to update.
The anomaly is you have to know your EEPROM model number as you could be presented with 2-3 choices you pick the wrong one you could brick your Mac[/QUOTE]

I tried and recorded the error(s) I got when I first attempted it. See post #5551.
macOS 10.14 Mojave on Unsupported Macs Thread

Thanks.
 
  • Like
Reactions: olad
The anomaly is you have to know your EEPROM model number as you could be presented with 2-3 choices you pick the wrong one you could brick your Mac

I tried and recorded the error(s) I got when I first attempted it. See post #5551.
macOS 10.14 Mojave on Unsupported Macs Thread

Thanks.[/QUOTE]
Yes I get that same message when I try the APFS Rom Patcher on my MacBook 5,2
 
Thanks - always appreciate any input on this ...
Yes, what Apple calls "vibrancy" (Dark or Light) is actually implemented using view compositing, blurs and blending modes at the opengl level (for some of our unsupported cards). All of these are combined as various "appearances". I'm currently waiting for GM as the code at this level is changing as we speak. Especially the dark/light mode appearance management methods. I thought it would be stable by now, but there have been enough changes between 7,8 and 9 (haven't looked into 10 yet) that chasing a bug is almost impossible.

What you should know is that the menu bar itself is almost completely handled in the Carbon framework. Which itself is composed of many frameworks, notably HIToolbox. There you'll find positive references to menu translucency. Mode switches in Preferences actually generate events and messages to these frameworks to switch the appearance of the top level menu bar. By the way, HIToolbox is also where the Apple logo is presented on boot, and where the logo switches contrast (if you've noticed) and backgrounds to black before login. Lots there.

I think the ultimate workaround that fixes the ugly Light Mode menu bar will have to start there. I'll crack this open again, once GM is released (hopefully sometime next week)
Sounds promising. The Dark Mode is nice for some things, but I cannot use it all the time because some apps that have not been optimized for the Dark Mode show those white translucency effects on drop-down boxes, etc.
 
  • Like
Reactions: TimothyR734
Thanks - always appreciate any input on this ...
Yes, what Apple calls "vibrancy" (Dark or Light) is actually implemented using view compositing, blurs and blending modes at the opengl level (for some of our unsupported cards). All of these are combined as various "appearances". I'm currently waiting for GM as the code at this level is changing as we speak. Especially the dark/light mode appearance management methods. I thought it would be stable by now, but there have been enough changes between 7,8 and 9 (haven't looked into 10 yet) that chasing a bug is almost impossible.

What you should know is that the menu bar itself is almost completely handled in the Carbon framework. Which itself is composed of many frameworks, notably HIToolbox. There you'll find positive references to menu translucency. Mode switches in Preferences actually generate events and messages to these frameworks to switch the appearance of the top level menu bar. By the way, HIToolbox is also where the Apple logo is presented on boot, and where the logo switches contrast (if you've noticed) and backgrounds to black before login. Lots there.

I think the ultimate workaround that fixes the ugly Light Mode menu bar will have to start there. I'll crack this open again, once GM is released (hopefully sometime next week)
I did PM you :)
 
To me (Mojave beta 9) it's working, try this open System Preferences / Security and Privacy / Privacy
now click on the lower-left lock and type your user admin password.
Select Enable Location Services, then click Details... near System Services, when inside select all the checkboxes (they are 8). Now Night Shift "Sunset to Sunrise" should work.

Thank you for your help. There are only 7 checkboxes now. Anyway enabling all of them has not solved the problem: Selecting "Sunset to Sunrise" still open a security window.
 

Attachments

  • Screenshot 2018-09-06 at 02.55.07.png
    Screenshot 2018-09-06 at 02.55.07.png
    106.3 KB · Views: 229
  • Screenshot 2018-09-06 at 02.55.23.png
    Screenshot 2018-09-06 at 02.55.23.png
    110 KB · Views: 208
  • Like
Reactions: TimothyR734
APFS ROM Patcher (WARNING: THIS TOOL COULD IRREVERSIBLY BRICK YOUR MACHINE, REQUIRING BOARD LEVEL COMPONENT OR MOTHERBOARD REPLACEMENT IN CASE OF FAILURE. PLEASE EXERCISE CAUTION WHEN DEALING WITH MACHINES THAT HAVE MULTIPLE EEPROM DEFINITIONS. Some relevant information can be found here, here, here, and here.)

Need one more assumption verified please.

On my MacPro 3,1 which already has BootROM modified for native NVME boot, will this addition of APFS play nicely with that?

My assumption is that this tool reads my current ROM then modifies it to add the APFS driver and then writes it back and therefore would retain the modified BootROM which contains the NVME driver.

Is there more risk by having an already modified ROM (I'm assuming no, a flash is a flash)?
Is there enough room in the ROM for both drivers to be there (again I assume yes)?
 
  • Like
Reactions: TimothyR734
Need one more assumption verified please.

On my MacPro 3,1 which already has BootROM modified for native NVME boot, will this addition of APFS play nicely with that?

My assumption is that this tool reads my current ROM then modifies it to add the APFS driver and then writes it back and therefore would retain the modified BootROM which contains the NVME driver.

Is there more risk by having an already modified ROM (I'm assuming no, a flash is a flash)?
Is there enough room in the ROM for both drivers to be there (again I assume yes)?
Yes, you will have no issues adding APFS support to your ROM if you've used my tools to add NVMe support. It does exactly as you say; dumps the ROM, adds APFS support, and flashes the modified ROM back on. Your ROM will still contain NVMe booting support once it's done. If there is not enough free space on the ROM, the program will stop and error out before flashing anything.
 
I swapped the WiFi card out of my MacBook Pro 4,1 all the way back when Sierra came out because it did not support the WiFi card installed. I switched it out with the WiFi card I had from a Late 2006 MBP that I had laying around (Atheros like yours). It did work fine, no patches needed, until Mojave. However, I did get it to work again by installing the WiFi patch in the post install tool. I then installed it manually again with the patch updater in Mojave and it works flawlessly again. Make sure you rebuild the cache after install in the post install tool. Try it and see if it works.
Thanks so much for replying but unfortunately it didn't work...what work is the post from hackintosh-montreal.com...it was in French but watched the video and did exactly how the video explained. Then I rebuilt the kextcaches manually via terminal...rebooted and viola!! Wifi was connecting again. Guess I would have to do it manually for every update until I get the supported card.
[doublepost=1536215726][/doublepost]
https://www.hackintosh-montreal.com/t7625-fix-wifi-atheros-dans-macos-mojave-10-14 can anybody confirm this would work?? gonna be leaving home soon don't have time to check it out until later or tomorrow. Thanks.
I can confirm this works for my Atheros wifi AR5008x..but you would have to manually rebuild kextcache..
 
  • Like
Reactions: TimothyR734
My first post ... but been reading up on this unsupported thread.

I have a very dated mid-2009 15" MacBook Pro (MacbookPro5,3) that contains 2 partitions on it's internal SSD drive.
  1. HFS Partition 1 has High Sierra GM.
  2. HFS Partition 2 has Mojave Public Beta 9.
These are my questions to folks in here:
  • Since my double boot drive is SSD, is HFS sufficient at this time?
  • Or should I change to APFS for better performance or Mojave might only be compatible when the GM is released?
  • Can I have a dual boot setup (HFS for the High Sierra, APFS for the Mojave)?
The last 2 bullets might not be relevant at this time since I encountered an issue.
When I attempted to do the APFS ROM Patch/EEPROM mod on this MBP5,3 it failed.
Steps and issue encountered is similar to this post: macOS 10.14 Mojave on Unsupported Macs Thread

Thanks for your responses.
 
Last edited:
Thanks - always appreciate any input on this ...
Yes, what Apple calls "vibrancy" (Dark or Light) is actually implemented using view compositing, blurs and blending modes at the opengl level (for some of our unsupported cards). All of these are combined as various "appearances". I'm currently waiting for GM as the code at this level is changing as we speak. Especially the dark/light mode appearance management methods. I thought it would be stable by now, but there have been enough changes between 7,8 and 9 (haven't looked into 10 yet) that chasing a bug is almost impossible.

What you should know is that the menu bar itself is almost completely handled in the Carbon framework. Which itself is composed of many frameworks, notably HIToolbox. There you'll find positive references to menu translucency. Mode switches in Preferences actually generate events and messages to these frameworks to switch the appearance of the top level menu bar. By the way, HIToolbox is also where the Apple logo is presented on boot, and where the logo switches contrast (if you've noticed) and backgrounds to black before login. Lots there.

I think the ultimate workaround that fixes the ugly Light Mode menu bar will have to start there. I'll crack this open again, once GM is released (hopefully sometime next week)

Thanks for you effort, agree on waiting for the GM to focus again on it, apparently the HIToolbox should have been deprecated for 64 bit apps, but instead it's there and it seems also mandatory for Mojave, since I've tried to replace the entire Carbon.framework from HighSierra into Mojave, and it stucks on black screen right after stage2 Apple logo, while if you replace every HS Carbon.framework content (sub-frameworks included) except the HIToolbox.framework leaving inside the Mojave one, it will boot correctly but with the known grey Finder menu glitch. So maybe playing with HIToolbox.framework through Xcode (or directly patching HIToolbox unix binary) wouldn't be a bad idea in attempting "blur blending windows fixing".

I have found a very good definition of HIToolbox here is in summary:

Human Interface Toolbox is a large framework for Carbon based User Interfaces, like windows and their contents handling user input events.

https://discussions.apple.com/thread/677675
 
Funny, when I changed my Fake MBP10,1 SMBios to MBP5,x.. it found No Trackpad.prefPane (just empty).
This reminds me with IOKit bug under Sierra early release on my real MBP5,2.. previously, used TrackPad.pref from 10.11.6 solved the issue. On Mojave Beta 10, I only replace "Trackpad" binary from 10.13.6 or 10.12.6, it back to (partially) normal.

Code:
/System/Library/PreferencePanes/Trackpad.prefPane/Contents/MacOS/Trackpad
 

Attachments

  • Screen Shot 2018-09-06 at 14.49.55.png
    Screen Shot 2018-09-06 at 14.49.55.png
    326.4 KB · Views: 231
My first post ... but been reading up on this unsupported thread.

I have a very dated mid-2009 15" MacBook Pro (MacbookPro5,3) that contains 2 partitions on it's internal SSD drive.
  1. HFS Partition 1 has High Sierra GM.
  2. HFS Partition 2 has Mojave Public Beta 9.
These are my questions to folks in here:
  • Since my double boot drive is SSD, is HFS sufficient at this time?
  • Or should I change to APFS for better performance or Mojave might only be compatible when the GM is released?
  • Can I have a dual boot setup (HFS for the High Sierra, APFS for the Mojave)?
The last 2 bullets might not be relevant at this time since I encountered an issue.
When I attempted to do the APFS ROM Patch/EEPROM mod on this MBP5,3 it failed.
Steps and issue encountered is similar to this post: macOS 10.14 Mojave on Unsupported Macs Thread

Thanks for your responses.

I have a similar setup on my MBP 5,5. El Cap HFS+, Mojave HFS+ on an SSD. I have done a lot of experiments on APFS for Mojave on unsupported, and each time I convert I find some bug that makes me want to go back to HFS+. Once it releases, we will see if it is required. However, you can dual boot HFS+ and APFS, but some have warned against it as it could cause some bugs.
I don't know much about the patching failures some have experienced as is not my area of expertise (I know little to nothing about it:D) but, if you do get it to work, dual booting should work and right now the only benefit of having APFS for mojave is being able to update OTA rather than downloading the 6gb installer and installing it via USB. Hope this helps!
 
Last edited:
I have a similar setup on my MBP 5,5. El Cap HFS+, Mojave HFS+ on an SSD. I have done a lot of experiments on APFS for Mojave on unsupported, and each time I convert I find some bug that makes me want to go back to HFS+. Once it releases, we will see if it is required. However, you can dual boot HFS+ and APFS, but some have warned against it as it could cause some bugs.
I don't know much about the patching failures some have experienced as is not my area of expertise (I know little to nothing about it:D) but, if you do get it to work, dual booting should work and right now the only benefit of having APFS for mojave is being able to update OTA rather than downloading the 6gb installer and installing it USB. Hope this helps!

Basically, if your Mojave volume isn't APFS, you won't be able to download and install the Software Updates. You'll have to download the full installer for each Mojave point release and use that instead.
 
MacBook 5,1 users, anyone facing some random finder or other apps freeze, its not frequent but after 30-40 minutes I get this issue, it stops responding, restart or shutdown doesn't work, only force restart fix it. Never had such problem on High Sierra.
 
I sent this DM to @dosdude1 because I thought he could be the most helpful but I'm posting it here as well incase someone has any insight.

If you could help me with this I would greatly appreciate it. I would like to know exactly how to create a classic macOS installer. The actuals commands to be used and how to use them. I have tried and failed to figure this out on my own so I really need your help. Thank you.
 
Funny, when I changed my Fake MBP10,1 SMBios to MBP5,x.. it found No Trackpad.prefPane (just empty).
This reminds me with IOKit bug under Sierra early release on my real MBP5,2.. previously, used TrackPad.pref from 10.11.6 solved the issue. On Mojave Beta 10, I only replace "Trackpad" binary from 10.13.6 or 10.12.6, it back to (partially) normal.

Code:
/System/Library/PreferencePanes/Trackpad.prefPane/Contents/MacOS/Trackpad
What if you replace some of the files from El Capitan? I asked before if someone had tried or wanted to try but I got no response. I’d love to try it myself but I don’t have one of those machines:D
 
  • Like
Reactions: TimothyR734
I've successfully patched a macOS 10.14 Mojave Developer Preview 10 installer application. This patch can be made cleaner by fixing the High Sierra naming, license, etc but the installer opens and most likely installs a stock copy of macOS 10.14 Mojave. I will attempt to fix the High Sierra related issues and will test it soon. I've included screenshots of the patched installer as well.

Patched Mojave Installer Home.png
Patched Mojave Installer License.png
Patched Mojave Installer Disk.png
Patched Mojave Installer Disks.png
 
Last edited:
I have a similar setup on my MBP 5,5. El Cap HFS+, Mojave HFS+ on an SSD. I have done a lot of experiments on APFS for Mojave on unsupported, and each time I convert I find some bug that makes me want to go back to HFS+. Once it releases, we will see if it is required. However, you can dual boot HFS+ and APFS, but some have warned against it as it could cause some bugs.
I don't know much about the patching failures some have experienced as is not my area of expertise (I know little to nothing about it:D) but, if you do get it to work, dual booting should work and right now the only benefit of having APFS for mojave is being able to update OTA rather than downloading the 6gb installer and installing it via USB. Hope this helps!

Thank You.

For now, I will stick with HFS+ format for both High Sierra and Mojave. I used @dosdude1's patcher apps for both of these unsupported OSs. Installing or updating via USB is not so bad.

Edit: I also noticed you are using El Capitan (instead of High Sierra). Any comments on why? Thanks again.
 
Thanks so much for replying but unfortunately it didn't work...what work is the post from hackintosh-montreal.com...it was in French but watched the video and did exactly how the video explained. Then I rebuilt the kextcaches manually via terminal...rebooted and viola!! Wifi was connecting again. Guess I would have to do it manually for every update until I get the supported card.
[doublepost=1536215726][/doublepost]
I can confirm this works for my Atheros wifi AR5008x..but you would have to manually rebuild kextcache..
I personally haven’t had to redo anything WiFi wise after updates but YMMV
 
  • Like
Reactions: TimothyR734
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.