OSDev.org

Hello guys! I am relatively new to OS development... There's one question I would like to ask... I own the Visual Studio 2008 Professional edition since I've been programming C++, DirectX/Win32 applications, static, dynamic libs and such stuff.... I've been wondering about something and it's not clear to me... Since everyone recommend compilers such as DJGPP, I was wondering... Is it possible to develop parts (of course) of the OS within the Visual Studio's IDE... Of course, full native code, ANSI/ISO.

Thanks in advance!

It is possiblel to develop an OS on VS, even only with it. If you want to know more look here http://www.brokenthorn.com, there is a toturial how to make am OS with Visual Studio.

There's also something about it on the wiki. Note that there are limitations to the VC++ compiler and linker (the COFF/PE output format limitation) and I believe there is some restriction about OS' in the MASM (Microsoft assembler which Visual Studio uses to assemble ASM files) license, but I'm not sure though.

If the compilers don't work out for you, remember that Visual Studio has a nice flexibility in rules. You could add your own build rules that use the MinGW compiler and linker with the NASM assembler for example. Another benefit is that you can set up Visual Studio with your OS so that you merely have to press the build button and your entire OS is built or the debug button to build your entire OS and start QEMU/Bochs with it for example.

There is a difference between the application used to compile your OS (generally cygwin), and the application used to write the code in (which can be anything, including Visual Studio)

Microsoft's compiler can be used for OS development, but it's not recommended.

Combuster wrote:There is a difference between the application used to compile your OS (generally cygwin), and the application used to write the code in (which can be anything, including Visual Studio)

Microsoft's compiler can be used for OS development, but it's not recommended.

I'm just curious, but why is it not recommended? I develop my OS with it, and I haven't had any problems (other than the obvious "oh noes, MS toolchain can't do the ELF format" thing, but that doesn't count as a problem for me).

ru2aqare wrote:

Combuster wrote:There is a difference between the application used to compile your OS (generally cygwin), and the application used to write the code in (which can be anything, including Visual Studio)

Microsoft's compiler can be used for OS development, but it's not recommended.

I'm just curious, but why is it not recommended? I develop my OS with it, and I haven't had any problems (other than the obvious "oh noes, MS toolchain can't do the ELF format" thing, but that doesn't count as a problem for me).

For one thing it's not portable. If you ever have a team of OS developers where some of them work on Linux, they'll have to rewrite the code because the code you write will only be VC++-compatible. So they'll have to use GCC or another compiler either way. If you never work in a team however, that's not a problem.

Creature wrote:For one thing it's not portable. If you ever have a team of OS developers where some of them work on Linux, they'll have to rewrite the code because the code you write will only be VC++-compatible. So they'll have to use GCC or another compiler either way. If you never work in a team however, that's not a problem.

Well I guess I have to install GCC and check this portability thing out, though I try not to use VC-specific features... However the same can be said of code written for GCC, some sources contain a lot of GCC-isms (for example, __attribute__), and I don't think that is portable.

ru2aqare wrote:

Creature wrote:For one thing it's not portable. If you ever have a team of OS developers where some of them work on Linux, they'll have to rewrite the code because the code you write will only be VC++-compatible. So they'll have to use GCC or another compiler either way. If you never work in a team however, that's not a problem.

Well I guess I have to install GCC and check this portability thing out, though I try not to use VC-specific features... However the same can be said of code written for GCC, some sources contain a lot of GCC-isms (for example, __attribute__), and I don't think that is portable.

Yes, that's true , but they assume everybody uses GCC!

Creature wrote:

ru2aqare wrote:

Creature wrote:For one thing it's not portable. If you ever have a team of OS developers where some of them work on Linux, they'll have to rewrite the code because the code you write will only be VC++-compatible. So they'll have to use GCC or another compiler either way. If you never work in a team however, that's not a problem.

Well I guess I have to install GCC and check this portability thing out, though I try not to use VC-specific features... However the same can be said of code written for GCC, some sources contain a lot of GCC-isms (for example, __attribute__), and I don't think that is portable.

Yes, that's true , but they assume everybody uses GCC!

Meh, in my kernel, I have things like #define __malloc __attribute__((malloc))

Then I have further checks for GCC, PCC, etc, and their versions, which #define away __attribute__ entirely if it's not supported. All the code is written using __malloc, __noreturn, and things like that, and #defined as appropriate by the pre-processor come compile time. I find that correctly handles the case of specifics not being supported by one compiler (usually PCC) while it is supported by another (like GCC). The resulting binary isn't much different, and it really shouldn't result in different behavior either wrt bugs in the code but it may result in more or less warnings during compile, shorter or longer compile times, and faster or slower running code.

I also find this keeps the code internally clean and consistent, with the only parts that may not be all that easy to follow are the header files that handle all the pre-processor magic to eliminate the unsupported code.

This is why in any medium sized project (100+ kloc) or larger that require portability as a requirement needs to be designed to provide an abstraction of compilier dependencies. Most larger projects that I have seen and worked with provide a basic set of preprocessor constants and names used just for this purpose and allows you to hide compilier dependencies behind a common interface and make build envirements more portable.

In other words, any project properly designed written using MSVC++ dependencies can be compilied to run under GCC through a common interface. (In the case of OS development, however, keep in mind the basic CRT startup code will also be different.)

neon wrote:(In the case of OS development, however, keep in mind the basic CRT startup code will also be different.)

CRT? Aren't most (if not all) kernels compiled standalone (meaning CRT isn't used)? I know all the tutorials I've read do it that way.

JohnnyTheDon wrote:CRT? Aren't most (if not all) kernels compiled standalone (meaning CRT isn't used)? I know all the tutorials I've read do it that way.

Not quite. CRT does not necessarily mean the CRT used by default for the compilier. It can also be your stand alone CRT which may be used fine for kernels and other system software components. (Example of usage: my (real) system and WinNT/2000 kernels).

Oh, you mean the CRT you create yourself will be different depending on the compiler. Understood.

Creature wrote:I'm just curious, but why is it not recommended? I develop my OS with it, and I haven't had any problems (other than the obvious "oh noes, MS toolchain can't do the ELF format" thing, but that doesn't count as a problem for me).

For one thing it's not portable. If you ever have a team of OS developers where some of them work on Linux, they'll have to rewrite the code because the code you write will only be VC++-compatible. So they'll have to use GCC or another compiler either way. If you never work in a team however, that's not a problem.

You can recompile GCC (and many other open source compilers) for your own OS. You cannot however recompile visual studio.
Then there's that awkward MASM license (making osdev with it illegal).

Then there's that awkward MASM license (making osdev with it illegal).

Seriously? How did they manage that one?