[TheSpaz]

For those of you who thought shapeshifter was so great because it doesn't modify System files... you are wrong. Look at what I found. I installed the theme Siro with ShapeShifter 2.2 and it does modify the Search.bundle file for Spotlight. Just look inside the package contents and you'll see the files from the theme you have installed.

So that whole "ShapeShifter doesn't touch your System files" thing is incorrect now.

[Kevin]

I am sure there will be a logical explanation.

[BatmanPPC]

Originally Posted by TheSpaz

For those of you who thought shapeshifter was so great because it doesn't modify System files... you are wrong. Look at what I found. I installed the theme Siro with ShapeShifter 2.2 and it does modify the Search.bundle file for Spotlight. Just look inside the package contents and you'll see the files from the theme you have installed.

So that whole "ShapeShifter doesn't touch your System files" thing is incorrect now.

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

[goMac]

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.

[goMac]

Originally Posted by BatmanPPC

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

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.

[TheSpaz]

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?

[TheSpaz]

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?

[rhythmicmoose]

Originally Posted by TheSpaz

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.

[Randman]

Fud

[G0Ducks]

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

R

[Sage]

Originally Posted by TheSpaz

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

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.

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?

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.

[Ji Eun]

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

[mrmister]

"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*.

[kwyjiboy]

+1!

[TheSpaz]

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.

[MindFad]

Suddenly you care about Spotlight? [/fans flames]

[rickey939]

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

[TheSpaz]

Originally Posted by MindFad

Suddenly you care about Spotlight? [/fans flames]

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.

[mpancha]

Originally Posted by mrmister

"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*.

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

[rhythmicmoose]

Originally Posted by mrmister

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

"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.

[goMac]

Originally Posted by rhythmicmoose

"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.

[Kevin]

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.

[nooon]

Originally Posted by Kevin

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.

Does this apply for all APEs or just Shapeshifter?

[Kevin]

Originally Posted by nooon

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.

[Blacktiger]

Originally Posted by goMac

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.

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.)

[Rosyna]

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).

[mrmister]

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.

[goMac]

Originally Posted by Blacktiger

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.)

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.

[goMac]

Originally Posted by nooon

Does this apply for all APEs or just Shapeshifter?

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

[Kevin]

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

[Rosyna]

Originally Posted by Kevin

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

Are you sure that's what you're noticing? When was the last version of SS you used?

[Rosyna]

btw, Shapeshifter's open doodad is constant time. No O business at all.

[goMac]

Originally Posted by Rosyna

btw, Shapeshifter's open doodad is constant time. No O business at all.

If you're reading a plist to find a match for a file you no longer have a constant algorithm time. You're then running into a search algorithm time which is an O function. The search time becomes dependent on the file you're looking at, which at worst case is O, where O is the number of files that Shapeshifter is theming. Therefore, the more ShapeShifter themes, the worse your maximum possible speed hit is.

What Blacktiger was talking about was something like my example above, where the code has a constant run time. In computer science something with a constant run time is ignored when looking at algorithm effectiveness. Big O notation simply drops anything constant.

[fisherKing]

in my use, shapeshifter/mightymouse/fruitmenu...slow down my mac...a bit.
if i run a test user account without ape, things are a little faster.

still...not worth giving them up! i LIKE a custom theme, a better cursor. and fruitmenu's custom contextual menus are indispensable.

whatever works 4 u!

[Rosyna]

goMac, do *not* assume to know how SS is doing it. You know what they say about people that assume things.

[goMac]

Originally Posted by Rosyna

goMac, do *not* assume to know how SS is doing it. You know what they say about people that assume things.

If you're looking in a list of files it's going to be an O algorithm. That's the way application theming is done at any level. The results that TheSpaz is getting do nothing but verify this. This would also probably be why ShapeShifter keeps a plist of files for the current theme, or why when you do an fs_usage you can see ShapeShifter redirecting the file opens, or why ShapeShifter is still writing out all the files from a theme individually, or why ShapeShifter has to reapply on a system update, or why ShapeShifter has to reapply when iTunes is updated... Either that or ShapeShifter keeps the plist for no clear reason, and all paths are hardcoded (which in itself could still be considered an O search algorithm), but I doubt that. I don't think ShapeShifter's fsref overrides are just for fun.

If you're catching a resource fetch mid call and pulling from another open resource file, yes, that's going to be a constant. That still doesn't change that for any application skin, even if the system is just running opens that have nothing to do with themes, you're going to take an O level hit. An O level hit doesn't refer to the average speed hit, it refers to the maximum. At maximum, you could take a speed hit that is dependent on how many files you are theming.

[Tick]

The bickering between the unsanity crowd and gomac continues to make me giggle, but I will digress.

Does anyone have any substantial proof as to what gomac or Rosyna are saying? Statistics on resource usage while shape shifter/other unsanity products would be nice.

[goMac]

Originally Posted by Tick

Does anyone have any substantial proof as to what gomac or Rosyna are saying? Statistics on resource usage while shape shifter/other unsanity products would be nice.

You could maybe do something with fs_usage, I'm not sure. Like I said before, the speed hit isn't even going to be noticeable by the end user, so I'm not sure why Rosyna is arguing this.

If you take a recursive function it's upper bound of running time is going to be dependent on how many possible possibilities there are. The application skinning functionality for ShapeShifter is going to be O(number of files being skinned), no matter how it's done. The longest possible running time is going to be the number of files being skinned. This is because at worst, ShapeShifter is going to have to look at the file being opened and compare it against every single file that it is interested in theming.

If Unsanity has found a way to make a recursive function where the number of iterations is dependent on some sort of scaling list, and make that run time constant, I have a friend who would be very interested in it. I also think they should talk to the Nobel Prize people.

Debating about Big O notation on a GUI forum seems kind of pointless to me. If you'd like to continue looking at Big O notation Rosyna see Google or email me at colin (at) whitemagiclabs.com.

[Tick]

Originally Posted by goMac

You could maybe do something with fs_usage, I'm not sure.

Without making a parser for that it would be a horribly long process to find out specifics. I haven't loaded shapeshifter on my g4 ibook yet, but when I was on the g3 ibook it wasn't that much of a difference.

[Ji Eun]

on my current machine there is no noticable lag whatsoever. on my previous one (G4800 / 640) the lag when launching an app was noticable.

[TheSpaz]

This thread isn't going anywhere... it's pretty much dead. I was proved incorrect... now isn't there a different thread for ShapeShifter benchmarks?