What do you think about .Net only versions of APIs?

We have .Net versions of APIs and we have native (C/C++) versions of APIs.  There are cases where we have a native version, but we don't have a .Net counterpart.  There aren't any real cases where we have a .Net API, and no native counterpart.  What if there were?

Maybe we are already doing this to some point.  For example, if you want to send an SMS using native code, it can take about 15 to 20 lines of code.  Using the .Net SmsMessage class (in the Microsoft.WindowsMobile.PocketOutlook namespace), you can code it in 2 lines! (1 line if you want to sacrifice a little bit of readability, but not much). 

Would not having a native version be a big deal?  What types APIs would you be ok with a .Net only version, if any?

- Brian

Comments (26)

  1. Patric says:

    I do all my programming for Windows Mobile using C#/.NET so for me its more convenient if something is available from a managed API than native. I believe most Windows Mobile applications are done using .NET, since the platform is so new so there’s not much legacy code. Also most applications tend to be small so its pretty easy to do a rewrite from native to managed code.

  2. Andemann says:

    Let me have it all available from .NET


  3. Kevin Daly says:

    Like Patric, I do all my Windows Mobile programming with C#.

    On the other hand, there are of course people who for reasons of personal preference (or because the application they’re working on requires it for reasons of performance or whatever) use C/C++ – and I don’t think it would be fair or helpful to deprive those people of native APIs – I would not like to try to identify which APIs might need only managed versions, because whenever you do that it turns out that someone has a use case you haven’t thought of.

  4. Jose Luis Balsera says:

    When the managed API needs an internal unmanaged API to be implemented, I think it would be nice to expose also the native API. I don’t think it would add much in terms of working set or size but it may be different in terms of development and support of the APIs.

  5. There are and always will be good reasons to write portions (if not all) of your application in native code. This obviously depends on what you are developing, but from the perspective on an ISV or a tool developer like me, shutting off APIs from native code is a bad thing.

    I also don’t understand your SMS example. In my native applications I also send SMS messages in one or two lines of code by reusing a wrapper class. That’s what the CF does for me right? So what’s new here?

  6. Jake says:

    I’m a .Net developer, so the native code is not a big deal for me. Only time I use it is when I have to P/Invoke to something because the managed framework doesn’t support it. VIVA LA MANAGED CODE!!!

    :// Jake

  7. WasNET says:

    It would be a terrible mistake in my humble opinion. It is already bad enough, evident with vendors putting on their own bloated UIs and what not and devices struggling with it.

    Going full on to CF is asking for exponential trouble in what is an exponential trend esp with WM5.0, storage or memory we are to play with getting slower and slower. It’s the same for Vista in many respects on the desktop.

    Due to this and more (that will be felt and is already felt with all GUI, memory and responsivness on desktop, even VS, etc): what you guys should be thinking of, again in my humblest of humle opinions, is native C++ classes (as in TR-whatever goes into standard along with boost etc) that look like CLR framework abstractions, not the other way around. Sure, security and verifiability are affected and what not but that’s a trust issue in the first place and like everything can probably be solved with opcodes (just like IL ;-).

    Or even better if you don’t buy that, optimise those CF and other CLR implementations to OS, as native and close to the metal as it can be. Ditch the compatibility with older stuff, you have to do it one day anyway.

    Then it might be worth it, but just wrapping or using MC++ isn’t enough. Heck I’d want it burned into chip to believe any benefits are worth the price you pay for the holy-grail..

    So on that all-mighty productivity topic.. it was way oversold with Java, now with CLR it is much better and less hyped but world moved on in many other places and people use what they perceive are the right tools for the right job.

    And as it is pretty obvious with all those devices out there, for anything with any complexity (I only judge from other people’s apps as my code is rubbish and not important to me), or any decent response times and where every fetch/store and cycle counts, no VM is enough. Not now and hardly few years down the line. That applies to desktop too.

    It’s the usual story of software companies pushing hardware guys and forcing another upgrade or economic cycle. It doesn’t solve the problem though, although I bought the idea back in 1999.

    It was a bad trade.

    My 2 liras,

    M _

  8. jevans says:

    Not a great move for those of us with large C++/COM code bases that predate C#.  Especially when you don’t provide a migration path other than scrapping and starting over.

  9. Patrick says:

    I´m a little bit jealus of this "one line" apis that are available for cf. But when i see those guys at my work who only can use this .net cf stuff and see their brain melt when try to understand complicated native code for something that could bo done with a simple namespace call i have to smile. i would like to have these simple native apis, but would prefer to have also the whole stuff. I think it gives you a little bit mor the chance to understand how its working ( if those sometimes cryptical names and attribs are ducomented in msdn or header files).

  10. Xentrax says:

    There is no C++/CLI support for CE. And no native to managed communication path either.

    Both must be available if MS wants to provide .Net only APIs.

    The problem is not only with the code already running on CE platform: while it’s hard to rewrite our 50MB C++ application to C#, we would like to port some of other ~300-400MB of C++ code available in our company.

  11. riki says:

    please god – no!

    as Xentrax, says at the VERY VERY least, wait until we can call managed code from nativeland.

    at least then there will be a workaround. But i have far to much native code – in fact all of it. and my apps need to support WM2002->WM5 with all screen resolutions, dynamicly leveraging new APIs if they are available.

  12. Sanjay Shetty says:

    I think it’s advantageous to have more .Net API’s

    I don’t think it makes sense to eliminate the underlying native API’s.

    People find the .Net API’s easier to develop against. It simplifies things. More developers would be able to develop if more .Net API’s are exposed making things simpler.

  13. Sanjay Shetty says:

    I think it’s advantageous to have more .Net API’s

    I don’t think it makes sense to eliminate the underlying native API’s.

    People find the .Net API’s easier to develop against. It simplifies things. More developers would be able to develop if more .Net API’s are exposed making things simpler.

  14. Reed Shilts says:

    We have a HUGE codebase for the PocketPC, Smartphone, and Tablet that is 90% NATIVE C++.

    Presenting APIs only in .NET would be DISASTROUS for customers like us.

  15. ajh says:

    Aren’t .NET framework api’s all based on C/C++ api’s?

    Granted there may be 20-50 lines of C/C++ that make up one line of C#, but it should be doable in C/C++, right?

  16. Alex Kac says:

    That would be terrible. 99% of all commercial apps are native code. CF is not anywhere close to being usable for commercial apps.

  17. BCross says:

    Yes, I totally agree that eliminating the native APIs would be very bad.  I should have been more clear in my intial post.  

    Let me rephrase:

    How would you feel if a new API came out and ONLY had a managed interface.  Existing native APIs would still be available and untouched.  Nothing would have to be ported.

    Would not having a native version for this new API be a big deal?  


  18. Sorry, but that’s a completely nonsensical question, at least from a technical perspective. What would it buy you *not* having native APIs? Only to force .NET on the developers?

    Maybe that’s what some MS marketing folks would like to pursue, but the real personality of Windows is, and will probably ever be, the Win32 API.

    Maybe it has become uncool to code against a 20+ year old, non object-oriented, C-style API, with plain C functions, structs, bitflags, messages, and return codes, but it’s still the fastest and most resource-effective way of programming Windows.

  19. Matthew says:

    .NET only APIs would cause a huge problem for anything not fitting the design of a tradition application. Sure, that might be fine for a card game, but what about applications that have components running as a service, or anywhere else in the system? Services, drivers, etc cannot be written in .NET, so adding new APIs without a native counterpart would be effectively denying use of those APIs from many non-trivial applications.

    That’s the technical reason I think its a bad idea. Additionally, not everyone has migrated, nor do they all plan to migrate to .NET. I’ve looked over it enough to see that the only benefit is somewhat easier GUI development, but still not the ease of some other GUI toolkits (considering toolkits not available on the CE platform). This marginal improvement does not offset the multitude of negatives.

  20. Xentrax says:

    … that .Net only new APIs is OK if there is a way to call into them from native code.

    Developers will be able to write small native wrappers around managed APIs and will use them in their native applications.

    Isn’t it silly?

    You see, there must be C++/CLI support in CF.Net.

  21. George Henne says:

    It would be a bad idea. Many of us have been developing CE apps with C++ since CE 1 or 2. We’ve been able to update our app for each new generation of the OS. Having managed only APIs would prevent us from updating our apps to take advantage of new features in future devices.

    Providing an easy way to call managed API functions from unmanaged code would be a solution.

  22. Altarace says:

    Gosh, I guess the WM5 changes and AKU2 changes are not enough to keep us busy in the weekends 🙂

    But Seriously: Reducing support for Native before you have a native-to-managed bridge will be a disaster. Also please don’t forget that some components cannot be managed like drivers and LAP’s so unless you change all that to CF I think your point is mute.


  23. cashto says:

    I imagine it would be OK as long as the .Net API didn’t provide any new functionality — it only provided a simplified interface to do common things in native code.

    Actually something that’s been a sore spot for me for a while now … quite frankly, a lot of our native APIs suck.  There’s no earthly reason why it should take 20-30 LOC in *any* language to send an SMS message.  A lot of the guiding principles that make .Net APIs easy to use can easily be translated to native code — such as providing reasonable defaults, hiding implementation details through good abstractions, and above all, design focus on ease-of-use rather than ease-of-implementation.

    The choice is not "do we provide a hard-to-use native API, or an easy-to-use managed API" … there are other options.  🙂

  24. Brian says:

    when you include .Net in the distribution of WM devices, then you should go to .net only.

    it is stupid having make the user install .net and then the app.

  25. Scott Lac y Salley says:

    That would make life terrible for me and many other developers.

    I work on multiple WinCE devices (and other platforms) as do most the developers I know. We use C because it is the only common denominator.  

    A lot of code is still C/C++ and will be for a *long* time.

  26. Trung Nguyen says:

    Hello everybody. I’m actually not a new programmer but i’m new at C#. I’ve been spending a lot of my time study some kinds of programming language, Java, Visual Basic, C and now I’m going to try C#. I know in the future, I would have to focus on one technology. So any of you can give me the advice? Should I use C# or Java if I want to write application for Mobile or for games.

Skip to main content