[WhiteSpir1t]

Someone is looking to port iOS to the Z10. With this, the "cesspool" aka Android can also be loaded on the Z10.

Dev says as long as all is ARMv7 code, despite 1% is messed up code and the other 99% of iOS should be interoperable on QualComm's SnapDragon Krait from Apple Ax Swift.

How do you guys think of this? If you're stressed about this, vent here

[jrohland]

I like it. True multitasking finally comes to iOS.

[howarmat]

lol, i will believe it when i see it. otherwise its all talk, kinda like bb10 on the PB

[WhiteSpir1t]

That's true. I'm the same. Lot's of talkers. I thought about it, but it made sense when that iOS App on PlayBook hack crossed my mind.

That dev, in his video, seemed to show a debugger running on translation lookaside buffer and he's got it all mapped out to run full blown on his Windows PC. So it's definitely feasible. Just Think Different

[quackquack147]

Someone is looking to port iOS to the Z10. With this, the "cesspool" aka Android can also be loaded on the Z10.

Dev says as long as all is ARMv7 code, despite 1% is messed up code and the other 99% of iOS should be interoperable on QualComm's SnapDragon Krait from Apple Ax Swift.

How do you guys think of this? If you're stressed about this, vent here

you are 100% right. i have spent nearly 5-6 years playing with embedded devices. first with mips and then moved into arm too. mips are of these types mips32 and mips64 and further divided into mipsel mipseb and many more classification.
and likewise arm is now heading for 64 bit arch. so we got arm32 and arm64, x-gene is a classic example of 64 bit arm. and we debian folks are working on them. we are 99% done with most porting. plus dont forget we got help from linaro too. which means we will soon have 100% support for arm64.
now coming to finer arm details. mind you i am not an arm expert and i will try to share little information i got with you.
arm is a company/organization which does maximum research and development work at present in UK. and they sell their licence to many vendors viz TI or Qualcomm, they inturn mod the spec sheets and add their own bit. like HS is a common set for arm cpu which enables hash and sign check. TI and qualcomm and many more arm vendors their own method od doing this. and its this HS which does the real trick.
So if apple hires a few guys from AMD and send them to arm team for their CPU wont be any sweat since armv7 is armhf or arm hard float. and the code which is their for android will work in all armhf w/o much porting needed. which is what he means by 99% compatible and 1% is vendor specific.
but what really will pi$$ you off will be the bootloader. there are different caches aka multicache. and each cache has different sizes which makes us leave with one thing. "Pray that the vendor release the key." which they wont so you need to "prey on their key."
i been trying to understand the keysize. the basic info which i gathered is this.
there are 2 stage booting in arm, one is called initialiazation and second is called chain bootloading.
first stage is 99% signed and second stage is mostly never signed. and also useless to sign the second stage. which leaves us with guessing. as how much is too much encryption.
this is because the MLO is only 20 KB which holds the code to kick of first stage booting. and second stage booting or chain loading will not happen unless first stage works smooth, but i have seen the MLO to be the size of
-rw-r--r-- 1 testuser testuser 128K Sep 13 2011 MLO_4430_HS
if the MLO which i get from compiling source (w/o stripping and -O2 gcc optimization) is
-rw-r--r-- 1 root root 20K Jun 10 23:55 MLO
then there is a gap of 128KB-20KB= 108KB = 108*1024*8 = 884736, enough to fit in 3072 bit RSA encryption. but if its in L2 cache then the size of sram is only 16K which reduces the chance of 3072 bit RSA encryption.
did anyone get the logic? or the information flew way above your head?
thanks
-paul

[WhiteSpir1t]

you are 100% right. i have spent nearly 5-6 years playing with embedded devices. first with mips and then moved into arm too. mips are of these types mips32 and mips64 and further divided into mipsel mipseb and many more classification.
and likewise arm is now heading for 64 bit arch. so we got arm32 and arm64, x-gene is a classic example of 64 bit arm. and we debian folks are working on them. we are 99% done with most porting. plus dont forget we got help from linaro too. which means we will soon have 100% support for arm64.
now coming to finer arm details. mind you i am not an arm expert and i will try to share little information i got with you.
arm is a company/organization which does maximum research and development work at present in UK. and they sell their licence to many vendors viz TI or Qualcomm, they inturn mod the spec sheets and add their own bit. like HS is a common set for arm cpu which enables hash and sign check. TI and qualcomm and many more arm vendors their own method od doing this. and its this HS which does the real trick.
So if apple hires a few guys from AMD and send them to arm team for their CPU wont be any sweat since armv7 is armhf or arm hard float. and the code which is their for android will work in all armhf w/o much porting needed. which is what he means by 99% compatible and 1% is vendor specific.
but what really will pi$$ you off will be the bootloader. there are different caches aka multicache. and each cache has different sizes which makes us leave with one thing. "Pray that the vendor release the key." which they wont so you need to "prey on their key."
i been trying to understand the keysize. the basic info which i gathered is this.
there are 2 stage booting in arm, one is called initialiazation and second is called chain bootloading.
first stage is 99% signed and second stage is mostly never signed. and also useless to sign the second stage. which leaves us with guessing. as how much is too much encryption.
this is because the MLO is only 20 KB which holds the code to kick of first stage booting. and second stage booting or chain loading will not happen unless first stage works smooth, but i have seen the MLO to be the size of
-rw-r--r-- 1 testuser testuser 128K Sep 13 2011 MLO_4430_HS
if the MLO which i get from compiling source (w/o stripping and -O2 gcc optimization) is
-rw-r--r-- 1 root root 20K Jun 10 23:55 MLO
then there is a gap of 128KB-20KB= 108KB = 108*1024*8 = 884736, enough to fit in 3072 bit RSA encryption. but if its in L2 cache then the size of sram is only 16K which reduces the chance of 3072 bit RSA encryption.
did anyone get the logic? or the information flew way above your head?
thanks
-paul

Damn Paul I barely finished posting an you're ahead already!! Lol


Sent from my iPhone4S after my Z10 took a trip in the bowl

[quackquack147]

lol, i will believe it when i see it. otherwise its all talk, kinda like bb10 on the PB

i think you need to reconsider what you said. armhf is universal to the best of my knowledge. thats because arm.co.uk sells the arm rights to vendors and they produce arm chipsets and arm charges them 1.17 US$/chip. which means it doesnt matter if the arm is from apple or qualcomm or ti or apm or any tom d*ck harry vendor, whats common is C-7 or C-9 or C15. C = Cortex ARM. the vendors makes minor changes. which means the arm C-9 from apple is same as arm c-9 from TI and also C-15 from TI is same as C-15 from snapdragon. only thing which changes is the vendor implementation of little tiny different things.
hope this helps.
thanks
-paul

[quackquack147]

Damn Paul I barely finished posting an you're ahead already!! Lol


Sent from my iPhone4S after my Z10 took a trip in the bowl

be quick or be dead!
thanks
-paul

[quackquack147]

$ strings MLO_4430_HS
PRIMAPP
KEYS
CertPK_
,P_w
?Z8k
yb@Dy^
V=f([
Y`[oq
^MKYQ
Vkk%K,<
t+K7
"H/K
PK_SIG_INFO_ROM_PKC
YB,u
Wss#j
hhUp?x
k05s
H|_+
CertPPA
u/?$
PPA_SIGINFO_ROM_PKC
dkHJ
044pR
%A'x+
jL`h
iIyD
dIyD
`IyD
UIyD
}HHD
\^`~
j*F
FATAL ERROR
Error Codes from ROM Code sub-modules:
See MSHIELD-DK/src/common/include/sec_err_define.h
For reset reason, refer to src/common/include/sec_reset.h
R0= %x
HW_Reset_Type 0x%x
R1= %x
Reason 0x%x
SEC_RESET_
UNDEFINED_INSTR
EXTERNAL_PREFETCH_ABORT
R2= %x
LR_Abort 0x%x
R3= %x
XFAR 0x%x
R4= %x
XFSR 0x%x
R5= %x
ScmPlatformStatus 0x%x
R6= %x
SecErrorFuncStatus 0x%x
R7= %x
SdpError 0x%x
R8= %x
RegistersBackup 0x%x
EXTERNAL_DATA_ABORT
SDP_DATA_ABORT_FAILED
PREFETCH_ABORT_FAILED
R%d= %x
[0x%x]:
0x%x
MMD(h
9hw
G(h@
(`p
FHDCh F
ID h
$c@op
JID h
L|D
LLDa
LLDa
OODy
MMDi
C(pp
OOD9h
$MD9hU
4`w
0@ H
jFID
IfhID h!
Iw ID h
F:F1F(F
Ge`(F
!hRF
`pG0
(NND
%(8U
x8Ud
[1;31m
HxDpG"(
0a"9
HxD&0pG
IID h")
ID h
`D`>
D%!:F F
D x%(;
"Fd
!:F F
`IhA`pG
FIyD
@ceR
`@$R
P,aR
@#dL|8,R
@%lE
%dA$R
@%i%
P,`R
@c`R
` hR
"@fl
\&`[
#MHDMD
h)h"(
FX"!FhF
F "!FhF
G)hw
$mF~D
Non Secure context:
= %x
,54/541
[PPA] Non existing Service
O M
0@ ,@
`pG
$c@o
!A`@
pG$c@o
)h)`
IID h
!jFO
ID h
ID h
ID h
"HHD
HPbO
aHaO
ID h
o$c@o
&MD(h`
0a"9
pG`/
IyD
I@<yD
[PPA] WARNING: HAL Service=%x
PPA freed %d bytes
DZh
`Xh@hH`Y`pG
HHDpG
pGp
2F)F F
OOD9h
& h
p `0F
!i2F
hhFx1
L4 FW: violation description
ACCESS=
WRITE
READ
PRIVILEGED
USR
DEBUG
FUNC
SECURE
PUBLIC
CONNID=%x (0=ARM, 1=DAP, 2=TESLA, 3=IVA, 4=ISS 5=DMA C=USB)
ADDRESS OFFSET=%x
sIyD
qIyD
ZFn
-- NON SECURE CODE GENERATED A SECURITY VIOLATION --
CONTROL_SEC_ERR_STATUS_FUNC = %x
Interrupted context:
r0=%x, r1=%x, r2=%x, r3=%x
r4=%x, r5=%x, r6=%x, r7=%x
r8=%x, r9=%x, r10=%x, r11=%x
r12=%x, lr_fiq=%x, spsr_fiq=%x
Before Violation, SW was in abort handler
SP_abt=%x, LR_abt=%x, spsr_abt=%x
L3 FW (%d port(s)) Error log format:
==> Err log (32b) / logical Addr (32b)
==> port %d:
==> reserved / reserved
[PA 0x%x] = 0x%x /
!!!!!!!!!!
usr_sp
usr_lr
svc_sp
svc_lr
svc_spsr
abt_sp
abt_lr
abt_spsr
und_sp
und_lr
und_spsr
irq_sp
irq_lr
irq_spsr
fiq_sp
fiq_lr
fiq_spsr
fiq_r8
fiq_r9
fiq_r10
fiq_r11
fiq_r12
2o! 1o"
1o-@1o.
1o/`1o
o2`2o3
2o4@0o
ERROR=%x (0=NO ERR, 1=RESERVED, 2=ADDRESS HOLE ERR, 3=PROTEC VIOLATION)
-- WARNING: violation might be due to speculative accesses. Check L3 interconnect
-- PPA cleans FW and CONTROL module registers & let the NS alive.
"IyD
-- OMAP %x (version %x) PPA release
hash %x
Device type:
oEMU
, ONLY PUBLIC DEBUG ON
!OBFUSCATOR ON!
Reset reason = %x
9CN;ID
`BJ`
`pGD
HxDJ`
HxDJ`
HxDH`
HxD`a
'MMD)h
G)hA
MD)h
JID h
|P)h
@@JM
PF)h
G)hA
$~D)hPF
%HHD
)hPF
PF)h
G h
LD!` I
ID h
IyDA`pG
`@hH`pG
ID%
ID h
,5I5H
`Hh
HHD
D!pG
o1.6.0-rc1
CertISW
H'm
ISW_SIGINFO_ROM_PKC
^L /
D0@xV4
PC0@`C0@
PC0@
8x0J
0@`A
0@pA
J8x0J@x0J
xx0J
J0x0J
0@$A
0@(A
||||
@1J$0
0@p@-
Hc0@<c0@lc0@Xc0@lc0@Hc0@
@ #!
@ c!
0@p@-
0@\1
H0@-
#(-27<FP
X-Loader hangs
Texas Instruments X-Loader 1.41 (Sep 12 2011 - 15:52:30)
MMC init failed
u-boot.bin
ONENAND
MMC/SD1
EMMC
Uboot-loading from Emmc
Starting OS Bootloader from %s ...
Could not read bootloader!
0123456789abcdefghijklmnopqrstuvwxyz
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
<NULL>
FAT32
FAT12
FAT16
** Can't read from device %d **
No current device
Interface:
SCSI
ATAPI
Unknown
Device %d:
No valid FAT fs found
Partition %d: Filesystem: %s "%s"
Error: reading boot sector
not there
Error: reading rootdir block
%d file(s), %d dir(s)
%s%c
%8ld %s%c
Error reading cluster
Invalid FAT entry
(%d:%d)
Model: %s Firm: %s Ser#: %s
Vendor: %s Prod.: %s Rev: %s
Type:
Hard Disk
CD ROM
Optical Device
Tape
# %02X #
Capacity: %ld.%ld MB = %ld.%ld GB (%ld x %ld)
Capacity: not available
mmc read: Invalid size
Try to init the controller
MMC on SLOT=%d not Supported
mmc_detect_card:Invalid Slot
|E0@
{0@Lz0@
a0@Db0@
T#b"
$H)H2*
_Kk>
<-ps:
Dms,

this is signed bootloader first stage. and here is unsigned bootloader first stage

$ strings MLO
CHSETTINGS
PC0@
D0@xV4
PC0@`C0@4
PC0@
0@(A
0@$A
`0J`A
0@dA
J8x0J@x0J
xx0J
J0x0J
0@p@-
0@3@-
@ #!
@ c!
0@p@-
0@l1
0@p@-
Xq0@tq0@|q0@|q0@|q0@`q0@|q0@lq0@
0@0@-
0@p@-
0@0@-
#(-27<FP
Texas Instruments X-Loader 1.41 (Jun 10 2013 - 23:54:57)
MMC init failed
u-boot.bin
X-Loader hangs
ONENAND
MMC/SD1
EMMC
Starting OS Bootloader from %s ...
Could not read bootloader!
0123456789abcdefghijklmnopqrstuvwxyz
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
<NULL>
FAT32
FAT12
FAT16
** Can't read from device %d **
Error: reading boot sector
not there
Error: reading rootdir block
%d file(s), %d dir(s)
%s%c
%8ld %s%c
Error reading cluster
Invalid FAT entry
No current device
Interface:
SCSI
ATAPI
Unknown
Device %d:
No valid FAT fs found
Partition %d: Filesystem: %s "%s"
(%d:%d)
Model: %s Firm: %s Ser#: %s
Vendor: %s Prod.: %s Rev: %s
Type:
Hard Disk
CD ROM
Optical Device
Tape
# %02X #
Capacity: %ld.%ld MB = %ld.%ld GB (%ld x %ld)
Capacity: not available
mmc_detect_card:Invalid Slot
MMC on SLOT=%d not Supported
mmc read: Invalid size
Try to init the controller
D0@|s0@4r0@([0@

now if you must understand its the signature and many functions which are embedded in the first stage bootloader incorporated by Mshield Signing Tool, nothing else, which is again nothing but a RSA PKI key + some functions + MLO thats it.
hope this helps!
thanks
-paul

[dothadamthang]

you are 100% right. i have spent nearly 5-6 years playing with embedded devices. first with mips and then moved into arm too. mips are of these types mips32 and mips64 and further divided into mipsel mipseb and many more classification.
and likewise arm is now heading for 64 bit arch. so we got arm32 and arm64, x-gene is a classic example of 64 bit arm. and we debian folks are working on them. we are 99% done with most porting. plus dont forget we got help from linaro too. which means we will soon have 100% support for arm64.
now coming to finer arm details. mind you i am not an arm expert and i will try to share little information i got with you.
arm is a company/organization which does maximum research and development work at present in UK. and they sell their licence to many vendors viz TI or Qualcomm, they inturn mod the spec sheets and add their own bit. like HS is a common set for arm cpu which enables hash and sign check. TI and qualcomm and many more arm vendors their own method od doing this. and its this HS which does the real trick.
So if apple hires a few guys from AMD and send them to arm team for their CPU wont be any sweat since armv7 is armhf or arm hard float. and the code which is their for android will work in all armhf w/o much porting needed. which is what he means by 99% compatible and 1% is vendor specific.
but what really will pi$$ you off will be the bootloader. there are different caches aka multicache. and each cache has different sizes which makes us leave with one thing. "Pray that the vendor release the key." which they wont so you need to "prey on their key."
i been trying to understand the keysize. the basic info which i gathered is this.
there are 2 stage booting in arm, one is called initialiazation and second is called chain bootloading.
first stage is 99% signed and second stage is mostly never signed. and also useless to sign the second stage. which leaves us with guessing. as how much is too much encryption.
this is because the MLO is only 20 KB which holds the code to kick of first stage booting. and second stage booting or chain loading will not happen unless first stage works smooth, but i have seen the MLO to be the size of
-rw-r--r-- 1 testuser testuser 128K Sep 13 2011 MLO_4430_HS
if the MLO which i get from compiling source (w/o stripping and -O2 gcc optimization) is
-rw-r--r-- 1 root root 20K Jun 10 23:55 MLO
then there is a gap of 128KB-20KB= 108KB = 108*1024*8 = 884736, enough to fit in 3072 bit RSA encryption. but if its in L2 cache then the size of sram is only 16K which reduces the chance of 3072 bit RSA encryption.
did anyone get the logic? or the information flew way above your head?
thanks
-paul

No Habla Espanol.......

[Gnomesane]

Someone is looking to port iOS to the Z10. With this, the "cesspool" aka Android can also be loaded on the Z10.

Dev says as long as all is ARMv7 code, despite 1% is messed up code and the other 99% of iOS should be interoperable on QualComm's SnapDragon Krait from Apple Ax Swift.

How do you guys think of this? If you're stressed about this, vent here

Obviously possible since Android runs just fine. But I'll treat it as a rumour... Android runs just as many apps (almost) as iOS so I personally don't see the benefit. Especially considering that iOS is NOT open source...

Posted via CB10

[Duffman19]

Posted via CB10

[SDTRMG]

o_O, Thought I was a quite intelligent person till I read this thread lol.

Posted via CB10

[Gees97]

you are 100% right. i have spent nearly 5-6 years playing with embedded devices. first with mips and then moved into arm too. mips are of these types mips32 and mips64 and further divided into mipsel mipseb and many more classification.
and likewise arm is now heading for 64 bit arch. so we got arm32 and arm64, x-gene is a classic example of 64 bit arm. and we debian folks are working on them. we are 99% done with most porting. plus dont forget we got help from linaro too. which means we will soon have 100% support for arm64.
now coming to finer arm details. mind you i am not an arm expert and i will try to share little information i got with you.
arm is a company/organization which does maximum research and development work at present in UK. and they sell their licence to many vendors viz TI or Qualcomm, they inturn mod the spec sheets and add their own bit. like HS is a common set for arm cpu which enables hash and sign check. TI and qualcomm and many more arm vendors their own method od doing this. and its this HS which does the real trick.
So if apple hires a few guys from AMD and send them to arm team for their CPU wont be any sweat since armv7 is armhf or arm hard float. and the code which is their for android will work in all armhf w/o much porting needed. which is what he means by 99% compatible and 1% is vendor specific.
but what really will pi$$ you off will be the bootloader. there are different caches aka multicache. and each cache has different sizes which makes us leave with one thing. "Pray that the vendor release the key." which they wont so you need to "prey on their key."
i been trying to understand the keysize. the basic info which i gathered is this.
there are 2 stage booting in arm, one is called initialiazation and second is called chain bootloading.
first stage is 99% signed and second stage is mostly never signed. and also useless to sign the second stage. which leaves us with guessing. as how much is too much encryption.
this is because the MLO is only 20 KB which holds the code to kick of first stage booting. and second stage booting or chain loading will not happen unless first stage works smooth, but i have seen the MLO to be the size of
-rw-r--r-- 1 testuser testuser 128K Sep 13 2011 MLO_4430_HS
if the MLO which i get from compiling source (w/o stripping and -O2 gcc optimization) is
-rw-r--r-- 1 root root 20K Jun 10 23:55 MLO
then there is a gap of 128KB-20KB= 108KB = 108*1024*8 = 884736, enough to fit in 3072 bit RSA encryption. but if its in L2 cache then the size of sram is only 16K which reduces the chance of 3072 bit RSA encryption.
did anyone get the logic? or the information flew way above your head?
thanks
-paul

Wayyyy too long to read

Posted Via My Most Used BlackBerry App

[Gees97]

lol, i will believe it when i see it. otherwise its all talk, kinda like bb10 on the PB

Haha I can't believe there are still people waiting for that. In my opinion the PlayBook is dead and nothing else will get updated with it. I actually told my girl I was gonna sell it if she didn't start using it again. Because it simply sits here all day without use. And I hate to say it but my Z10 does everything my PlayBook can do lol. So no use for it

Posted Via My Most Used BlackBerry App

[quackquack147]

QNX can easily run most of the OSs on top of it as a simple ported layer and totally sandboxes..

What do you think they were saying when you head POXIS certified and all that total butter from BlackBerry haha

YES you can certainly run iOS and android in total on BB10.

Posted via CB10

QNX can easily run most of the OSs on top of it as a simple ported layer and totally sandboxes..

virtualization is enabled in C-9 so shouldnt be an issue.

What do you think they were saying when you head POXIS certified and all that total butter from BlackBerry haha

same BS different day. if its *nix or Linux (r) it must be posix compliant and NLS and FHS, i.e. total butter BS. i have the source for qnx and i did compare it with netbsd. no sh!t mate no sh!t.

YES you can certainly run iOS and android in total on BB10.

BOM and repackaging. thats about i guess. else the binaries are already armhf ..... so how does iOS and BB OS and android and et al. if its armhf and posix and NLS then repack it and it should work. iOS and BB OS are both BSD related.
hope this helps!
thanks
-paul

[quackquack147]

Wayyyy too long to read

Posted Via My Most Used BlackBerry App

TI omap4430 documentation is 5554 pages w/o HS (which locks your bootloader is already missing and another 1000 pages). if this is too much. then the documentation is beyond any doubt, you will never read. ;-) this is the best i could compress. thats nearly 400 + 80 + 350 pages in one para. to read or not to read is your headache and understand, i dont know you mate. ;-)

thanks
-paul

[WhiteSpir1t]

QNX can easily run most of the OSs on top of it as a simple ported layer and totally sandboxes..

What do you think they were saying when you head POXIS certified and all that total butter from BlackBerry haha

YES you can certainly run iOS and android in total on BB10.

Posted via CB10

You need to google POSIX again


Sent from my iPhone4S after my Z10 took a trip in the bowl

[Gees97]

TI omap4430 documentation is 5554 pages w/o HS (which locks your bootloader is already missing and another 1000 pages). if this is too much. then the documentation is beyond any doubt, you will never read. ;-) this is the best i could compress. thats nearly 400 + 80 + 350 pages in one para. to read or not to read is your headache and understand, i dont know you mate. ;-)

thanks
-paul

Lol I'll leave that for you.

Posted Via My Most Used BlackBerry App

[annon91221]

lol, i will believe it when i see it. otherwise its all talk, kinda like bb10 on the PB

I remember a while back there was this guy featured on CB that had working iOS player like Android, for PlayBook... I think B1aze even confirmed it as legit but then that guy kina disappeared giving rise to conspiracy theories that he got hired by Apple or got threatened to get sued..

Anyways... as B1aze's famous quote goes, on these forums...

"When there is a will, there is a way..."

Posted via CB10

[scrannel]

So... you get an iPhone that looks like a BBerry? How about a new label: iBury. iMutant. No, I got it: iAbortion!

[quackquack147]

You need to google POSIX again


Sent from my iPhone4S after my Z10 took a trip in the bowl

he is right in theory, we can sandbox everything. practical issue is whats stopping many like us. QNX and BSD and IOS (which is also BSD based) should run w/o any issue. but i have never come across such binutils which does a direct translation. and theory says bsd platforms are interchangeable (binary also?) i doubt.

M$ windows is also POSIX. but we cannot run M$ binaries (armhf) in QNX or in android or in iOS w/o a translator aka wine. so he is right in theory and paper but practically he is far off. hence butter QNX.

Yes you can run android and iOS apps in BB provided you can do a clean FHS conversation in a jailroot with repackaging and binary utils maps it well.

so he is theoritically (in pen and paper) right but technically dead wrong. i will give him an OK based on his theory which to the best of my knowledge is right, but practically DEAD wrong.

thanks
-paul

[quackquack147]

Lol I'll leave that for you.

Posted Via My Most Used BlackBerry App

;-)
thanks
-paul

[quackquack147]

I remember a while back there was this guy featured on CB that had working iOS player like Android, for PlayBook... I think B1aze even confirmed it as legit but then that guy kina disappeared giving rise to conspiracy theories that he got hired by Apple or got threatened to get sued..

Anyways... as B1aze's famous quote goes, on these forums...

"When there is a will, there is a way..."

Posted via CB10

yes, possible, provided you get a perfect translation. considering we dont know the optimization and stripping and other factors. but its hard because how about FHS and binary translation from one posix compliant system to another. iOS and QNX are fully posix compliant. and if the package is based on BSD then yes, else i got no idea how it can be done, but surely can be done, i dont know how to bridge it.
thanks
-paul

[rangus]

Aw Crap. Zero..13Alpha..FPF this LOC. Fix bayonets, God save the Queen, Out.

Posted via CB10