Share via

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

  • Article

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

  • Anonymous
    April 21, 2006
    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.
  • Anonymous
    April 21, 2006
    Let me have it all available from .NET

    andreas
  • Anonymous
    April 21, 2006
    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.
  • Anonymous
    April 21, 2006
    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.
  • Anonymous
    April 21, 2006
    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?
  • Anonymous
    April 22, 2006
    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
  • Anonymous
    April 22, 2006
    The comment has been removed
  • Anonymous
    April 22, 2006
    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.
  • Anonymous
    April 22, 2006
    The comment has been removed
  • Anonymous
    April 23, 2006
    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.
  • Anonymous
    April 23, 2006
    The comment has been removed
  • Anonymous
    April 24, 2006
    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.
  • Anonymous
    April 24, 2006
    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.
  • Anonymous
    April 24, 2006
    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.
  • Anonymous
    April 24, 2006
    The comment has been removed
  • Anonymous
    April 24, 2006
    That would be terrible. 99% of all commercial apps are native code. CF is not anywhere close to being usable for commercial apps.
  • Anonymous
    April 24, 2006
    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?  

    -Brian
  • Anonymous
    April 24, 2006
    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.
  • Anonymous
    April 24, 2006
    The comment has been removed
  • Anonymous
    April 24, 2006
    ... 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.
  • Anonymous
    April 25, 2006
    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.
  • Anonymous
    April 25, 2006
    The comment has been removed
  • Anonymous
    April 26, 2006
    The comment has been removed
  • Anonymous
    May 01, 2006
    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.
  • Anonymous
    August 16, 2006
    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.
  • Anonymous
    September 12, 2006
    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.