for applications you intend to sell on the app marketplace, you use C++?
YES!
actually; we use C basically - on iphone; you need to have some objective-c wrappers to handle the device specific execution entry point. on symbian; you need C++ classes for the the framework base.
you do need to re-compile your binary for every PLATFORM (not device). if you want to see it in action; check out http://www.mobilewizardry.com/multi-platfori/atariretro/ (commercial applications) and http://www.mobile1up.com/ (iphone, desktop apps) - this is what i specialize in. when i hear about platform fragmentation i laugh. be a good architect - and your problems are solved.
all our applications BUILD NATIVE - so, there is no runtime environments required and we have binaries optimized for the platform. when a new platform comes; we simply rebuild utilizing the tools and/or minimal custom coding for the execution frameworks
no it isn't - it is in *design* - not in practice.
Java provides the classic write once run anywhere; have you ever tried to build a J2ME client? do you know how many skews you have to build to support all the phones? so much for write-once-run-anywhere.
secondly; since mobile devices are underpowered - you need speed/fast applications to make them useful. Java runs on top of a VM - VM's are slow. you are looking at 20x speed slowdown; and there is no JIT (just in time) compilers available on mobile phones.
Java belongs on the desktop and server - not in the mobile space. you can argue as much as you want - i left Java programming to get into mobile development back in 1999. i've got years of experience within this area; surely more than the author of that article.
Show us on the doll where Chris Haseman touched you.
heh - i wonder how many people realize he is a martial arts trainer as well. i think hats off to the guy for getting the press - but, he seems to be complaining a lot about something he seems to be supporting heavily (author of book et al)..
Looks like the author is so green behind the ears he does not even know where the concepts of such mini applications with well defined interactions with other mini ops are coming from. At least one thing is sure, he got the attention he craved so much.
i think we can knock that down to experience:) lets take him back 10 years and program newton and palm os devices and see how much he loves android after that.
>> how long does it take to be a "veteran mobile application developer?"
checking out his profile (http://www.linkedin.com/pub/chris-haseman/1/369/a32) he has barely touched the majority of mobile platforms:) where is his symbian, palm os (68k, arm), ebookman, embedded linux, psp, nintendo ds, experience? surely - some of us started this stuff professionally back in the late 1990's with devices like the newton and palm professional. boy how things have changed - yet some things stay the same. he announces himself that ""(and by "in my day," I mean two years ago)"".
>> 3. Device Debugging
be thankful - some platforms you still need to do printf() style debugging.
>> 6. Java—Thanks, But I'll Take It from Here
Java - probably the worst language used on mobile devices to date. the desktop and server platform has evolved in many ways which are not being reflected in the mobile space; due to battery life, talk time etc - the typical moore's law of computing doesn't apply to mobile phones. there was a period where CPU speeds dropped on mobile devices - hopefully things will change coming up with new ARM and low powered x86 CPU's - but time will tell.
A true mobile developer demands a native C/C++ interface on mobile devices - if you want something done, more than a bouncing ball on the screen - its the preferred way. NDK under Android is a must - C/C++ isn't that bad - if you know what you are doing.
>> 8. Platform Fragmentation
its a problem? come on - seriously. you deal with it. you design around it; thats where your years of experience really kicks in and allows you to build cross-platform applications without issues. just because most companies hire an outsourcing department or "specialists" on specific platforms isn't a problem - it is a choice. there are plenty of alternatives out there.
So, you going to port liberty over?;) So we don't have to try and run it in Classic. And yeah, I remember you as another regular from the old PalmOS mailing list about 10 years ago
Liberty was written in 68k assembler:) we ported it to MIPS for a contract job. but no; gameboy emulation; plenty of other options available out there.. but i do intend to bring some of my other palm os games up-to-date:P
apple started off with "web" only development - then finally released a native SDK. google utilized it's Java like language (dalvik) - then finally released a native SDK (NDK).. there has been a native SDK since day one available for the Palm Pre - however, it was restricted to a select few developers. a copy ended up in my hands; and it is a little rough around the edges; but the signs shown here (1.3.5) are promising enough to believe that there will be a native SDK officially coming to the platform. we've been waiting for this opportunity ourselves. it will be interesting to see what CES and MWC announcements are made.
i think it really depends on your working environment.
in your example; you mention that the development team is intermingled with sales, marketing, accounting - those guys can be on the phone 24/7 and i think you are 100% correct that the team will be distracted by the ambient noise from the other people. however i don't think slapping on headphones is the solution; music is also a distraction; you should be thinking about the problems and coding rather than focusing on the deep beats of the music:) i think what you need to do is identify with your boss that there is ambient noise from the other divisions of the workforce; and request to be moved or isolated into an area where you wont hear them. most development teams i know prefer an open plan; you should work together and not sit in isolation in a cubicle - thats just stupid. as a technical manager myself; we move the sales and marketing guys to one side of the office and the development team to the other side - our office is designed well for this purpose.
> and they want to be able to call me on my personal cell phone after-hours
so your a 9-5 worker? mon-fri?
as an employer; our contracts states that the business is of entrepreneurial/startup nature - were the employee may be expected to work outside of normal business hours, and possibly on the weekends in the case of emergency, this includes being contactable (24 hour turnaround) even when on vacation. but, then again - we offer six (6) weeks paid vacation a year; the extra week covers these "outside normal hours", which over the last three years has never happened.
i interview people on a regular basis; and i honestly wish people were more like me - someone who loves their work. i take it home, i take it on vacation.. that's just me.
as an iphone developer (http://www.mobile1up.com/) - one who has been there from quite early on, i have started to notice how long it takes to get approved. in the early days, it was 3-4 days for a new version or update; now, i have two applications waiting in the approval process, it has been over two weeks! is apple employing enough people? i think so. the issue is that you get morons who think they need to release a "special" version of their application 100 times; take, for example, there was a weather application posted recently - one for each city in the united states.. come on; how much wasted time is there for apple to approve all 100 of these apps - when they could have approved one. with the introduction of "nude or raunchy" content; submissions have increased exponentially; now you dont get a fart app - you get a fart app with a hot girl in it.
as a vertern who only checks every now and then compared to every second 5+ years ago - what about us veterns? should there be a 5, 10+ year member status?:) still, fun stuff, gives boasting points:P
PC Alien. it was a IBM PC DOS based program that would allow you to read older computer disk systems (5 1/4 etc). i remember using it on my 80x86 to read CP/M based disks from my microbee:)
Do you want to control the copyrights or do you want to control the access rights?
This is really the issue at hand here. DRM that prevents people from copying software is protection via obscurity. open sourcing this means nothing and is a complete waste of time. DRM to control access rights can simply use configuration files and digital signatures - these algorithms can be public. if a user changes the configuration file (access rights), they are blocked from using the material because the signature will fail. This is a technique we use to control access rights for our products.
yes, you are wrong. AnySim is an iphone application - not a hack. the device must first be hacked (jailbroken); in order to install applications onto the phone. once done, AnySim simply updates the baseband firmware. the jailbreak process uses the exploits; not AnySim.
the iPhone/iPod Touch SDK will let you write apps in C/C++/objective C.
yes, i already have support for the iPhone/iPod Touch (one of those users apple hates right now). the unofficial SDK is even hosted on google groups. now, android may create devices which are only for android, i need C/C++ SDK to support these devices. the other devices are already handled.
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
where is the C/C++ SDK?
i have not had a chance to look at the SDK, but i assume you should be able to JNI (java native interface)? i was looking forward to android, but unfortunately, if it only has a Java SDK, it does not suit the needs of my development
> They make it sound like they have the right to go after people just because they haven't activated the phone.
this is really the question.
as a european, i have purchased a total of three iphones, on my own credit card (business, private); and i had a friend pick one up for me on their own credit card. now; none of these phones have been activated with AT&T, as i and the users of these phones are not based in USA. yes, the phones have been unlocked and we use our own sim cards, and we also install our own applications.
now, could apple turn around and force me to pay for an AT&T contract?
i doubt they could, because when i purchased the iphone, i never agreed to actually activating the phone with AT&T. when asked, i told the apple guy that i have no interest in activating the phone, he said i would not be able to use it without so; and he confirmed that it was apples belief that you had to activate it in order to use it. this was way before unlock tools were available.
DRM that locks software to a card means if you want to have five games available you have to carry around five cards.
its a pity the true DRM specification was never released to the public. one of the designs was to allow a user to identify an SD card as their "gaming card" (ie: go out and buy a 1GB SD card). a user could then purchase software online, get it signed to their card and copy the file to \Palm\Launcher and it would run on any zodiac as long as the SD card was used.
this wasn't a case of buying cards seperately (thats for retail), but, the design for allowing users to download multiple games onto a single SD card was in place. you couldn't copy that card; but, you could put more than one game on it.
as i said; i was only involved in the design - i was not so much involved in the implementation. i think a lot of the "design" was never implemented.
i am not pro-DRM, but - i realise that some license holders want DRM. its a service; and, if abused it can make the users life a living hell. itunes et al seem to have been working ok, its just the limited numnber of/. users who complain that there is no linux client available:) how many win/mac users know there is even DRM there?
You justify it however you want: Your DRM is customer-hostile. I'm glad I didn't get suckered in.
DRM is designed to protect content. i agree with you that locking content to a specific device that you use is not customer-nice, especially if you have hardware problems and you had to change hardware. thats why i always tend to go with locking to the packaging that it is delivered with (ie: locking to the memory card).
the plan was that the tapwave servers would have a user area where they could update their profile and re-download signed versions of the applications. the problem here is that the DRM was never implemented to its full capacity (as designed), instead - it was limited to what could be written in time. i wrote all the signing tools, not the infrastructure to call the signing tools.
I'm looking forward to seeing somebody who manages to reverse engineer your code and disable it. Then, the Zodiacs that will be flooding eBay will be excellent pieces of hardware.
well, it uses RSA SHA1 digital signatures.
twkeygen.jar twsign.jar
i got both of these on my laptop - and, they are even available in the tapwave SDK. its no secret as to what algorithms are being used.
// load the key keyFactory = KeyFactory.getInstance("RSA"); keyEnc = new PKCS8EncodedKeySpec(key); priv = keyFactory.generatePrivate(keyEnc);// initialize signing rsa = Signature.getInstance("SHA1withRSA"); rsa.initSign(priv);
ofs = 0; len = buf.length; rsa.update(buf, ofs, len);// sign it! x = rsa.sign();
here is the problem, there are 21 private keys that were generated; and, depending on the checksum of your application, the appropriate key would be used to do a signature check (nasty). now, if you had this algorithm AND you had all the 21 keys, you could use the twsign.jar tools to generate your TSIG.1 resource.
Perhaps you might want to ponder that when thinking about why you're out of business.
for what it was worth; i am not a tapwave employee - i was a contractor who worked with tapwave when they were just in the final stages of finalizing their hardware and rom builds. the last code i wrote for tapwave was on 16-sep-2003.
Ah, hey aaron, I've seen you around a lot.
i try not to post too often:) i also lurk:P
Well maybe not the DRM, but what was done with it. In my experience, most developers will always choose the most restrictive option possible. If your DRM had an option for an iris scan using the infared port on application startup, 3/4th of the programs would have required it.
you hit the point right on the nose there. it was developer error who made the DRM fail. there were plenty of options available for the developers to use; but, they are the ones who put the restrictions on the users. as a provider; tapwave had to provide a number of options for the developer to protect their application content.
Yoyo's emulator (SNES, NES, Genesis, GameGear, TurboGrafix, GameBoy, etc) took ages to get cleared by Tawpave
rumor was that Tapwave was issues a cease and desist letter from Nintendo. this affected all gameboy emulators at the time (including firestorm).
Put another way, was there an option for a developer writing a Zodiac-specific app to do the equivilent of generating an anonymous J2SE code-signing cert and using it to sign apps for free use by anyone willing to accept the validity of the cert?
i re-read your question - and, i have an answer for it.
YES.
you could write a single application that would be signed by tapwave that had the calls to the zodiac API's and provided them via a library/plugin interface.
for example: zodiac API - signed application - developer plugin
lets say i wrote a program that would load executable code from a.pdb file (database file). it would then lock the code down with a function pointer, and the main signed application would call it - passing a pointer to all the API's the sign application allows.
if the developer application *never* called the zodiac API's via the function pointers - it would never fail the signature check.
the tapwave DRM was designed to check that the code that is executing the tapwave API call is signed. if you put code seperately (in a database) and made the main application act as a loader - you could get away without signing applications. but, you would have to distribute the software as plugin's to the signed application.
its 100% do-able, and i was considering setting up something for my SHARK developer kit (www.mobilewizardry.com/multi-platform/) which would allow any SHARK developer to not have to get their applications signed on tapwave.
OK, question... was there any provision for allowing open-source thirdparty apps that used the Zodiac's API and hardware extensions to be promiscuously signed and made available for free at no cost to anyone who wanted to download them?
yes. in a similar way that the demo versions of software that used the API's could be signed and used on any zodiac hardware.
tapwave did not charge a fee for doing the digital signing, all you had to do as a developer was send your unsigned file to tapwave for signing and they would email a signed copy back to you. this was normally done within 24 hours in most cases. tapwave didn't have an online system for signing - fearing it would be abused.
in regards to tapwave refusing to sign applications - this has only come up once with the firestorm GBA emulator. they had a few legal concerns with nintendo threatening legal action since by tapwave signing the application - they effectively endorse it and its purpose (as nintendo thinks - to encourage piracy).
i dont need a lecture about emulators and their moral stance - hell, i'm one of the emulator writers; myself and mike ethetton were responsible for the first gameboy emulator on palmos - and, nintendo got on our backs about that as well.
as one of the designers of the DRM - it was developed with the developer in mind, and most importantly protecting the content that was published on the platform. as a developer in the handheld space; i've looked at a number of DRM systems - and, the system we contributed with helping tapwave with was secure. it still hasn't been broken, and it shares uncanny resemblances to the new Sony PSP DRM (someone copied). even i had software signed.
See, software that took advantage of the special hardware accelerator/screen API/system functions in the Zodiac had to have been cleared and approved by Tapwave
the tapwave was capable of running *all* palmos applications without digital signing. it was only the applications that used the specific zodiac hardware that actually required digital signing.
Furthermore all software that was authorized to run, could only run on your one zodiac. It'd reset otherwise. I had a hell of a time with that when having to replace my Zodiac for another one.
the DRM was tailored to support universal signing for all devices - just take a look at some of the games we wrote. you could download a demo which was using the zodiac hardware API's and it would run on *every* zodiac out there. if you wanted the full version, you had to get a version signed to your device.
the problem is not the DRM - but, what the developers chose to do with the DRM. most developers refused to look into the alternative options that the DRM provided; and, did the simple "hey, you need to be signed against your device id - sucker". there was options in the DRM to allow signing against a user account - which, in the event a user changed their tapwave device, they just need to update their profile on their handheld to ensure that their user account was still valid.
- software signed against user-account - user-account signed against device
when the user changed device; they could get a new user-account signed - and, the existing application would continue to run. now - my point is that this was *all* in the design of the system. the DRM was also designed for SD card distribution - which, you could take a single SD card between multiple devices. the people you heard bitch about the DRM should have purchased card versions of the software maybe?
to what extent tapwave made the full design of the DRM available, i dont know - it been a long time since i checked. if you have any questions regarding the DRM - dont hesitate to fire me an email. the tapwave was a great device - that failed due to a lack of marketing and branding. it wasn't the DRM.
this is where the article poster confused palmone's future plans with their existing plans. the lifedrive runs garnet, which is palmos 5.4. this is the palm proprietary format; no different to what is on the tungsten t5 and treo 650.
palmone has announced they will be providing an alternative kernel (linux based) in their future cobalt devices. currently, cobalt has a different kernal than the garnet devices; which has been headed up by a lot of old-beos developers. (remember, they purchased em).
its a nice device - i look forward to adding it to my museum:P
Slashdot Mirror
my point is he shouldn't be complaining about good debugging environments. be happy and thankful he doesn't need to deal with printf() for debugging.
for applications you intend to sell on the app marketplace, you use C++?
YES!
actually; we use C basically - on iphone; you need to have some objective-c wrappers to handle the device specific execution entry point. on symbian; you need C++ classes for the the framework base.
you do need to re-compile your binary for every PLATFORM (not device). if you want to see it in action; check out http://www.mobilewizardry.com/multi-platfori/atariretro/ (commercial applications) and http://www.mobile1up.com/ (iphone, desktop apps) - this is what i specialize in. when i hear about platform fragmentation i laugh. be a good architect - and your problems are solved.
all our applications BUILD NATIVE - so, there is no runtime environments required and we have binaries optimized for the platform. when a new platform comes; we simply rebuild utilizing the tools and/or minimal custom coding for the execution frameworks
Java is he answer to platform fragmentation?
no it isn't - it is in *design* - not in practice.
Java provides the classic write once run anywhere; have you ever tried to build a J2ME client? do you know how many skews you have to build to support all the phones? so much for write-once-run-anywhere.
secondly; since mobile devices are underpowered - you need speed/fast applications to make them useful. Java runs on top of a VM - VM's are slow. you are looking at 20x speed slowdown; and there is no JIT (just in time) compilers available on mobile phones.
Java belongs on the desktop and server - not in the mobile space. you can argue as much as you want - i left Java programming to get into mobile development back in 1999. i've got years of experience within this area; surely more than the author of that article.
Show us on the doll where Chris Haseman touched you.
heh - i wonder how many people realize he is a martial arts trainer as well. i think hats off to the guy for getting the press - but, he seems to be complaining a lot about something he seems to be supporting heavily (author of book et al)..
i prefer printf() debugging - how is point 8 related to point 3? i can do printf style debugging on every platform :)
Looks like the author is so green behind the ears he does not even know where the concepts of such mini applications with well defined interactions with other mini ops are coming from. At least one thing is sure, he got the attention he craved so much.
i think we can knock that down to experience :) lets take him back 10 years and program newton and palm os devices and see how much he loves android after that.
>> how long does it take to be a "veteran mobile application developer?"
checking out his profile (http://www.linkedin.com/pub/chris-haseman/1/369/a32) he has barely touched the majority of mobile platforms :) where is his symbian, palm os (68k, arm), ebookman, embedded linux, psp, nintendo ds, experience? surely - some of us started this stuff professionally back in the late 1990's with devices like the newton and palm professional. boy how things have changed - yet some things stay the same. he announces himself that ""(and by "in my day," I mean two years ago)"".
>> 3. Device Debugging
be thankful - some platforms you still need to do printf() style debugging.
>> 6. Java—Thanks, But I'll Take It from Here
Java - probably the worst language used on mobile devices to date. the desktop and server platform has evolved in many ways which are not being reflected in the mobile space; due to battery life, talk time etc - the typical moore's law of computing doesn't apply to mobile phones. there was a period where CPU speeds dropped on mobile devices - hopefully things will change coming up with new ARM and low powered x86 CPU's - but time will tell.
A true mobile developer demands a native C/C++ interface on mobile devices - if you want something done, more than a bouncing ball on the screen - its the preferred way. NDK under Android is a must - C/C++ isn't that bad - if you know what you are doing.
>> 8. Platform Fragmentation
its a problem? come on - seriously. you deal with it. you design around it; thats where your years of experience really kicks in and allows you to build cross-platform applications without issues. just because most companies hire an outsourcing department or "specialists" on specific platforms isn't a problem - it is a choice. there are plenty of alternatives out there.
So, you going to port liberty over? ;) So we don't have to try and run it in Classic. And yeah, I remember you as another regular from the old PalmOS mailing list about 10 years ago
Liberty was written in 68k assembler :) we ported it to MIPS for a contract job. but no; gameboy emulation; plenty of other options available out there.. but i do intend to bring some of my other palm os games up-to-date :P
apple started off with "web" only development - then finally released a native SDK. google utilized it's Java like language (dalvik) - then finally released a native SDK (NDK).. there has been a native SDK since day one available for the Palm Pre - however, it was restricted to a select few developers. a copy ended up in my hands; and it is a little rough around the edges; but the signs shown here (1.3.5) are promising enough to believe that there will be a native SDK officially coming to the platform. we've been waiting for this opportunity ourselves. it will be interesting to see what CES and MWC announcements are made.
i think it really depends on your working environment.
in your example; you mention that the development team is intermingled with sales, marketing, accounting - those guys can be on the phone 24/7 and i think you are 100% correct that the team will be distracted by the ambient noise from the other people. however i don't think slapping on headphones is the solution; music is also a distraction; you should be thinking about the problems and coding rather than focusing on the deep beats of the music :) i think what you need to do is identify with your boss that there is ambient noise from the other divisions of the workforce; and request to be moved or isolated into an area where you wont hear them. most development teams i know prefer an open plan; you should work together and not sit in isolation in a cubicle - thats just stupid. as a technical manager myself; we move the sales and marketing guys to one side of the office and the development team to the other side - our office is designed well for this purpose.
> and they want to be able to call me on my personal cell phone after-hours
so your a 9-5 worker? mon-fri?
as an employer; our contracts states that the business is of entrepreneurial/startup nature - were the employee may be expected to work outside of normal business hours, and possibly on the weekends in the case of emergency, this includes being contactable (24 hour turnaround) even when on vacation. but, then again - we offer six (6) weeks paid vacation a year; the extra week covers these "outside normal hours", which over the last three years has never happened.
i interview people on a regular basis; and i honestly wish people were more like me - someone who loves their work. i take it home, i take it on vacation.. that's just me.
as an iphone developer (http://www.mobile1up.com/) - one who has been there from quite early on, i have started to notice how long it takes to get approved. in the early days, it was 3-4 days for a new version or update; now, i have two applications waiting in the approval process, it has been over two weeks! is apple employing enough people? i think so. the issue is that you get morons who think they need to release a "special" version of their application 100 times; take, for example, there was a weather application posted recently - one for each city in the united states.. come on; how much wasted time is there for apple to approve all 100 of these apps - when they could have approved one. with the introduction of "nude or raunchy" content; submissions have increased exponentially; now you dont get a fart app - you get a fart app with a hot girl in it.
as a vertern who only checks every now and then compared to every second 5+ years ago - what about us veterns? should there be a 5, 10+ year member status? :) still, fun stuff, gives boasting points :P
http://www.melbpc.org.au/pcupdate/9503/9503article5.htm
:)
PC Alien. it was a IBM PC DOS based program that would allow you to read older computer disk systems (5 1/4 etc). i remember using it on my 80x86 to read CP/M based disks from my microbee
or do you want to control the access rights?
This is really the issue at hand here. DRM that prevents people from copying software is protection via obscurity. open sourcing this means nothing and is a complete waste of time. DRM to control access rights can simply use configuration files and digital signatures - these algorithms can be public. if a user changes the configuration file (access rights), they are blocked from using the material because the signature will fail. This is a technique we use to control access rights for our products.
I could be completely wrong
yes, you are wrong. AnySim is an iphone application - not a hack. the device must first be hacked (jailbroken); in order to install applications onto the phone. once done, AnySim simply updates the baseband firmware. the jailbreak process uses the exploits; not AnySim.
the iPhone/iPod Touch SDK will let you write apps in C/C++/objective C.
yes, i already have support for the iPhone/iPod Touch (one of those users apple hates right now). the unofficial SDK is even hosted on google groups. now, android may create devices which are only for android, i need C/C++ SDK to support these devices. the other devices are already handled.
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language. where is the C/C++ SDK? i have not had a chance to look at the SDK, but i assume you should be able to JNI (java native interface)? i was looking forward to android, but unfortunately, if it only has a Java SDK, it does not suit the needs of my development
> They make it sound like they have the right to go after people just because they haven't activated the phone.
this is really the question.
as a european, i have purchased a total of three iphones, on my own credit card (business, private); and i had a friend pick one up for me on their own credit card. now; none of these phones have been activated with AT&T, as i and the users of these phones are not based in USA. yes, the phones have been unlocked and we use our own sim cards, and we also install our own applications.
now, could apple turn around and force me to pay for an AT&T contract?
i doubt they could, because when i purchased the iphone, i never agreed to actually activating the phone with AT&T. when asked, i told the apple guy that i have no interest in activating the phone, he said i would not be able to use it without so; and he confirmed that it was apples belief that you had to activate it in order to use it. this was way before unlock tools were available.
DRM that locks software to a card means if you want to have five games available you have to carry around five cards.
/. users who complain that there is no linux client available :) how many win/mac users know there is even DRM there?
/. community is within the 20% area.
its a pity the true DRM specification was never released to the public. one of the designs was to allow a user to identify an SD card as their "gaming card" (ie: go out and buy a 1GB SD card). a user could then purchase software online, get it signed to their card and copy the file to \Palm\Launcher and it would run on any zodiac as long as the SD card was used.
this wasn't a case of buying cards seperately (thats for retail), but, the design for allowing users to download multiple games onto a single SD card was in place. you couldn't copy that card; but, you could put more than one game on it.
as i said; i was only involved in the design - i was not so much involved in the implementation. i think a lot of the "design" was never implemented.
i am not pro-DRM, but - i realise that some license holders want DRM. its a service; and, if abused it can make the users life a living hell. itunes et al seem to have been working ok, its just the limited numnber of
80-20 rule.
You justify it however you want: Your DRM is customer-hostile. I'm glad I didn't get suckered in.
// load the key // initialize signing
// sign it!
:) i also lurk :P
DRM is designed to protect content. i agree with you that locking content to a specific device that you use is not customer-nice, especially if you have hardware problems and you had to change hardware. thats why i always tend to go with locking to the packaging that it is delivered with (ie: locking to the memory card).
the plan was that the tapwave servers would have a user area where they could update their profile and re-download signed versions of the applications. the problem here is that the DRM was never implemented to its full capacity (as designed), instead - it was limited to what could be written in time. i wrote all the signing tools, not the infrastructure to call the signing tools.
I'm looking forward to seeing somebody who manages to reverse engineer your code and disable it. Then, the Zodiacs that will be flooding eBay will be excellent pieces of hardware.
well, it uses RSA SHA1 digital signatures.
twkeygen.jar
twsign.jar
i got both of these on my laptop - and, they are even available in the tapwave SDK. its no secret as to what algorithms are being used.
keyFactory = KeyFactory.getInstance("RSA");
keyEnc = new PKCS8EncodedKeySpec(key);
priv = keyFactory.generatePrivate(keyEnc);
rsa = Signature.getInstance("SHA1withRSA");
rsa.initSign(priv);
ofs = 0;
len = buf.length;
rsa.update(buf, ofs, len);
x = rsa.sign();
here is the problem, there are 21 private keys that were generated; and, depending on the checksum of your application, the appropriate key would be used to do a signature check (nasty). now, if you had this algorithm AND you had all the 21 keys, you could use the twsign.jar tools to generate your TSIG.1 resource.
Perhaps you might want to ponder that when thinking about why you're out of business.
for what it was worth; i am not a tapwave employee - i was a contractor who worked with tapwave when they were just in the final stages of finalizing their hardware and rom builds. the last code i wrote for tapwave was on 16-sep-2003.
Ah, hey aaron, I've seen you around a lot.
i try not to post too often
Well maybe not the DRM, but what was done with it. In my experience, most developers will always choose the most restrictive option possible. If your DRM had an option for an iris scan using the infared port on application startup, 3/4th of the programs would have required it.
you hit the point right on the nose there. it was developer error who made the DRM fail. there were plenty of options available for the developers to use; but, they are the ones who put the restrictions on the users. as a provider; tapwave had to provide a number of options for the developer to protect their application content.
Yoyo's emulator (SNES, NES, Genesis, GameGear, TurboGrafix, GameBoy, etc) took ages to get cleared by Tawpave
rumor was that Tapwave was issues a cease and desist letter from Nintendo. this affected all gameboy emulators at the time (including firestorm).
Put another way, was there an option for a developer writing a Zodiac-specific app to do the equivilent of generating an anonymous J2SE code-signing cert and using it to sign apps for free use by anyone willing to accept the validity of the cert?
.pdb file (database file). it would then lock the code down with a function pointer, and the main signed application would call it - passing a pointer to all the API's the sign application allows.
i re-read your question - and, i have an answer for it.
YES.
you could write a single application that would be signed by tapwave that had the calls to the zodiac API's and provided them via a library/plugin interface.
for example: zodiac API - signed application - developer plugin
lets say i wrote a program that would load executable code from a
if the developer application *never* called the zodiac API's via the function pointers - it would never fail the signature check.
the tapwave DRM was designed to check that the code that is executing the tapwave API call is signed. if you put code seperately (in a database) and made the main application act as a loader - you could get away without signing applications. but, you would have to distribute the software as plugin's to the signed application.
its 100% do-able, and i was considering setting up something for my SHARK developer kit (www.mobilewizardry.com/multi-platform/) which would allow any SHARK developer to not have to get their applications signed on tapwave.
OK, question... was there any provision for allowing open-source thirdparty apps that used the Zodiac's API and hardware extensions to be promiscuously signed and made available for free at no cost to anyone who wanted to download them?
yes. in a similar way that the demo versions of software that used the API's could be signed and used on any zodiac hardware.
tapwave did not charge a fee for doing the digital signing, all you had to do as a developer was send your unsigned file to tapwave for signing and they would email a signed copy back to you. this was normally done within 24 hours in most cases. tapwave didn't have an online system for signing - fearing it would be abused.
in regards to tapwave refusing to sign applications - this has only come up once with the firestorm GBA emulator. they had a few legal concerns with nintendo threatening legal action since by tapwave signing the application - they effectively endorse it and its purpose (as nintendo thinks - to encourage piracy).
i dont need a lecture about emulators and their moral stance - hell, i'm one of the emulator writers; myself and mike ethetton were responsible for the first gameboy emulator on palmos - and, nintendo got on our backs about that as well.
The only problem was the DRM.
i resent that comment.
as one of the designers of the DRM - it was developed with the developer in mind, and most importantly protecting the content that was published on the platform. as a developer in the handheld space; i've looked at a number of DRM systems - and, the system we contributed with helping tapwave with was secure. it still hasn't been broken, and it shares uncanny resemblances to the new Sony PSP DRM (someone copied). even i had software signed.
See, software that took advantage of the special hardware accelerator/screen API/system functions in the Zodiac had to have been cleared and approved by Tapwave
the tapwave was capable of running *all* palmos applications without digital signing. it was only the applications that used the specific zodiac hardware that actually required digital signing.
Furthermore all software that was authorized to run, could only run on your one zodiac. It'd reset otherwise. I had a hell of a time with that when having to replace my Zodiac for another one.
the DRM was tailored to support universal signing for all devices - just take a look at some of the games we wrote. you could download a demo which was using the zodiac hardware API's and it would run on *every* zodiac out there. if you wanted the full version, you had to get a version signed to your device.
the problem is not the DRM - but, what the developers chose to do with the DRM. most developers refused to look into the alternative options that the DRM provided; and, did the simple "hey, you need to be signed against your device id - sucker". there was options in the DRM to allow signing against a user account - which, in the event a user changed their tapwave device, they just need to update their profile on their handheld to ensure that their user account was still valid.
- software signed against user-account
- user-account signed against device
when the user changed device; they could get a new user-account signed - and, the existing application would continue to run. now - my point is that this was *all* in the design of the system. the DRM was also designed for SD card distribution - which, you could take a single SD card between multiple devices. the people you heard bitch about the DRM should have purchased card versions of the software maybe?
to what extent tapwave made the full design of the DRM available, i dont know - it been a long time since i checked. if you have any questions regarding the DRM - dont hesitate to fire me an email. the tapwave was a great device - that failed due to a lack of marketing and branding. it wasn't the DRM.
It runs PalmOS so where's the Linux part come in?
:P
this is where the article poster confused palmone's future plans with their existing plans. the lifedrive runs garnet, which is palmos 5.4. this is the palm proprietary format; no different to what is on the tungsten t5 and treo 650.
palmone has announced they will be providing an alternative kernel (linux based) in their future cobalt devices. currently, cobalt has a different kernal than the garnet devices; which has been headed up by a lot of old-beos developers. (remember, they purchased em).
its a nice device - i look forward to adding it to my museum