Quick question… Managed or Native?

It’s been interesting to see the adoption of managed code for Windows Mobile devices, the majority of Windows Mobile developers today are using Managed code (C#/VB), I think this totally makes sense. But what about the embedded developer?

I’m curious to find out whether you are a managed or native developer, and why you chose to use one over the other.

- Mike

Comments (13)

  1. I usually work on drivers and low-level layers of the OS, so I do most of my work in C/C++.

    If I need to make applications I usually prefer .NET and C# because development times are shorter and the resulting application runs smoothly even on a resource-constrained device.

    The only drawback of the .NET CF is the size of the framework that could increase memory requirements of an embedded device, forcing you to add more flash or more RAM to support it.

    I also think that the choice is not mutually exclusive. Using a good balance of native and managed code, integrated using PInvoke or COM wrappers (ATL made COM development simple!) can result in solutions that require a reasonable development and test time and give good performances.

  2. Ripper says:

    I work on device drivers and a lot of middle layer sutff so C/C++ it is for me. Even some simple applications that I need to write for testing my code I do it in C++. Managed code right now looks greek and latin to me but it facsinates me just because I see so many people talking about it! I am looking forward to learning C# development and Im gonna start very soon.

  3. David White says:

    We have found C# difficult for custom drawing. Not from a resource usage standpoint (although we spent many hours keep GCs from happening)but from all the nearly "native" things you have to do anyways. Also when a GC happens it halts all .NET threads on the device which makes your app look like it is hung. To me it seems right tool for the right job. C# is great for web services interaction and more business driven apps. In the consumer electronics space though it seems to fall short

  4. Sebastian says:

    Native.  On Windows Mobile.

    For its more precise control and speed.  .NET CF on mobile is too slow.  Users want instant load times and response.  They don’t want to see a spinning colourful hourglass while waiting.

    It’s a phone, not a PC.

  5. Neilos says:

    On Windows CE.

    Native for drivers (of course).

    We also use native libraries to access hardware communication interfaces (e.g. CAN bus): this allow to continue to receive data from the bus into a buffer while GC is running.

    All other parts are in .NET C# CF 3.5

  6. I develop for Windows Mobile almost exclusively in C++. Although the development complexity is higher than in C#, I get much more control and performance out of the platform.

  7. I’ve moved to managed. I only go back to native if some functionality is lacking in managed. Even then, I embed it in my C# app.

  8. Vyacheslav Lanovets says:

    Native C++ because C++ is a better language than C# and there is no C++/CLI.

    And we’ve no choice but C++ anyways. Our 50MB of compiled binaries do not fit into VM and we explicitly load/unload them. Think of rewrting 70MB of C++ code into C#.

    At least WM6.1 has an extra slot for DLLs.

  9. Patrick says:

    Mostly Windows Mobile sometimes CE.

    But allways native!

    I don´t see that development times are faster with managed code. Maybe i´m just to good or have to much finished classes and snippets that i can reuse.

    But i must say that i do a little more complicated stuff than just some boring LOBs. So i see no reason to write managed code when most of it depends on PInvoke.

    And on Desktop: Win32 and MFC are still my first choice…

  10. Amit says:

    I love C# for large apps, if you do it right it’s about as fast as native code but way easier to design and implement

    It’s a huge pain to use it for small apps, though, because the OS integration is spotty at best on CE, so you end up having to either spend half an hour on your app and 2 hours p/invoking things, or spend an hour writing it in native code

    It’s also a pain to write a native C++ DLL and interface with it, it’d be great if there were some sort of wizard to help with the process (or even just a guide on MSDN).  The problem is that you have to export things in a certain way to import them into C# with p/invoke, and the standard C++ declspec doesn’t work for it

  11. DarthObiwan says:

    Mostly Windows Mobile 5/6 with C#.

    We do lots of barcode scanning software with Symbol handhelds.

    I’ve done one CE app with C#.

    It is definitely easier to get something out the door going the managed route. Developing and designing inherited forms can take ages native.

    I have had to use native a couple times for writing autorun applications. One was even for distributing the Windows Mobile 6 sales kit.

    I’ve had to resort to native calls to get some things done from Managed but find that’s a small burden to bare. I’ve rarely run into the GC issue. The issues I run into the most are controls I’m not able to inherit from and implement myself.

  12. Bruce Casner says:

    We are using a combination of C, C++ and C# in our embedded design, under CE 5.0 because that’s the latest BSP for the hardware.  C/C++ for speed, and C# where the APIs in C/C++ are unmanageable and they are easy in C#.  We will soon have an application under C# from a third party also running on our device.

  13. Native code: I typically code device drivers and OAL code so managed code is not an option. I use C/C++ if I need to write some simple UI, for example a control panel applet or a simple demo. If I had enough time, anyway, I’d like to improve my C# skills!

Skip to main content