Osdev with MinGW

[xardias]

Hello,

i was using DJGPP for compiling my little kernel until now. But it is really slow and i want to use MinGW now. But i cant find any working example code with compilation instructions that works. I am experimenting the whole day now and nothing works. I get my own kernel compiled and linked, but it does not boot.

Maybe someone knows a tutorial or a sample code that uses MinGW as compiler instead of DJGPP ?

[Pype.Clicker]

there are several issues with MingW for osdev'ing. You should *really* consider using cygwin instead.

[xardias]

well, i finally got it. i dont know why my linker had crashed with an assertion error, but now it works!

But now i want to do something... sick *g*
I Heard, that someone uses vc7 to compile his cpp files ans linkes them with MinGW (because the vc7 linker puts his whole ms stuff inside the binary)

Well i want to link vc7 .obj files with my binary. MinGW does really accept them, but all funktions of the obj stay unresolved.
Any idea how do get them linked together?

[Perica]

..

[xardias]

Perica:
The issues i found out:
- you have to define __alloca and _main or MinGW will not link it.
- the linker crashes here, when i want to get the CTOR and DTOR list.

[Chris Giese]

>In a nutshell, what are the issues ?

MinGW is a 10+ megabyte download and, like CygWin, now requires a helper DLL (MSYS-1.0.DLL). So it's no longer "minimal".

MinGW 'make' uses 'sh' as the shell if it finds 'sh' on the path. This is the Wrong Thing. DJGPP 'make' works better: it looks at the SHELL and COMSPEC environment variables.

'strip' changes the file alignment. This will make a Multiboot-kludge kernel unbootable.

(GCC 2.95) "ld -r -d ..." doesn't get rid of all the common variables.

(GCC 2.95) BSS size is stored in the wrong location of the section header, so MinGW does not correctly interoperate with NASM.

"ld -Ttext=NNN ..." doesn't put the .text section at the correct address unless you also use the "--image-base=0" option.

Linker claims to support ELF, but says "PE operations on non PE file" if you try to use ELF.


I tip-toed around the bugs and got my kernel to build with MinGW: http://my.execpc.com/~geezer/os/index.htm#borealis

[Love4Boobies]

Not trying to be a necro or anything, but here's where MinGW's page on the wiki leads. I'm not sure if any of the reasons we give for MinGW not being a good choice in OSDev'ing is still true. We only mention antique versions of MinGW there and much has changed since. It's time to update. I'll check the current standard toolchain. What are your oppinions on MinGW?

[Creature]

Before I switched to a cross-compiler with Cygwin, I used MinGW and before that DJGPP. The reason I switched to DJGPP is that DJGPP wasn't too keen of my C++ code and I really wanted C++ with which MinGW seemed to perfectly agree . I had to do some strange changes though. I had to:

• Let NASM assemble my ASM files as ELF format.
• Tell the MinGW linker that I wanted x86 PE format files.
• Pass the ELF assembly files and the PE C++ object files to the linker together.

Strange as it may sound, it worked perfectly! Then I switched to a cross-compiler and set everything to ELF. You might also want to know that MinGW uses GCC 3.4.5 (?) which is a pretty old version since the latest GCC release is 4.3.3 (?) at the time of writing this post. Another reason to create a cross-compiler .

[Love4Boobies]

There's also a 4.3.0 binary for GCC in MinGW's download section so you can get that if you're too lazy to make a cross-compiler yourself.

[Combuster]

both MinGW and Cygwin still target Windows and thus come with builtin stuff. A crosscompiler has no knowledge of the platform stuff and therefore it will be better (independent of mingw improvements).

[kerravon]

>In a nutshell, what are the issues ?

MinGW is a 10+ megabyte download and, like CygWin, now requires a helper DLL (MSYS-1.0.DLL). So it's no longer "minimal".

I have produced my own gcc 3.2.3 build for Windows, and it is minimal (relying only on msvcrt.dll). It's a single executable - gccwin.exe and now written in pure C90 (so no fork() etc), and as such, you are required to do separate assembly and link steps yourself (ie just use a makefile - and I provide pdmake for that purpose too).

I developed this for my own OS for a reason, and that reason may apply to others too - I want to run gccwin, plus my own msvcrt.dll, under my own Windows-compatible OS. For people who wish to produce "yet another Windows clone" instead of "yet another Posix OS".

The Wiki led to this thread for mingw and I'm wondering whether I should update the Wiki to mention the above alternative which is available from http://pdos.org

Any thoughts?

[nullplan]

I have produced my own gcc 3.2.3 build for Windows,

So, fittingly for a necropost, you resurrected an old compiler. You do know the current version is GCC 10 or something, right?

It's a single executable - gccwin.exe and now written in pure C90 (so no fork() etc), and as such, you are required to do separate assembly and link steps yourself (ie just use a makefile - and I provide pdmake for that purpose too).

Chaining together compiler, assembler, and linker is supposed to be the one job of a compiler driver. You have stripped out so much stuff from gcc that it ceases being useful.

For people who wish to produce "yet another Windows clone" instead of "yet another Posix OS".

Windows IS a POSIX OS, with the notable omission of fork(), but then, I am trying to build my own OS like Linux but all the BS removed, and it is not going to have fork(), either. In any case, Windows does have subprocesses and pipes, even if they work a little differently.

In any case, you shouldn't necro. This thread is old enough to buy beer in Germany, and even the most recent resurrection is no longer allowed to bike on the sidewalk. Just make another topic.

[kerravon]

I have produced my own gcc 3.2.3 build for Windows,

So, fittingly for a necropost, you resurrected an old compiler. You do know the current version is GCC 10 or something, right?

Sure, and the latest version isn't even written in C. Useless for me. I have enough trouble just supporting C90. When C90 is working to my satisfaction on all my environments, I'll maybe look at other languages.

It's a single executable - gccwin.exe and now written in pure C90 (so no fork() etc), and as such, you are required to do separate assembly and link steps yourself (ie just use a makefile - and I provide pdmake for that purpose too).

Chaining together compiler, assembler, and linker is supposed to be the one job of a compiler driver.

Says who? You can't do complicated stuff like that in C90. C90 exists for a reason. There are limits to what you can do on some environments. What system() does is "implementation defined". fork() doesn't exist at all.

You have stripped out so much stuff from gcc that it ceases being useful.

It is totally useful. It actually works on my OS. No other version does, and good luck trying to get another (more complex) version to work.

For people who wish to produce "yet another Windows clone" instead of "yet another Posix OS".

Windows IS a POSIX OS, with the notable omission of fork(), but then, I am trying to build my own OS like Linux but all the BS removed, and it is not going to have fork(), either. In any case, Windows does have subprocesses and pipes, even if they work a little differently.

PDOS/386 doesn't have any of that, but it will run gccwin, a perfectly valid Windows executable that should work on everything from Win 95 on.

In any case, you shouldn't necro. This thread is old enough to buy beer in Germany, and even the most recent resurrection is no longer allowed to bike on the sidewalk. Just make another topic.

If someone had updated the Wiki so that it doesn't point here for the "latest information", I wouldn't be here.

[kzinti]

Is this you, bzt?

[iansjack]

If someone had updated the Wiki so that it doesn't point here for the "latest information", I wouldn't be here.

Everyone is someone.

Even you are someone.