Brenden (aka xsism), autor do site, começa expondo a notícia de seu retorno no site principal:

It’s been almost 2 years since anything has been updated here. All I could do in the mean time is keep the server online and renew the domain once a year(or forget about it and have it go down and then grab the domain back from DNS pergatory before it became a squat site). Well, 2 years is flippin’ rediculous.

I haven’t been talking to Cody at all; not in at least a year. I don’t know where he went, but I do see him in gtalk every so often. Either way, I am taking ownership back. I already pay for hosting and the domain, so I’m going to start maintaining the content, too.

Que diz o seguinte em português:

Se passou quase 2 anos desde que tudo foi atualizado aqui. Tudo que eu poderia fazer no tempo médio é manter o servidor online e renovar o domínio, uma vez por ano (ou esquecer-se e deixa-lo cair, em seguida, pagar o domínio de volta a partir do purgatório de DNS). Bem, 2 anos é muito ridículo.

Eu não fui falar com Cody ao todo; não em pelo menos um ano. Não sei onde ele foi, mas eu o vejo no gtalk tantas vezes. De qualquer maneira, estou tomando a posse de volta. Já para pagar hospedagem e do domínio, então eu vou começar a manutenção do conteúdo, também.

Assim como acontece com a OSDever.net, a OSDev Brasil anda meio parada, mas estou para preparar mais algumas novidades  ao site. Assim que possível estaremos com mais conteúdo na área de desenvolvimento de sistemas operacionais.

Para quem quer conferir é só entrar no site do autor jamesmolloy.co.uk e aproveitando este post estou anúnciando que em breve estarei lançando meu projeto de sistema operacional baseado no Uni*.

Até mais.

Nele você poderá encontrar CVS, listas, controle de bugs, quadro de mensagens/fóruns, gerenciador de tarefas, hospedagem, arquivamento permanente de arquivos, backups completos e administração totalmente baseado na web.

Para conferir você poderá entrar aqui: http://codigolivre.org.br/

O Plan 9 é um sistema operacional descendente do Unix e desenvolvido pela Bell Laboratories. Ele não é uma variante Unix, mas é muito parecido. O Plan 9 explora várias “simplificações” do modelo Unix original. Isso incrementa a experiência de usar e programar o sistema, notavelmente em ambientes multi-usuários distribuídos. O Plan 9 foi um projeto interno da Bell Labs por muitos anos, mas a distribuição pública feita em 1993, seguida por uma versão encolhe-envolve em 1995. A Bell perdeu o interesse comercial no projeto após a década de 90 e distribuiu uma terceira versão sobre um licença não-livre (porém com o código fonte disponível) em 2000, e finalmente sobre uma nova licença open source em 2002. Esta é a quarta, e atual, edição do sistema.

Como podem ver o Plan9 é um sistema descendente do Unix assim herdando algumas de suas características e dando novas funcionalidades a ele. E aí pronto para testar?

Link para site oficial: http://plan9.bell-labs.com/plan9/

Abraços

Ele usa como base o Busybox o e o Linux Kernel série 2.6, tudo isso em um disquete de 1.44 MB!

Atualmente a equipe de desenvolvimento está precisando de pessoal interessado para manter o sistema, quem tiver interesse é somente entrar no site abaixo.

Para quem quiser conferir poderá entrar em: http://code.google.com/p/terabeauts/

Para acompanhar o artigo entre no seguinte link: http://www.oficinadanet.com.br/artigo/851/o_que_e_um_sistema_operacional

Então um dos melhores sites com informações de sistemas operacionais que você poderá encontrar na Web é o OSRC, nele você poderá encontrar os seguintes tópicos:

Software:

1. The Boot Process
2. Partitions
3. File Systems
4. Memory Management
5. Protected Mode
6. Executable File Formats
7. Plug and Play Specs
8. Device Driver Interfaces
9. Miscellaneous Software

Hardware:

1. Processor Architecture
2. Interconnect Buses
3. Disk and Disc Drives
4. Human Interface Devices
5. Sound Devices
6. Communication Devices
7. Networking Devices
8. Miscellaneous Devices
9. Other Hardware

Espero que isso possa ser de ajudar.

Até mais

Para quem quiser conferir poderá entrar no seguinte link: http://bananakernel.sourceforge.net/

Espero que seja de bom proveito.
Até mais.

Para nosso núcleo ser executado pelo GRUB, precisamos ter um cabeçalho nos primeiros 8KB e deve ter a seguinte forma:

/*****************************************************************************
** Cabeçalho Multiboot, com "aout kludge"
** GRUB não irá iniciar o núcleo a menos que
** - está estrutura esteja presente nos primeiros 8192 bytes do arquivo do núcleo
** - está estrutura estiver alinhada em um endereço divisivel por 4-byte
** - o valor mágico Multiboot está presente na estrutura
** - o número de checagem (checksum) esteja correto
*****************************************************************************/

MBOOT_PAGE_ALIGN EQU 1<<0
MBOOT_MEMORY_INFO EQU 1<<1
MBOOT_AOUT_KLUDGE EQU 1<<16
MBOOT_HEADER_MAGIC EQU 0x1BADB002
MBOOT_HEADER_FLAGS EQU MBOOT_PAGE_ALIGN | MBOOT_MEMORY_INFO | MBOOT_AOUT_KLUDGE
MBOOT_CHECKSUM EQU -(MBOOT_HEADER_MAGIC + MBOOT_HEADER_FLAGS)

ALIGN 4
mboot:
dd MBOOT_HEADER_MAGIC
dd MBOOT_HEADER_FLAGS
dd MBOOT_CHECKSUM
// aout kludge
dd mboot    // Endereço do cabeçalho multiboot
dd _d_code    // Endereço da área de código
dd _d_bss    // Endereço da área de dados não inicializado
dd _end        // Fim do núcleo
dd ncl_inicio    // Endereço inicial do núcleo

E terá de configurar também o arquivo menu.lst que se encontra em /boot/grub/ e deverá ter o seguinte código:

title   SOmBRA
root    (fd0)
kernel  /nucleo.cof

O title é o título que irá aparece na inicialização, o root diz qual o driver será o diretório raiz e o kernel diz onde se encontra nosso núcleo que será carregado. O grub suporta vários tipos de arquivos executáveis, tais como COFF, DJCOFF e ELF, e com ele ainda podemos acrescentar módulos, que poderão depois ser usados pelo núcleo, mas isso será matéria do próximo artigo.

Até mais.

Primeiro devemos saber como o C processa os parâmetros e o retorno de dados, na verdade isso é bem simples. Quando passamos os parâmetros para o código o C joga os dados na pilha, então para um arquivo como:

teste.c:

int soma(int x, int y)
{
return x+y;
}

int main(void)
{
int r;

r = soma(5, 6);

return 0;
}

Teremos o seguinte código assembly:

teste.asm:

_soma:
push     ebp
mov    ebp, esp
mov    eax, DWORD [ebp + 12]
add    eax, DWORD [ebp + 8]
pop    ebp
ret

_main:
push    ebp
mov    ebp, esp
sub    esp, 24
and    esp, -16
mov    eax, 0
add    eax, 15
add    eax, 15
shr    eax, 4
sal    eax, 4
mov DWORD [ebp - 8], eax
mov    eax, DWORD [ebp -8]
call    __alloca
call    ___main
mov    [esp+4], 6
mov    [esp], 5
call    _soma
mov    [ebp - 4], eax
mov    eax, 0
leave
ret

Parece ser muito complicado não? Mas vou explicar cada linha!

Como você deve ter percebido, o C adiciona um underscore antes do nome de cada função, a função _soma é de longe bem fácil de entender, como a função recebe os dados da pilha primeiro ela deverá manipula-los, então ela salva o EBP na pilha e move o valor de ESP para ele, a pilha agora deverá ser algo do tipo:

VALOR 6
VALOR 5
VALOR DE EIP
VALOR DE EBP

No código assembly gerado, podemos ver que o EAX é quem recebe o retorno, por isso todas as manipulação são feitas encima dele, então

mov eax, DWORD [ebp+12]

seria nosso Y e

add eax, DWORD [ebp + 8]

seria o mesmo que return x+y; depois disso o valor de EBP é retomado e a função volta de onde foi chamada.

Na função _main, vamos aquele amontoado de código gerado para alocar as variáveis, mas podemos ignora-lo, o que interessa mesmo é esta parte:

mov    [esp+4], 6
mov    [esp], 5
call    _soma
mov    [ebp - 4], eax
mov    eax, 0
leave
ret

As três primeiras linhas de código como podemos ver seria os valores passados a pilha e a chamada a função, seria o mesmo que fazer:

push 5
push 6
call _soma

E como o valor de retorno está em EAX, o [EBP - 4], representa nossa variável r e como podemos ver, todas as variáveis criadas dentro das funções ficam na pilha, por isso o uso de EBP. Como termino return 0, é representado como:

mov eax, 0
leave        ; Libera o espaço usado por _main na pilha
ret        ; Retorna

Acredito que depois disso podemos entender, em geral, como o C gerá o código Assembly, mas pera ai! Não estamos esquecendo de algo?

Claro e como podemos juntar um arquivo assembly com um C? Se você estiver usando o DJGPP e o NASM, você pode fazer o seguinte:

nasm -fcoff assembly.asm -o assembly.o
gcc -c arquivo.c -o arquivo.o

ld -r assembly.o arquivo.o -o combinado.o

Para isso vou dar um exemplo final:

arqasm.asm:

[BITS 32]

[SECTION .text]

_soma:
push     ebp
mov    ebp, esp
mov    eax, DWORD [ebp + 12]
add    eax, DWORD [ebp + 8]
pop    ebp
ret

arqc.c:

int soma(int x, int y);

int teste(void)
{
int r;

r = soma(5, 6);

return 0;
}

Se alguêm tiver interesse em ver como o GCC gerá os códigos para o assembly, você poderá tentar o seguinte comando:

gcc -c arquivo.c -S teste.s

Espero que tenham gostado, se tiverem dúvidas ou algo estiver errado, mandem um comentário.