when writing a dos-like OS
(as in console, no multitasking.)

whats better ?
hooking INTs like DOS got int 21h,
or linux int80h,

or should i create APIs like windows got ?

int pros:
easy to use
no need for a file header, just run the code (optional of course..)
smaller code in apps

int cons:
slower
requires a lot of stuff for someone like me who dont really understand int tables and stuff


api pros:
faster
easy to use
simpler to document, search and program because of names of apis

api cons:
needs a header to be parsed and loaded (such as PE, ELF, etc..)
i donno, there must me more things in here..

so, what would you have done ? INT or API ?

Interrupt functions are really simpler to implement, and you can assign some meaningful names to function numbers anyway, in some kind of header file.

Well, interrupts are APIs. The difference between windows style API calls and DOS/Linux is that in windows API calls are done via a CALL instruction with a dynamic address in the import table that gets patched to wherever the actual API code is at load time and interrupt calls are done via the INT instruction, which uses the interrupt number as an index into an array full of pointers to API code. In practise, the real difference then is speed as CALL style calls can be done with no additional runtime overhead since the loader can patch that address up directly (windows does not do that, but other OSes do), but if you use interrupts there will always be the overhead needed to translate "21h" into a real address.
The point about file headers really does not apply here since APIs are just code. Headers would only come into place when you're talking about actually loading the APIs into memory. In that case a header is optional, and it doesn't matter wether or not you use CALL or INT because an interrupt style API could also have a header (code size, code base, interrupt number, etc).
As for ease of implementation, if you're going to use protected mode (which you really should), then you will need to set up an interrupt table anyway because you'll have to handle exceptions. Otherwise a simple divide by zero error will choke your box.
And finally, code size will be smaller with interrupts because the opcode is simple CD nn where nn is the interrupt number. CALLs require a 32-bit address in addition to the opcode. Then again, does a difference of 4 bytes really matter? Interrupts also require an interrupt table, so you need additional space for that anyway, and in a world where computers have around a gig of ram you're not going to be running short on available memory anytime soon, and if you are you should really reconsider your algorithms.

ok,
when i said APIs i meant windows like apis, made by calls.
.com files, they got no header, just plain code,
thats the thing i'm talking about, that you dont HAVE to have the header.

now, i know interrupt table takes up space, but so is the code of the apis,
no ?

i dont know if i want it protected or real mode yet. it will probably have like,
a console and i'll write 3 programs for it. that would be it..

consider i'm lazy, and will most probably only use this OS to impress chicks..
so no divide by 0 is possible

i said it as a matter of laziness that controls my life for the last 18 years
(and 6 months and bla bla..)
so basicly i'm asking, whats better for a system ? INTs or CALLs ??

Here is an interesting topic about it:

http://board.win32asmcommunity.net/showthread.php?s=&threadid=14677

Not to sound insulting here, but .com files have absolutely nothing to do with how you design an operating system. They're just one method used by one operating system to store process code and have nothing to do with the API implementation. MZ files are also DOS executable files, and they have a header. They still use INTs to access APIs just like a .com would.
I think you are refering to the import and export tables in PE files. In that case, that is just Windows' way of doing API calls. There are other ways to accomplish the same thing (API calling via CALL) without having to have a header. You could for example patch up your code directly. That is, hardcode the address to some set value, then search for E8+value. This would give you a 5 byte pattern, which is plenty to make an accurate assumption imho. Another way would be to use static API addresses. They could all be defined in some include file which every application imports. This obviously requires you to recompile your code everytime something changes, but depending on your operating systems purpose that might not be an issue. I believe Unununium did that, and my HP calculators use that as well.


Yes of course, but so does your interrupt code. It doesn't matter if you access your APIs via an INT or a CALL, you're still going to have to code them. The interrupt table is needed to "translate" INT 20h to CALL 100598h or whatever. If you're already using a straight CALL, there is no need to lookup "20h" and determine how to eventually do the actual execution transfer.


Well, if you trust your coding skills enough to never encounter a divide error, never cause an overflow, never cause a stack exception, never accidently get garbage in there that causes an invalid opcode exception, and never need to use breakpoints in your code, go ahead :)


How about you start your OS, then try both out and determine it for yourself? :) Blindly following someone elses suggestions in an area as tricky as OS development is not a good idea, and if you're going to impress chicks it might be good to be able to backup your demonstration with knowledge. If you don't think you'll need to, I recommend you just download some obscure operating system instead and save yourself some time.