Disappointed about WP7 APIs

BitFlipper said:

1.6

The number of days between press conferences if MS was to hold one every time they sold 1 million copies of Windows 7.

Pizza.

What I am eating right now.

Charles said:

BitFlipper said:

*snip*

Man, this thread has really wound down a rabbit hole.... So, what are the issues you're having with WP7 APIs? Please elaborate.

C

Whilst my disappointment about there not being a native API is well-known, I'd like to justify it with the following bullet points. I would appreciate an "officially supported approach" response to the scenarios I propose:

• Running native code allows for raw access to the hardware and to invoke and work with pieces of the system directly. I made a post about how a guy I knew wrote software that set up Wi-Fi based iTunes synchronisation. These kinds of utilities are impossible to achieve in a sandboxed environment. Does Microsoft believe we'll (both users and developers) be satisfied with applications that cannot do anything more than "take in information, process it, and present it to the user"?
• The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms. It also means we cannot use preexisting C++ libraries like OpenCV or GMP. "Compiling C++ to CIL" is not an option because only Verifiable CIL is allowed. Right now the only real C# vision library is AForge, which whilst good, is nothing compared to OpenCV, and things like this mean that we won't see any "cool" Augmented Reality projects for WP7 because the effort involved in porting over OpenCV to C# would be tremendous.
• High-performance applications would be impossible to work with. Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag, but that's verboten.
• Lack of competition: I feel it's unfair that Microsoft gets to develop their applications using native code (IE, Word/Excel, PIM, etc) but we become second-class citizens. How will this foster a true "partner" spirit between Microsoft and ISVs?

I'll play along with WP7 for the basic app: the usual sort that does the usual "information processing" tasks, but if Microsoft wants to see innovative and eye-catching applications they're going to have to make it possible to run native code.

I feel the restriction on non-verifiable code is stupid: CLR programs run in a sandbox anyway and it won't stop programs from magically crashing, yet it makes certain classes of applications extremely difficult, if not impossible, to implement, such as (as I said) painting or image processing applications.

W3bbo said:

Charles said:

*snip*

Whilst my disappointment about there not being a native API is well-known, I'd like to justify it with the following bullet points. I would appreciate an "officially supported approach" response to the scenarios I propose:

 

• Running native code allows for raw access to the hardware and to invoke and work with pieces of the system directly. I made a post about how a guy I knew wrote software that set up Wi-Fi based iTunes synchronisation. These kinds of utilities are impossible to achieve in a sandboxed environment. Does Microsoft believe we'll (both users and developers) be satisfied with applications that cannot do anything more than "take in information, process it, and present it to the user"?
• The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms. It also means we cannot use preexisting C++ libraries like OpenCV or GMP. "Compiling C++ to CIL" is not an option because only Verifiable CIL is allowed. Right now the only real C# vision library is AForge, which whilst good, is nothing compared to OpenCV, and things like this mean that we won't see any "cool" Augmented Reality projects for WP7 because the effort involved in porting over OpenCV to C# would be tremendous.
• High-performance applications would be impossible to work with. Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag, but that's verboten.
• Lack of competition: I feel it's unfair that Microsoft gets to develop their applications using native code (IE, Word/Excel, PIM, etc) but we become second-class citizens. How will this foster a true "partner" spirit between Microsoft and ISVs?

I'll play along with WP7 for the basic app: the usual sort that does the usual "information processing" tasks, but if Microsoft wants to see innovative and eye-catching applications they're going to have to make it possible to run native code.

 

I feel the restriction on non-verifiable code is stupid: CLR programs run in a sandbox anyway and it won't stop programs from magically crashing, yet it makes certain classes of applications extremely difficult, if not impossible, to implement, such as (as I said) painting or image processing applications.

I'm more concerned over the "develop in Silverlight" garbage. Silverlight is basically a gimped version of .NET, a huge step back in everyway. For some reason the prospect of having less functionality and tooling available exictes people to no end. It has a cool name and abstract logo!

Charles said:

BitFlipper said:

*snip*

Man, this thread has really wound down a rabbit hole.... So, what are the issues you're having with WP7 APIs? Please elaborate.

C

LOL, ok sorry.  Will try to stay on topic...

For me, the two I noticed:

Lack of ComboBox Control

I was surprized to find there is no combo box control. From the MSDN forums, the reason given was that it doesn't "fit in with the Metro design". Except in the emulator if you go to Settings, you'll find at least 3 different ways that the designers came up with to work around the fact that there is no combo box:

1. Click on "theme", and the control expands, pushing down the controls below it in order to expose the available selections.
2. Click on "region & language", and you get options where if you click them, you go to a completely different page that lists the available options.
3. Although this option no longer seems to take you anywhere after upgrading to the beta, previously selecting "date & time", then toggling one of the options (forgot which one exactly) caused some additional options to be exposed. If you then selected some of them, you got one of those "one-arm-bandid" type spin wheel controls.

So just in that area of the UI alone, there is a huge amount of inconsistency already. I don't know how app developers are supposed to be consistent when the basic, built-in UI is already all over the place. MS better fix it soon because we will end up with a multitude of combo box implementations, each looking and working in a different way.

Microsophone input Sample Rate

Not really a big issue for most people, but you can't set the sample rate on the mic input. This is a problem for me since I want to develop an app that detects the pitch of an incoming voice. This calculation is pretty complicated, and the higher the sample rate, the more CPU cycles you use processing the signal. Since the highest that a person's voice can typically go is ~1.6KHz, the highest sample rate I really need is about 3.2KHz.  Except I'm stuck at a fixed sample rate. In the pre-beta emulator, this was 44.1KHz. For the beta, this is 16KHz. The beta is better (for my purposes, anyway), but still 5 times what I need. Supposedly the way this works is that WP7 will detect the highest sample rate the hardware supports, and then use that. There are no plans to make this an app-settable value as far as I know.

W3bbo said:

Charles said:

*snip*

Whilst my disappointment about there not being a native API is well-known, I'd like to justify it with the following bullet points. I would appreciate an "officially supported approach" response to the scenarios I propose:

 

• Running native code allows for raw access to the hardware and to invoke and work with pieces of the system directly. I made a post about how a guy I knew wrote software that set up Wi-Fi based iTunes synchronisation. These kinds of utilities are impossible to achieve in a sandboxed environment. Does Microsoft believe we'll (both users and developers) be satisfied with applications that cannot do anything more than "take in information, process it, and present it to the user"?
• The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms. It also means we cannot use preexisting C++ libraries like OpenCV or GMP. "Compiling C++ to CIL" is not an option because only Verifiable CIL is allowed. Right now the only real C# vision library is AForge, which whilst good, is nothing compared to OpenCV, and things like this mean that we won't see any "cool" Augmented Reality projects for WP7 because the effort involved in porting over OpenCV to C# would be tremendous.
• High-performance applications would be impossible to work with. Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag, but that's verboten.
• Lack of competition: I feel it's unfair that Microsoft gets to develop their applications using native code (IE, Word/Excel, PIM, etc) but we become second-class citizens. How will this foster a true "partner" spirit between Microsoft and ISVs?

I'll play along with WP7 for the basic app: the usual sort that does the usual "information processing" tasks, but if Microsoft wants to see innovative and eye-catching applications they're going to have to make it possible to run native code.

 

I feel the restriction on non-verifiable code is stupid: CLR programs run in a sandbox anyway and it won't stop programs from magically crashing, yet it makes certain classes of applications extremely difficult, if not impossible, to implement, such as (as I said) painting or image processing applications.

"Running native code allows for raw access to the hardware"

Er, no. Not unless you're allowed to write drivers. The only difference between native code and managed code is that the latter is inherently portable. Any other difference comes down to what API's you expose and there is no guarantee that a native code API would expose any more than you currently get.

"The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms"

Stretching the point somewhat. It's a phone. The vast majority of those titles would need major reworking to be viable titles on any phone anyway (if they ever would be). And, as Apple have shown, if it's worth doing people will rewrite them.

"Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag"

Seriously? You think there is going to be major calls for painting applications? Again, it's a phone. And Silverlight does have the ability to support custom pixel shaders and the perf differences between native/JITted code are not nearly as vast as some people want to believe.

"How will this foster a true "partner" spirit between Microsoft and ISVs"

By guaranteeing that an app written for WP7 will work on every single Windows Phone released from now on? By assuring developers they won't have to  re-release/rework titles when WP8 comes along (think side-by-side VMs)? By eradicating hardware dependency from the equation entirely, allowing future WP-like devices to use whatever CPU architecture is appropriate, entirely transparently?

Bass said:

W3bbo said:

*snip*

I'm more concerned over the "develop in Silverlight" garbage. Silverlight is basically a gimped version of .NET, a huge step back in everyway. For some reason the prospect of having less functionality and tooling available exictes people to no end. It has a cool name and abstract logo!

Actually I think it is the opposite. Many people find Silverlight to be an ideal environment to develop the type of "sandboxed" apps you will find on a phone. While I agree that the loss of native code development is a problem for some, I really have to wonder how much really. If Silverlight gives you everything you need, why would you need to P/Invoke? Yes you will lose some performance benefits since you can't do native pointer arithmetic, but have you done tests on actual hardware to see how much of a problem it really is? How large will this graphic be that you will be manipulating on your phone? No, really?

You obviously have issues with Silverlight and probably with .Net in general. That doesn't mean everyone else have these issues.

I saw a slide show somewhere (ok, I saw it here) where someone did a side-by-side comparison of building a basic app for iPhone and WM7. It's like day and night. WP7 development is much cleaner and faster. Quite eye-opening for someone like me that have not done any iPhone development.

AndyC said:

W3bbo said:

*snip*

"Running native code allows for raw access to the hardware"

 

Er, no. Not unless you're allowed to write drivers. The only difference between native code and managed code is that the latter is inherently portable. Any other difference comes down to what API's you expose and there is no guarantee that a native code API would expose any more than you currently get.

 

"The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms"

 

Stretching the point somewhat. It's a phone. The vast majority of those titles would need major reworking to be viable titles on any phone anyway (if they ever would be). And, as Apple have shown, if it's worth doing people will rewrite them.

 

"Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag"

 

Seriously? You think there is going to be major calls for painting applications? Again, it's a phone. And Silverlight does have the ability to support custom pixel shaders and the perf differences between native/JITted code are not nearly as vast as some people want to believe.

 

"How will this foster a true "partner" spirit between Microsoft and ISVs"

 

By guaranteeing that an app written for WP7 will work on every single Windows Phone released from now on? By assuring developers they won't have to  re-release/rework titles when WP8 comes along (think side-by-side VMs)? By eradicating hardware dependency from the equation entirely, allowing future WP-like devices to use whatever CPU architecture is appropriate, entirely transparently?

"The only difference between native code and managed code is that the latter is inherently portable. Any other difference comes down to what API's you expose and there is no guarantee that a native code API would expose any more than you currently get."

Managed APIs for doing things tend to simply be wrappers around native APIs, so the range of functionality possible with managed applications will always be a subset of what native code can do.

I wouldn't be arguing this point if P/Invoke was allowed, since then Managed apps can call native APIs (albiet with some overhead), but as some people have already pointed out some things (e.g. controlling the flashlight or device-specific hardware provided by OEMs) really are just impossible.

"And, as Apple have shown, if it's worth doing people will rewrite them."

Apple hasn't shown anything. You don't need to rewrite anything either: You can use the same C/C++ libraries on the desktop as you can on the iPhone. Doom has been ported to the iPhone, not rewritten, as has Quake 3. Biiig difference.

You ignored my point about libraries simply too big for a small team to rewrite, such as OpenCV. Yet if this library was available we'd see a whole load of innovative camera-based applications such as augmented reality. As things stand, we won't see anything like this, ever, on WP7.

"Seriously? You think there is going to be major calls for painting applications? Again, it's a phone. And Silverlight does have the ability to support custom pixel shaders and the perf differences between native/JITted code are not nearly as vast as some people want to believe."

There are a large number of popular finger-painting applications on the iPhone and iPad. Then there'a also photo-processing applications and applications that process real-time video. .NET on Windows can sort-of get away with this because the GDI+ System.Drawing API is fast enough for many tasks, but it doesn't exist under Silverlight-on-WP7.

Pixel Shaders aren't the same thing, and you can't do everything with them either.

"By guaranteeing that an app written for WP7 will work on every single Windows Phone released from now on?"

Funny that, I've got applications developed for Pocket PC 2000 that run perfectly fine on my Windows Mobile device. You're basing your argument on the assumption that there are viable alternatives to ARM when there aren't.

Charles said:

W3bbo said:

*snip*

I actually think the idea behind focusing on a managed sandbox app model in this case is

 

a) there are many programmers today who are comfortable with the .NET model and the supporting tools are rather mature and capable,

 

b) you won't be able to crash the device with your buggy code since you won't be working at the memory level directly, etc...

 

c) we're trying to make programming apps on WP7 more accessible to lower-skilled developers/hobbyists, rather than focusing primarily on the professional and highly-skilled engineers

 

WP7 will be the best PC phone Microsoft has ever released. We're navigating through uncharted waters as far as we're concerned: WP7 aims to employ simplified experience from the app model to the UI.... In some sense, this is not our typical behavior, so I am happy we're breaking out of our comfortable straightjacket and taking a chance here.

 

I am a big fan of native code, as is Microsoft, of course. Not supporting it as a platform tool for building WP7 apps doesn't mean WP7 isn't useful for pro developers... The number of scenarios that are possible to write with .NET (SL/XNA) are many, not few.

 

Watch the C9 Live @ TechED NA for the official response regarding no-native on WP7 (Carmine007 asks "why are you forcing developers to use managed code..."): http://channel9.msdn.com/posts/NicFill/Ch9Live-at-TechEd-NA-2010-Talking-WP7-with-Brandon-Watson--Peter-Torr/

 

C

"a) there are many programmers today who are comfortable with the .NET model and the supporting tools are rather mature and capable"

That's a fine observation, but there are also many more programmers today who are comfortable with the C/C++ model and the supporting tools are even more mature and capable.

"b) you won't be able to crash the device with your buggy code since you won't be working at the memory level directly, etc... "

That's a weak argument, Windows CE has always been a pre-emptively multitasking OS. user-mode applications cannot crash the device. If a native application dereferences a null pointer it will crash just as well as it would on desktop Windows, but the system will continue running happilly enough. Removing pointer arithmetic doesn't stop programs from crashing.

"c) we're trying to make programming apps on WP7 more accessible to lower-skilled developers/hobbyists, rather than focusing primarily on the professional and highly-skilled engineers"

For the very golden nuggets you'll find by adopting that policy you'll have to wade through a huge amount of really awful applications with no conceivable utility. I hypotheise that Microsoft has already effectively doomed the Marketplace by not adopting minimum quality standards. I thought Windows Phone 7 was about creating a first-class mobile experience unlike the hodgepodge of Windows Mobile, but by lowering standards like this you're only bringing us back to those awful programs spamming PocketGear et al.

I'll also like to remind everyone that Microsoft has never won a D&AD award, yet their competitors have. Go figure.

"WP7 will be the best PC phone Microsoft has ever released. We're navigating through uncharted waters as far as we're concerned: WP7 aims to employ simplified experience from the app model to the UI.... In some sense, this is not our typical behavior, so I am happy we're breaking out of our comfortable straightjacket and taking a chance here."

Contradiction there. A "PC" lets you do what you want to do with it, free of any first-party control, if you wanted that then you went with Nintendo. WP7 is worse than Apple in this regard, and no-one considers the iPhone a "PC phone". WP7 devices are halfway between Smartphone and Feature Phone.

"I am a big fan of native code, as is Microsoft, of course. Not supporting it as a platform tool for building WP7 apps doesn't mean WP7 isn't useful for pro developers... The number of scenarios that are possible to write with .NET (SL/XNA) are many, not few."

I never said that .NET had "few" scenarios, just that the more adventurous and innovative "out of the box" applications are only really possible with native code given the state of the entire developer ecosystem right now (e.g.... again, OpenCV).

W3bbo said:

AndyC said:

*snip*

"The only difference between native code and managed code is that the latter is inherently portable. Any other difference comes down to what API's you expose and there is no guarantee that a native code API would expose any more than you currently get."

 

Managed APIs for doing things tend to simply be wrappers around native APIs, so the range of functionality possible with managed applications will always be a subset of what native code can do.

 

I wouldn't be arguing this point if P/Invoke was allowed, since then Managed apps can call native APIs (albiet with some overhead), but as some people have already pointed out some things (e.g. controlling the flashlight or device-specific hardware provided by OEMs) really are just impossible.

 

"And, as Apple have shown, if it's worth doing people will rewrite them."

 

Apple hasn't shown anything. You don't need to rewrite anything either: You can use the same C/C++ libraries on the desktop as you can on the iPhone. Doom has been ported to the iPhone, not rewritten, as has Quake 3. Biiig difference.

 

You ignored my point about libraries simply too big for a small team to rewrite, such as OpenCV. Yet if this library was available we'd see a whole load of innovative camera-based applications such as augmented reality. As things stand, we won't see anything like this, ever, on WP7.

 

"Seriously? You think there is going to be major calls for painting applications? Again, it's a phone. And Silverlight does have the ability to support custom pixel shaders and the perf differences between native/JITted code are not nearly as vast as some people want to believe."

 

There are a large number of popular finger-painting applications on the iPhone and iPad. Then there'a also photo-processing applications and applications that process real-time video. .NET on Windows can sort-of get away with this because the GDI+ System.Drawing API is fast enough for many tasks, but it doesn't exist under Silverlight-on-WP7.

 

Pixel Shaders aren't the same thing, and you can't do everything with them either.

 

"By guaranteeing that an app written for WP7 will work on every single Windows Phone released from now on?"

 

Funny that, I've got applications developed for Pocket PC 2000 that run perfectly fine on my Windows Mobile device. You're basing your argument on the assumption that there are viable alternatives to ARM when there aren't.

 

 

 

Actually to add to this, Android and iPhone use the same exact graphics library: OpenGL ES. Which makes porting between them trivial.

Porting a full blown OpenGL app to OpenGL ES is trivial as well. That's how iPhone got AAA games so quickly.

Bass said:

W3bbo said:

*snip*

Actually to add to this, Android and iPhone use the same exact graphics library: OpenGL ES. Which makes porting between them trivial.

 

Porting a full blown OpenGL app to OpenGL ES is trivial as well. That's how iPhone got AAA games so quickly.

And the surprising thing is that OpenGL ES worked fine on Windows Mobile 5. What a shame we can't use this.

W3bbo said:

Bass said:

*snip*

And the surprising thing is that OpenGL ES worked fine on Windows Mobile 5. What a shame we can't use this.

I wouldn't be suprised if XNA on most WinMo7 phones is just a wrapper around OpenGL ES anyway.

W3bbo said:

AndyC said:

*snip*

"The only difference between native code and managed code is that the latter is inherently portable. Any other difference comes down to what API's you expose and there is no guarantee that a native code API would expose any more than you currently get."

 

Managed APIs for doing things tend to simply be wrappers around native APIs, so the range of functionality possible with managed applications will always be a subset of what native code can do.

 

I wouldn't be arguing this point if P/Invoke was allowed, since then Managed apps can call native APIs (albiet with some overhead), but as some people have already pointed out some things (e.g. controlling the flashlight or device-specific hardware provided by OEMs) really are just impossible.

 

"And, as Apple have shown, if it's worth doing people will rewrite them."

 

Apple hasn't shown anything. You don't need to rewrite anything either: You can use the same C/C++ libraries on the desktop as you can on the iPhone. Doom has been ported to the iPhone, not rewritten, as has Quake 3. Biiig difference.

 

You ignored my point about libraries simply too big for a small team to rewrite, such as OpenCV. Yet if this library was available we'd see a whole load of innovative camera-based applications such as augmented reality. As things stand, we won't see anything like this, ever, on WP7.

 

"Seriously? You think there is going to be major calls for painting applications? Again, it's a phone. And Silverlight does have the ability to support custom pixel shaders and the perf differences between native/JITted code are not nearly as vast as some people want to believe."

 

There are a large number of popular finger-painting applications on the iPhone and iPad. Then there'a also photo-processing applications and applications that process real-time video. .NET on Windows can sort-of get away with this because the GDI+ System.Drawing API is fast enough for many tasks, but it doesn't exist under Silverlight-on-WP7.

 

Pixel Shaders aren't the same thing, and you can't do everything with them either.

 

"By guaranteeing that an app written for WP7 will work on every single Windows Phone released from now on?"

 

Funny that, I've got applications developed for Pocket PC 2000 that run perfectly fine on my Windows Mobile device. You're basing your argument on the assumption that there are viable alternatives to ARM when there aren't.

 

 

 

"Managed APIs for doing things tend to simply be wrappers around native APIs, so the range of functionality possible with managed applications will always be a subset of what native code can do."

No. That may be true on Windows, where there was a well established native API with a managed stack then added at a much later date, there is simply no reason that it has to be true on an entirely new platform, which is what Windows Phone 7 is.  It's a bit like suggesting that GDI shouldn't be there on Win32, because previous platforms allowed you to directly manipulate the graphics hardware. Nonsense.

"You're basing your argument on the assumption that there are viable alternatives to ARM when there aren't."

And you're basing your argument on the assumption that Intel will simply cede the mobile market. Whether there are viable alternatives to ARM today is largely irrelevant. And if anyone knows the burden of tying a platform too tightly to the underlying architecture, it's Microsoft (see every attempt to ditch x86).

My biggest disappointment isn't the APIs. It's the fact that the marketplace is apparently the only way to get apps into the hands of consumers, and that putting apps on it costs money.

I'd be interested in doing a WP7 version of my Japanese dictionary (assuming I have enough time for it, and assuming WP7 has native Japanese input since I can't develop a SIP for it), but it's currently a completely free, open source app under BSD license. I'd want to keep it that way but I can't afford to pay $99 per year so people can download my app for free.