Worked fine for me on my v6.1 HTC Touch Pro. So far I've only downloaded the Netflix app, but it has worked flawlessly (and a lot faster than most of my phone's other apps).
1) They actually outright state that the "basic" protection is simply requiring that someone sign in with a Live ID before they can download, then deleting the CAB file. It's phrased to imply that there's more going on, but that's it.
2) Apparently only a few hypothetical "super-hackers" could possibly work around the protection provided by (1)
3) The expensive, premium protection is seemingly the same old tie-the-app-to-the-IMEI patching of the binary that everyone and their dog uses, which is probably trivial to hack too.
I had heard that he was just hijacking the CAB file. It's probably downloading to some temp location. If you make a copy of that CAB while the installer is running, you should be able to then copy the CAB to any other WinMo device. Most of them have a point where they prompt for input (install to device or to card is a good candidate) and you can probably grab it then.
If they use Pocket IE, then it's very likely in that standard directory. A quick "Chandler" should find the full path. You could probably even write a small app that automatically mirrored any CAB file out of there.
@SQLGuru: Yes, that's basically it. Although to be fair, the documentation spells this out pretty clearly. It also talks about an alternate key-based system that involves adding some code to your program. I think maybe that's not available yet.
I'm still undecided on whether to submit my software to the Marketplace. I'm not worried about piracy much, as they're only $1.99 apps anyway. But the expense and trouble that seems to be involved in getting things approved is an impediment to individual developers like me.
I have two apps now in the Samsung App Store. That was very cheap and easy, and it has a pretty good copy protection scheme, tied to the phone's ID.
@CSX321: Do you have a good "finger friendly" set of widgets that you use for your app? I have an app that I've started writing, but with no native controls as part of the SDK, I'm torn between continuing working on it and giving up. (I'm more of a function over form guy.) My app is about 90% done in terms of function but only about 10% done in terms of "pretty" -- at least the version I plan on giving away for free. Then I would release a "pro" version with additional features.
As for piracy, I'm really writing it for me but wouldn't mind a few buck from others who find it just as useful.
@SQLGuru: I got started writing stuff for myself, too.
No, I don't really have a set of controls or anything yet. I have a C# image button class I did for one app. For other things, I just space them so they can be hit easily with a finger. Oh, I also have a form base class with "flick" gesture support and the ability to slide up, down, left, or right between forms. I've pretty much found the limits of what can be done graphics-wise with the .NET 2 CF.
For my apps I have demo versions that have limited features and nag screens, but no time limit. They can be activated with an RPN key (Handango-style) to full version status. I haven't decided yet whether to put them on Handango, etc. 50% is a lot compared to Samsung's and Microsoft's 30%.
I'll add my 'thanks' for this post. As a long time WiMo user, the lack of love for it (and some of the really stupid comments that show people really don't have a clue) has been disappointing.
There are thousands and thousands of WiMo apps out there.
@mullingitover: WM has been doing Google Voice for a while now with some XDA developed apps.
It only got popular due to Apple blocking it, and the official release by Google for BB/Android.
This is a frustrating issue. I'll be the first to admit that iPhone OS is a richer environment for a simple reason: it's almost 10x larger than WiMo.
Windows Mobile was designed to fit - with all the core apps - into 32MB of ROM. The fact that it can do all the things it can do is actually pretty amazing - especially for the company that's the alleged posterboy for 'bloat'. iPhone OS, on the other hand, clocks in at 220MB+.
The WiMo ecosystem hasn't reacted to the much cheaper cost of flash memory and low power memory, and keeps building WiMo devices that are at least four years behind the curve... and Microsoft hasn't done much to convince them to knock it off.
WiMo 6.5 does a bit to fix this (and ONLY a bit) - but the big hope is 7.0 which sets new minimal hardware requirements. Thing is, unless Microsoft is ready to fill in a lot of missing parts and get rid of .Net CF - and just deliver .Net ARM, they're doomed to be left behind - and the window is closing (so to speak).
That being said, I read the article in question and have to bring up a few issues. First, it's entirely possible, if a little tricky, to make controls that look and behave just like iPhone controls in .Net CF (it's trivially easy in full .Net). Second, the ease of porting is very dependent on what you do and how you do it. I felt the author went about it in a somewhat difficult way. Still, the fact that Microsoft chose to publish that as a case study is unfortunate - and underlines the chief problem at MSFT with respect to WiMo - a kind of wilfull blindness.
It's weird that the simple UI is clunky when the hard one - the real time sound display - is almost identical. Most people over estimate the complexity of iPhone/Mac OS controls. Most of them are simply graphical elements (pngs, bmps and tifs) that are composited. I know this because I wrote a complete MacOS X Aqua UI kit for .Net 1.1 several years ago and actually OVER designed it - I actually generated the shading and elements algorithmically - then later found out how Apple did it.
The screen shot attached shows a sample - every control there works correctly.
But, the development tools in Visual Studio are often clumsy when you get to WiMo as soon as you start to cut your own controls because of the mechanism they use to insulate the developer from the complexities of things like P/Invoking into the OS.
Several people here dismiss the value of C# and .Net, but here's a good example of why it's easier - Apple posted a 'your first iPhone app' and I did the exact same thing in .Net:
The issue I see with this is that this app uses the simplest of controls that have a direct analog in Windows Mobile. Once you start using the more complicated controls available (in either system) it makes it hard to write code that works on both systems. What ends up happening is either you end up with two mostly dissimilar codebases, or you end up custom writing huge parts of the UI.
For the most part, direct porting of applications leads to sub par applications for all the systems you work on. For example, take a look at Safari 3 for the PC, it was a direct port, and worked terribly, Safari 4 then changed that strategy, and now it integrates much better with windows.
@cristiana: Actually, that's only partly true. The bigger issue in this exercise is that of the many different platforms - only one uses Objective C. The rest use or can use C++.
.Net allows you to use managed C++ mixes with native C++ and that's the trick that lets you make a portable application.
If you write an application with intention of it being crossplatform, the pain is paid once - but in this case, the app was written for the least compatible case, then ported.
You will end up writing a lot of custom UI code - once - but then you'll have a library of code you can use from then on.
I'm a developer, and I can tell: porting an iPhone app to Windows Mobile (or Android, or whatever, or the other way around for that matter) is not a trivial task.
Sure, if you have experience with multiplatform development you can make this process much less painful, but it's still far from a simple task.
All points mentioned in the article are moot:
* Language independence: while it's nice to be able to work with any language, it's not such a big deal. Any developer worth their salt should be able to pick up Objective C in a few weeks, and it is a sweet language to work with. I'd love to have garbage collection as on option, thou.
* Working on a single program: while it's true that you use a number or programs to develop for the iPhone, all those programs are very well integrated.
* Licensed libraries: Microsoft licenses additional libraries, Apple has most of these functionality built-in, for free. Some developers are also starting to distribute/sell libraries for iPhone.
* Development tools: iPhone development tools are also built into Apple's tools. For free, BTW. Visual Studio isn't exactly cheap.
* Community: iPhone developer community is huge already, and growing at a scaring pace.
All that said: WinMo (or more importantly, BB) is still an important target for corporate applications, and it's probably worth the effort to port your apps. Just don't expect anything to happen magically.
@Pazu: I'm also a developer and I agree. Porting Objective-C to Java (Andorid & Blackberry), C (Windows Mobile), or Palm Pre (JavaScript) is not easy. My brother is porting my App over and the Windows mobile library sucks. Graphics libraries are horrible (They don't even handle transparent images), the GPS uses Nautical miles and there are hundreds of other issues plaguing the system.
One thing I don't think the average consumer will ever realize about the iPhone is that it's super easy to develop for in comparison to any other mobile device. Even thought Apple is trying to make a big deal out of features like MMS, Video, Voice commands and things that I had back on my Treo 650 in 2004--The fact of the matter is that the ease of development is going to allow it to push so far beyond other devices in upcoming years unless mobile OS makers get serious.
With that being said, every phone is a target. Nobody likes every phone and as a business person, you have to keep the customers interest ahead of yours. If you're serious about a mobile application, you need to serve as many devices as you possibly can no matter how crappy the development environment is.
@Pazu: it's more than just working in one application - it's how the IDE handles the basics. With Cocoa, you have to handle the intermediary controller layer while that's all handled for you in VS.
Draw a button, set up the features in properties and double-click and bang, you're in the actual routine that gets called when someone clicks on the button.
You can DO it the way Cocoa does it - but you don't have to.
You have a point about having to pay to get access to a version of Visual studio that can handle WiMo, and yes, if Microsoft wants WiMo to catch on, they'll have to give it up and add it to the Express editions.
You're muddying up the issue with extra libraries. Even in .Net CF, which is stunningly minimal compared to full .Net, a LOT of stuff comes built in. Again, as I note in another comment, given that WiMo is only 32-64MB in size, including the system and core apps, it's actually surprising how well it works - but the truth is, they need to get over it and make WiMo complete.
@Vroomtrap: "Graphics libraries are horrible (They don't even handle transparent images)" Errr. AlphaBlend() is a standard GDI API call since WiMo 5.0. It handles alpha graphics quite nicely. Not supported in .Net CF - but you said C, not C#.
@valkilmerisawful: I think he's trying to say that the dearth of new things are what stuffs yearn to schnoodle within. I'm surprised you didn't get that the first time through.
@EpiphyteCorp.: Hahaha I was just crackin' up over here. I don't know what the hell you just said to me, but it was hilarious. I feel like it has something to do with him spooning technology...
@aquajaws: Hopefully that's the only reason why....I gotta say man, Palm Pre and iPhone apps are the only apps I've seen from all mobile OS'es that look sexy. All others just look meh....
@teexcue: WinMo is just about the ugliest thing ever. I've never understood how anyone can justify it visually. Then again, there are many reasons WinMo is trash. This article outlines one of those reasons: the apps suck.
10/09/09
10/09/09
1) They actually outright state that the "basic" protection is simply requiring that someone sign in with a Live ID before they can download, then deleting the CAB file. It's phrased to imply that there's more going on, but that's it.
2) Apparently only a few hypothetical "super-hackers" could possibly work around the protection provided by (1)
3) The expensive, premium protection is seemingly the same old tie-the-app-to-the-IMEI patching of the binary that everyone and their dog uses, which is probably trivial to hack too.
10/09/09
If they use Pocket IE, then it's very likely in that standard directory. A quick "Chandler" should find the full path. You could probably even write a small app that automatically mirrored any CAB file out of there.
10/09/09
[blogs.msdn.com]
"\Windows\Profiles\guest\Temporary Internet Files".
Anyone with the WinMo app store that can verify this for 6.5?
10/09/09
I'm still undecided on whether to submit my software to the Marketplace. I'm not worried about piracy much, as they're only $1.99 apps anyway. But the expense and trouble that seems to be involved in getting things approved is an impediment to individual developers like me.
I have two apps now in the Samsung App Store. That was very cheap and easy, and it has a pretty good copy protection scheme, tied to the phone's ID.
10/09/09
As for piracy, I'm really writing it for me but wouldn't mind a few buck from others who find it just as useful.
10/09/09
No, I don't really have a set of controls or anything yet. I have a C# image button class I did for one app. For other things, I just space them so they can be hit easily with a finger. Oh, I also have a form base class with "flick" gesture support and the ability to slide up, down, left, or right between forms. I've pretty much found the limits of what can be done graphics-wise with the .NET 2 CF.
For my apps I have demo versions that have limited features and nag screens, but no time limit. They can be activated with an RPN key (Handango-style) to full version status. I haven't decided yet whether to put them on Handango, etc. 50% is a lot compared to Samsung's and Microsoft's 30%.
08/10/09
There are thousands and thousands of WiMo apps out there.
08/09/09
08/09/09
It only got popular due to Apple blocking it, and the official release by Google for BB/Android.
08/05/09
This is a frustrating issue. I'll be the first to admit that iPhone OS is a richer environment for a simple reason: it's almost 10x larger than WiMo.
Windows Mobile was designed to fit - with all the core apps - into 32MB of ROM. The fact that it can do all the things it can do is actually pretty amazing - especially for the company that's the alleged posterboy for 'bloat'. iPhone OS, on the other hand, clocks in at 220MB+.
The WiMo ecosystem hasn't reacted to the much cheaper cost of flash memory and low power memory, and keeps building WiMo devices that are at least four years behind the curve... and Microsoft hasn't done much to convince them to knock it off.
WiMo 6.5 does a bit to fix this (and ONLY a bit) - but the big hope is 7.0 which sets new minimal hardware requirements. Thing is, unless Microsoft is ready to fill in a lot of missing parts and get rid of .Net CF - and just deliver .Net ARM, they're doomed to be left behind - and the window is closing (so to speak).
That being said, I read the article in question and have to bring up a few issues. First, it's entirely possible, if a little tricky, to make controls that look and behave just like iPhone controls in .Net CF (it's trivially easy in full .Net). Second, the ease of porting is very dependent on what you do and how you do it. I felt the author went about it in a somewhat difficult way. Still, the fact that Microsoft chose to publish that as a case study is unfortunate - and underlines the chief problem at MSFT with respect to WiMo - a kind of wilfull blindness.
It's weird that the simple UI is clunky when the hard one - the real time sound display - is almost identical. Most people over estimate the complexity of iPhone/Mac OS controls. Most of them are simply graphical elements (pngs, bmps and tifs) that are composited. I know this because I wrote a complete MacOS X Aqua UI kit for .Net 1.1 several years ago and actually OVER designed it - I actually generated the shading and elements algorithmically - then later found out how Apple did it.
The screen shot attached shows a sample - every control there works correctly.
But, the development tools in Visual Studio are often clumsy when you get to WiMo as soon as you start to cut your own controls because of the mechanism they use to insulate the developer from the complexities of things like P/Invoking into the OS.
Several people here dismiss the value of C# and .Net, but here's a good example of why it's easier - Apple posted a 'your first iPhone app' and I did the exact same thing in .Net:
apple: http: // www.vargr.com / files / iphone101.pdf
WiMo: http: // www.vargr.com / files / wimo101.pdf
(sheesh - embedding links is a real pain now)
It speaks for itself. If Microsoft fixed WiMo and gave us a full .Net, this discussion would be moot.
08/04/09
For the most part, direct porting of applications leads to sub par applications for all the systems you work on. For example, take a look at Safari 3 for the PC, it was a direct port, and worked terribly, Safari 4 then changed that strategy, and now it integrates much better with windows.
08/05/09
.Net allows you to use managed C++ mixes with native C++ and that's the trick that lets you make a portable application.
If you write an application with intention of it being crossplatform, the pain is paid once - but in this case, the app was written for the least compatible case, then ported.
You will end up writing a lot of custom UI code - once - but then you'll have a library of code you can use from then on.
08/04/09
Sure, if you have experience with multiplatform development you can make this process much less painful, but it's still far from a simple task.
All points mentioned in the article are moot:
* Language independence: while it's nice to be able to work with any language, it's not such a big deal. Any developer worth their salt should be able to pick up Objective C in a few weeks, and it is a sweet language to work with. I'd love to have garbage collection as on option, thou.
* Working on a single program: while it's true that you use a number or programs to develop for the iPhone, all those programs are very well integrated.
* Licensed libraries: Microsoft licenses additional libraries, Apple has most of these functionality built-in, for free. Some developers are also starting to distribute/sell libraries for iPhone.
* Development tools: iPhone development tools are also built into Apple's tools. For free, BTW. Visual Studio isn't exactly cheap.
* Community: iPhone developer community is huge already, and growing at a scaring pace.
All that said: WinMo (or more importantly, BB) is still an important target for corporate applications, and it's probably worth the effort to port your apps. Just don't expect anything to happen magically.
08/04/09
One thing I don't think the average consumer will ever realize about the iPhone is that it's super easy to develop for in comparison to any other mobile device. Even thought Apple is trying to make a big deal out of features like MMS, Video, Voice commands and things that I had back on my Treo 650 in 2004--The fact of the matter is that the ease of development is going to allow it to push so far beyond other devices in upcoming years unless mobile OS makers get serious.
With that being said, every phone is a target. Nobody likes every phone and as a business person, you have to keep the customers interest ahead of yours. If you're serious about a mobile application, you need to serve as many devices as you possibly can no matter how crappy the development environment is.
08/05/09
Draw a button, set up the features in properties and double-click and bang, you're in the actual routine that gets called when someone clicks on the button.
You can DO it the way Cocoa does it - but you don't have to.
You have a point about having to pay to get access to a version of Visual studio that can handle WiMo, and yes, if Microsoft wants WiMo to catch on, they'll have to give it up and add it to the Express editions.
You're muddying up the issue with extra libraries. Even in .Net CF, which is stunningly minimal compared to full .Net, a LOT of stuff comes built in. Again, as I note in another comment, given that WiMo is only 32-64MB in size, including the system and core apps, it's actually surprising how well it works - but the truth is, they need to get over it and make WiMo complete.
08/05/09
08/04/09
Ahhhwhatnow?
08/04/09
08/04/09
08/04/09
08/04/09
08/04/09
08/04/09
08/04/09
08/04/09
08/05/09
07/12/09
07/12/09
I'm digging all the cool stuff i can do with my WinMo phone.
-far more than I expected as a former PalmOS enthusiast.
07/12/09
07/12/09
07/12/09
07/12/09
07/12/09
Works great on my i910 Omnia.
-and YES I'll be flashing it real soon.
07/12/09
As a programmer, I really like my Omnia. Windows Mobile is very hackable. What are you going to flash? 6.1 or 6.5 beta? Cooked?
Edit...Why are my comments still not showing up without "show all"?!? Edit again...At least it let me promote my own comment! Ha!
07/12/09
I have no idea. I'm a bit out of my depth because i haven't hunkered down and read everything yet.