Welcome to the MacNN Forums.

Fotek2001 · Jun 6, 2002, 11:15 AM

With the release of Silk for OS X 10.1.5, I've been wondering how these haxies actually work and if they can mess up the system...

In OS 9, extensions could be used to dynamically patch the system at boot time and thereby add and change functionality in the OS but in OS X, this kind of behaviour is supposed to be impossible because all apps live in completely protected and isolated memory space.

In spite of this, Unsanity have been able to make haxies to change global system behaviour and I'm interested to know how it's done and if these changes can affect the stability of other applications and the core OS. Although I like these little programs, my experience with OS 9 makes me nervous about one application patching or fiddling with another one hence the question.

b*tchy · Jun 6, 2002, 11:52 AM

don't know about silk, but I've had windowshade running since it was released. The only time I ever have to reboot is when doing system upgrades or when I need an OS 9 only problem. Zero stability issues here.

Fotek2001 · Jun 6, 2002, 01:07 PM

I've not had any problems either but I'd be interested to know how these applications can work in a protected memory environment.

fmalloy · Jun 6, 2002, 01:10 PM

System extensions can exist in OS X just as in OS 9. You can patch traps just as easily. The idea that you can't destabilize X with software is false. Extensions are low-level OS patches, not applications, and therefore are not subjected to memory protection.

One reason UNIX systems are extremely stable is that their administrators don't go installing cute extensions, and users do not have the privilege to install patches. All functionality in UNIX is done thru scripts and compiled programs which run in user space.

gorgonzola · Jun 6, 2002, 01:40 PM

Something I read on Mac OS X Hints about Silk said that it's basically just something that calls a new system call that enables Quartz AA in a given app. In other words, the method it's using to enable the smoothing is basically Apple-sanctioned, and I strongly doubt you'll have any stability issues with Silk. I don't know about the other haxies, though.

Millennium · Jun 6, 2002, 02:10 PM

<blockquote>quote:<hr />Originally posted by fmalloy:
System extensions can exist in OS X just as in OS 9. You can patch traps just as easily.<hr /></blockquote>False.

It was possible to patch traps in OS9 because Apple allowed it. They did this by maintaining something called a trap table. This was basically a long list of all the traps in the OS and the exact memory locations of each one. An extension could thus find the trap it wanted to patch, store the old result (good extensions did this anyway), and then replace the system's entry in the trap table with its own. That's how patching traps worked.

OSX does not have a trap table. There is no way to reliably find traps to patch, much less a specific one. So OS9-sytle extensions are not possible.

It is possible to hack around in the OS, using even skankier methods than patching traps was. But this can only be done by device drivers (or other things posing as device drivers) and people who actually do this should be viciously flogged.
<blockquote>quote:<hr />One reason UNIX systems are extremely stable is that their administrators don't go installing cute extensions, and users do not have the privilege to install patches. All functionality in UNIX is done thru scripts and compiled programs which run in user space.<hr /></blockquote>And that is how the Haxies work. It's actually very clever how Unsanity managed this feat. It works by using Carbon Events to listen for things like (in Silk's case) app launches. Then they make the proper system calls and get the heck out of there, so the app is left to execute in peace, unpatched in the case of Silk. Not all haxies can do this "execute-a-call-and-get-out" method (WindowShade X can't, for example), but they run along similar lines.

Only problem is, using CarbonEvents to do this will only work for Carbon apps. You can use Cocoa's event model (which only works for Cocoa apps) to achieve the same effect, but this is a lot harder to do. That's why so many of these hacks only support Carbon apps at first; they do the Carbon stuff to get the basic concept up and running, and then they tackle the problem for Cocoa later.

KidRed · Jun 6, 2002, 03:48 PM

Well, I had FruitMenu, WindowShadeX, ASM, XSounds and DefaultFolder all installed and things just fealt funny. I would get periods were I would get the beach ball for minutes at a time not doing anything. I saw mostly speed issues, not really stability ones. I since only run ASM, and Silk with no probs or periods of slowdowns. So it might have been a combo of all the hacks, or it may have been just one. This is on a dual gig.

Rickster · Jun 6, 2002, 07:29 PM

Unsanity's "Haxies" and other similar products have not risk of destabilizing the system -- they pretty much all do their nasty tricks in user space. They can potentially cause trouble for applications, from simple misbehaviors (we've seen odd things happen in OmniWeb with WindowShade X enabled) to app crashes (aka "unexpectedly quit"), but they generally aren't able to cause kernel panics or destroy the Window Server.

Chuckit · Jun 6, 2002, 08:12 PM

<blockquote>quote:<hr />Originally posted by Fotek2001:
In spite of this, Unsanity have been able to make haxies to change global system behaviour and I'm interested to know how it's done and if these changes can affect the stability of other applications and the core OS.<hr /></blockquote>Well, it looks Silk can bring some applications down if they already have font rendering issues. But that's the worst damage I've heard of from a haxie.

moki · Jun 7, 2002, 02:08 AM

<blockquote>quote:<hr />Originally posted by Millennium:
And that is how the Haxies work. It's actually very clever how Unsanity managed this feat. It works by using Carbon Events to listen for things like (in Silk's case) app launches. Then they make the proper system calls and get the heck out of there, so the app is left to execute in peace, unpatched in the case of Silk. Not all haxies can do this "execute-a-call-and-get-out" method (WindowShade X can't, for example), but they run along similar lines.<hr /></blockquote>Actually, no, that's not how Haxies (or other programs that patch into OS X apps) work. Default Folder, WindowShadeX, Silk, and many others use something called "libPatch" by Ed Wynne. Ed wrote a nifty nifty library that does some rather skanky things with mach ports to allow you to inject a piece of code into another application's address space.

Under Mac OS X, usually applications are entirely partitioned from eachother; libPatch allows another application to inject some code into each application, which allows some interesting things to be done that normally could not.

libPatch allows developers to do on the kind of thing old-style extensions did under Mac OS X, but on a per-application basis. It's a double-edged sword -- libPatch lets you do things that are otherwise impossible, such as extending the OS in the ways the above programs have. On the downside, it allows one application to potentially crash another application (but it shouldn't affect the stability of the actual OS).

These hacks are clever, yes, but credit where credit is due: libPatch is the clever enabling technology.

[ 06-07-2002, 02:10 AM: Message edited by: moki ]

Fotek2001 · Jun 7, 2002, 05:22 AM

Wow... Thanks for all the useful replies everyone!