Just wondering, which is actually faster? Interrupts or calls?

What sort of calls? Near? Far? What mode? Real? PM? What code setting? 16? 32?

near calls are faster than interrupts.
far calls to another task is slower than interrupts.
jmp far is faster than call far
jmp to another task is slow.
task switch is slow
segment change in real mode is faster than segment change in protected mode.
but interrupt is not as easy to operate as calls (for system coder).
but interrupts are easyer to use as application programmer, it is more convenient for librairy sharing, linux does this, via int80h

more precisions will come via other members.

So which would be faster? The Linux interrupts or Windows API (assuming both do the samethings)?

Windows API is not the lowest layer. The Win32 functions end up calling the NT native functions, which then generate an int 2Eh to make a kernel call.

Is it possible to make a kernel call or an int 2Eh directly without windows API?

windows api come from a file loaded in memory at boot time.
a .dll
for use of these libs need an include '*.inc', to import the list of pointers and equates.

Theoretically yes, but Int 2Eh is undocumented internal interface and sometimes changes between windows versions, so using it is nonportable (unlike int 21h for DOS or int 80h for Linux, which are standard interfaces).

If you want low level access to Windows, better use Native API, which is still mostly officially undocumented but is more well known. See http://undocumented.ntinternals.net/ for NT native functions.

Yes and no.

Yes in the sense that there is no restriction and you can directly call int 0x2e if you want. Although there is very little advantage to doing so because the whole interface is not officially documented and can change at any time with an update or service pack. Note that many kernel32 API's are simply wrappers to int 0x2e functions, so in effect you already do call the kernel directly.

No in the sense that you are forced to load at least one API DLL into your address space, ntdll.dll will always be mapped in and depending on the OS version ntdll will subsequently load in kernel32.dll. My testing shows that Win2K and WinXP behave differently, one will allow an exe file with no imports and the other will not. I forget which one works and which doesn't, but it is not important anyway, it is enough to know that doing so is unreliable.