PseudoSubstrate, a replacement for MobileSubstrate (available in Cydia) is now available for the Installer.app, allowing to host and use the packages that use MobileSubstrate.
RiP Dev has posted a detailed explanation of why they believe PseudoSubstrate improves on MobileSubstrate and we have reprinted it below... For more information please use the Read More link below to visit the RiP Dev site.
-----
PseudoSubstrate is used for situations when you don't have Cydia installed or prefer Installer over the former and requires no additional work from developers' side. And it's faster, too. The first package is also available now, named MySMS.
And a little background for the curious minds. Often the task of many utilities are to extend the functionality of existing applications, such as SpringBoard, SMS, and so on. Of course, to extend the application, some additional code created by a third party has to be loaded into the application memory and then alter the behavior of these applications. How is this done? Altering is performed by finding one of the common functions in the application that perform the task we'd like to alter (for example, function that sends an SMS message). Then a replacement "patch" function is written that accepts the same parameters as the original, and it is "swapped" with the original one. Usually these patches do something then call the original, so essentially nothing is lost functionality-wise.
Both Mobile Enhancer and MobileSubstrate are essentially bootstrappers that aid the patch modules in loading into the host application they are about to extend and to help them patch the functions by providing common interfaces that replace the original function with a patched one and provide facilities for calling the original afterwards. They're nothing else than that - iterating through a list of patch modules loading them one-by-one into the application you're launching and then providing some helpers to assist the modules into getting the job done (and don't conflict with other modules who potentially wish to patch the same function).
Of course, nothing is stopping a developer for creating their own bootstrapper, and this is what some of them still do. But it's more logical to adopt a single platform and then use it.
Mobile Enhancer exists since September 2007, and is a direct descendant (actually, in some aspects, it is an ARM port of it) of Application Enhancer by Unsanity, which is a Mac OS X library doing the same thing. MobileSubstrate was born sometime this year because apparently its author didn't like the fact Mobile Enhancer is closed source (but still free). I may be wrong in the reasoning, though, maybe the author will comment on his own.
As it often happens, free is not necessarily better. As any quick&dirty job, MobileSubstrate does what it's made for, but the way it does it is far from effective. But hey, it's open source, anyone can make it better, right?
You may think I might be biased, but let's look at the facts:
- MobileSubstrate is using a simple way of patching C functions where multiple patches for the same function will conflict.
- The way of patching Objective C methods used by MobileSubstrate is puzzling me. Instead of just swapping the IMP addresses of the functions, it does that, but also adds a new method into the class methods list. While I can understand, why (it's easier for the developer to write [self orig_patchedFunction:arg1] than gPatchedFunction(obj, sel, arg1);) but in the end it causes a separate call to objc_msgSend resulting in 50 to 400 extra instructions to be executed just to call the original function. Talk about speed, huh.
- The way MobileSafety works (it controls the Safe Mode commonly seen in the SpringBoard) is okay for a UN*X diehard - but it relies on some assumptions it shouldn't. For example, it traps common signals sent when the app is crashed (SIGSEGV, SIGBUS, etc) but doesn't passes the extra information to next handlers in chain! Hello, this is 21st century, and we're not talking of command line tools here - it's done inside a full-fledged GUI app, and who knows, that extra information MobileSafety discards may be useful - you never know!
- The loader itself is written in Objective C which means it is much more slower than compared to the one written in pure C - and that affects every application launch.
Well, I guess since it still gets the job done, I couldn't blame it much. It's a great concept which got executed fairly poorly - which is understandable as the author apparently have a day job and maybe has little time and/or knowledge for hacks like this (again, UN*X is not Mac OS X).
Either way... since MobileSubstrate is inferior to Mobile Enhancer, it was pretty easy to create a wrapper that would load MobileSubstrate libraries (using pure C, so it does it faster) and provide the functions provided by MobileSubstrate (that also work more correctly in some aspects) so the developers who use MobileSubstrate don't have to change anything in their applications - it will just magically work.
-----
Read More
RiP Dev has posted a detailed explanation of why they believe PseudoSubstrate improves on MobileSubstrate and we have reprinted it below... For more information please use the Read More link below to visit the RiP Dev site.
-----
PseudoSubstrate is used for situations when you don't have Cydia installed or prefer Installer over the former and requires no additional work from developers' side. And it's faster, too. The first package is also available now, named MySMS.
And a little background for the curious minds. Often the task of many utilities are to extend the functionality of existing applications, such as SpringBoard, SMS, and so on. Of course, to extend the application, some additional code created by a third party has to be loaded into the application memory and then alter the behavior of these applications. How is this done? Altering is performed by finding one of the common functions in the application that perform the task we'd like to alter (for example, function that sends an SMS message). Then a replacement "patch" function is written that accepts the same parameters as the original, and it is "swapped" with the original one. Usually these patches do something then call the original, so essentially nothing is lost functionality-wise.
Both Mobile Enhancer and MobileSubstrate are essentially bootstrappers that aid the patch modules in loading into the host application they are about to extend and to help them patch the functions by providing common interfaces that replace the original function with a patched one and provide facilities for calling the original afterwards. They're nothing else than that - iterating through a list of patch modules loading them one-by-one into the application you're launching and then providing some helpers to assist the modules into getting the job done (and don't conflict with other modules who potentially wish to patch the same function).
Of course, nothing is stopping a developer for creating their own bootstrapper, and this is what some of them still do. But it's more logical to adopt a single platform and then use it.
Mobile Enhancer exists since September 2007, and is a direct descendant (actually, in some aspects, it is an ARM port of it) of Application Enhancer by Unsanity, which is a Mac OS X library doing the same thing. MobileSubstrate was born sometime this year because apparently its author didn't like the fact Mobile Enhancer is closed source (but still free). I may be wrong in the reasoning, though, maybe the author will comment on his own.
As it often happens, free is not necessarily better. As any quick&dirty job, MobileSubstrate does what it's made for, but the way it does it is far from effective. But hey, it's open source, anyone can make it better, right?
You may think I might be biased, but let's look at the facts:
- MobileSubstrate is using a simple way of patching C functions where multiple patches for the same function will conflict.
- The way of patching Objective C methods used by MobileSubstrate is puzzling me. Instead of just swapping the IMP addresses of the functions, it does that, but also adds a new method into the class methods list. While I can understand, why (it's easier for the developer to write [self orig_patchedFunction:arg1] than gPatchedFunction(obj, sel, arg1);) but in the end it causes a separate call to objc_msgSend resulting in 50 to 400 extra instructions to be executed just to call the original function. Talk about speed, huh.
- The way MobileSafety works (it controls the Safe Mode commonly seen in the SpringBoard) is okay for a UN*X diehard - but it relies on some assumptions it shouldn't. For example, it traps common signals sent when the app is crashed (SIGSEGV, SIGBUS, etc) but doesn't passes the extra information to next handlers in chain! Hello, this is 21st century, and we're not talking of command line tools here - it's done inside a full-fledged GUI app, and who knows, that extra information MobileSafety discards may be useful - you never know!
- The loader itself is written in Objective C which means it is much more slower than compared to the one written in pure C - and that affects every application launch.
Well, I guess since it still gets the job done, I couldn't blame it much. It's a great concept which got executed fairly poorly - which is understandable as the author apparently have a day job and maybe has little time and/or knowledge for hacks like this (again, UN*X is not Mac OS X).
Either way... since MobileSubstrate is inferior to Mobile Enhancer, it was pretty easy to create a wrapper that would load MobileSubstrate libraries (using pure C, so it does it faster) and provide the functions provided by MobileSubstrate (that also work more correctly in some aspects) so the developers who use MobileSubstrate don't have to change anything in their applications - it will just magically work.
-----
Read More