ShapeShifter DOES Modify System Files!

I am sure there will be a logical explanation.

nope, doesnt modify the file .. do this in terminal and see for yourself:

% cp /System/Library/CoreServices/Search.bundle/Contents/Resources/MDSearchWidget_Pressed-1.tiff /tmp/
% open /System/Library/CoreServices/Search.bundle/Contents/Resources/MDSearchWidget_Pressed-1.tiff /tmp/MDSearchWidget_Pressed-1.tiff

It doesn't modify the file per say. It tricks the file system into pointing to a different file instead of the one in the system folder. Spotlight finds MDSearchWidget_Pressed, and when you open it, Preview asks the system to open the file at the path for MDSearchWidget_Pressed. ShapeShifter, using APE, has patched into OS X's open routines and intercepts the open request for MDSearchWidget_Pressed. It takes the request looks through it's cache folder for a file that matches the one the system is trying to open. If it doesn't find a matching file, it allows the system to continue loading the file it originally tried to load. If it does find a matching file in the cache directory, it tricks the application asking the file into instead loading the matching file from the ShapeShifter. In essence, Preview asked the system to load the MDSearchWidget_Pressed file, ShapeShifter intercepted the call to open MDSearchWidget_Pressed, tricked the call into opening a themed MDSearchWidget_Pressed widget instead that it keeps elsewhere on the hard drive.

So yes, ShapeShifter IS still replacing files. It is not however replacing any files on the hard drive. Instead it patches into the OS X file handling system and redirects calls to files it is interested in changing to different paths. This does mean it can use a different set of patched paths per user in since the files aren't being replaced, and no authentication is needed.

Here is demo code written in Mach_Inject and not APE. To try it, create a Cocoa Application in XCode, download Mach_Override, put both mach_override.h and mach_override.m in your project's classes, and replace the code in your Main.m with the following:

code:

---

#include <sys/attr.h>

#include "mach_override.h"
#import <Cocoa/Cocoa.h>
#include <Carbon/Carbon.h>

typedef OSStatus (*fsmakerefProc)(const UInt8 * path, FSRef * ref, Boolean * isDirectory);
OSStatus FSPathMakeRefOverride (const UInt8 * path, FSRef * ref, Boolean * isDirectory);
static fsmakerefProc gFSPathMakeRef;


int main(int argc, char *argv[])
{
mach_override( "_FSPathMakeRef", NULL, FSPathMakeRefOverride, (void**) &gFSPathMakeRef );
return NSApplicationMain(argc, (const char **) argv);
}

OSStatus FSPathMakeRefOverride (const UInt8 * path, FSRef * ref, Boolean * isDirectory)
{
OSStatus returnVal;
FSRef extrasRef;
gFSPathMakeRef("/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/Extras.rsrc",&extrasRef,0);
returnVal=gFSPathMakeRef(path,ref,isDirectory);
if(noErr == FSCompareFSRefs (&extrasRef,ref))
{
returnVal=gFSPathMakeRef("/Extras.rsrc",ref,isDirectory);
}
return returnVal;
}

---

This code demos patching the file system to theme. Please note if you don't have a valid Extras.rsrc on the root level of your hard drive the application will crash. It's demo code, not crash proof code.

The reason this works is probably because ShapeShifter patches FSRef like my above code. Using the terminal bypasses FSRef by using the UNIX Open() command. Spotlight being a proper Mac OS application probably does use Carbon FSRef's.

I got lost in all of that Programmer language stuff. So basically those files are not actually in that folder... or am I wrong?

What would happen if I was running a ShapeShifter theme and I decided to un-install ShapeShifter from my System without first re-applying the Aqua theme?

What would happen if I manually uninstalled ShapeShifter while a theme was applied... could I log out and log back in and see that it's automatically back to Aqua? And then... would those files still be in that folder?

So what I want to know... how did the name of that file change? ShapeShifter must have done SOMETHING to Search.bundle to rename those System files or replace what was in there. I'm not understanding this stuff... can someone help me out? What exactly am I missing here?

What I think goMac is trying to say is something like this: ShapeShifter is acting like a secret agent who infiltrates your office and replaces your files every time you go to look at them. He doesn't actually go into your filing cabinet and physically alter your files and folders, but when you pull something out to look at it, he rappels down from the ceiling Mission Impossible style and does a quick switch on whatever you're about to look at.

(Yeah, yeah, we've heard it before.)

But even when you're going into Search.bundle to find those resource images, ShapeShifter is still doing it's job. Whenever you try to look at them, ShapeShifter performs its little switcharoo. It doesn't matter whether the images are being displayed in the window of an application or if they're being opened in Preview.

Fud

Ah.. the great Namdnar Speaks! Sheesh...

R

Let’s say the system is looking for Widget.tiff. Normally, Widget.tiff is stored at a specific place on your HD. When the OS goes to look for it though, SS will intercept and point it to the new file. And as rhythmicmoose said, it doesn’t matter whether the system is looking for the file to draw as a widget, or if you’re looking at the file in the Finder or Preview – SS will still do its quick interception and point to a file that isn’t actually in that spot.


In both cases, you’d be back to Aqua, and no, the alternate theme files won’t be in those spots, because they never were to begin with. They are never physically there – they only appear there, because that’s what SS is telling the OS to point at instead of the real files.

this thread sucks. not surprising considering....
aren't you supposed to be on panther anyways.... ugh.

"What I think goMac is trying to say is something like this: ShapeShifter is acting like a secret agent who infiltrates your office and replaces your files every time you go to look at them. He doesn't actually go into your filing cabinet and physically alter your files and folders, but when you pull something out to look at it, he rappels down from the ceiling Mission Impossible style and does a quick switch on whatever you're about to look at."

Which is why SS always sucks up system resources. *Always*.

+1!

Oh... I understand now. Sorry for wasting everyone's time with a stupid question. Duh... I should have know all that developer stuff... what was I thinking???

By the way... I run Panther at home... I run Tiger at work. So I KNOW what's going on in Both OSes and I still don't like Tiger... it's lots of trouble at work... and when I get home... I'm in peace.

Suddenly you care about Spotlight? [/fans flames]

Nooooooooooooooooooooooooooo, say it ain't so. My ShapeShifer is pure!

Actually... I was about to remove the spotlight menu... but, I was a little curious as to what was actually in it... that's where I found the graphics. So... no I don't really care about spotlight.

haha, that's the best explanation ever! Cheers!

"Always" is a bit strong. It really only does so during the rappelling and snatching steps. After that. There should be no effect on the system.

Actually, MrMister is right. Every time the system tries to open a file ShapeShifter will add the overhead of actually checking to see if it's a file it's interested in, even if it doesn't actually need to patch the file. The penalty is not huge, but you're probably about doubling (edit: now that I think about it, the changer has to search some database of files it's interested in, which depending on the algorithm, would probably be at least triple or quadruple) the time it takes to get a file open for reading. This isn't noticeable under most cases, but from a strictly computer science standpoint, that's a decent speed hit.

Yes SS does slow your system down. One of the main reasons I don't use it. The very same reason I stopped using Kaleidoscope. Anytime you open a new Finder window, SS is slower than a none-SS Finder. It's like downgrading your computer.

Maybe SS should have two options? A "Safe Install" and a "Full Install" ?

I'd probably even use SS if it actually replaced the files.

Does this apply for all APEs or just Shapeshifter?

Not sure, the only ones I have used is Mighty Mouse for a few days and ShapeShifter.

Actually, if you want to be technical. From a computer science standpoint, doubling and tripleing are merely big-omega(2 or 3)... and since we throw out constands you have big-omega(1). So its technically not a decent speed hit. In fact its a negligable speed hit.

(Note that in reality doubling or tripleing can be a decent performance hit if the algorithm does actually take up a significant amount of time to complete. I can't really say that I have ever noticed SS's speed hit though, and I have an 800MHz G4 eMac with a GeForce 2 MX.)

This is an extremely negligible speedhit. I mean on the nanosecond scale here. And OS X only opens most files once so you're getting this hit once. I've noticed that humans can't tell any lag has passed unless it is over 60 milliseconds, and this is hundreds of times less than this (and I mean that for all files, not per file).

R~

You should put together a demo with timings, or invite others to do so—concerns about speed hits are the #2 reason people shirk from SS, right after concerns for stability.

Sure, a big O(squared) hit would be awesomely bad. In reality though, it is a 2O hit because Shapeshifter has to go back and look up in it's table of files that it wants to override to see if it has a match. At this point ShapeShifter takes a big O operation and makes it a big 2O operation. So it's not just adding a constant, it's adding another big O operation.

It depends entirely on how the author wrote that APE module.

It's a speed hit I can notice considerably. The same with Kaleidoscope back in the day.