- Joined
- Aug 6, 2009
- Messages
- 452
- Trophies
- 0
- Age
- 44
- Location
- The Boonies
- Website
- Visit site
- XP
- 135
- Country
Hey guys, I have a question regarding stub IOSs. I was originally worried that stub IOSs were a crap idea, presenting a brick risk when downgrading and even wasting a tiny bit of space. However, when I see how many people out there are doing things like CIOSCORP, and thereby how many people are susceptible to upgrade bricks, I can see how they probably keep a lot of people out of trouble.
I wonder though, is there a better idea? Rather than removing stubs or leaving them in place [a chance to brick either way if one's not careful] could we maybe develop another solution? I don't know if it's possible, but I wonder if we could develop something useful but not much larger than the current stub. Does anyone think that it's possible to develop some kind of "IOS pointer" to take the place of a stub?
The idea is that a little piece of code would be installed in the place of the stub. When it would get called, it'd say, "oh snap, this program wants IOS ##a but THAT'S ME! OH NOES! I'd better redirect it's call to IOS ##b, he'll know what to do!" -- masquerading as one IOS while passing its calls onto another.
Any thoughts? What kinds of restrictions might keep us from doing this? Think we can make this happen?
I wonder though, is there a better idea? Rather than removing stubs or leaving them in place [a chance to brick either way if one's not careful] could we maybe develop another solution? I don't know if it's possible, but I wonder if we could develop something useful but not much larger than the current stub. Does anyone think that it's possible to develop some kind of "IOS pointer" to take the place of a stub?
Any thoughts? What kinds of restrictions might keep us from doing this? Think we can make this happen?