Jump to content

Plans for a (possible) new OSx86 utility

~pcwiz

By ~pcwiz,
in OSx86 10.6 (Snow Leopard)

 Share
59 posts in this topic

Recommended Posts

~pcwiz
~pcwiz
Posted
Posted

Hi,

 

I haven't really been active on the scene for a few years now but I recently had to install OSx86 on my computer again because I needed it for recording/music production. Looking through the forums I still found tons of reference to using OSx86Tools, which has long been outdated, and basically the only functions on it that are still usable are the kext installation and the EFI string generation.

 

I've been thinking of writing a preference pane (written in native Objective-C/Cocoa) that would be easily accessible through System Preferences. Some ideas I've been throwing around for it:

 

Basics:

 

- Kext/kernel manager (support for both S/L/E and Extra, drag and drop UI)

- Basic "maintenance" tasks (regenerating kext caches, permissions, etc.)

- Creating and patching DSDT

- Generating and applying EFI strings

- Configuring various settings (32/64bit modes, boot timeout, kernel flags, etc.)

- SMBIOS confiugration

 

Extras (crazy ideas)

 

- Chameleon theme manager (easy theme selection/installation, maybe even a central theme repo?)

- "Suggestions" system

--> This one is one of my favorite ideas. Basically, its like a solutions center, where you select your problem (e.g. sleep doesn't work, PS/2 mouse/keyboard doesn't work) and it offers downloads for drivers, or guides/resources that may be of use. I think, that for users that have managed to successfully install OS X, it would reduce the "noob clutter" where people are asking for solutions to common problems.

 

Another possibility is to have it be able to scan hardware using lspci and offer driver downloads. I have learnt from past experience using OSx86Tools that this doesn't work as well as I'd like, but I think I've come across a reasonable compromise. Instead of it auto downloading kexts and installing them, instead I would link to the actual pages from which they come from, so that the user is more aware of what is being installed.

 

Those are all my ideas for now, does anyone else have any other suggestions? Also note, I'm not promising I'm gonna be doing this anytime soon, its just one of those "free time" projects (even though my free time at the moment is severely limited).

R3van
R3van
Posted
Posted

* If you build a dsdt patcher so please document what the fixes are doing, that is the most missing feature for me in existing patchers.

 

* Maybe a list what fixes are already done in dsdt.dsl

 

*support for EFI-Partition

 

* Build mkext

 

my suggestions so far -_-

~pcwiz
~pcwiz
Posted
  • Author
Posted
* If you build a dsdt patcher so please document what the fixes are doing, that is the most missing feature for me in existing patchers.

 

* Maybe a list what fixes are already done in dsdt.dsl

 

*support for EFI-Partition

 

* Build mkext

 

my suggestions so far -_-

 

The fixes will definitely be documented. It may be difficult to detect the fixes that have already been applied, simply because it can be patched in many ways. I could give a very general idea of whats patched (e.g. HDEF, AZAL, etc.) but its hard to get much more specific than that. If by support for "EFI-partition" you mean installing kexts, etc. to an EFI partition I think I can do that. And of course it will automatically build the mkext when kexts are changed ;)

3.14r2
3.14r2
Posted
Posted

IMO the idea as itself is good. There is no such ALL-IN-ONE tool for now. There are only separate tools scattered around like:

  • Lizard - Chameleon management
  • Various DSDT patching tools
  • Kexst install tools and so on...

I guess it would be wiser to unite (if it is possible at all) those separate projects under one Global pref.pan. I think it is not efficient time-wise to write such an application/pref.pan, as you suggest from the ground. Just because IMHO much of it's components area already created (though not all off them work equally good).

 

I don't think the idea with drivers is much appropriate for the current state of things (IMHO), cos' in some cases with certain hardware drivers may not work as they should. Therefore installing such drivers via automated/semi-automated manner can do more harm then good. Also some drivers require fine tuning from the user side to work properly.

 

Though if a user is just given an information where a certain driver can be downloaded (it is him to decided which and where), it might work more or less well. Possible it could be done just like it is done in Linux - adding repositories for certain hardware types.

~pcwiz
~pcwiz
Posted
  • Author
Posted
IMO the idea as itself is good. There is no such ALL-IN-ONE tool for now. There are only separate tools scattered around like:

  • Lizard - Chameleon management
  • Various DSDT patching tools
  • Kexst install tools and so on...

I guess it would be wiser to unite (if it is possible at all) those separate projects under one Global pref.pan. I think it is not efficient time-wise to write such an application/pref.pan, as you suggest from the ground. Just because IMHO much of it's components area already created (though not all off them work equally good).

 

It wouldn't be all that time consuming to write one, much of the code needed is already in OSx86 Tools, all I need to do is convert it to Objective-C code.

 

I don't think the idea with drivers is much appropriate for the current state of things (IMHO), cos' in some cases with certain hardware drivers may not work as they should. Therefore installing such drivers via automated/semi-automated manner can do more harm then good. Also some drivers require fine tuning from the user side to work properly.

 

Though if a user is just given an information where a certain driver can be downloaded (it is him to decided which and where), it might work more or less well. Possible it could be done just like it is done in Linux - adding repositories for certain hardware types.

 

That's what I was planning, there is no downloading involved, it just directs the user to the resource at which the driver may be found. That way they won't miss out on instructions, details, etc. that may go along with the driver.

~pcwiz
~pcwiz
Posted
  • Author
Posted

 

Yep, I've seen that one. The DSDT patcher I'm planning will likely be a very simple one, just a few checkboxes/dropdowns to choose what you want to patch and a button to apply it ;)

sch8mid
sch8mid
Posted
Posted
Yep, I've seen that one. The DSDT patcher I'm planning will likely be a very simple one, just a few checkboxes/dropdowns to choose what you want to patch and a button to apply it :whistle:

 

 

GOOD GOOD news

 

the return of a legend

 

my first hack in 2007 without pcwiz tools ? NO way

 

greets from Suebia

Gringo Vermelho
Gringo Vermelho
Posted
Posted

Sounds great, welcome back.

 

The 'solutions center' is a great idea if you can pull it off.

 

About the hardware scan idea, we already have something like that and it even runs under Windows which is extremely useful if you're a beginner:

http://www.insanelymac.com/forum/index.php?showtopic=219584

 

I have one, small request! If you're going to add a radio button that forces GLQuartz on for everything, this time please add a huge popup that says "this button does not enable QE/CI" in red, bold italic.

 

:whistle:

bertmannaustria
bertmannaustria
Posted
Posted

sounds great

 

graphics --> many people got problems with qe/ci even on newer graphic cards and/or wrong detection. i got a gtx 295 co-op, chameleon graphics enabler detect only one card, i have to use an efi string to get both gpus recognized by the system, efi string generator for special cards like that? another problem i solved by replacing wrong engine with the correct one into the sources of the chameleon boot file and compiled it to get an ati radeon hd ... it think it was a 4670 working fine. it think it would be very handy to have a tool that select the right precompiled boot file and adds hardware id's to kexts if required.

 

sound --> sometimes it took hours to get sound working as it should, a database which can say what version of applehda etc. will work on selected mainboard, patching files included, hoo hoo a one-click-i-got-sound-working-thingie :(

 

kext merge --> it's possible to combine all /E/E kexts into one, don't ask me how but it works :) that would be fine to have only one kext file in /E/E with plugins if needed

 

a usb-boot maker :)

~pcwiz
~pcwiz
Posted
  • Author
Posted

sch8mid, Thanks :)

 

Gringo,

 

I've checked out that app and it appears to tell the user which hardware is compatible, and what kexts are used, but doesn't actually direct the user to a resource on where they can find the required files, which is what I aim to do. About the QuartzGL thing, it's probably not something that I'm going to be putting in the prefpane. It's not particularly relevant to OSx86, and its a tweak that can easily by applied through the Terminal.

 

bertmannaustria,

 

There will be a string generator :) For it to auto add device IDs to kexts and stuff, that would mean it would have to have a repository of patches for each individual card, not sure how well that would work out :-/

 

As for sound, I think I can include the most common patches for sound in the DSDT patcher. And by "kext merge" I think you're talking about using Extensions.mkext, which will automatically be created by the prefpane when kexts are changed.

Gringo Vermelho
Gringo Vermelho
Posted
Posted

AppleHDA was changed from 10.6.3 and up so that you now have to hex edit the AppleHDA binary itself if your audio device's device ID is not directly supported. Someone made a series of clever scripts (they're here in a post somewhere) that patches the binary on the fly according to what audio codec you have. Last time I saw that post there was support for 4-5 common HDA devices. Maybe you can include those scripts in your new app. If I see the post again I'll add the link here.

I've checked out that app and it appears to tell the user which hardware is compatible, and what kexts are used, but doesn't actually direct the user to a resource on where they can find the required files.

Yes it does actually, but they're changing servers so it's not working at the moment.

 

I was referring to the QuartzGL button in OSX86Tools, just razzing you dude :) that button has been a source of confusion and false hope for many a beginner and I probably have in the vicinity of 20-30 posts over the years (on this and an older account) where I try to explain what that button does and why they shouldn't use it.

MaLd0n
MaLd0n
Posted
Posted

http://www.projectosx.com/forum/index.php?...post&p=9687

 

ALC889

 

sudo perl -pi -e 's|\x85\x08\xec\x10|\x89\x08\xec\x10|g' /System/Library/Extensions/AppleHDA.kext/Contents/MacOS/AppleHDA

 

ALC888

 

sudo perl -pi -e 's|\x85\x08\xec\x10|\x88\x08\xec\x10|g' /System/Library/Extensions/AppleHDA.kext/Contents/MacOS/AppleHDA

 

ALC883

 

sudo perl -pi -e 's|\x85\x08\xec\x10|\x83\x08\xec\x10|g' /System/Library/Extensions/AppleHDA.kext/Contents/MacOS/AppleHDA

 

AD2000B

 

sudo perl -pi -e 's|\x8b\x19\xd4\x11|\x9b\x98\xd4\x11|g' /System/Library/Extensions/AppleHDA.kext/Contents/MacOS/AppleHDA

 

ALC662

 

sudo perl -pi -e 's|\x85\x08\xec\x10|\x62\x06\xec\x10|g' /System/Library/Extensions/AppleHDA.kext/Contents/MacOS/AppleHDA

oldnapalm
oldnapalm
Posted
Posted

~pcwiz

 

The database for "System Info" app is being migrated to http://kexts.insanelymac.com/

 

If you want to see it working, it's temporarily here http://olarila.com/kexts/

 

It would be nice if your app uses the same DB. If you agree we can give the API to access and submit data.

~pcwiz
~pcwiz
Posted
  • Author
Posted

Gringo and MaLd0n,

 

If possible I'll include direct AppleHDA patching as an option (for those who dont want to use DSDT). Thanks for the resources :)

 

XLR,

 

Thanks :)

 

Scottapotamus,

 

I listed SMBIOS editing as a planned feature in the main post

 

oldnapalm,

 

That looks great! I didn't know there was something like that. When I start making the app I'll PM you for API access

Gringo Vermelho
Gringo Vermelho
Posted
Posted
If possible I'll include direct AppleHDA patching as an option (for those who dont want to use DSDT).

But that's the thing. Since 10.6.3, unless your audio codec is among the few that are directly supported, you can no longer get by with just patching DSDT (or using HDAEnabler), you have to binary-patch AppleHDA.

 

Otherwise you must use AppleHDA.kext from 10.6.2, VoodooHDA or some other kernel extension.

sch8mid
sch8mid
Posted
Posted
~pcwiz

 

The database for "System Info" app is being migrated to http://kexts.insanelymac.com/

 

If you want to see it working, it's temporarily here http://olarila.com/kexts/

 

It would be nice if your app uses the same DB. If you agree we can give the API to access and submit data.

 

Joined forces - fine

FKA
FKA
Posted
Posted

Hi pcWiz, welcome back :rolleyes:

 

How about software RAID support for either installing or post install access to multiple 'Extra' folders?

http://www.insanelymac.com/forum/index.php?showtopic=160467

 

And within 'config various settings' - the ability to change ATI frame buffer for when Kablys ati boot is added to chameleon trunk

http://www.insanelymac.com/forum/index.php...=231768&hl=

 

D

  • 3 weeks later...
Mushishi
Mushishi
Posted
Posted

So we can expect another half done tool where you will blame the users for the flaws it have not not helping them when they hose there install...

 

Chameleon prefpanel it is allready there done by the chameleon team.

 

kext manager (if by that you mean repair permissions) then it is allready here... it is called pfix...

 

DSDT utillity just like above... allready here called dsdtse

 

EFI sterings... well yes i use strings right now but i had to use a leopard install to generate them because snow {censored}s the strings up... So no point it having that in a snow tool.

 

smbios config... Honest there are so many smbios.plist's out here just google for them and you can find them... why need a tool to make them...

 

So the short way to say it from me...

 

Do not want...

do_not_want_trollcat.jpg

aschar1
aschar1
Posted
Posted

This world would be better without guys like pcwiz.

In the past he only stole others work, gave no credits and just wrapped a gui around it . Osx86tools is one of the worst apps i have seen so far. Similar {censored} is the dsdt gui patcher. All of pcwiz work has caused severe probs in the past for many n00b users who like the 1 click experience and dont understand what they are doing. Just my 2 cents.

 Share
Go to topic listing
×
×
  • Create New...