Coffeehouse Thread

108 posts

Disappointed about WP7 APIs

Back to Forum: Coffeehouse
  • User profile image
    Charles

    BitFlipper said:
    W3bbo said:
    *snip*

    So these same people could not choose a Mac when they decided to buy a computer?

     

    Besides, my point is just to show how ridiculous it is that Apple holds a press conference every time they sell 1 million of a product.

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

    C

  • User profile image
    Bass

    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.

  • User profile image
    W3bbo

    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.

  • User profile image
    Bass

    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!

  • User profile image
    BitFlipper

    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.

  • User profile image
    AndyC

    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?

  • User profile image
    Charles

    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 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

  • User profile image
    BitFlipper

    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.

  • User profile image
    W3bbo

    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.

     

     

     

  • User profile image
    W3bbo

    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).

  • User profile image
    Bass

    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.

  • User profile image
    W3bbo

    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.

  • User profile image
    Bass

    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.

  • User profile image
    AndyC

    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).

  • User profile image
    Charles

    W3bbo said:
    Charles said:
    *snip*

    "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).

    Pointer arthimetic isn't the only knife... Yes, I understand that the applications will be running in an application environment. Point is, there will be no direct access to the hardware from third party code.

     

    Strictly defining the application/os boundaries, supporting only a very limited hardware configuration,focusing squarely on user experience, providing high level programming abstractions (that are also powerful and enable a plethora of very useful application scenarios for developers and then users of the device).

     

    By PC, I mean Personal Computing. There's a difference between a personal computer and personal computing (a personal computer enables some form of personal computing...). Modern smartphones are hand-held personal computers that enable a specific personal computing experience including web browsing, downloading and running applications and of course telephony, etc...

     

    Yes. C/C++ and supporting tools (IDEs, text editors, compilers, libraries, etc) are very capable and mature. The point is that, by design, the supported WP7 application framework exposes a rich set of very useful programmable features with the extra benefit of an established managed execution model. There's nothing wrong with democratizing application development: enabling broad adoption of the platform, especially among those who already possess a solid working knowledge of the supported design tools and engineering domains. For those who do not, getting up to speed will be easier than getting up to speed with, say, Objective C or C++. Yes, you could argue that supporting both models would just increase the surface area of developers who would target the platform. I can't argue against that notion, given that is in fact correct. Not sure entering that rabbit hole is useful at this point... That said, read the first paragraph of this reply again.

     

    Suffice it to say that WP7 will provide many, many developers around the world with a reliable and capable platform that does not require them to learn how to use new or foreign tools - they already have the right equipment to design and implement their WP7 applications. Again, that statement also applies to the legions of native developers. Not sure what you want to hear. The WP7 platform that ships will be what it is. I'm really looking forward to it. It will be like nothing else we've delivered in this space. Why don't you give it a fair chance before dismissing its potential based on the application development tools it doesn't support?

     

    Promise and deliver. The new Microsoft.

     

    I want my new phone.

    C

     

     

  • User profile image
    Clint

    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.

    so the lack of these c/c++ libraries is stopping you from building apps?

  • User profile image
    Sven Groot

    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.

  • User profile image
    Charles

    Sven Groot said:

    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.

    Then charge 2.50 USD to download it and use the cumulative income to pay for the yearly fee and also provide you with some cash for good sushi and sake. Smiley

    C

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.