14

Would it be possible to code and compile C#, on a Windows 8 Tablet (WinRT) (the ARM processor edition)?

Basically it comes down to this:

  • Is there a C# compiler that runs on ARM?
  • Is there and IDE that can run in WinRT?

If the above is true, I don't see any issue, but I currently can't find if the C# compiler runs on ARM (only a lot of posts about compiling for ARM). I've also looked at SharpDevelop, and found that their source code compiles for "Any CPU", which according to this post: Windows RT and c#, means that it'll run on ARM.

Sharpdevelop however requires .NET 4.0 "Full" runtime, which I couldn't find if WinRT has or not. I'm betting it doesn't, as WinRT is supposed to be a really lightweight edition of Windows.

As a sidenote, I know that Windows tablets will come in two editions, one for ARM and one for classic processors. The classic processors will run a normal Windows 8 edition, which means it can run all the native applications. Compiling C# wouldn't be an issue here - so the question is rather, can I do the same on ARM?

This would be awesome for travelling and trying out new ideas quickly.

Community
  • 1
  • 1
Michael Bisbjerg
  • 905
  • 10
  • 18
  • 1
    This doesn't directly answer your question, but in case you aren't aware, there is [ShiftEdit](https://shiftedit.net) – JMK Nov 12 '12 at 12:53
  • 2
    It's very unlikely SharpDevelop will work on Windows RT. For all intents and purposes you can consider WinRT a separate platform from "Windows .NET". They share a good chunk of the standard library, but if you want to make a GUI app you *have* to explicitly code against WinRT-specific APIs. – millimoose Nov 12 '12 at 12:55
  • 1
    @JMK, ShiftEdit looks awesome, I'll remember that tool. :) But yea, not what I was looking for. :P On the path of online IDE's, there is https://compilr.com/, which I'll have a look at. – Michael Bisbjerg Nov 12 '12 at 12:56
  • @millimoose, I was thinking more along the lines of console applications, and it would of course have to use the libraries available on RT (or with .NET if that's available), if it is to run on it. – Michael Bisbjerg Nov 12 '12 at 13:02
  • 2
    Even if you could you don't want to run Visual Studio or compile on a toy. Better use remote desktop and connect to a "real" computer. – Albin Sunnanbo Nov 12 '12 at 13:04
  • 2
    @AlbinSunnanbo These "toys" probably have roughly the computing power of the late Pentium IIIs that VS.NET and VS2003 ran on. It's not an unreasonable request to want to get /some/ coding done on them, and your suggestion is borderline trollish. – millimoose Nov 12 '12 at 14:03
  • 1
    @MichaelBisbjerg What I meant is that the (GUI) IDE you're looking for would have to target WinRT specifically – which is why SharpDevelop won't work – not the apps you'd write with it. (That said, those would probably have to be restricted as well, since it's unlikely a WinRT app can install a full other app. Intercepting the console output of another process might be doable though.) – millimoose Nov 12 '12 at 14:05
  • I just checked a Win8 RT tablet (Snapdragon processor), and I was able to navigate into the .NET folder using the desktop. The folder had the csc.exe file needed, and it then requested source files to compile. My initial verdict is that, given enough time (touch keyboard and all), I'd be able to code a test app, compile it, and run it... All on the tablet. All that's needed is then the IDE. – Michael Bisbjerg Nov 12 '12 at 15:52
  • I was going to suggest the `Microsoft.CSharp` namespace (http://msdn.microsoft.com/en-us/library/microsoft.csharp.csharpcodeprovider.aspx) but you seem to have already found an answer. IMO compiling to C# is a given, though compiling to run a non-WinRT executable is not likely. – Trisped Nov 12 '12 at 18:13

3 Answers3

6

Currently: no, and no.

It would certainly be possible to build a Windows Store app that contains an IDE and a C# compiler. However, you would not be able to run any programs built using such an app. Windows Store apps run with reduced privileges in a sandbox. In this sandbox, the CLR will only load system assemblies and assemblies contained in the app package. The app package is immutable and cannot be modified at runtime.

James McNellis
  • 348,265
  • 75
  • 913
  • 977
  • So reflection is crippled (no support for dynamic codegen) when using .NET in a WinRT/Store context? I suppose you could still take the output and upload it somewhere, then install/update the newly-generated app package from there using the Store. – Ben Voigt Nov 12 '12 at 18:09
  • @BenVoigt: There is no support for dynamic codegen, Reflection::Emit is not supported, System::Assembly::LoadFrom is not supported (really, none of the Load methods are fully supported). In native code, LoadLibrary and VirtualAlloc/VirtualProtect are not supported. You could use a second PC running Windows 8 (on x86 or x64), and somehow communicate with that machine and get it to deploy the new app onto the ARM device. But then, if you do that, what's the point of building the app on ARM in the first place? (i.e., why not remote into the x86/x64 machine?) – James McNellis Nov 12 '12 at 18:26
  • So what happened to framework classes that generated code at runtime, like XML serializers? Just not available? And Microsoft .NET will be the only JIT ever supported (because Java/Python/Flash/whatever runtime can't generate code and the run it)? – Ben Voigt Nov 12 '12 at 18:29
  • @BenVoigt: XmlSerializer is supported. Policy restrictions apply to user assemblies, not to framework assemblies and platform components. – James McNellis Nov 12 '12 at 18:33
  • So the app you describe could go through some process to become a platform component, just like a hypothetical third-party Python JIT? Or third-party JIT is totally banned? – Ben Voigt Nov 12 '12 at 18:34
  • @BenVoigt: Sorry, I didn't see the edits to your comment. My understanding is that VirtualAlloc and friends are necessary and essential for building a JIT, so I don't see a way for a third party to build a JIT that would pass Windows Store approval ([you can call non-approved functions](http://seaplusplus.com/2012/06/25/printf-debugging-in-metro-style-apps/), but an app that does so won't pass Store certification). I don't know what Windows's long-term plans are concerning this. – James McNellis Nov 12 '12 at 18:38
  • So a development environment (or third-party JIT) could use those APIs as long as it is side-loaded? That seems like a small hurdle for a developer. – Ben Voigt Nov 12 '12 at 18:41
  • Yes, with the caveat that any calls to non-approved APIs formally yield undefined behavior. Calls may produce unexpected results or may fail to work correctly, and any update to Windows might change the behavior. The APIs are entirely unsupported for Windows Store apps. I'm happy to advocate use of such APIs for testing and debugging, but I'd be very hesitant to recommend their use for long-term, production use, even in a sideloading or development environment. – James McNellis Nov 12 '12 at 19:09
  • Oh. That does change things. I thought maybe they were documented but intended for use by the hardware integrator. – Ben Voigt Nov 12 '12 at 19:12
  • Yeah. The documentation has been updated to indicate which APIs are supported in which environments. For example, in the "Requirements" section of [the VirtualProtect documentation](http://msdn.microsoft.com/en-us/library/aa366898.aspx), the Minimum supported client is "Windows XP [**desktop apps only**]". [the OutputDebugString](http://msdn.microsoft.com/en-us/library/aa363362.aspx) documents say "Windows XP [**desktop apps | Windows Store apps**]." If the documentation doesn't say that an API can be called from Windows Store apps, then doing so is unsupported. – James McNellis Nov 12 '12 at 19:17
  • That leaves open the question of where sideloaded apps fit in. They aren't either desktop apps or Windows Store apps. They're Windows-Modern-UI apps outside the store. (And I suspect hardware manufacturers will have quite a few of them) Personally, I'm sticking with desktop apps until all of this gets sorted out (I tend to need low-level platform APIs to talk to peripheral devices). – Ben Voigt Nov 12 '12 at 19:24
  • Sideloaded Windows Store apps are still Windows Store apps, even though they are not distributed through the Windows Store. When the API documentation refers to _Windows Store apps,_ it means _formerly-known-as-Metro-style apps_, not _apps distributed through the Windows Store._ At least, that's what it means most of the time. This is all very confusing. – James McNellis Nov 12 '12 at 19:41
1

Actually, the .Net framework on the surface includes csc.exe, the Csharp compiler. I've gotten code to compile, but WinRt doesn't seem to like it being run without proper signing.

The IDE won't happen for a while, not yet at least. I'm sure that with proper signing, it is possible to run a compiled executable.

Or the other guy might be right and it isn't just an issue of signing.

violet_white
  • 404
  • 2
  • 15
1

I've ported SharpDevelop to run on unlocked Windows RT devices, it works at least for C# Windows Forms apps. http://chentiangemalc.wordpress.com/2013/03/18/sharpdevelop-rt-edition-beta-code-windows-forms-directly-on-windows-rt/

Malcolm McCaffery
  • 11
  • 1