OSDev.org

Hello. this may be so stupid but I really don't know the answer.
Between linux and windows, which one is the best for building a kernel?
I prefer linux cuz I have more control over the compiler and I can use a simple makefile to build and test the kernel in qemu
but in windows I have the power and beauty of visual studio and I can build the kernel by one click and create .NET apps to do that makefile job and run the kernel in an emulator and using VS is much easier than GCC. But in linux I can create grub and port compilers for my OS much easier. Please help

You are rather wrong about simplicity of windows, goodness of VS and hard way of linux.
Your words look too much like a beginner impression, so it's time to just learn the tools (linux IDEs, makefiles, python/perl/bash/etc scripting) and you'll find another picture.
I'm using cygwin but it's not the simplest way, linux is a more straight and simple way. May the scripts be with you.

That's a rather pointless question as different people have different needs. The "best" OS, for any purpose, is the one that best suits your requirements. Only you can judge that.

The most worrying aspect of the question is that you seem to be asking someone else to make the decision for you.

I would agree that using Windows for development is "easier" than Linux, for everything except OS development.

The main problem is that almost no one uses Visual Studio for OS development, which means that you aren't going to be able to find a lot of tutorials that are going to be helpful to you. Most of the walkthroughs and articles that I've seen use GCC as a standard compiler toolset.

So the question is whether you want to use GCC on Windows or on Linux. If you are more comfortable with Windows, I would stick with what you are comfortable with. However, either way, you are probably going to be spending a lot of time in the console.

Using Visual Studio for OS development is a nightmare and should only be attempted by the masochistic and those with better documentation on the internals of Visual Studio than we have.

Hello,

The reasons described for why you prefer Linux over Windows is wrong; there is nothing that prevents the use of makefiles nor QEmu under Windows (actually, it is what we use internally) and many good build systems and IDE's for Linux. I recommend to reevaluate your reasons for choosing a specific OS; I assert that there is no best host OS and recommend using a build system that can work with both. I also argue that the lack of tutorials or articles about development of operating systems under any specific host environment is irrelevant due to the developer being expected to know their tool chain inside and out.

A lot of things work directly out of the box on GNU/Linux and it's much easier to cross-compile Unox software to your OS from an Unix system. If you are serious about going self-hosting, Linux is really the superior choice.

OSX is obviously the best choice - full power of UNIX with a candy-bar beautiful UI.

MadZarx wrote: I prefer linux cuz I have more control over the compiler and I can use a simple makefile to build and test the kernel in qemu

Why wouldn't you be able to do the same in Windows or OSX?

Use the OS that you feel comfortable with.

I detest Linux, but, at the same time, I do not think you can use Visual Studio for OS development. It is intended for applications development, and, for example, the linker will insist upon linking in Microsoft's startup code. That code presupposes that it is running in a Windows environment, and, in any case, you would probably want to write your own.

If you do not want to use a Windows version of gcc, the Watcom compiler is the next most likely candidate. At the moment it is only 32 bit, but a 64 bit version is under development.

Hello,

Casm wrote:I detest Linux, but, at the same time, I do not think you can use Visual Studio for OS development. It is intended for applications development, and, for example, the linker will insist upon linking in Microsoft's startup code. That code presupposes that it is running in a Windows environment, and, in any case, you would probably want to write your own.

Visual studio can certainly be used for operating system development (it is trivial to disable the default libraries and set your own startup code), however, its use as the primary development platform is not recommended due to (1) it is closed source, (2) harder to port with other tool chains, (3) does not support the latest C standards, (4) depending on design, might be harder to manage the project.

Given the above, GCC is the better option over Microsoft's CL for operating system development. (1) can be resolved by using an open source solution (like GCC) to self host with or writing your own compiler; (2) can be resolved by using a portable build system or using your own with the use of make files, (3) The requirement to build or port an open source C run time library will rectify this one, absent of language version specific additions to the grammar which cannot be resolved without choosing a supporting compiler, (4) is dependent on the project source code management practices.

Some development efforts include utilities to generate Visual Studio solution projects as well for their operating systems (such as ReactOS). In short, we conclude that Visual Studio is a great set of tools that can be used for operating system development, however, we do not recommend it as a primary build environment. Although Visual Studio is primarily targeted for applications development use, the underlying tool chain is not.

neon wrote: In short, we conclude that Visual Studio is a great set of tools that can be used for operating system development, however, we do not recommend it as a primary build environment. Although Visual Studio is primarily targeted for applications development use, the underlying tool chain is not.

I have never yet persuaded the Microsoft linker not to link in one of their "sub systems" as they call them. Visual Studio can perhaps be used to write some of the utilities which may be needed, and maybe to testbed something like a file system.

Hello,

Casm wrote:I have never yet persuaded the Microsoft linker not to link in one of their "sub systems" as they call them. Visual Studio can perhaps be used to write some of the utilities which may be needed, and maybe to testbed something like a file system.

Sorry, however I can only assume improper use then. We have in the past used Visual Studio and have not had any issues; for both kernel and boot loader development. Several people here have; thus we can assert that it can be used.

Off topic, but addresses above:
Please note that the /subsystem flag does not link anything; it sets the subsystem field in the optional header of the PE image for the kernel loader. The linker only links the provided images given via command line; the "native" subsystem is intended for device drivers and kernel mode software and should be the subsystem set. The IDE attempts to link default libraries in all projects; the developer may specify $(NOINHERIT) in linker->Input to disable all default libraries from linking. Please reference my article on the use of the IDE for more information. The OSDev.org Wiki also provides a nice article on the use of MSVC.

neon wrote:Sorry, however I can only assume improper use then.

Tell me which switch to use, and I will use it. Default libraries are easy to disable, but the startup code is not.

Hello,

Casm wrote:Tell me which switch to use, and I will use it. Default libraries are easy to disable, but the startup code is not.

To be fair, by changing the entry point routine we effectively change the startup code that is first executed. Nonetheless, we recommend the following linker options that can be set through the IDE in order to insure the resulting image is properly built.

1. Linker > Input should be $(NOINHERIT) followed by any additional libraries to link in specific to your project.
2. Linker > Ignore Default Libraries should be Yes (/NODEFAULTLIB).
3. Linker > System > SubSystem should be /NATIVE.
4. Linker > System > Driver should be Driver (/DRIVER) due to (3).
5. Linker > Advance > Entry Point should be your real entry point routine. (Command line: /ENTRY option)
6. Linker > Advance > Base Address should be the VA of your program. (Command line: /BASE option)
7. Linker > Command Line should include /ALIGN:alignment, where alignment is the section alignment that you want unless default alignment is fine.

In any case, we are off topic. If you are interested in reading more, please review the above links provided that provide more through information on the topic in question.