Using one of the preceding instructions would mean making a direct system call and bypassing all system libraries as shown in the following figure. However, this is not the best practice and we will see why in a moment:

Using the direct system call approach on Linux would, most likely, work, as Linux system calls are well documented and their numbers are well known (they may be found in /usr/include/asm/unistd_32.h for a 32-bit system and in /usr/include/asm/unistd_64.h for a 64-bit one), and those numbers do not tend to change. For example, the following code prints a msg string to the standard output on a 32-bit Linux system:

mov  eax, 4      ; 4 is the number of sys_write system call
mov  ebx, 1      ; 1 is the stdout file number
lea  ecx, [msg]  ; msg is the label (address) of the string to write
mov  edx, len    ; length of msg in bytes
int  0x80        ; make syscall

Here is its 64-bit counterpart:

mov  rax, 1      ; 1 is the number of sys_write on 64-bit Linux
mov  rdi, 1      ; 1 is the stdout file number
mov  rsi, msg    ; msg is the label (address) of the string
mov  rdx, len    ; length of msg in bytes
syscall          ; make the system call

On Windows, however, despite the fact that the idea is the same, the implementation is different. To begin with, there is no publicly available official documentation of Windows system calls, which not only requires a certain portion of reverse engineering, but also gives no guarantee that the information found through reversing ntdll.dll would remain intact after the next update, not to mention the fact that system call numbers tend to change from version to version. However, for the sake of common education, here is the system call invocation procedure from the 32-bit ntdll.dll:

_KiIntSystemCall:
   lea  edx, [esp + 8]      ; Load EDX with pointer to the parameter block
   int  0x2e                ; make system call

Also, if the SYSENTER instruction is available, then we have the following:

_KiFastSystemCall:
   mov  edx, esp            ; Load EDX with stack pointer so that kernel
                            ; may access the parameter block on stack
   sysenter                 ; make system call

Although the second variant is more promising, there is still no guarantee that the format of the parameter block would not change (though, this is not likely). In conclusion of this subsection, it is important to say that it is much advised not to make use of direct system calls unless absolutely necessary.