OSDev.org

Hi!

I am looking for a good C comliler for windows. Any suggestions.

lcc-win32, mingw, cygwin, etc.

I've used cygwin and was impressed with it. Provides a nice posix(ish) shell, as well.

--Jeff

for what kind of use ?

OOP , or osdev ?

OOP -> VC++,BorlandC++

osdev -> take the linux to windows ports

I've used none of them for osDev (all my osDev has been on a unix box), but they are all fully capable. Technically speaking, so are the Borland and MS compilers, but I find there's more osDev related tools and information for GCC ports.

I would recommend not just a unix compiler, but an entire unix-like OS to build on (cygwin is great for windows users in this sense).

Why? The compiler is only one part. The other tools that unix provides are also very usefull to have when developing an OS.

--Jeff

Borland C

VC++ (or intel, but that one costs -- expensive)

I use Dev-Cpp

It's pretty handy as an editor, but that's pretty much all I use it for.

For a compiler I use DJGPP which is a port of the gcc to windows. It's very handy.

I use NASM for my low level stuff. Every OSdever needs to know assembler (you can't get by without it unfortunately).

I use PARTCOPY to install my OS.

I use Bochs to test my OS. Bochs is a PC emulator which lets you run any OS ontop of windows or linux. It's not quite the same as a real pc, but you get the benefit of integrated debugging features which are ESSENTIAL for all OSdevers alike.

MS compile with free VS 2005 Express Edition is good development enviroment. I was using MS at first but now I'm using Intel's compiler. Ther is option for NASM so it can generate VS style error messages.

About PARTCOPY: you cannot write on HDDs under Windows XP.

for what kind of use ?

OOP , or osdev ?

OOP -> VC++,BorlandC++

osdev -> take the linux to windows ports

Why can't it be OOP OS development? I'm using C++ for kernel.

About Partcopy:

I stick to using diskettes/disk images when developing

I don't want to risk having my hard disk corrupted when I write to the wrong sector

For a compiler I use DJGPP which is a port of the gcc to windows. It's very handy.

not true, DJGPP is a 32bit compiler, running in a psudo-32bit environment emulated on a 16bit emulation, within a true 32bit windows environment:
basicaly
windows tries very hard to provide a 16bit RMode environment, (within the normal 32bit environment) and convince DJGPP that it is alone in a 16bit environment,

then DJGPP tries very hard to break out of the protected environment windows has created for it, and create a 32bit environment (inside the 16bit environment) for GCC to run in (GCC is a 32bit program)

instead of simply running GCC natively within the existing true-32bit environment, it is running in a emulated-32bit environment, inside an emulated 16bit environment, inside a true 32bit environment


this extra complication and overhead (and the fact that it doesn't always work correctly under winXP) is why most people advise avoiding DJGPP

JAAman what are you takling about?

DJGPP uses the windows DPMI server to do all it's 32-bit programming. It is running in a true 32-bit environment when it executes. Just read the README files!

yes thats exactly my point

DPMI exist within a 16bit environment, DPMI has nothing to do with windows, it is part of windows 16bit emulation code (and was originally part of DOS)

DPMI is a method of allowing 32bit programs to run in a 16bit environment, any program running in a true 32bit environment will not use DPMI

No that's not how DPMI works.

DPMI is a library suite/set of system calls that are used to either:
1. Create a 32-bit environment on top of a 16-bit environment for protected mode apps (DOS)
2. Break out of a 16-bit emulated environment and run instead in a DPMI controlled 32-bit environment.

DJGPP running on windows (any version 9x and above) uses option 2. Windows has an integrated DPMI server. When a program running in 16-bit VM86 mode calls the DPMI interface, Windows will turn off VM86 and start the program in DPMI mode.

One thing you should note is that DPMI is NOT an emulator. It is a protected mode interface. It can interface with a pre-created environment (windows) or you can have a server (such as CWSDPMI) to create a 32-bit environment for the app to run in.

Last note: Another kind of protected mode interface, called Go32, was abandoned for this very reason. It would only ever create a protected mode interface. Running Go32 programs in windows causes them to crash (unless you are using one of the later versions, which uses DPMI to emulate Go32). They crash because they are doing exactly what you say DPMI does (which it doesn't). Why is it impossible to create a 32-bit environemnt inside VM86? The intel docs have than answer (look at the differences between real mode and VM86 mode)

It is possible to emulate a 32-bit environment inside a 16-bit environment inside a 32-bit environment. Use Bochs

He jus says that. It works in 32bit env. on top of 16bit dos box on 32bit operating system

So it looks like this 32->16->32! It is little too much.

no no
DPMI on windows works like this:

1. 16-bit program starts
2. 16-bit program makes call to DPMI interface to start 32-bit mode
3. windows pulls program out of 16-bit mode altogether and restarts it in DPMI mode


so infact DPMI does this:
32->32

yes there is a little bit of emulation in there, but there is no 16-bit code involved.


When DPMI is running on DOS, the story is different. Since DOS doesn't have 32-bit mode, the DPMI server (usually CWSDPMI) handles everything.

DPMI on DOS looks like this:
16->32