Ok, I want to write an OS, but I'm using Windows, so it doesn't have many (if any) decent built in tools for this sort of thing.
So, just wondering what I would need and where I can get it from. I already have access to a C++ compiler (well... visual c++, but you can use the compiler seperately).
Thanks in advance etc
Windows: tools to start development
-
pini
Re:Windows: tools to start development
I don't know if it is really possible to make Visual C++ be completly plateform independant (although it should, since it should be a C++ compiler) ?
-
distantvoices
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:Windows: tools to start development
cygwin could be something to be taken into consideration...
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
-
kaos
Re:Windows: tools to start development
It is obviously possible to use Visual C++ for writing an OS, but most people who are writing a new OS choose to use some variant of gcc--it is free, runs on almost any platform if there are enough resources, and targets almost any architecture. Visual C++ does not target as many architectures and costs money. In addition, support and documentation for writing an OS using gcc are freely available on a variety of websites, forums, newsgroups, irc, etc.
As far as utilities go, you'll probably want a nice set of Unix command line utilities, an x86 emulator (Bochs, etc), and some tools for manipulating disk images. You'll also want a good text editor (Ultraedit) and maybe a hex editor (Hex Workshop).
Oh, yeah--you'll probably want nasm too.
As far as utilities go, you'll probably want a nice set of Unix command line utilities, an x86 emulator (Bochs, etc), and some tools for manipulating disk images. You'll also want a good text editor (Ultraedit) and maybe a hex editor (Hex Workshop).
Oh, yeah--you'll probably want nasm too.
Re:Windows: tools to start development
More info on Cygwin:
Available at http://www.cygwin.com, cygwin.dll is a library that provides a POSIX compliant API on Windows. On top of this DLL, various GNU tools have been "ported", including bash, gcc, binutils, nasm etc. etc.
Basically, Cygwin is a "bash box", i.e. a DOS box running a fully enabled bash shell with most tools you'd expect from e.g. a Linux environment.
It comes with a setup.exe, and is installed and maintained in a breeze. I was successful in compiling various other Linux tools without any touching of the source code, and would call Cygwin my most important Windows application.
Only downside is that the Cygwin gcc, out-of-the-box, does not create ELF binaries but PE binaries. Building a cross-compiler isn't too difficult though.
My rating: 9.5 out of 10. A definite must-have for the serious developer, either as addition to VisualC++, or as standalone dev-env.
Available at http://www.cygwin.com, cygwin.dll is a library that provides a POSIX compliant API on Windows. On top of this DLL, various GNU tools have been "ported", including bash, gcc, binutils, nasm etc. etc.
Basically, Cygwin is a "bash box", i.e. a DOS box running a fully enabled bash shell with most tools you'd expect from e.g. a Linux environment.
It comes with a setup.exe, and is installed and maintained in a breeze. I was successful in compiling various other Linux tools without any touching of the source code, and would call Cygwin my most important Windows application.
Only downside is that the Cygwin gcc, out-of-the-box, does not create ELF binaries but PE binaries. Building a cross-compiler isn't too difficult though.
My rating: 9.5 out of 10. A definite must-have for the serious developer, either as addition to VisualC++, or as standalone dev-env.
Every good solution is obvious once you've found it.
-
Kemp
Re:Windows: tools to start development
Hi, thanks for the responses, I have found a load of the tools you suggested plus some more. Are there any sites that give you a good place to start coding, or does it tend to be a case of looking at someone else's code and working from there? I have a copy of the MazzanetOS source and am working from that at the moment, but it is only a very tiny, basic thing and I don't really know where to start expanding.
-
Kemp
Re:Windows: tools to start development
Additionally, do I need to watch out for anything if I'm developing on an AMD Athlon? I read that most of the instructions are the same, but has anyone encountered any that weren't implemented properly between x86 and the various AMD processors?
Re:Windows: tools to start development
There was only one (probably why you ask) which was the LOOPnn instruction, that was in fact implemented properly, but a lot faster than the intel version. Because of this some Windows programs broke (which counted on the delay for some reason).
AMD is fully Intel-compatible, and it even has some features Intel does not, a lot like Intel has features AMD doesn't have. The only things you should not count on are rumors, that is, things that have been seen by others, heard by others or you have tested experimentally. If it's in the standards (Intel processor manuals or AMD programming manuals, I myself advise the AMD ones, I think they're clearer) it should work exactly as described there. If it does not, some note will be made explicitly, and in most cases the hardware will be recalled. If it is a bug that is only prevalent in buggy software (such as virusses...) usually there will not be a hardware recall, but they will be published. The current list is about 4 in length, just about all of which are pre-500mhz range, so (imo) not interesting. For instance, the FDIV (P1 60 +P1 66) had to do with an extremely minor roundoff error in floating point divide, the F00F error had to do with an instruction encoding that should've invoked an invalid opcode exception, but instead functioned as normal (with disastrous results) and things like that.
Small note, AMD has once again slowed the execution of the LOOPnn instruction. If you still want the fast behaviour, use DEC ECX; Jcc instruction sequence.
HTH, Candy
AMD is fully Intel-compatible, and it even has some features Intel does not, a lot like Intel has features AMD doesn't have. The only things you should not count on are rumors, that is, things that have been seen by others, heard by others or you have tested experimentally. If it's in the standards (Intel processor manuals or AMD programming manuals, I myself advise the AMD ones, I think they're clearer) it should work exactly as described there. If it does not, some note will be made explicitly, and in most cases the hardware will be recalled. If it is a bug that is only prevalent in buggy software (such as virusses...) usually there will not be a hardware recall, but they will be published. The current list is about 4 in length, just about all of which are pre-500mhz range, so (imo) not interesting. For instance, the FDIV (P1 60 +P1 66) had to do with an extremely minor roundoff error in floating point divide, the F00F error had to do with an instruction encoding that should've invoked an invalid opcode exception, but instead functioned as normal (with disastrous results) and things like that.
Small note, AMD has once again slowed the execution of the LOOPnn instruction. If you still want the fast behaviour, use DEC ECX; Jcc instruction sequence.
HTH, Candy