Paulo Pires escreveu:
> On 2/25/07, gethostbyname <[EMAIL PROTECTED]> wrote:
>
>>> Apenas que a composição do texto na norma, tanto na construção da
>>> frase como na apresentação visual, torna difícil a interpretação do
>>> que quer dizer.
>>>
>>>
>> Compreendi. Foi um erro meu ter misturado o negrito no meio do código,
>> além de ter duplicado a mensagem.
>>
>
> Não falo nem do negrito. O próprio PDF da norma é confuso.
>
Ah, sim.
>
>>> Até concordo com você, mas é porque nós estamos acostumados com
>>> máquinas e sistemas que trabalham com números. Não precisaria ser o
>>> caso. Eu não se um CP/M da vida tinha alguma coisa como "exit status"
>>> de um programa, nem tenho muita dificuldade em imaginar um sistema em
>>> que um processo retornasse, ao invés de um mero valor, algo que
>>> pudesse ser interpretado como um comando/ação ou um objeto mais
>>> complexo.
>>>
>>>
>> Esse objeto "mais complexo ou comando" poderia ser enviado ao OS por
>> outros modos, não? Chamar system, por exemplo. Seria mais prático e
>> simples, não? Imagine a main retornando algo que não seja o número, que
>> complicação isso geraria.
>>
>
> system() não devolve algo ao SO, mas requisita algo dele (se pensarmos
> no UNIX, system(3) é uma composição de fork(2), execve(2) e
> waitpid(2)/wait4(2)).
>
>
Eu pensei nisso porque você disse "algo que pudesse ser interpretado
como um comando/ação".
> Deixe-me dar um exemplo do que eu quis falar. Digamos que você fez um
> programa chamado -- digamos -- "beethoven", que utiliza alguma técnica
> que você vai patentear para gerar uma sinfonia completa a partir de
> uma seqüência incial de bits. Se esse programa existisse hoje num
> sistema operacional corrente, o resultado ou seria gravado em arquivo
> ou seria enviado a um outro processo através de um pipe ou socket,
> como parte da própria execução do programa, e, somente após essa etapa
> final de manualmente depositar a sinfonia em algum canto, o programa
> devolveria 0 se fosse bem sucedido ou outro valor se falhasse. Se, ao
> invés disso, você tivesse um SO que permitisse devolver um "objeto
> sinfonia" ao término do programa, você não precisaria se preocupar com
> manualmente gravar ou serializar sua sinfonia. Esse "peso" ficaria
> com o sistema.
>
> Claro que um SO assim teria que saber o que fazer com o objeto que
> você lhe envia. Certamente seria um sistema mais complexo, mas não
> sei se já não caminhamos para uma coisa assim, ainda mais nesses dias
> de rede para todo mundo e processamento cada vez mais distribuído.
> MIME types são uma abordagem já em uso para identificação de objetos
> arbitrários, assim como são as extensões de arquivo ou as assinaturas
> de arquivos executáveis (incluindo aquela linha começando com "#!" no
> topo dos nossos scripts em shell, PERL, AWK etc.).
>
> Compare as duas versões do programa acima mencionado (em C++).
>
> // beethoven.cc -- SO de hoje
> // stdout deve ser redirecionado para
> // arquivo ou pipe.
> #include
> #include "beethoven.h"
>
> int main(int argc, char **argv){
> try {
> symphony S(argc, argv);
> std::cout << S;
> }
> catch(...){
> return 1;
> }
> return 0;
> }
>
>
>
> // beethoven.cc -- SO viajante
> #include "beethoven.h"
>
> symphony main(argc, argv){
> return symphony(argc, argv);
> }
Você gostaria de mais ou menos um SO orientado a objetos que não
seguisse padrões rigorosos? Algo dinâmico como a API de JAVA, diferente
de C++?
gethostbyname
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
