OSDev.org

hello i have a small doubt why is that most people use Cygwin why cant they use code blocks other tools??

is it because we want plain binary???

Thanks!

Going via the Cygwin route is the easiest and cheapest way for Windows users to get a fully functional GCC / Make-enabled toolchain (like on Linux).

The canon suggestion made by the Wiki is to build yourself an ELF-targeting GCC Cross-Compiler on either platform, because it avoids several mistakes that are commonly born out of negligence, allows everyone to reproduce your environment even on the other operating system, and helps keeping Makefiles, tutorials, and posts generic.

Thanks for the reply!

so cygwin automatically converts to ELF type am i correct??
so i can use other ELF programs in my own OS correct???
can you tell me what type of file format is used in windows??(i searched but )

Thanks!

Erm... nononono.

ELF is a binary format. ELF defines how a binary is structured, i.e. where the information on the start address or the loading address is located within the binary. It's some kind of "toolchain compatibility", and very well supported tools-wise, but it does not provide any kind of automatic compatibility of executables or libraries across operating systems. You still get BSD ELF, Linux ELF, YourOS ELF etc.

In contrast, Windows binaries come in PE format. You cannot run ELF binaries under Windows, with or without Cygwin.

What you can do is, you can compile many programs originally targeted at Unix-ish operating systems (including the GCC toolchain itself) under Cygwin, generating a Windows (PE) executable.

So the idea is, you use the Cygwin GCC (which generates Windows binaries) to compile a GCC Cross-Compiler (which is a Windows / PE binary, but generates ELF binaries - hence "crossing" from the PE realm to the ELF realm). You then use that cross-compiler (not the native Cygwin one!) to generate YourOS binaries, executables and libraries, in ELF format (which is readily supported by tools like bootloaders, emulators, and debuggers, much more so than PE format).

The upside, as I said above, is that you can use the same tools, same command line options etc. as those people developing under Linux. (Or BSD, or MacOS, or whatever.) Your cross-compiler will cry out loud if you e.g. negligently include system headers that are not there for YourOS yet. You also enable people to join your project effort (or helping you debug a specific problem) without forcing them to install Windows and/or a specific, potentially commercial IDE first.

yeah i read about ELF its a structure ok i get it i have read about ELF and PE i guess

so cygwin(in windows) converts from ELF to PE format correct???(so that i can run in windows)

suppose i have a program "X" which is a Unix-ish program(in ELF) and i can run that program in windows by using Cygwin to convert from that ELF to PE right??

so basically i use cygwin to write code that supports ELF and use the same in my OS
so i guess ELF is like standard file format which is like a portable standard on most systems right??

so if i implement the same ELF in my OS then without any conversion i can run it ???

sorry for being pain in the a**.
Thanks

Cygwin doesn't convert ELF to PE: in fact, Cygwin code is entriely PE. It's just that it can run programs (after compiling them from source) that use the POSIX API instead of the Windows API. Because tools for compiling and linking ELF files use the POSIX API (because they're intended for Linux/UNIX, which use ELF), it is necessary to use Cygwin to work with ELF files.

There's a very big difference between executable format and API: even if you use the executable format of a platform, you can't simply run programs from it without recreating its API functions as well (which would basically require rewriting that platform inside your own).

wenn32 wrote:so cygwin(in windows) converts from ELF to PE format correct???(so that i can run in windows)

No.

Cygwin provides two things:

• a POSIX ("Unix-ish") API, so that sources writen for Unix systems can be compiled in a Cygwin environment, too.
• a variety of tools, programs etc. for which this has already been done, making a bash ("Unix-ish") / X11 ("Unix-ish") environment available for Windows users that need one.

Cygwin does not provide an environment in which binaries compiled for Unix can be run.

I.e., you can take the source code for a program originally written for Linux, BSD etc., compile that in Cygwin, and (with a little luck, some work, spit and polish) get a Windows executable.

You can not take that same program in binary form intended for a different system (e.g. from a Linux download mirror) and expect that binary to run on Cygwin.

suppose i have a program "X" which is a Unix-ish program(in ELF) and i can run that program in windows by using Cygwin to convert from that ELF to PE right??

Not really.

The source for e.g. "sed", compiled on Linux, results in an ELF-Linux executable.

The same source for "sed", compiled on Cygwin, results in a PE-Windows executable.

Because that is what the compiler on that system generates.

...

Make sure you understood the above before reading on.

...

The GCC Cross-Compiler we keep talking about is the source for "gcc" (and the "binutils" package which GCC relies on), compiled on Cygwin (to give PE-Windows executables), which in turn are configured to generate generic ELF binaries when run. I.e., the output of Cygwin's GCC toolchain runs on Windows, the output of said cross-compiler does not run on Windows.

so i guess ELF is like standard file format which is like a portable standard on most systems right??

That, indeed, is correct. "Most systems", however, does not include Windows.

so if i implement the same ELF in my OS then without any conversion i can run it ???

At some point in time you have to implement a "loader" component in your OS that takes executables or libraries from storage, and puts them into active memory in some appropriate way. If you decide to "go ELF", that "loader" would have to handle the ELF format.

But keep in mind that the binary format (i.e., ELF or PE) is ony one small part of the magic that is "compatibility". The other two parts would be the Application Programming Interface (API, i.e., the functions offered by your OS on the source level), and the Application Binary Interface (ABI, i.e., how an application addresses those functions on the machine level). Only if you keep all three compatible you can take a binary compiled for OS X and run it unchanged on OS Y. (The two systems would, however, be very much alike anyway. Even two different Linux distributions aren't really binary compatible that way.)

However, all you need to be able to compile the same source code for two different operating systems is a compatibility in the API. The compiler will generate the correct binary format and address the ABI in the correct way, automatically.

----

There are two ways you could have approached at your type of question. You either:

• ...have a good understanding of operating system structures in general, and just were a bit fuzzy on the subject of binary formats. In that case, I hope I was of help, and good luck with your endeavour. Or you...
• ...lack quite crucial background knowledge on what happens "under the hood". In that case, let me flash a warning at you: Starting OS development without a good technical background will result in frustration and annoyed people, which most likely will include yourself and several forum users that feel obliged to answer questions that shouldn't be necessary. In that case, I still hope I was of help in building up your background knowledge, but I seriously suggest that you build that kind of knowledge while doing application development work. Everything you will learn there will help you in OS development, should you return - and it is a much less painful way of learning, as userspace development is much better supported by tools, books, and support websites.

from the last two posts i serious get it.You know i got it in my mind but i was little confused with "Source" and "Binary"(i actually was thinking it was converting from ELF to PE sorry i was looking at the binary part)but now i got it cleared.

There are two ways you could have approached at your type of question. You either:

* ...have a good understanding of operating system structures in general, and just were a bit fuzzy on the subject of binary formats. In that case, I hope I was of help, and good luck with your endeavour. Or you...
* ...lack quite crucial background knowledge on what happens "under the hood". In that case, let me flash a warning at you: Starting OS development without a good technical background will result in frustration and annoyed people, which most likely will include yourself and several forum users that feel obliged to answer questions that shouldn't be necessary. In that case, I still hope I was of help in building up your background knowledge, but I seriously suggest that you build that kind of knowledge while doing application development work. Everything you will learn there will help you in OS development, should you return - and it is a much less painful way of learning, as userspace development is much better supported by tools, books, and support websites.

i would say both.

Thanks for clearing things up! i really appreciate that!

wenn32 wrote:hello i have a small doubt why is that most people use Cygwin why cant they use code blocks other tools??

is it because we want plain binary???

Thanks!

Code::Blocks is not a compiler or linker, it is an IDE. It merely provides a single environment from which you can edit your code, invoke the compiler to build your executable, invoke the created executable, and it also provides a GUI for some debuggers. It might be possible to configure Code::Blocks for use with a cross-compiler for OS development, but it seems like too much hassle for maybe a small gain in ease of development.

Most OS devers do not want a plain binary format for their kernel. A lot of people use ELF, some use PE, others use a custom executable format. It is possible to use one though, and it can even be multiboot-compliant.

wenn32 wrote:

You either:
* ...have a good understanding of operating system structures in general, ...
* ...lack quite crucial background knowledge on what happens "under the hood". In that case, let me flash a warning at you: Starting OS development without a good technical background will result in frustration and annoyed people,

i would say both. Thanks for clearing things up!

I'll assume you know the theory (from any introductory OS text-book), but missing on the nitty-gritty details. If that's the case, your best bet is to write several userspace assembly programs while reading the Intel Manual volume 1. That way, you'll get comfortable with the x86 architecture, assemblers, operating system interfaces, and binary formats. You can even disassemble the resulting binaries to discover how the linker re-ordered your code and get comfortable with disassemblers and linkers in the process.

Doing the above will guarantee you a mostly frustration-free experience. Doing it by extreme trial-and-error and copying tutorials code (I loathe tutorials, they do more harm than good) will lead you to a very ugly path. Good luck!