Printable View
Does anyone know of a C++ compiler (free if possible) that can create OS-independent .COM executables for X86 (without a lot of, say, "hello I'm a windows-program"-type of code) This is because one day I want to create my own OS and/or compiler. I'd also like a modern 32-bit equivalent of the old Debug that came with dos/windows that displayed 16-bit machine code as ASM, so that I can see what the compiler creates...
> create OS-independent .COM executables for X86
No such animal exists.
>> I'd also like a modern 32-bit equivalent of the old Debug that came with dos/windows
Until now I had never realized that debug.exe is 16-bit, lol!
edit: Is there a 32-bit version of debug.exe? :confused:
I'm sure does! They made windows using some generic C/C++, right folks?Quote:
No such animal exists
> create OS-independent .COM
> I'm sure does! They made windows using some generic C/C++, right folks?
Right. That is because COM is a Microsoft executable format.
WARNING - I don’t have any hands-on experience with this stuff… So the following is hearsay, assumption, and speculation: :D
I think the Linux GCC compiler can do what you want. Because with Linux, you can boot a bootloader and then compile the OS… before you have a (complete) OS installed.
When you’re ready to learn to write an operating system, check-out Minix. Minix was created as a learning tool. The Minix source is free (not open source), but you have to pay for the book.Quote:
This is because one day I want to create my own OS and/or compiler.
Of course, you can study the Linux source code. But, I wouldn’t attempt that unless you can find a really good study guide. (Linux 2.4 is 2.4 Million lines of code!!!)
You need a disassembler. A good Compiler/IDE with a debugger should include a disassembler. I’m pretty sure that the MS Visual C++ debugger has one.Quote:
...that displayed 16-bit machine code as ASM,
> I'm sure does! They made windows using some generic C/C++, right folks?
Sure, and what about Linux, Solaris, NetBSD, OpenBSD, FreeBSD and a host of other operating systems which you've never heard of.
None of those are going to think much about 16-bit COM files.
For a command line tool, try ntsd. WinDbg is the GUI version.Quote:
I'd also like a modern 32-bit equivalent of the old Debug that came with dos/windows that displayed 16-bit machine code as ASM
Well to those who say .COM's are either always 16-bit (not true) or a microsoft concept (not true either) I just want to let them know. I've read about them in old assembler books. The exe:s are relocatable so they can be put and operate in any area memory were space is available, that's the main/defining difference... A .COM is simple usually not very OS oriented (because it's either the startup-file of an OS or an old and therefore simple tool for that OS) and would be the thing to use for learning machine code or startup of an OS (when you know free memory starts at 0)
Still, you're going to be SOL as soon as your program wants to say
- display anything
- read input
- read a file.
Because all those services are very specific to each and every OS.
Well, there are the BIOS routines for doing such things (it has text-printing and I think a standard screen mode for that). It has not file reading (since it's specific to the OS and FileSystem), but sector reading. Then I can learn how to communicate with the graphics card for doing manual (more advanced) graphics...
There has to be some generic C/C++ compiler!
Sure because every BIOS is the same too
-err no.
Try learning something before speaking next time. If you really want to get into OS design then learn assembly. This will serve as the base for your OS and it is the only way to start to build one.
If you want to get into compiler design check out the red dragon book, do a search on this board for other books, or *gasp* try google.
You are correct as in the idea of executable programs is not microsoft original, however the implementation of an executable IS OS dependant and thus there is no "generic" compiler that you speak of since the implementation is different for each OS.
This is all correct, but it requires assembly. The bios interrupt is 0x10, and you use the registers AH, AL, BH, and BL in order to set the text and attributes. No C or C++ compiler (that I know of anyways) is going to help you here.Quote:
Well, there are the BIOS routines for doing such things (it has text-printing and I think a standard screen mode for that). It has not file reading (since it's specific to the OS and FileSystem), but sector reading. Then I can learn how to communicate with the graphics card for doing manual (more advanced) graphics...
...but they did use C rather than assembler to make windows!
To make MOST of of windows. Bootstrap loaders have to be written in assembly. And the code used to make windows isn't compiled on any magic compiler. It's just that you won't be able to call any functions that are normally defined by the OS. In other words, you'll have basic C syntax, but you'll have to code all your routines for input, etc... in assembly.
I have realized that such an animal does indeed exist, every compiler that won't delete pre-link created obj-files is one. If one has used no OS-calls these obj files could be booted as an operating system. But one has to place either the .obj's code itself (if it's really tiny) or (more likely) code that will load it, in the boot sector.
If it should load not at boot - but from within Windows - I guess one must arrange for the assembler equivalent of "ORG 100h" to make room for the (theoretical) command line at the benning of it's memory space, making it an MS-DOS .com... Perhaps other X86 systems (OS/2, Linux) will run this kind aswell?
Note that I'm not thinking that the same .com that acts as an OS at one time would also double as an application. An operating system's code beeing run as an application would of course violate the rules of the OS it's beeing run by (unless the code has little power and is of little use as an OS).
Quote:
Originally Posted by bithub
Or something like that. It's been ages.Code:union REGS regs;
regs.x.al = 0x10;
int86 (®s, ®s);
> every compiler that won't delete pre-link created obj-files is one.
All the object file formats I know about contain a lot of relocation information as well. They're not simply "memory dumps" of the assembler code they represent, so there's no way you can simply load them into memory, jump to where you loaded them and expect anything useful to happen.
> Perhaps other X86 systems (OS/2, Linux) will run this kind aswell?
I said it before, so let me say it again.
Every OS out there has it's own "executable" format, so there's no way you can make a one size fits all format.
But then again, I've lost interest in your ramblings.
Relocatable code needs to be "located" to be useable. This is quite possible. An earlier employer of mine used Borland Turbo Pascal and assembler to build it's embedded software. The resulting relocatable object was then processed by our own locator to resolve addresses. It was then blown into a PROM at a fixed offset above a simple BIOS written in raw hex in a seperate PROM. The application was an executive loop and a series of state machines. Was over ½million lines of code.
Reading your posts, I would suggest that this is beyond your current knowledge/expertise level.