What is in the HP Probook Installer/What does it do?

[RehabMan]

Hmm, I'm using Toledo's HDA Clover patch which runs out of terminal. I think you're right in the way mine does it, but to Rehabman's point, "my way" uses the native AppleHDA kext with no dummy kexts/non native kexts in /S/L/E which gives it a much better chance of surviving updates.

Maybe something to consider in the new version. You're right in that it is "more compact" putting a dummy HDA kext in /S/L/E, but it is less "native".

The PBI-CE uses the native AppleHDA.kext. After you install, you should examine the files to have a better understanding. I think you're confused.

It is pure myth that adding kexts to /S/L/E somehow makes the system "less native". For example, my real Apple MacBookAir6,2 has kexts from 3rd parties in /S/L/E... for example, HP printer drivers. Should I instead use Clover to boot my Mac just so I can place the HP printer drivers in Clover/kexts and keep /S/L/E "more native"?

In fact, the runtime environment is "more native" with everything installed to /S/L/E. This way it can be included in cache, and placed in memory where OS X will naturally place them (as opposed to the tricks going on inside OsxAptioFix*.efi). This is proven by the fact that some kexts simply don't work when injected.

 

[kpkp]

It is pure myth that adding kexts to /S/L/E somehow makes the system "less native"...

Agreed, there is/was this obsession with "vanilla" that sometimes is just not constructive. I can't think of any sound argument why the extra kexts we use shouldn't be in /S/L/E. It must be an aesthetic thing in simple words "make the OSX system files look as much as it's on the Macs" pushed over the rational limit.

Wouldn't kext be easier to upgrade for newbies if they were in /S/L/E? There are simple drag and drop tools for that.

 

[Gordo74]

Agreed, there is/was this obsession with "vanilla" that sometimes is just not constructive. I can't think of any sound argument why the extra kexts we use shouldn't be in /S/L/E. It must be an aesthetic thing in simple words "make the OSX system files look as much as it's on the Macs" pushed over the rational limit.

Wouldn't kext be easier to upgrade for newbies if they were in /S/L/E? There are simple drag and drop tools for that.

Thanks for the informative post RehabMan. You are correct in that there are other third party kexts installed to /S/L/E in order to load various third party hardware, but, in my mind that is a different scenario (see below).

KP - I don't think there is anything irrational about it, personally. What we are doing here is vastly different than installing/injecitng a printer driver. Here we are tricking OSX through either various kexts or injections that our hardware is actually a Mac and telling the software how to interface with the hardware that isn't actually that hardware in many cases (bluetooth, wifi, audio, ethernet are good examples of this). By keeping anything that isn't "made for OSX" or "native" in its own little bubble, this makes it easier, in my opinion, to make sure everything is working as it should.

As they say though, there is more than one way to skin a cat.

 

[RehabMan]

Thanks for the informative post RehabMan. You are correct in that there are other third party kexts installed to /S/L/E in order to load various third party hardware, but, in my mind that is a different scenario (see below).

IMHO, not different. We have specific drivers for the hardware installed. It is as simple as that.

I don't think there is anything irrational about it, personally. What we are doing here is vastly different than installing/injecitng a printer driver. Here we are tricking OSX through either various kexts or injections that our hardware is actually a Mac and telling the software how to interface with the hardware that isn't actually that hardware in many cases (bluetooth, wifi, audio, ethernet are good examples of this). By keeping anything that isn't "made for OSX" or "native" in its own little bubble, this makes it easier, in my opinion, to make sure everything is working as it should.

Not easier. Not more native. Nothing special (I see no trickery) about the kexts we use. They are simply drivers for the hardware we have. What is important is the runtime environment of the kernel. And the kernel runtime environment is more native with everything in kernel cache.

If you have trouble keeping track of which kexts are native, which are hack kexts, use tags.

As a software developer, I think I see less "magic"... Fact is that placing all kexts in /S/L/E so they can be loaded from kernel cache replicates the runtime environment for the kernel more faithfully than does injecting (some of) them with Clover.

 

[Gordo74]

Not easier. Not more native.

While you've made a good argument about the latter, I disagree about the "easier". Personally, I find my clover install "easier" to maintain than the Chimera install I had previously. For instance, if I have all my 3rd party kexts in /S/L/E and an update causes my PC not to boot, I can simply boot into Windows, delete the offending kext out of my Clover partition, and boot back to OSX fine. If they are in /S/L/E, I have to go digging and hope to god I got the right one and that I havent touched any of the kexts that are supposed to be there.

But, as I said, more than one way to skin a cat, what works for me may not be to your liking and THAT'S OKAY! That's the great part about the tools at our fingertips. Where you may use a hacksaw to cut a pipe, I may use a pipe cutter. Same result, different approach. Is one wrong? No.

That is all off topic though. I appreciate the answers of what PBI does and where it puts things.

Thanks for all your hard work to the community!

 

[RehabMan]

...Personally, I find my clover install "easier" to maintain than the Chimera install I had previously.

No argument there. A Clover-based install is easier to maintain, not because of kext injection (even Chimera has kext injection via /Extra/Extensions), but because of config.plist hotpatching of kexts (KextsToPatch).

...If they are in /S/L/E, I have to go digging and hope to god I got the right one and that I havent touched any of the kexts that are supposed to be there.

Good idea to have a clear understanding as to which hack kexts you have installed. Like I said, use tags, or write them down in your notes.

Another reason I install to /S/L/E is because of the link-time checks that kextcache does when it rebuilds cache. Of course, I'm actively developing kexts, so this is a concern that is not common for non-developers.