Jump to content

MLWrapper: a 64bits wrapper to load incompatible kexts in ML (Exemple code included!)


VirtualGuitarist
 Share

11 posts in this topic

Recommended Posts

Hello, happy developers! :)

 

I hiope this topic will not be just a waste of time for you, but following this topic and the release by Netkas of a 32 bits ML kernel, came to my mind a strange idea, i''m just a noob but following my message someone encouraged me to submit my idea to Slice, just in case...

 

Here's the message i sent to him, it exposes my idea, but the answer from Slice is far better in the sense in that it opens a practical way to make this simple noob idea an eventual reality, it doesn't implies that Slice is supporting or approve my idea in any way, it just explains things better:

 

Hi!

 

I hope this message will not be a waste of time for you, i would be very sorry about that because i as i said elsewhere i'm really admirative and respectful about the work of developers like you, without humans like you there's simply no osx86 and no community, just a massive bunch of newbies and wannabes that try to convince themselves that they are interesting.... lol!

 

Here is the facts: with the release of ML, a lot of people (including regular apple users) feel angry, frustrated and/or abandoned by apple because their hardware is simply too old or incompatible with the last release. Their hardware are incompatible because the drivers are 32 bits only, or because they have 32 bits efi, etc... As an exemple amongst many, many others you could read this article of blog, it have beaten some records of frequentation since the publication of this tutorial! So my conclusion is that a LOT of people is concerned, not just osx86 community.

 

So here's my idea: instead of creating legacy kernels that will soon be rendered obsolete by future updates (apple says they will release one major update per year!), is it possibe to imagine a 64 bits wrapper, in the form of a generic kext, capable of loading 32 bits (old or incompatible) kexts?

 

What i call a "wrapper" in my noob language could play the role of a proxy between the kernel and an incompatible kext, with it we could be able to load a 32 bit kext in a 64 bit "space".

 

The result could take the form of a kext where we could put our 32 bits kexts inside a folder called, for exemple, "plugins", because in fact the 32 bit kext becomes a plugin of the 64 bit wrapper kext.

 

Here's the post i've written about it, you will see that i'm deeply interested by the subject, because i'm stuck with my incompatible nvidia 7600 gs, so for now there's no way for me to really play with and enjoy ML with QE/CI...

 

I'm just a noob and perhaps this is only a stupid idea, if this is the case please accept my apologies!

 

And (with his permission) here's the Slice's answer:

 

Hello!

 

Yes, your idea is entitled to be. As far as I understand there is some workaround in the kernel to start 32-bit application with 64-bit kernel. Why not a kext?

Such wrapper should have multiple instances, one for each superclass you want to execute as 32bit.

For example, if some application calls IOEthernetControllerClass it should calls wrapper and it calls your driver.

In terms of C++ you have to create subclass instances.

 

About 7600GS it is strange why NVidia do not produce 32-bit drivers. I checked in Lion with 7300LE. Version 270 works in 64bit, but crashes in 32bit. So I understand you. It is only reason why you can't use ML. Mmmm.... another reason is Attansic? Twice bad.

 

This is very complex subject and I feel my skill is not enough to do something here. Anybody else? I can help if I'll see that I can help.

 

(/Off-topic note: about the Attansic/Atheros L1, the problem can be solved by using AttansicL1Ethernet.kext from SL and PCIRootUID=1)

 

So what's your thoughts about this?

 

About nvidia incompatibilities with ML, you could read also this article, interesting in the sense that we can see that the problem with nvidia is more complex than just a 32bits/64bits issue.

 

In any case, i'm available for testing/anything, but of course i can't help for programming, because i'm only a dumb and useless musician, sorry... :afro:

 

The goal is to find a global and sustainable solution, not just for me or for osx86 but also for regular apple users who suffer of incompatibilities between their (not so old, after all!) hardware and Mountain Lion.

 

- - - - - - -

 

EDIT 09-12-12:

 

I have EXCELLENT news! :) I've found an actual exemple of what a wrapper could look like: it's called nspluginwrapper (see attached file), and it's used to load 32bits plugiins, like flash for exemple, in 64 bits browsers! Of course it is really focused on NPAPI, so it could not be usable "as is", but... but... this is for me a "proof of concept", and i'm sure we could find other examples in the Linux world... A good start point for possible genius developers?

 

 

:superman::superman::superman:

 

- - - - - - -

nspluginwrapper-1.4.4.tar.gz

  • Like 2
Link to comment
Share on other sites

Here is some complementary ideas, perhaps totally crazy, but perhaps also, in some way, will inspire you?

 

1°) Make the MLWrapper a part of Chameleon.

 

- The incompatible kexts are put in a special folder, the bootloader detects them, and loads them in a ram disk. Then the MLWrapper creates virtual 64 bits modified instances of the kexts in memory and inserts them into the kernel tree,

 

- or intercepts all communication between the kernel and the incompatible kexts and not only translates 64 bits messages to 32 bits and vice-versa, but also helps to prevent compatibility problems by canceling, translating or transforming some kernel "calls" / "functions"/ "orders"/ "events" (sorry i don't know how you call that), and the response to them, that otherwise could provoke a kernel panic.

 

2°) A special version of kextcache, that will create a cached 64 bits modified version of the incompatible 32 bits kexts.

Link to comment
Share on other sites

Here is a new idea for you dear developers:

 

- A 32 bits legacy sub-kernel. A sub-kernel could be a simplified 32 bis kernel structure wich have the ability to handle all communication to/from legacy/32 bits kexts, and, why not? legacy incompatible libraries and binaries (and here, of course i think strongly about Rosetta, wich have been (cowardly?) abandoned by apple).

 

(Please note that any time i say "incompatible / legacy, i talk about all that's incompatible with Mountain Lion (and its future udaptes too!). That's the very reason of this thread, to find a solution for harware and software incompatibilities).

 

If we could represent the main kernel by a tree, the sub-kernel could be a like a second simplified tree (a sub-tree) connected to the main tree, in fact becoming a simple branch amongst many others. Or, another imaginary representation, like an interpreter which translates a language to another. Of course, following the choices you make, it could have a big impact on performances. It's why i imagine that it could be a very simplified kernel structure, connected to the main kernel by a continuous stream of data.

 

What i call "a continuous stream of data" is the way a Core Audio driver communicates in real-time priority with the kernel. In professional audio, we need a very minimum of latency between the moment of a sound (let's say a guitar note for exemple) enter in the sound card, and the moment when it is heard. It's this delay wich is called latency, and it could be a real nightmare when you're a sound engineer and have to mix 48 instruments and voices tracks with tons of effects loaded in, all perfectly synchronized with a video, and all that in real time!

 

To accomplish successfully this herculean task, the audio driver establishes a continuous channel of communication (real-rime streaming) with the kernel witch have a very high (real-time) priority above any other event. The result is that the latency is no more a software issue, but only depends on your hardware. More powerful your CPU and your soundcard are, less is the latency.

 

So i imagine that a sub-kernel could exploit this possibility, to establish a very fast communication with the main kernel, so the performance issues could be minimized.

Link to comment
Share on other sites

hello

 

is a nice idea, not sure if can be implemented.. but the idea is good

 

Hi, Artur-pt!

 

Thank you very, very much to have taken the time to read my prose! :)

I'm happy that you have a positive impression about my ideas!

 

This topic is like a bottle in the sea, it's why i asked for your advice, because as you i'm not sure that it can become a reality, but... who knows?

 

Few years ago, installing osx on pcs was considered completely crazy, because on real macs apple have implemented a TPM chip which prohibits that

And what happened? Crazy developers created a kext (fake SMC, which at first was called r2d2.kext) which emulates the tpm and decrypts apple libraries in real time! Say hello to Netkas and Maxxuss, hero members at the very origin of the osx86 project... I was thinking about them when i opened this topic.

 

another problem is with x3100 only solutions in 32 bit, but the graphics card is in 64 bit notebooks

 

good hack

 

Old graphics cards in notebooks are a real true problem, because they can't be changed or upgraded as we can in a desktop... But i have faith in our developers, i'm sure they can find a solution, perhaps this solution will be completely different that those i try to imagine with my non-existent knowledge, so perhaps this topic will be completely useless, but perhaps some of them will realize there is a real need here, not for a "simple" legacy kernel, but for something radically different, so...why not?

Link to comment
Share on other sites

  • 2 weeks later...

I have been following this thread as I would like to see ML graphics work with the X3100 GPU. However, it occurs to me that the X3100 only supports OpenGL 2.0 and ML uses OpenGL 4. Would a wrapper be able to address this factor?

Link to comment
Share on other sites

Hi Mnfesq, unfortunately i haven't enough knowledge to really discuss about it, but this is an excellent question and i hope that someone more skilled than me will take the time to answer.

 

Though what i can say is that nvidia 8x and 9x series (nv50) works very well with ML, aren't they opengl 2.0 also ? Is it implying that there is some retro-compatibility between opengl versions ?

 

Of course, if this is the case now, this isn't mean that this will be the case in the future...

 

(Edit:geforce 8 and 9 series are in fact opengl 3.3 source: wikipedia. I need more investigation to know if there is actual retro-compatibility with the opengl 2.0 impemented in previous generations of ATI and Intel "X" series chipsets, if you have some infos about this, and how opengl are handled by osx, please share)

 

Thank you for following this thread, i hope to see my wish becomes reality one day, why not for christmas?! :)

Link to comment
Share on other sites

Today i have really, really great news... :D ! Please see the "EDIT" in the first message with exemple code included!

 

I'm happy because it is a proof that my noob concept really exists, and is actually used, in a daily basis... in our browsers! Please read!

 

Of course if you are a developer and read this, this is old news for you, but when i started this thread i was really not sure that something like that really existed.... So from my humble POV, this is simply great!

 

EDIT: If ever you find other examples like that, which illustrate different ways to translate 32 bits binaries into 64 bits, please share!

Link to comment
Share on other sites

Another example comes to my mind, a library that is used daily in windows machines all around the world: Wow64.

 

This compatibility layer is able to run 32 bits apps in 64 bits versions of windows. As far as i can understand, it exploits a compatibility mode of 64 bits (Intel EMT64 and AMD64) processors, and takes care of environment too, redirecting paths to the registry and system folders (exemple: references to HKLM/Software are redirected to HKLM/Software/WOW6432, "\Windows\System32" is redirected to "\Windows\SysWoW64", etc...).

 

Though WoW64 have a down side: it don't takes care of drivers, so all 32 bits apps that include 32 bits drivers can't run on the 64 bits versions of windows.

 

But the important information here for me is that there is a "compatibility mode" included in our modern 64 bits processors. A good lead to elaborate a fast MLWrapper?

Link to comment
Share on other sites

  • 2 years later...

with the coming out of yosemite I've thinked that we can "reverse engineer" the gmax3100 and gma950 kext with the gdb debugger and recompile them to 64 bit with some changes

 

the requirement is to have 2 macs: 1 to debug and 1 to run, as said by apple. I would have done that if I've had 2 macs but I only have one.. if someone has 2 macs to do that will be awesome :D

 

here is some guidelines

use gdb to inspect the assembly code of a kernel extension

you can use the kextload tool to create a symbols file that you can load into gdb. this will let you see decoded symbol names for functions, &c. there's atutorial here:http://praveenmatanam.wordpress.com/...ugging-on-mac/ 

Link to comment
Share on other sites

  • 4 weeks later...

with the coming out of yosemite I've thinked that we can "reverse engineer" the gmax3100 and gma950 kext with the gdb debugger and recompile them to 64 bit with some changes

 

the requirement is to have 2 macs: 1 to debug and 1 to run, as said by apple. I would have done that if I've had 2 macs but I only have one.. if someone has 2 macs to do that will be awesome :D

 

here is some guidelines

use gdb to inspect the assembly code of a kernel extension

you can use the kextload tool to create a symbols file that you can load into gdb. this will let you see decoded symbol names for functions, &c. there's atutorial here:http://praveenmatanam.wordpress.com/...ugging-on-mac/

How about a Virtual Machine?

The physical for the kext and the virtual for the debugging?

Link to comment
Share on other sites

 Share

×
×
  • Create New...