Jump to content

iPad IOS 5.1 crashing


mercantigo

Recommended Posts

judging by your post about os x archive utility adding an invisible folder that invalidates the signature i would wager that at some point our build process got changed in a way that files are added after the signing process thereby invalidating the signature.

Link to comment

I don't know for sure, but I think the addition of the OSX folder came after using AppResign, rather than being a result of the (un)zipping process. The folder is basically just a mirror of the contents of the .ipa but with "._" before all the file names.

 

Avenger - I agree. The effect of code signing is basically to prevent any third-party code running on iDevices which hasn't been approved and distributed by Apple. I struggle to see how that's not an anti-competitive practice, especially given that the EU is (was?) "investigating" Microsoft for including Internet Explorer on fresh installs of Windows.

Link to comment

I see: the IPA was invalidated not the signature? If you have access to a mac feel free to install xcode (free) and figure out what code signing project settings are incorrect/missing and send us a patch.

 

the __MACOSX folder, i assue you, annoyingly created by the mac archive utility.

 

about code signing in general:

it is not just a way to lock out developers (that is done by ONLY allowing signed code from your root CA). signed code itself is a GoodThing because it establishes trust much like self-signed vs trusted root signed SSL certificates. I'm sure wikipedia has an article about it that will explain its true purpose.

 

believe it or not this is not an iOS thing or even an Apple thing. it is on Android too; of course Android lets you run untrusted code provided you enable it in device settings. lack of this ability on iOS is what makes code signing seem "anti-competitive".

 

I'm not saying Apple isn't being anti-competitive or unfair to customers, and hope very much that one day you won't need to jailbreak just to run programs that don't meet the requirements of being distributed on apples app store.

 

lastly: this isnt actually difficult to do. obviously without a target device it is difficult to test, however :)

Link to comment

Sorry, I should have said "the effect of Apple's implementation of code signing" above.

 

Don't think it renders the .ipa invalid because a) you can still install it via iTunes and b) I infer from various posts here that people have got the buildbot builds to work fine on iOS <5.1. From what I understand Apple changed the way the OS handles code signatures for 5.1, since the main (to my knowledge, at least) tools for homebrew signing (ldone/ldid) no longer work.

 

If I can get access to a Mac I will have a look and see whether I can contribute at all, but given that one week ago I thought code signing was something to do with Saussure I doubt I will be able to help much. For now I've got BG1 running in EasyTutu so will give that a try over the next few days. Fullscreen disables touch input but it let me prance around Candlekeep and talk to people fine. Thanks for all your help!

Link to comment

fullscreen doesnt disable touch input. the problem is the coordinates seemingly get screwed up, but i havent been able to reproduce the problem in the simulator so I'm not sure where the problem is exactly.

 

there are a couple of potential candidates and the bug may actually be inside SDL (not likely i think)

 

the most likely candidate seems to be in SDL20VideoDriver::ProcessEvent

 

#if TARGET_OS_IPHONE
 if (fullscreen) {
  // simulated window adjustment
  xScaleFactor = (state->xres / backBuf->w);
  yScaleFactor = (state->yres / backBuf->h);
 } else {
#endif
 int w, h;
 SDL_GetWindowSize(window, &w, &h);
 xScaleFactor = (state->xres / w);
 yScaleFactor = (state->yres / h);
#if TARGET_OS_IPHONE
  // now we need to offset the x/y coordinates
  xOffset = ((w - backBuf->w) / 2) * -1;
  yOffset = ((h - backBuf->h) / 2) * -1;
 }
#endif

 

you could try using SDL_GetWindowSize for both cases.

 

despite being the author of this code i don't recall why we are using backBuf->w and backBuf->h at all. Realistically i believe when GemRB is in fullscreen the backBuf dimensions are the same and the window.

 

then again maybe its because iOS uses a renderer that can scale games to fullscreen that wouldnt normally fill the screen (when the resolution isn't 1024x768 ex PST).

 

It's been so long i dont quite remember, but i'm almost certain all these cases (fullscreen vs windowed etc) work fine in the simulator so maybe it has more to do with a retina display (double pixel density)

 

since i now have iOS 5.1 simulator and a new MBP equipped with a retina display maybe i can finally reproduce this problem in the simulator.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...