C Compiler Choices

[Antony]

I made this a separate thread only because I think we will need to have a series of discussions around the process.

The FreeDOS reference C compiler is supposed to be Watcom C, but most of what was written in FreeDOS is still built with Borland toolsets (Borland/Turbo C++ 3, maybe 4.5 for Windows). Some tools were written in Pacific C, a few in Watcom, and some in various other languages, as is the norm for DOS. NightKernel won't be as flexible because those compilers for the most part only target 16-bit real and protected mode output. Borland C++ 4.5 targets Windows and OS/2 32-bit but with it being so old, it's probably not worth the effort to strip it down for the kernel.

Watcom has the sources for its compiler publicly available and I believe with the license, a derivate work can be made of the compiler. I'm not sure how much bootstrapping and configuration it would take to add NightKernel as a target. The one benefit of OpenWatcom is that on top of having the DOS API (and multiple targets and environments to build in) it comes with an assembler that is very MASM compatible (much to the dismay of all the NASM code written so far), however, you have a complete end to end development tool for both NightKernel and FreeDOS (it may take some massaging of the C code and makefiles to rebuild totally in OpenWatcom, but that's another topic).

GCC has an advantage and a disadvantage. Its main advantage is that it can build itself, which means using GCC, we can build a GNU development toolset specific for NightKernel. The cool thing about GCC is we can set the output format of elf, win32, and a few others that escape me at the moment. That is a good thing because pretty soon the code base is going to need to move from flat binary to relocatable code. The portable executable format is the standard for EFI and is analogous to ELF (in Linux) and Mach-O (MacOS). The build environment tools would be similar to what is available in 

GCC's disadvantage is that it can't compile real mode code, even DJ Delorie (DJGPP) had difficulty building a 16-bit real mode version. This means that anything that we needed to do on the 16-bit DOS/FreeDOS side would require a separate compiler. 

[Maarten Vermeulen]

One problem with ELF though... The FreeDOS kernel loads raw binary files, which ELF isn't. You actually need to load (or read) some ELF specific headers. Which would mean writing a second stage raw binary bootloader that can be loaded by FreeDOS and can load ELF, or rewriting the bootloader of FreeDOS.

For example, Bird OS (which uses ELF) can't be loaded by the FreeDOS loader.

There are no advertisements in this reply.........................................................................................................................................................................................

[Antony]

FreeDOS can't load Windows PE files either. It just so happens that Windows PE files have a MZ EXE stub attached to them. 

However, FreeDOS wouldn't be loading anything. NightKernel is supposed to replace the FreeDOS kernel and then run it inside a VM86 instance (at least that's what Mercury said) 

[Mercury Thirteen]

On Wednesday, August 1, 2018 at 7:01:35 PM UTC-4, Antony wrote:

FreeDOS can't load Windows PE files either. It just so happens that Windows PE files have a MZ EXE stub attached to them. 

However, FreeDOS wouldn't be loading anything. NightKernel is supposed to replace the FreeDOS kernel and then run it inside a VM86 instance (at least that's what Mercury said) 

Right! At least... that's the plan lol

From everything I've researched, it should work since that's basically exactly what early versions of Windows did back in the day. Granted, they didn't use a copy of the DOS kernel since they had their own DOS compatibility layer (and eventually Night will too) but in the beginning, this will probably be the quickest way to get DOS apps up and running on Night. Then, little by little, Night will gain the functions necessary to eliminate the need for the FreeDOS kernel altogether and will translate DOS calls directly.

[Antony]

Hi,

Once the flat binary kernel loads, ELF support would be built in

-Tony

[Mercury Thirteen]

Just to clarify, by "ELF support" you mean that we would be able to add code to the kernel in ELF format, not that the kernel would suddenly support running ELF-format applications, right?

[Antony]

The kernel can support whatever we build it for. To load ELF applications, we have to load and relocate code. Most code in ELF format is typically in Linux so to run Linux applications, but the kernel itself if built in ELF format would provide all the benefits of the ELF format. 

-T

[Antony]

This is what happens when you don't get much sleep...

[Mercury Thirteen]

I know that feeling lol

[Antony]

The assembler has been settled, I really see no need in moving a bunch of code from NASM to WASM or JWASM just to write to Microsoft's assembly style, so I guess if you're considering C again, are you leaning towards OpenWatcom or GCC?

-T

[Mercury Thirteen]

I know Watcom is the reference compiler for FreeDOS, but I would personally prefer GCC. It's standard on most every Linux machine these days (I think) and it's actually more "free" than Watcom is.

[Antony]

Hi,

Here's the information on building a GCC toolchain for the OS

https://wiki.osdev.org/OS_Specific_Toolchain

-T

[L Michaels]

On Tuesday, July 31, 2018 at 4:32:04 PM UTC-4, Antony wrote:

GCC's disadvantage is that it can't compile real mode code, even DJ Delorie (DJGPP) had difficulty building a 16-bit real mode version. This means that anything that we needed to do on the 16-bit DOS/FreeDOS side would require a separate compiler. 

Don't know if it would be of any use, but ELKS is using gcc in 16 bit mode:

https://github.com/tkchia/gcc-ia16 

Might be a useful starting point.

[Mercury Thirteen]

Thanks!

By the way... welcome to the forum! :)