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.
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
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'.
I learned windows programming using Visual C++, and the Win32 API. Nowadays, it seems most apps are being developed in .NET using C#. I understand that most of the time there isn't much performance difference between native code and managed code. So I'm wondering, if I were to start writing a new desktop app today, is there any reason (other than the fact that I'm more familiar with C++), that I might want to write it in non-managed C++ instead of .NET? Are there still some advantages to using C++ and native code? Or has that method been more-or-less replaced with .NET on the Windows platform?
Of course I know that people who are writing low-level device drivers and similar programs wouldn't do it in .NET. I'm asking with reference to typical client-facing apps that don't make direct hardware calls.
IMO the most important one for small downloadable applications is that native code does not need the .NET runtime. While broadband becomes more and more common not nearly everybody has it yet.
Some people may be disappointed to see that your 2 MB application actually requires another 20MB of framework download and a bothersome installation process to run. If they are not sure whether or not they really need your application in the first place, they might just delete it before even giving it a try and turn to a competing product.
Performance (certain situations, such as graphics)
Memory footprint (as Mancuso said)
Use of existing libraries
No need for a runtime
Finer control
To list a few.
However, you may also want to look at the question from the opposite angle to fairly evaluate which language to use.
Additionally, you could use C++/CLI to incorporate both native and .net code.
If your application needs to be able to run without an installation (i.e. if you can't or shouldn't do something like install the .NET framework), you can't count on .NET being on a windows machine (pre-Vista). Lots of utility applications can fall in this category.
I would recommend to write every desktop application in managed code. .NET/C# is a great platform to do so.
My reasons:
Performance penalty is negligible. Google for benchmarks if you don't take my word. What matters more is the code itself. You can write O(n^m) algorithms in C++ or .NET/C#. JIT engines are very mature these days.
Unmanaged C++ has major drawbacks when it comes to unit testing, mocking and refactoring. It's very cumbersome and inflexible. Reflection allows managed code to make such things very convenient.
Deployment is a small issue. However, creating a setup which checks for the necessary .NET preconditions and installs them automatically is a no-brainer.
Compilation is quicker, no linker! It even happens in the background when you edit the code.
.NET library support is way better and cleaner than STL, MFC and boost.
No header files and macros. They are just error prone.
Security! Good bye buffer overflows, bad pointers, uninitialized variables...
Exceptions. Clear exception hierarchy in .NET. C++ exceptions are messed up.
Memory footprint. But unless you're developing for a severely handicapped machine memory-wise, it really shouldn't be an issue for most applications.
If you can afford the dependency on the stack, go for .NET
Modern, elegant, powerful and as a result much quicker to develop for.
But realize that you chain your app to it - to the language and the framework, if you forsee a future where you may want to escape this, then better think twice.
Win32 is old and clunky, but it works on virtually any Windows version without extra dependencies, and your code can be in plain, portable, C/C++.
+1 for not having to require a .NET package/install on the target machine(s). This is still a big issue.
When all machines have mono or NET it won't be such a big deal.
Two things that I can think of.
Protection of intellectual property. It's infinitely harder for someone to reverse engineer an Unmanaged C++ app. Managed .Net or Java apps can be easily de-compiled this is not the case with Unmanaged C++.
Speed. C++ is closer to hardware and has a smaller memory footprint as the other comment mentioned. This is why most video games continue to be written in C++ and inline assembly.
.Net programs also have a support lifetime, where native do not really. Native will run for many years across different OS's without requiring updates.
.Net programs can be hosed by bad .Net configuration, native just keeps on running and is hardly effected by OS updates.
.Net programs startup slow and feel sluggish, native starts quick and runs quick.
.Net has to be coded for lowest common denominator (most distributed framework version), Native compiles all code into application - so use what you want.
Use Delphi for Native, not C++. .Net is partially based on Delphi RAD and Java backend.
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 ......