The question says it all. Can I compile C# to native code and boot it? I know of Cosmos and Singularity, but I was wondering if there are more recent techniques or tools. Thanks.
Apparently you can compile to native code using Mono:
http://www.mono-project.com/Mono:Runtime#Ahead-of-time_compilation
Still, you won't be able to write an OS with that. Its impossible to write an entire OS in C#, Cosmos and Singularity will have portions that aren't managed code.
Or of course, you can set your code to boot at Windows Startup - .NET applications will run just fine once Windows has booted up to the login screen and beyond.
What exactly do you mean by "boot it"... If you mean "boot on a machine as an OS" you would need to set up a bootloader and re-write most of the c# functions yourself. You would also have to set up all the machine-specific features from a lower-level language (assembly/c[++]/etc). Basically, there's no way to have it boot by itself without a significant amount of work.
One option would be to author a windows service that is set to start with the system. I believe there are other ways to accomplish this but this maybe 'the easiest'.
Related
I hope that question would not mess with StackOverFlow FAQ rules
So ,when using Libraries which are written in C++ for example ,and that means we have some Code in these DLL's which is going to be executed ,when Software execution cames in that case ,will this Portion of code be executed by CLR ?
I need that because we plan to develop a Software and some Angry Algorithms i think will be better to program them in C++ ,but Visual C# serves us some tools that we cant find in c++ (Linq ,Anonymous etc) .
You can use DLLs created in C++ inside your C# project, and as you already know you have to make an interop call. This switches context to unsafe, so the code is probably executed outside the CLR. This means that you lose the portability options the CLR gives you. For example a C# based app would run on Windows and Windows Phone, but adding interop calls will only make it work on Windows (or whatever system the DLL was compiled for).
But normally this isn't much of an issue.
Also see this thread: http://forums.devshed.com/net-development-87/using-a-c-dll-in-c-107829.html
I was reading about Singularity and it was developed in part with C#, but how can I develop a operatin system in part with C#?(because the boot loader needs to be in Assembly, that I know) the thing that I want to know is where to start(tutorial, library...)?
PS: Congratulations to the Singularity developers, very nice job! ;)
Renraku is an open source project to create an OS using .NET technologies as much as possible. This post has a link to the source on GitHub.
Just because you write your program in c# it doesn't have to be compiled to IL. Writing a c# to machine code compiler can be done and last time I saw an OS written in C# that was exactly what they had done
The major difference between an operating system that runs on managed code vs. one that runs directly on machine code is really nothing more than having a byte-code interpreter at a very low level that processes all byte code sent to it and translates to the corresponding machine code. Once that exists, the various operating system components would be implemented in pretty much the same way as they would in a traditional OS.
I have searched quite a lot of places and I only found one GINA replacement called pGINA but it is in C++ which I don't know at all.
Does anybody know one in either C# or VB.NET?
(I'm writing software for use at work to control what employees are doing)
Hosting .NET in Winlogon (where GINA dlls are loaded) is probably not such a hot idea- could cause all sorts of conflicts if something else decides to do the same thing, and if you trash winlogon, you're not getting anywhere with that PC. Also, GINA has been replaced as of Vista with ICredentialProvider (see here)- so your investment would be lost as soon as you move to a newer OS. Even there, the same thing applies: custom credential providers are loaded into Winlogon, so probably not a great idea to use .NET there.
Regardless, both of these are intended to support custom authentication modules, not "controlling what employees are doing". There are other ways to run software on the logon desktops, if that's what you're trying to do.
All that said, if you still want to try it, you'll need an unmanaged shim DLL, C++/CLI or some IL hacking (see here) to export the GINA functions because C# can't directly export DLL functions. A pure managed C# solution isn't possible.
To expand on nitzmahone's eexcellent points:
Completely replacing GINA is really a no-no using managed code. OTOH, it is quite possible to write a replacement GINA in C++ and have it call .Net code to do the grunt work.
Some years ago I used this technique to replace the CTRL+ALT+DEL screen with a fancy news service. My custom GINA was a proxy for the standard GINA. Most of the time it transparently passed calls on to the standard GINA. The exception was that it ran the .exe for the .Net app instead of displaying the ALT+DEL+CTRL screen, then waited for the .exe to terminate before displaying the logon screen.
With regret, I abandoned the project when it was clear that the work could not be directly applied to Vista.
Is there any work being done to create a C# compiler to produce native exe's? e.g. the output is a native exe and NOT a .NET assembly.
Why don't you try NGen. For exemple Paint.NET use nGen to create native images after installation.
If you want a standalone deployment (i.e. without needing the framework), there are a few options - see here. However, I'm not aware of anything that will reliably produce purely unmanaged code. What is the use-case you have in mind? For embedded etc there is micro-framework, CF, etc.
There is such solution for Mono, this is 'mkbundle' - static linking instead of using JIT/CLR/GAC, I guess
You'd still have to provide the libraries in some form so either you'd still have to have a runtime installed, or the native exe would have to be huge.
There are two active projects. They are geared toward CIL-based operating systems, but the current iteration of MOSA Compiler Framework runs on Windows (unit tests etc.) and has limited boot support. Cosmos used to have a Windows architecture and a few plugs, but they don't do Windows any more - only booting into a CIL environment.
Cosmos is much futher along however, they have pretty much nailed object support. MOSA is only bare-metal (static methods) for now - although it is done the 'proper' way and well unit-tested (and I think making faster progress). Give it a few more months and then go back and have a look.
Niether has a JIT at the moment (which doesn't matter since you don't want one). It is all compiled to machine code ahead of time.
MOSA (Compiler Framework)
COSMOS (IL2CPU)
.NET linker
You might find this interesting to read as well: .NET Internals and Native Compiling.
Note that for the reflection to work a lot of information about the code will always have to present.
Before I jump headlong into C#...
I've always felt that C, or maybe C++, was best for developing drivers on Windows. I'm not keen on the idea of developing a driver on a .NET machine.
But .NET seems to be the way MS is heading for applications development, and so I'm now wondering:
Are people are using C# to develop drivers?
Do you have to do a lot of API hooks, or does C# have the facilities to interface with the kernel without a lot of hackery?
Can anyone speak to the reliability and safety of running a C# program closer to Ring 0 than would normally be the case?
I want my devices to be usable in C#, and if driver dev in C# is mature that's obviously the way to go, but I don't want to spend a lot of effort there if it's not recommended.
What are some good resources to get started, say, developing a simple virtual serial port driver?
-Adam
You can not make kernel-mode device drivers in C# as the runtime can't be safely loaded into ring0 and operate as expected.
Additionally, C# doesn't create binaries suitable for loading as device drivers, particularly regarding entry points that drivers need to expose. The dependency on the runtime to jump in and analyze and JIT the binary during loading prohibits the direct access the driver subsystem needs to load the binary.
There is work underway, however, to lift some device drivers into user mode, you can see an interview here with Peter Wieland of the UDMF (User Mode Driver Framework) team.
User-mode drivers would be much more suited for managed work, but you'll have to google a bit to find out if C# and .NET will be directly supported. All I know is that kernel level drivers are not doable in only C#.
You can, however, probably make a C/C++ driver, and a C# service (or similar) and have the driver talk to the managed code, if you absolutely have to write a lot of code in C#.
This shall help you in a way: Windows Driver Kit
It's not direct answer to your question but if you're interested you might look at Singularity project.
Can anyone speak to the reliability and safety of running a C# program closer to Ring 0 than would normally be the case?
C# runs in the .NET Virtual Machine, you can't move it any closer to Ring 0 than the VM is, and the VM runs in userspace.
If you're willing to have a go at a proprietary framework, Jungo's WinDriver toolkit supports user-mode driver development (even in managed code) for USB, PCI, and PCI-E devices.
Microsoft has a number of research projects in the area of having a managed-code OS, in other words kill with Win32 API.
See Mary Jo Foley's article: Rebuilding a Legacy
Writing device drivers in .net makes no sense for current versions of windows.
<speculation>
Rumors are that MS is investing a lot of money in bringing Singularity to the next level. Just look for Midori. But that's 2015+
</speculation>
If I remember it correctly, the Dokan Project is a user-mode file system driver, which also allows .NET code to be executed by a system driver: https://github.com/dokan-dev/dokan-dotnet.
So, you could develop a C# "driver" (user-mode application really), which is then called/invoked by a C++ kernel-mode driver. The kernel-driver could simply pass everything along without manipulating the data and act as a simple wrapper.
Needless to mention, that it is very unsafe and you would most likely end with a BSOD (I tried it).
Mildly related:
The Cosmos Project is an open-source Operating system, which is developed in C# and runs
"(kernel) drivers" and user-level applications written completely in C#/F#/VB.NET/...
Though these are technically kernel-level drivers, the OS is no longer Windows but your own, so I guess that this is not a correct answer ......