FAQ

Please see Plugs.

Cosmos is licensed under the New BSD license. Please see License

This is also a generic error in some cases. It happens every time the assembler fails to build it, e.g. Visual Studio 2015 recognizes INT16 as found, but the assembler cannot due to a missing plug

If you use the Devkit (as of 14/03/16 (dd/mm/yy)) you need to update from .NET 4.5 to 4.5.2.

Yes. Cosmos runs on real hardware (and you can debug with a serial cable) as well as Virtual PC, HyperV, Virtual Box and others. See Deployment.

We have Visual Studio integration for running using VMware and Bochs.

We supported Mono in the past and will again in the future. Currently Mono support is disabled merely as a way to focus our limited resources as Mono requires a different set of plugs.

Development has also started on using .NET Core, which is a cross-platform version of the .NET framework, and although Visual Studio is a Windows-only application at the time being, using Visual Studio Code (a cross-platform Visual Studio IDE) may be a possibility in the future.

Yes. Despite C# being in the Cosmos name, any .NET language can be used including Visual Basic.NET, F#, Delphi, Chrome and more. In fact, Cosmos will work with any .NET language that compiles to pure IL without P/Invokes. The C# refers to what we use to build Cosmos itself and is simply our personal preference of language.

Yes. Many of the developers on the team are using 64-bit Windows.

The .NET Micro Framework targets tiny devices and is interpreted. Cosmos targets both large and low resource machines and is compiled.

Some crazy eccentric developers, some high school students, university level students, a wide range of people.

Cosmos currently only runs on x86 and x64 processors. It has the capability to run on ARM and other processors as well but currently only Intel is supported.

Have a look at Features Users have produced demos that use basic networking and graphics, but the core team is still focused on kernel and debugger. When we have the foundation built to a sufficient level the core team will integrate the work of users into Cosmos itself.

To answer your question, Cosmos currently has a working VMware SVGA driver (up to 1920×1200, but only works on VMware) and a non-working-at-the-moment VGA driver (up to 320×200, wow!). A Cosmos Graphics Subsystem is in development but doesn’t work on VMWare at the time of writing, by the time you’re reading this, it might do. I don’t know 😛

Basic networking is being worked on, and our FAT drive works but has bugs.

Cosmos and Singularity have a lot in common. Singularity however is only a research project to determine the usefulness of pieces that might later be used in .NET and or future versions of Windows. Singularity itself is not intended to ship as a Microsoft supported the operating system. In March 2008 Singularity was released to the public on CodePlex. However the license is for academic use only and thus differs greatly from the goals of Cosmos. Developers of Cosmos should not look at Singularity source to avoid contaminating Cosmos and violating the Singularity license.

If you have looked at Singularity the past, you are welcome to develop on Cosmos however you must be careful not to use your knowledge of Singularity. Unless you were involved deeply into Singularity code this will likely not be a problem. If you are concerned about this, choose purposefully to develop in a different area of functionality in Cosmos.

Primarily because it’s fun. But beyond that, how else can you boot .NET on a floppy or small USB stick? Who else will try to put .NET on the Wii, OLPC, and iPhone?

We are also developing a TCP/IP stack. Imagine instead of deploying half a dozen virtualized OS’s, deploying many dozens of dedicated OS’s. One that only does DNS, a few that only do HTTP, etc. One instance, one function.

Console apps mostly for now. When we have more of the foundational pieces we will move to graphics.
A Cosmos Graphic Subsystem is in development, with it at the time of writing, is only operational on Bochs

Currently we support Visual Studio 2015 Pro/Enterprise/Community, with support for Visual Studio 2017 nearly completed. Older versions, such as Milestone 4, do support Visual Studio 2008. Visual Studio 2015 Community Edition is free and support is being developed/tested so there is not need to support Visual Studio 2010/2013 further.

This is usually caused by using HAL code (ring 1) in Ring 3, your kernel. You must make a pass over layer from Ring 3 to Ring 2 to Ring 1 to access HAL functions

Officially is it the C# Open Source Managed Operating System, but we just go by Cosmos.

In fact, the name Cosmos was chosen before any meaning was attributed to it. Later we decided by chance what the letters stood for. Thus it is also Cosmos, and not COSMOS or CosmOS.

And besides, VBOSMOS sounds stupid.

World domination of course, but until we achieve that our goals are:

A reliable OS which never hangs (of course until the hardware fails). Whichever program crashes, the OS should never hang or go unresponsive.
Very safe (safe in the sense which is free from buffer overflows, heap overflows, exploits etc.)
Drivers and programs being able to be verifiable/tested. Even the Kernel should be verifiable at a later stage (maybe using TALx86)
The LINUX of tomorrow.

Creating our kernel written in C# and our run time we will accomplish a lot of advantages respect to use the Linux kernel:

There will be only a version of Cosmos that will run on any CPU (code once run everywhere)
The OS will be safer using the Linux kernel we will expose us to all the security bug that C code has
Cosmos and the applications will condivide the same memory space using the .NET runtime to isolate processes memory. At the same time when needed a process could give the “ownership” of an object to another process directly without the need to serialization; a reference to the very same object will be used
Cosmos will permit to implement Zero Copy I/O very easily (faster web server ever?)
Using C# will permit us to code and debug using Visual Studio to debug the kernel itself
Not using the Linux kernel we do not take the dependency from others and are more free to do our choices

The goal is that Cosmos developers will never need to write assembly language. However a few of us working in the compiler and debugger areas must work with assembly language. To ease our task we have developed an HLA (High-level assembler) which uses a language called X#.

The EditorConfig project defines a simple file format for configuring common text-editor options such as indentation sizes. These configuration files are designed to sit alongside a project’s source code, allowing text editors to use the right options on a file-by-file basis. The EditorConfig project provides plugins for many common text editors, making the format fully cross-platform.

You can download and install EditorConfig support for Visual Studio here.

Make sure you have Inno setup, VMWare and that you have updated Visual Studio 2015 to Update 1 or later. The easiest way to update is to go to the build.sln and it will probably say that the project has multiple projects and give you a link which you will click. Then update VS2015 and make sure you check ALL the extensibility tools. If VMWare does not work, but it should, repair it from the setup.

The Devkit is the source code for Cosmos. You can download it from the Source Code tab to take a look or even install it. See Devkit for information on how to install it. Keep in mind the latest Devkit contains the latest code, which may be unstable or untested. If you don’t like hunting for bugs, take a look at the Devkits listed on the Releases page.

You can use Cosmos with QEMU, however we have removed specific support for QEMU because QEMU on Windows is horribly buggy and the developers being all Linux developers simply do not seem to care about the Windows distribution.

Several years ago a Windows specific bug existed and required only one line of code to change. Despite this the QEMU developers left the bug unfixed for several years, and in fact may still be unfixed.

Building QEMU on Windows manually has a lot of dependencies and is not a trivial task. One user even reported to us that the developers only test the Windows build against WINE on Linux, which has its own set of bugs and is not a good platform to test against as a substitute for a real installation of Windows.

This and other issues have caused us to simply give up on QEMU. We however have not and will not take any steps to block QEMU, but we will not make any steps to specifically support it again. If you do not want to use a virtualizer and need an emulator, we suggest Bochs instead.