Além de uma interface de usuário (o shell, Korn Shell no caso), se é que ainda podemos chamar assim. Também foi criada uma interface de acesso aos serviços do Sistema Operacional, chamadas de SYSCALLS.

A verdade é que fazem quase 25 anos que estes padrões estão inalterados, e nos dias de hoje é simplesmente impossível entender por que ainda seguimos esta norma, abaixo segue um exemplo de como esta desatualizada a API de programação:

struct ifreq *ifr;
struct ifreq ifrr;
struct sockaddr_in sa;

ifr = &ifrr;

ifrr.ifr_addr.sa_family = AF_INET;

strncpy(ifrr.ifr_name, ifname, sizeof(ifrr.ifr_name));

…..

*ifaddr = ifrr.ifr_addr;
printf(“Address for %s: %s\n”, ifname, inet_ntoa(inaddrr(ifr_addr.sa_data)));

O código acima serve para mostrar os IP’s das interfaces de rede presentes na maquina, ele é tão antigo que no tempo em que o POSIX foi criado, as máquinas dificilmente tinham varias interfaces de rede, então para facilitar ao programador localizar o IP da máquina, foi criada uma macro chamada ifr_addr.sa_data, mas o que acontece quando queremos saber o endereço de outras interfaces? A maneira mais simples é fazer isto:

Copiar o nome da interface para a estrutura ifrr, chamar novamente o ioctl() pertinente, e pegar o campo .sa_data, mas o que acontece se não sabemos o nome da interface? Bem.. dai perdeu playboy. Não existe syscall POSIX para enumerar as interfaces presentes.. O Linux atualmente esta implementando uma função mas não é padrão..

Um método extremamente ultrapassado de se fazer uma operação muito simples.

E assim acontece o mesmo com a maioria das chamadas SYSCALLS do POSIX, outro exemplo é o já citado ioctl(), ele tem tantas funções que simplesmente é impossível uma pessoa saber a metade deles, ele preenche estruturas de tamanho variavel, com informação variavel, sem qualquer explicação do retorno possível a não ser na documentação do proprio sistema operacional.

Tenho conhecimento de dois sistemas operacionais com API’s atuais, o Windows e o Mac OS X.

No caso do Windows existem tantas SYSCALLS que algumas inclusive fazem exatamente as mesmas coisas, somente para manter a compatibilidade entre as versões interiores, mas a questão é que pelo menos elas lidam com problemas atuais como Orientação a Objeto, Leitura e Escrita multiplexada (ao mesmo tempo sem threads) e muito mais.

Ainda existe o Darwin, que é o verdadeiro sistema operacional do Mac OS X, pois este é muito mais, na verdade é um conjunto de serviços de alto nivel como manipulação de tela, execução de conteudo multimidia, comunicação com hardware e dezenas de outros serviços.

O fato é que este último eu ainda estou estudando para poder dar uma opnião correta, mas o meu ponto neste artigo é que, pelo menos estes dois sistemas operacionais tentam atender as necessidades dos desenvolvedores, ao contrario do POSIX que tenta manter compatibilidade e dificulta a criação de aplicações.

Acredito que num futuro breve será necessária a criação de um novo padrão para compatibilidade de sistemas operacionais, e poderemos nos ver livres desta interface velha e obsoleta.