.net Micro To Be Open Sourced

[Pleng]

Microsoft are opening the .NET Micro framework

Does this mean it could become possible to develop Pandora applications using Visual Studio?

 

[benjymous]

Microsoft are opening the .NET Micro framework

Does this mean it could become possible to develop Pandora applications using Visual Studio?

You already can develop Pandora applications using Visual Studio (that's what I do), you just need to use a different compiler

 

[Pleng]

Are you referring to MONO?

Coz I tried mono before and couldn't get it to work properly

 

[sindbad]

The .NET micro thing is useless, just a PR stunt.

If you really want to use a .NET language on the pandora, use mono. It will work, but it most certainly will not be bundled with Pandora. Your games/apps will be HUGE because you'll have to include mono.

This is all the same whether you're using Visual Studio or not.

 

[skeezix]

*gasp* Mono runs on Linux? Pandora runs Linux? *amazing*

No need to post to the Pandora dev forum for every language that exists Pandora runs Linux, your favourite language ____ has a compiler/interp for Linux, it probably could be made to work.

(Granted this OP is more about the micro framework toolkit, so is a little more on topic, but I'm referring to the 'glut' of language postings; Go, Haskell, Stackless Python, Mono for .net....

jeff

 

[Pleng]

Cripes!

So what forum would you recommend posting on if I want to know a development related question?

As I said before, MONO did not work when I tried it, and as Sindbad eluded to apps would be much bigger than needed because they would need to be bundled complete with MONO. Therefore a way to compile apps natively for Pandora with Visual Studio using the .NET micro framework would be very useful.

 

[skeezix]

Ah, see, now you've gone and made it a Pandora questrion. Just saying "they're opening the source.." doesn't relate to Pandora any more than saying "firefox got an update", and we just don't need to see that

As to mono as a interp on Pandora, then this goes back to whats been said before; if someone is common enough that everyone should have it, it can go into the device as a firmware patch; until then, best to include it in the pnd-file. Theres also some thoughts about making pnd-files that could pre-mount at device-boot and thus be available to all apps without replication, but I'm avoiding building that sort of system in until after we ship and see how much it is needed. The alternative to that is to build an ipkg tha people could run to install into firmware, short of being an actual firmware patch.

But of course, previous to that would be porting Mono and required libs to the device, which you'll probably have to wait until youve' got it in your hands (or someone else does who cares about .net); ie: I don't think any of us very few folks workign on getting the Panda software together are working on it, and of course we're very busy getting the firmware ready to ship and not worried about that

jeff

edit: I suppose I should clarify; open sourcing the micro framework has little to do with any of this; first the mono interp would need porting, and al the basic libs. IF that works, and you also needed the Micro foundation, that would have to get ported too. (I've not looked into it, but I've heard tell that they've not really open sourced enough to make it portable.. ie: it depends on a lot of other bits that are not opened, so they'd have to be patched in and so on so lots of work.)

 

[atomicthumbs]

Will I be able to program my Pandora in INTERCAL?

 

[skeezix]

Yes.

Come From
Bastard.

jeff

 

[Tenuki]

AFAIK there are two main issues (fears) regarding C#/Mono usage for development on Pandora :
1. Won't MS change their mind and forbid development of Mono. MS still owns C# and for now they are officially OK regarding Mono, but I'm not sure for now long. No one knows, but IMHO - a valid point. Hearing that they are opening some of source code sounds a bit reassuring to me.
2. Mono (as well as C#) have overhead for memory management and rest of architectural decisions. That is, it generally runs a bit slower on Windows. Yes, sometimes it can run faster, but I'm more concerned about worst case scenario. It's not an issue on PC as you rarely exploit PC up to maximum in hobby projects. So it is still a question (for me at least) how slow Mono can be on Pandora? It is practical, from performance point of view, to develop a game for Pandora?

If someone already got a real Pandora and if they did any tests, could you perhaps share your findings?

 

[Pleng]

Ah, see, now you've gone and made it a Pandora questrion. Just saying "they're opening the source.." doesn't relate to Pandora any more than saying "firefox got an update", and we just don't need to see that

I thought the line: "Does this mean it could become possible to develop Pandora applications using Visual Studio? " would have made it a Pandora questrion

As to mono as a interp on Pandora...

Ye. I'm not really interested in MONO. I liked the idea of being able to create Pandora native applications with in VB.Net as that is the only language I have a decent enough understanding of at this time. (please not this is not a call for 'you should learn x language type of posts'!)

edit: I suppose I should clarify; open sourcing the micro framework has little to do with any of this; first the mono interp would need porting, and al the basic libs. IF that works, and you also needed the Micro foundation, that would have to get ported too. (I've not looked into it, but I've heard tell that they've not really open sourced enough to make it portable.. ie: it depends on a lot of other bits that are not opened, so they'd have to be patched in and so on so lots of work.)

Thanks. That was the information I was looking for. So current belief is it's not going to be possible, as it's not actually 'open' enough for somebody to port the framework, even if somebody was interested in taking the project on.

 

[lulzfish]

I liked the idea of being able to create Pandora native applications with in VB.Net as that is the only language I have a decent enough understanding of at this time. (please not this is not a call for 'you should learn x language type of posts'!)

Well, I won't suggest any languages, then.

However, it was my understanding that .NET was completely interpreted (Microsoft calls it "managed code"), and that there was really no such thing as a .NET native application?

 

[Pleng]

hmm u may have a point there. I don't know the inner workings of .NET but yes, it does require the framework to be installed on the host OS, doesn't it? So the framework would need to be installed on the host device for the apps to work.

Bugger

 

[dflemstr]

I liked the idea of being able to create Pandora native applications with in VB.Net as that is the only language I have a decent enough understanding of at this time. (please not this is not a call for 'you should learn x language type of posts'!)

Well, I won't suggest any languages, then.

However, it was my understanding that .NET was completely interpreted (Microsoft calls it "managed code"), and that there was really no such thing as a .NET native application?

The CLI does indeed use byte code for assemblies, but it's been designed so that it's easy to JIT-compile it (it's NOT designed to be interpreted also, like the JVM BC was), so any applications deployed as CLI assemblies WILL run JIT'ed and will run as fast as native applications in practice (C fanboys, don't argue. GCC might be able to produce faster executables than the Mono/.NET JIT compiler can, but there's no real practical difference)

The Runtime is tiny (kinda), so it should be easy to bundle that with your application...

BTW, if you're referring to "native" as being able to use Windows Forms projects on the Pandora, and that they will look like they're using native widgets, then no, that's not possible, because of Microsoft's horrible design choices when designing their widget system and GDI+ (they themselves had problems because of it when designing Aero, as well, for instance, since GDI+ up to that point didn't have transparency support, and all black text rendered as transparent on Vista (so that you actually saw through the window where the text should have been) for a while because of that).

 

[Pleng]

Well I had a quick look at creating a 'new mobile device application' and they have thier own set of widgets. Would the apps look like that? Or would they look different?

The only forms components I would be using anyway would be text boxes, list boxes, and images

 

[sixstringmonk]

There is an ahead of time compiler for Mono which generates native binaries at compile time. This is what Mono for iPhone uses as JIT is not allowed on the iPhone. From what I've read, the application footprint has gotten a lot smaller as of late using this method.

 

[lulzfish]

Microsoft's idea of a mobile device is undoubtably something running Windows Mobile or Windows CE or whatever it's called.
On Angstrom Linux, all widgets will have to end up in one of the native X11 libraries (Unless you're making your own widgets in OpenGL / SDL / Cairo / whatever), usually GTK+ or Qt, occasionally FLTK or Motif or something weird like that. WxWidgets also exists, but I've never used it, and I think it's just a layer over GTK+

 

[renwils]

While on the topic of Mono...

I've heard some positive things about C#, but are there any particular advantages for someone who generally doesn't program for Windows? I understand that there are some shortcomings in Mono's garbage collection, but I'm not too concerned with stability. I've also heard concerns about patents on .NET technologies. Mainly I'm concerned about learning a platform that will end up being restrictive in the long-term. Please correct me if I'm misinformed.

 

[dflemstr]

BTW, in this post, I use a few key words:
CLI: the common language infrastructure (including the virtual machine technology, the IL assembly technology etc), for which the .NET suite of libraries was originally developed. When a C# or VB.NET or F# or J# compiles something, it creates binaries for the CLI.
.NET: A suite of libraries developed for the CLI, that only exists for the Windows platform
Mono: An open-source clone of the .NET libraries supported by Novell

While on the topic of Mono...

I've heard some positive things about C#, but are there any particular advantages for someone who generally doesn't program for Windows?

1. Portability (duh). You can write an application for Linux and it will run on Windows, Mac, Solaris, BeOS (more or less) *without recompilation*. In other words: you can deploy one zip file and it will work everywhere.
2. Libraries. The standard CLI platform (based on the .NET core libraries) is pretty extensive. You won't have to deal with e.g. STL and Boost dependencies when you program; you'll have a standardized set of libraries that just work. And any libraries that you reference (stored in .dlls for compatibility, even on Linux) will be cross-platform too, so you can include them in your distribution and won't have to compile them for every platform you target.
3. Security. There's no risk of creating memleaks or segfaults, and you can manage CLI memory in so-called "AppDomains" and can use other such facilities that give you a fine-grained control over how your application works and what can access what.

Compared to Java (and the JVM in general), the CLI is:
1. Faster, since it allows for structs (aka non-referenced classes, that are stored on the call stack) and type parameters (similar to C++ templates) using non-wrapped primitives. This doesn't sound like that much of a deal, but it really is; in Java, you have to "malloc" everything that isn't a boolean, int, float etc, while when using the CLI, you can avoid that, and in Java, you can't say "LinkedList<int>" because "int" is a primitive type (you have to use the wrapper class Integer like so: "LinkedList<Integer>").
2. Easier to develop for, since the CLI has a better dependency architecture, and because you can access native libraries directly, which you can't do in Java (you have to create intermediary helper libraries for that)
3. Not as widely supported, since the JVM is much more portable than the CLI ever was designed to be.

I understand that there are some shortcomings in Mono's garbage collection, but I'm not too concerned with stability. I've also heard concerns about patents on .NET technologies. Mainly I'm concerned about learning a platform that will end up being restrictive in the long-term. Please correct me if I'm misinformed.

Garbage collection: I don't know that much about its faults to be honest, but any issues can surely be solved.
Patents: The CLI is an accepted standard NOT owned by Microsoft in any shape or form. The only patent issue that might be problematic concerning Mono is the "System.Windows.Forms" API (and some other APIs only interesting to webapp developers), which is from the .NET library for accessing Windows widgets from managed code. Mono has created a library which is compatible with the original Windows.Forms library (in order to make porting .NET apps to Mono easier), and that library has some potential patent issues. There is therefore a "free" version of Mono (similar to the "free" version of the Linux Kernel; the vanilla Kernel does also have proprietary firmware binaries in it as you might know), from which all potentially dangerous elements have been removed. But even if Microsoft starts to complain, nothing will happen, since there's too many who are using that API already, and Microsoft will be powerless in such situations.

And if you want to avoid patent issues all together, just use the GTK# libraries, which are (you guessed it) the libraries you need to access GTK from the CLI. That'll be your choice anyways, unless you want Windows-looking widgets in Linux, of course...

 

[renwils]

-snip-

Thanks for the detailed response.