IMPLEMENTACÃO DE UM TERMINAL X PARA O SISTEMA

IMPLEMENTACÃO DE UM TERMINAL X PARA O
SISTEMA OPERACIONAL PLURIX
Luiz Fernado Huet de Bacellar
TESE
SUBMETIDA
PROGRAMAS
FEDERAL DO
DE
CORPO
DOCENTE
DA
COORDENAÇÃO
DOS
PÓS-GRADUAÇÃO DE ENGENHARIA DA UNIVERSIDADE
RIO
NECESSARIOS
AO
DE
JANEIRO
COMO
PARTE
DOS
REQUISITOS
PARA A OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIAS
EM ENGENHARIA DE SISTEMAS E COMPUTAÇÃO.
Aprovada por:
Prof. Newton Faller, Ph.D.
(presidente)
RIO DE JANEIRO, RJ - BRASIL
MARCO DE 1990
BACELLAR, LUIZ FERNANDO HUET DE
Implementação de um Terminal X para o Sistema
Operacional Plurix [Rio de Janeiro] 1990
IX,
104
p.
29,7
cm
(COPPE/UFRJ,
M.Sc.,
Engenharia de Sistemas e Computação, 1990)
Tese
-
Universidade
Federal
do
Janeiro, COPPE
1. Sistemas Computacionais Gráficos
I. COPPE/UFRJ
.
11. Título (série)
Rio
de
A m i n h a esposa A d r i a n a
AGRADECIMENTOS
Ao Doutor
Newton
Faller
pelo
apoio,
incentivo
e
orientação fornecidos no transcorrer deste trabalho.
Aos Doutores Edil severiano Tavares Fernandes e Júlio
Salek Aude pela honra de tê-los participando da banca.
Aos
meus Pais por terem tornado possível a chegada a
este ponto.
Aos Amigos do NCE que de
para
alguma
forma
contribuiram
a realização deste trabalho e ao NCE por ter tornado
viável o desenvolvimento e a implementação do trabalho.
Resumo da Tese apresentada a
requisitos
COPPE/UFRJ
como
parte
dos
necessários para obtenção do grau de Mestre em
Ciências (M. Sc.)
IMPLEMENTAÇÃO DE UM TERMINAL X PARA O
SISTEMA OPERACIONAL PLURIX
Luiz Fernando Huet de Bacellar
Março, 1990
Orientador: Prof. Newton Faller, Ph.D.
Programa: Engenharia de Sistemas e Computação
Este trabalho consiste na definição
e
implementação
de um sistema integrado de hardware e software, denominado
Terminal
X.
O
objetivo
principal
é dotar o Plurix, um
sistema operacional com filosofia ~ n i x ,de
uma
interface
gráfica com seus usuários.
Apresentamos
primeiramente
o
sistema
Window, que foi utilizado para a definição da
de janelas X
arquitetura
do ~erminalX implementado. A seguir demonstramos como foi
realizada a implementação do Terminal X e ao final fazemos
uma
avaliação
melhorias
do trabalho executado, sugerindo possíveis
ampliações no sistema.
Abstract of Thesis presented
fulfillment o£
to
COPPE/UFRJ
as
partia1
the requirements for the degree of Master
o£ Science (M. Sc.)
AN X TERMINAL IMPLEMENTATION FOR THE
PLURIX OPERATING SYSTEM
Luiz Fernando Huet de Bacellar
March, 1990
Thesis Supervisor: Prof. Newton Faller, Ph.D.
Department: Systems Engineering and Computer Science
This
work
implementation
o£
consists
a
o£
hardware
the
and
definition
software
system named X ~erminal.Its main purpose
is
and
integrated
to
provide
Plurix, an Unix-like operating system, with a graphic user
interface.
First
we present the X Window system, which was used
to define the architecture o£ the
explain
how
the
X
~erminal. Later
we
X ~erminalwas actually implemented and
finally we make an evaluation of the work done, suggesting
possible improvements and extensions to the system.
I
.
........................................
1
1.1.
Apresentação do Trabalho....................
1
1.2.
Motivação
Introdução
1.3.
1.4.
I1
.
...................................
Proposições Adotadas no Trabalho ............
Organização do Trabalho .....................
4
...............................
8
O Sistema X Window
11.1.
A Arquitetura de um Sistema de Janelas
11.2.
A Arquitetura do Sistema X Window
2
5
.....
..........
11.2.1.
Características Básicas ..............
11.2.2.
O Modelo Cliente-Servidor
............
11.2.3.
O Modelo Cliente-Servidor
no Sistema
X Window .............................
11.2.4.
Protocolo
O
para
X
Cliente-Servidor
11.2.5.
Os
X
11.2.6.
.
.....................
....................................
Suporte do Sistema Operacional para o
............................
Arquiteturas para um Terminal X
111.1.
Motivação
para
o
..................
Desenvolvimento
27
dos
...............................
28
Definição de Arquiteturas para Terminais X
30
Terminais X
111.2.
Comunicação
Recursos Fornecidos pelo Servidor
Sistema X
I11
a
111.2.1.
Arquitetura Tradicional Usando Rede.
111.2.2.
Arquitetura
Alternativa
Usando
....................
Interface Seria1
111.3.
IV.
Arquitetura
Utilizada
no
30
32
Terminal X
Implementado............................
34
Implementação do Cliente.........................
39
IV.1.
Implementação
da
Comunicação
com
o
Servidor X.................................
40
IV.l.l.
Implantação do Módulo para Conexão.
IV.1.2.
Implantação do Módulo para
IV.2.
Troca
..
41
de
Mensagens ...........................
48
Modificações Realizadas no Ambiente Plurix.
50
IV.2.1.
Modificações
nos
Compiladores
do
Plurix
...............................
50
IV.2.2.
Inclusão de Rotinas na Biblioteca C..
52
IV.2.3.
Implantação dos Arquivos de Inclusão.
53
IV.2.4.
Incompatibilidades com os Utilitários
V.1.
Definição do Hardware do Terminal X.........
59
V.2.
Implementação do Servidor X.................
63
V.2.1.
Arquitetura do Servidor X.............
65
V.2.2.
Implantação
da
Camada
DIX
no
Terminal X............................
V.2.3.
Implementação
da
Camada
OS
67
no
Terminal X............................
V.2.4.
Implementação
da
Camada
69
DDX
no
Terminal X............................
VI.
Testes e Avaliação da Implementação
..............
77
87
1.1. Apresentação do Trabalho
Este trabalho consiste na definição
e
implementação
de um sistema integrado de hardware e software, denominado
Terminal X, para dotar o sistema operacional Plurix de uma
interface gráfica com seus usuários. O sistema operacional
Plurix, um sistema com filosofia Unix, foi desenvolvido no
Núcleo de Computação Eletrônica da Universidade Federal do
Rio
de
Janeiro
e é executado no computador Pegasus-32X,
também desenvolvido no mesmo local [l - 2 - 31.
A definição da arquitetura Terminal
X
baseou-se
no
sistema de janelas X Window, desenvolvido no Massachusetts
Institute of Technology, EUA.
É
um sistema que fornece ao
seu usuário uma biblioteca de rotinas gráficas para
utilizadas
na
criação
recursos gráficos. O
de
aplicações
sistema
X
Window
serem
que necessitem de
tem
seu
código
colocado em domínio público.
O
hardware
do Terminal X foi definido de acordo com
as características da arquitetura a
ser
utilizada
e
de
forma a suportar todas as exigências quanto aos recursos a
serem
oferecidos
pelo
sistema
X
Window. O software do
Terminal X
foi
implementado
através
da
adaptação
das
funções do sistema X Window a arquitetura e ao hardware do
Terminal X. Para a adaptação do X Window ao Terminal X foi
necessário
modificar
seu
código
original e implementar
novos procedimentos de software para
a
interação
com
o
hardware definido.
O
Terminal
X apesar de ter sido implementado para o
sistema operacional Plurix, tem
versão
final, poder
ser
o
objetivo
ligado,
através
de,
de
em
sua
redes de
computadores, a qualquer sistema computacional que utilize
o
sistema
X
Window
como
interface
gráfica
com
seus
usuários.
O
Terminal
X
foi
desenvolvido
e
implementado no
Núcleo de Computação Eletrônica da Universidade Federal do
Rio de Janeiro.
I. 2 Motivação
O advento das estações de trabalho com suas telas
exibição
de
alta
resolução, trouxeram
interfaces gráficas para uma variedade de
interfaces
gráficas
uso e entendimento
gráficas
o potencial das
aplicações.
As
facilitam o processo de aprendizado,
das
proprietárias
aplicações.
Diversas
interfaces
surgiram, provocando dificuldades
no transporte de aplicações desenvolvidas
computacional
de
em
um
sistema
que utilize uma determinada interface, para
outro com interface distinta.
Diante deste fato, surgiu a necessidade da
uma
interface
gráfica
que
computacionais de diferentes
idéia,
foi
sistema
camadas
ou
tem
em
de
sistemas
fabricantes. Baseado
nesta
EUA o sistema de janelas X
desenvolvido nos
Window. Este
diversas
fosse padrão
busca
sua
níveis.
arquitetura
dividida
em
Essas camadas se sobrepõem
conforme aumenta a complexidade das
bibliotecas
gráficas
oferecidas ao usuário. A finalidade é permitir ao usuário
a utilização das diversas bibliotecas
de
acordo
com
as
necessidades de sua aplicação.
O
sistema X Window foi colocado em domínio público e
sua arquitetura passou a ser adotada
sistemas gráficos.
como
um
padrão
No entanto, somente a camada do nível
básico do sistema X Window passou a ser utilizada como
padrão
de
um
fato. Foi iniciada uma intensa discussão sobre
como seriam definidas as camadas de mais
utilizariam
em
as
rotinas
alto
nível
que
do nível básico para fornecer ao
usuário um ambiente gráfico sofisticado.
Concorrentemente
desenvolvido no
Surgiu então a
interface
NCE/UFRJ
necessidade
que
desenvolvimento
a
estes
o
de
foi
sistema operacional Plurix.
de
permitisse
acontecimentos,
dotar
aos
aplicações
o
Plurix
seus
de
uma
usuários
o
Porém,
o
gráficas.
Pegasus-32X, computador no qual o Plurix é executado, não
possui o suporte de um hardware gráfico.
foi
projetado
como
Como
o
Pegasus
computador protótipo em 1984 e ainda
hoje funciona desta forma, procurou-se uma solução que
se
tornasse independente deste computador.
A
solução
encontrada
veio
com o Terminal X. Estes
produtos surgiram nos EUA no final
basicamente
serviço de
como
de
sistemas computacionais
exibição
gráfica.
fato
O
e
1988
funcionam
dedicados
dos
ao
Terminais
X
utilizarem o sistema X Window para serem implementados foi
fundamental
sistema
X
na
escolha da solução. Somente as camadas do
Window
necessárias para
que
a
vão
até
o
a
básico
são
implementação dos Terminais X. Desta
forma, adotou-se uma solução gráfica
possibilitará
nível
para
o
Plurix
que
implantação das demais camadas que serão
executadas sobre a camada básica, assim que
for
definido
um padrão para estas.
Proposições Adotadas no Trabalho
1.3.
Duas
proposições
básicas
foram
adotadas
orientações no trabalho de desenvolvimento do
como
Terminal
X
para o sistema operacional Plurix.
A
primeira proposição e manter total compatibilidade
entre o software
sistema
de
implementado para
janelas
X
Window.
o
Terminal
X
e
Esta linha foi seguida a
partir do fato do nível básico do sistema X Window ter
tornado
um
padrão
em
ambientes
que
de
ser
se
oferecem recursos
gráficos. Sem tal compatibilidade, o Terminal X
inviável
o
se
torna
aproveitado para execução de aplicações
genéricas já existentes para o sistema X Window, inclusive
-5-
aquelas comerciais.
A
compatibilidade
aplicações
que
permite
tenham
sido
não
só
a
execução
implementadas
sistemas computacionais que utilizem o sistema
1.4.
em
X
de
outros
Window,
Organização do Trabal
Este
trabalho está organizado em mais seis capítulos
alem deste
sistema
de
introdução.
O
capítulo
I1
apresenta
o
de janelas X Window. São definidos os componentes
-6-
de um sistema de janelas e
principais
Window.
a
características
seguir,
da
Procura-se mostrar
envolvidos
neste
sistema
mostradas
arquitetura
os
e
são
as
do sistema X
principais
conceitos
suas dependências quanto ao
ambiente computacional no qual está sendo executado.
No capítulo I11 é feita a definição de um Terminal
e
dos
São
motivos
que proporcionaram o seu desenvolvimento.
explicadas
implementação
X
as
e
é
arquiteturas
mostrada
a
existentes
arquitetura
X
adotados na implementação do Terminal
para
sua
e o caminho
realizada
neste
trabalho.
Nos
capítulos
e
IV
V é explicado como foi feita a
implementação do Terminal X
Plurix.
capítulo
O
IV
para
o
descreve
sistema
a
implementação
recursos necessários para o desenvolvimento de
gráficas
no
implementação
X.
Terminal
da
parte
do
O
operacional
aplicações
capítulo V
sistema
X
dos
Window
trata
da
que
irá
interagir com o hardware definido para o Terminal X.
O
capítulo
ambiente
V I relata como foram feitos os testes no
X
Plurix/Terminal
implementado.
Procura-se
mostrar as principais metodologias adotadas e os problemas
encontrados
durante
análise
desempenho
do
este
do
trabalho.
sistema
É
feita também uma
desenvolvido
e
são
sugeridas áreas de atuação para possíveis melhorias.
Por
fim,
no
capítulo
VI1
são
apresentadas
as
conclusões tiradas em função do
das
proposições
mostrar o
caminho
iniciais
a
ser
trabalho
deste
seguido
desenvolvido
trabalho.
para
a
e
Procura-se
evolução
Terminal X como um sistema computacional gráfico.
do
CAPITULO 11
O SISTEMA X WINDOW
sistema
O
X
Window,
ou
simplesmente X, nasceu da
necessidade de se poder utilizar estações de
diferentes
fabricantes
de
uma
trabalho
forma transparente sob o
ponto de vista da aplicação a ser criada. O começo de
desenvolvimento data
do
ano
de
rotinas
gráficas
para as estações
fabricante.
baixo
nível
aplicações
que
A idéia inicial
[4].
sistema
de
janelas
com
que pudesse ser facilmente transportado
de
Esse
um
seu
no Massachusetts
1984
Institute o£ Technology (MIT) nos EUA
era desenvolver o nucleo de
de
trabalho
nucleo
llbit-mappedll
de
forneceria
permitiriam
o
rotinas
qualquer
básicas de
desenvolvimento
de
de mais alto nível que pudessem ser executadas
nas diversas estações de trabalho, praticamente
sem
ser
transporte,
foi
necessário a realização de adaptações.
Junto
a
idéia
da
facilidade
de
incorporada a possibilidade de, através do
usuário
uma
poder
rede
interagir
que
grande
estações
de
poderá
exibir
os
o
trabalho
e
porte, a aplicação gráfica de um
usuário que está utilizando qualquer um dos
rede,
X,
com um ambiente distribuído. Em
interligue
computadores de
sistema
resultados
elemento que possua uma tela gráfica.
em
elementos
qualquer
da
outro
A partir destas idéias foram
versões
do
desenvolvidas
sistema X Window. Este sistema aparece também
como seqüência aos sistemas de janelas
desenvolvidos
VGTS
e
W,
ambos
para o sistema V, um software para sistemas
distribuídos construído na Universidade de
[4].
diversas
Stanford,
EUA
De ambos, o sistema X herdou diversas características
como,
por
exemplo,
o conceito de hierarquia com relação
aos recursos oferecidos pelo sistema.
Com a versão 10.4 o sistema
pelo
MIT
como
X
Window
foi
colocado
um sistema de domínio público. Isto gerou
uma grande popularidade do mesmo, fazendo com que diversas
aplicações e variações fossem desenvolvidas em cima
sistema,
deste
dentre as quais podemos citar os Terminais X que
tratamos neste trabalho. A versão do sistema
X
utilizada
para o desenvolvimento do Terminal X foi a 11.2.
11.1.
As Partes de um Sistema de Janelas
Para
que
um
sistema
de
janelas
seja
'mportante primeiramente se fazer a
definição
janela e de alguns termos associados
[5].
Uma
formal
de
memória para armazenamento de uma imagem (I1frame
memoryI1 ou I1framebufferI1) é um buffer
refrescamento
da
utilizado
de
elétrons
tela
de
imagem
fósforo.
para
o
informação visual exibida em um monitor
através da varredura de um feixe
de
definido é
Uma
memória
convencional tem pelo menos a quantidade
sobre
'
uma
llbit-mappedll
necessária
para
armazenar um valor correspondente a cada pixel na tela de
exibição. Em
dividida
quais
várias
aplicações
tela
de
exibição
é
por software ou firmware em janelas, através das
diferentes tarefas
regiões
a
retangulares
desenhadas,
representa
dentro
armazenadas
um
são
e
executadas.
das
quais
manipuladas.
Janelas
são
imagens
são
Cada
janela
pedaço da memória de imagem. Janelas podem
se sobrepor na tela, com uma janela totalmente visível
e
outras parcialmente, ou totalmente, ocultas.
Um
sistema
controlar onde
tamanho
e
de
uma
janelas
janela
tem
como
aparece
funções básicas
na
tela,
qual
seu
alterar o seu conteúdo. Para desempenhar estas
funções um sistema de janelas é dividido
em
três
partes
segundo SCHEIFLER e GETTYS [ 4 ] :
Um
o gerenciador de janelas;
o gerenciador de entradas;
o sistema de janelas básico.
sistema
de
janelas, sob
o
ponto
aplicação, ou seja de um procedimento que
irá
de vista da
utilizá-lo
para exibir seus resultados, possui diversas interfaces de
acordo
com
SCHEIFLER
e GETTYS
implementadas pelas três partes,
compõem
é
[4].
Essas interfaces são
acima
mencionadas,
que
o sistema. Para se definir cada uma destas partes
importante primeiro analisar as interfaces de um sistema
de janelas.
A
interface de
programação
é
uma
biblioteca
de
rotinas
e tipos fornecida em uma determinada linguagem de
programação que permite a interação da
aplicação
com
o
sistema de janelas. As interfaces de programação podem ser
de
baixo
nível ou de alto nível, sendo ambas normalmente
desenvolvidas junto com o sistema de janelas básico.
A interface de
programação
é
dita
de
alto
nível
quando são desenvolvidas rotinas que utilizam a biblioteca
de
baixo nível para a elaboração de objetos gráficos mais
complexos do que as
esta
biblioteca.
compõem
a
primitivas
Normalmente
interface
de
gráficas
fornecidas
por
o conjunto das rotinas que
programação
de
alto
nível
é
denominado "toolkitVV
.
A interface com a aplicação é a interação mecânica do
usuário
com
a
aparência
determinada aplicação. Ela
visual
define
específica
como
a
de
uma
informação
é
apresentada e manipulada dentro da aplicação.
A
interface de gerenciamento é a interação mecânica
do usuário tratando com o controle geral do dispositivo de
hardware em si e dos
quais
o
sistema
de
dispositivos
de
entrada
são
os
janelas e as aplicações estão sendo
executadas. A interface de gerenciamento
aplicações
sobre
define
como
as
arrumadas e rearrumadas na tela, e como o
usuário troca de aplicação.
A interface com o usuário é a junção da interface com
a aplicação e a interface de
gerenciamento.
A
interface
com
o
usuário
responde
por
toda
a
interação entre o
usuário e o sistema computacional por ele
utilizado
para
executar a aplicação desejada.
Uma vez feita a análise das funções das interfaces de
um sistema de janelas, pode-se definir como as três partes
nas
quais
um
sistema
de
janelas
é
dividido,
irão
implementar as funções de cada interface.
O
gerenciador
interface
de
de gerenciamento.
É
como uma aplicação, utiliza a
interface
de
programação
posicionamento das
implementa
janelas
janelas
parte
da
apenas um programa que, tal
biblioteca
para
de
controlar
das
rotinas
da
o tamanho e o
aplicações
na
tela
de
exibição. Ao gerenciador de janelas é dada uma autorização
especial
para
realizar
esta
função, autorização que as
demais aplicações não possuem.
O gerenciador de janelas tipicamente permite que
aplicação
uma
mova ou redimensione as suas janelas e controle
a pilha de janelas que se sobrepõem de acordo
pré-definidas.
O
conjunto de
com
regras
regras que especificam os
tamanhos permitidos e a posição das janelas é
a
política
para o layout das janelas de um sistema.
O
gerenciador
de
en radas implementa o restante da
interface de gerenciamento. Ele
controla
qual
aplicação
enxerga uma sinalização proveniente de um dos dispositivos
de
entrada
do
sistema, normalmente
um
teclado
ou um
llmousell.
A finalidade do gerenciador de entradas é
que
aplicações
evitar
que não estejam ativas ou associadas a um
dispositivo de entrada não sejam interrompidas por
sinais
enviados por este dispositivo.
A
principal
parte
de
um
sistema
janelas é o
de
sistema de janelas básico. Ele é o substrato
no
qual
as
aplicações e os gerenciadores de janelas e de entradas são
construídos. No sistema de janelas básico estão as rotinas
que
realizam
a interface do sistema com o dispositivo de
hardware em si e com os dispositivos de entrada.
Para a implementação do
trabalho,
foi
utilizada
básico do sistema
biblioteca
que
X
a
parte
Window,
As
demais
janelas
o
gerenciador
definido
neste
do sistema de janelas
junto
partes
com
como
de
as
rotinas
o
gerenciador
entradas,
transportadas automaticamente para o
básico,
X
da
implementam a interface de programação de
baixo nível.
e
Terminal
sistema
por
de
de
serem
janelas
e a interface de programação de alto nível, que é
implantada sobre
a
interface
de
programação
de
baixo
nível, não fazem parte do escopo deste trabalho.
A Arquitetura do Sistema X Window
11.2.
11.2.1.
O
~aracteristicasBásicas
desenvolvimento do sistema X Window foi baseado em
duas importantes características quanto a sua
arquitetura
A
[4].
primeira
que
é
as
aplicações devem
ser
independentes do sistema computacional no qual estão sendo
executadas. A
segunda,
computacionais de
o
uma
sistema
deve
utilizar
redes
forma transparente sob o ponto de
vista da aplicação executada.
Sobre
a
independência do
sistema
quanto
X
ao
computador no qual o sistema está sendo executado, existem
diversos fatores a se ressaltar. Ao se utilizar um sistema
com
este
tipo
de independência, pode-se transportar uma
aplicação de um sistema computacional para outro
distinto
praticamente
sistemas
sem
modificações.
Caso
os
dois
executem um sistema operacional compatível
m%smo
e
possuam
um
processador central, o transporte pode ser feito ao
nível do programa objeto da aplicação.
A independência quanto
obtida
ao
sistema
computacional
sistema X através da padronização da interface
no
de programação. Através desta padronização, uma
encontra
é
as
mesmas
funções
gráficas
qualquer sistema X independentemente das
aplicação
disponíveis
em
característica
do dispositivo de exibição gráfica suportado pelo sistema.
Quanto
a
transparência
computacionais, o sistema X
sejam
executadas
em
um
permite
rede,
Normalmente
possivelmente
estes
dois
acesso
que
a
redes
aplicações
que
determinado computador da rede,
possam exibir seus resultados em
desta
de
algum
uma
sistemas
outro
estação
são
de
computador
trabalho.
distintos,
com
arquitetura e sistema operacional diferentes.
Estas
características
sistema X a se basear no
levaram
modelo
a
arquitetura
do
cliente-servidor. Neste
possível implementar naturalmente um sistema de
modelo,
é
janelas
com
uma
filosofia que
coincide
com
as
duas
características citadas.
O Modelo Cliente-Servidor
11.2.2.
conceito
O
do modelo cliente-servidor é definido em
COMER [ 6 ] , a partir de um ambiente onde
interligando
diversos
cliente-servidor é uma
exista
uma
rede
sistemas computacionais. O modelo
extensão
natural
da
comunicação
entre processos em um único sistema computacional.
termo
O
servidor
se aplica a qualquer programa que
ofereça um serviço que possa ser
rede.
O
servidor aceita
serviço e retorna o
as
resultado
requisitado
através
da
requisições, realiza o seu
ao
sistema
que
gerou
a
requisição.
Um
programa
em execução é denominado cliente quando
ele envia uma requisição a um servidor através da
Normalmente
rede
e
os servidores são programas aplicativos,
ou seja, processos, sendo
executados
em
um
determinado
sistema. Desta forma, o servidor de um determinado serviço
pode
ser executado em um sistema compartilhando tempo com
outros processos, ou pode ser executado em
computacional específico
algum
sistema
para ele, podendo ser inclusive
em computadores pessoais.
Múltiplos servidores podem oferecer o mesmo serviço e
podem
ser
executados
na
mesma
máquina
ou
em
várias
máquinas. Isto acarreta que servidores de um mesmo serviço
que
estejam
em
máquinas
distintas,
distintos, um para cada máquina.
cada
uma
mesmo
destas
máquinas,
subendereço
ou
No
estes
porta.
O
tenham
entanto,
endereços
dentro
de
servidores possuem um
número
das
portas
de
servidores bastante difundidos e conhecidos pelos usuários
da
rede
é
fixo,
de
forma
que ao se desejar um destes
serviços, conhecendo-se o endereço da máquina onde está
servidor,
basta
enviar
requisições
para
a
o
porta
correspondente a este servidor.
O Modelo Cliente-Servidor no Sistema X Window
11.2.3.
O modelo cliente-servidor no sistema
forma
X
funciona
de
a manter a independência da aplicação em relação ao
hardware
que
dispositivo
a
exibe
físico
de
[4].
Assim
exibição
para controlá-lo, de forma a
sendo,
para
cada
irá existir um servidor
manter
a
aplicação/cliente
independente do dispositivo.
Um
dispositivo
constituído
de
um
físico
ou
mais
é
de exibição, ou lldisplayll,
monitores
que
utilizem
a
tecnologia de exibição por varredura, de um teclado, de um
llmouselle
do hardware para controle destes dispositivos.
Um sistema computacional pode possuir mais de um lldisplayll
e nesse caso tem-se um servidor sendo executado para
lldisplaytl.
E
cada
importante notar que um l1displayUpode ter
mais de um monitor
a
ele
ligado,
desde
que
todos
os
monitores sejam controlados por um hardware único.
Uma
aplicação/cliente
através de qualquer
canal
se
de
comunica
com um servidor
comunicação
bidirecional,
confiável e que se possa enviar mensagens de tamanho igual
a
um byte. Existe um protocolo definido pelo sistema X, o
protocolo X, que
faz
a
comunicação
do
cliente
com
o
servidor através do canal de comunicação. Se o cliente e o
servidor
estão na mesma máquina, o canal pode ser baseado
em qualquer mecanismo de comunicação entre processos. Caso
contrário, se o cliente e o
distintas
interligadas
servidor
estão
em
máquinas
através de uma rede, é necessário
estabelecer uma conexão entre os dois através da rede.
O fato do sistema X Window não necessitar de um canal
de comunicação complexo para a comunicação entre o cliente
e o servidor, faz com que o sistema possa ser utilizado em
diversos ambientes. Como exemplo, pode-se citar o
protocolo
X
sobre
os
protocolos
(I1TransmissionControl Protocol /
de
Internet
uso
rede
do
TCP/IP
ProtocolI1) e
DECNET (I1DigitalEquip. Corp. Network Protocol1I) [ 4 ]
.
Pode-se ter no sistema X vários clientes com conexões
abertas
simultaneamente a um Único servidor e um cliente
pode abrir conexões a vários servidores ao mesmo tempo.
tarefa
básica
diversos
do
clientes
controla,
e
servidor
em
é multiplexar os pedidos dos
relação
separar
as
ao
I1displayl1 que
sinalizações
de
ele
entrada
enviando-as para
provenientes do teclado e do llmousell,
cliente
apropriado.
utilização do
De
visualização
A
sistema
X
Window
é
de
um
exemplo
mostrada
na
do
de
figura
fundamentais para
interfaces
com
hardware
são
o
usuário.
colocadas
no
se
hardware. Além disso, o
e
servidor
comunicação, fazendo
realmente
é
implementar
Todas
seja
protocolo
que
o
fazendo
com
independente
de
independente
com
diversas
as dependências com o
servidor
cliente/aplicação
qualquer
janelas
sistema X Window. Ele fornece os recursos e os
mecanismos
cliente
o
acordo com as definições do item 11.1, o servidor
do sistema X, ou servidor X, engloba o sistema de
básico
A
deste
comunicação
do
meio
que
entre
físico de
cliente/aplicação
seja
independente da máquina na qual o servidor está
sendo executado.
O sistema X fornece uma interface de
lioteca X
[7],
na
qual
estão
todas
necessárias para que o cliente/aplicação
com
o
servidor
e
solicite
programação,
faça
a
as
rotinas
a
conexão
as tarefas desejadas. Ao se
ligar a aplicação as rotinas fornecidas pela biblioteca X,
a forma de comunicação com o servidor se torna
totalmente
CLIENTE
1
CLIENTE 2
COMPUTADOR 1
FIGURA
.
I1 1
-20-
transparente para
o
cliente.
Nas rotinas da biblioteca
estão todas as dependências quanto ao mecanismo
utilizado
para
enviar
as
mensagens
aplicação utiliza estas rotinas para
servidor
ou
do
que
será
protocolo X. A
especificar
a
qual
servidores ela fará conexão para exibir seus
resultados.
11.2.4.
O Protocolo X para a Comunicação Cliente-Servidor
O protocolo X [7] foi projetado de forma
servidor
está
cliente,
ele
clientes.
esperando
deve
poder
por
uma
resposta
continuar a
que,
se
o
de um certo
servir
outros
Isto evita que, no caso de um cliente com erro,
troca da ordem dos bytes vindos do cliente. Caso as ordens
que
sejam iguais nada é feito, evitando assim o lloverheadll
existiria se a ordem dos bytes na comunicação fosse fixa e
tanto
o
cliente quanto o servidor estivessem em máquinas
com ordem oposta a ordem fixada.
Além
do
comunicação,
problema
existe
quanto
a
ordem
protocolo
byte
na
o problema quanto ao alinhamento das
informações que são transmitidas através do
comunicação
de
protocolo
de
entre cliente e servidor. Isto é resolvido no
fazendo
X
transmitidas
com
que
as
informações
em blocos com tamanhos múltiplos de
Além disso, quantidades de 16 bits e
32
sejam
32
bits.
bits dentro de
bloco são sempre alinhadas em espaços de 16 bits e
32
um
bits
respectivamente. Isto significa que, no protocolo X, ao se
transmitir
uma
informação de tamanho de um byte e depois
outra de 16 bits, entre as duas irá sempre uma
de
tamanho
igual
informação
a um byte sem nenhum significado. Este
byte é denominado llpadll.
O protocolo X é dividido em quatro tipos
de
formato
para a transmissão de informações [ 7 ] :
O
.
formato para requisições;
.
formato para respostas;
.
formato para erro;
.
formato para evento.
formato para as requisições do cliente ao servidor
é sempre de um llheaderll
de quatro bytes, seguido
de
zero
ou
mais
bytes de dados adicionais. O I1headerwé composto
de quatro bytes, sendo um com o
dois
que
indicam
o
tamanho
llopcodell
da
requisição,
da informação adicional em
unidades de quatro bytes e um byte genérico.
O formato para resposta do servidor ao cliente contém
sempre
bytes seguidos de zero ou mais
32
adicionais.
bytes
de
Nos 32 bytes fixos existe um campo de
dados
bits
32
que diz o número de bytes adicionais em unidades de quatro
bytes.
O formato
relação
a
para
alguma
comunicar
erro
requisição, tem
bytes. Um dos bytes dá
informações como
um
o
código
do
ao
cliente
sempre tamanho de
erro
e
os
32
demais
o llopcoden
da requisição que falhou e o
número de seqüência desta requisição. No sistema X,
as
em
requisições entre
um
cliente
e
um
todas
servidor
são
cliente
que
numeradas seqüencialmente.
O formato para um servidor notificar um
algum evento ocorreu, tem também tamanho fixo de
Todos
os
32
bytes.
eventos possuem um byte com o código do tipo de
evento que está sendo comunicado.
11.2.5.
Os Recursos Fornecidos pelo Servi
0s recursos básicos fornecidos pelo
janelas,
fontes
de
servidor
X
são
caracteres, cursores controlados por
llmousell
e imagens não visíveis na tela (I1pixmapsl1)[ 4 ] .
O
cliente
requisita
a
criação
de um recurso e o servidor
aloca o recurso ao cliente, retornando um identificador do
recurso. Qualquer cliente que conheça o
um
recurso
mesmo
que
cliente.
criar
pode
este
Isto
usar
que
tenha
permitido
gerenciadores de
aplicações
irão
de
e manipular o recurso livremente,
recurso
é
identificador
sido
criado
por
outro
com a finalidade de se poder
janelas
utilizar
independentemente
as
janelas.
das
Além disto,
pode-se ter no sistema X, aplicações desenvolvidas através
de
múltiplos
processos
que
compartilham
os
mesmos
recursos.
Todas
as
operações
em
parâmetro o identificador do
aplicação
conexão
um
recurso
recurso.
devem ter como
Desta
forma, uma
pode multiplexar o uso de várias janelas em uma
única
com
computadores.
um
servidor, através
Similarmente,
cada
da
evento
rede
gerado
servidor irá conter o identificador da janela
na
de
pelo
qual
o
evento ocorreu.
As
janelas e as imagens não visíveis na tela são, no
sistema X Window original, regiões de
memória
acessíveis
através de descritores de arquivos fornecidos pelo sistema
operacional. A diferença entre as janelas e as imagens não
visíveis
e
que
as
bufferl'do sistema
outras
estão
na
primeiras
gráfico
memória
do
de
estão
situadas no I1frame
computador,
trabalho
enquanto
do mesmo sistema
computacional. Isto significa que as imagens não
só
aparecerão
as
visíveis
na tela de exibição caso sejam copiadas em
alguma das janelas que estejam visíveis nesta tela.
É
importante
hierarquia
de
ressaltar
janelas
no
também
o
X
sistema
conceito
No
[4].
hierarquia, está a janela raiz que cobre toda
a
de
topo da
tela
de
exibição e é criada pelo próprio servidor. Nas aplicações,
as
janelas
de mais alto nível na hierarquia, são criadas
como subjanelas, ou
janela
de
empilhadas
filhas,
da
janela
uma
aplicação, suas
em
qualquer
arbitrariamente.
ordem
modelo
O
da
raiz.
subjanelas
e
se
hierarquia
Dada
uma
podem
ser
sobreporem
de janelas do
sistema X procura, desta forma, representar uma
pilha
de
papéis sobre uma mesa de trabalho.
Quando
uma
janela
outra janela, diz-se
que
cobre parcialmente ou totalmente
a
primeira
está
ocultando
a
segunda. Uma janela filha pode ocultar totalmente a janela
podendo inclusive possuir dimensões maiores que a da
mãe,
m ã e . Neste caso, a janela filha
sempre
restrita
a
área
terá
ocupada
sua
parte
visível
por sua m ã e e sua área
excedente ficará invisível. A janela raiz limita o tamanho
máximo de uma janela qualquer. Nenhuma
dimensões
maiores
janela
terá
suas
que a da janela raiz, que cobre toda a
tela de exibição do monitor ligado ao servidor do
sistema
X Window.
11.2.6.
Su
e do Sistema Operacional para o Sis
O sistema X Window foi desenvolvido, desde sua versão
inicial,
em
computadores
que
operacional Unix. O sistema Unix
utilizavam
utilizado
sistema
inicialmente
o desenvolvimento foi o Unix 4.2 BSD da Universidade
para
de Berkeley, EUA. A partir da versão 11.2
foi
o
do
sistema
X,
utilizada a versão 4.3 do Unix de Berkeley [8] para o
desenvolvimento. A facilidade de transporte de
entre
sistemas Unix-like
e
o grande número de usuários
deste tipo de sistemas, fez com
que
transportado
outros
e
adaptado
utilizassem sistema
softwares
para
o
operacional Unix
sistema
X
fosse
computadores
que
não
que
fosse
o
desenvolvido em Berkeley.
O
sistema
X pode ser também implantado sobre outros
preparado para utilizar rotinas do sistema que implementam
três famílias de protocolos para comunicação [ll]: o I1Unix
domainl' para
a
comunicação
local, ou
seja, quando o
cliente e o servidor estão num mesmo computador; o
e
TCP/IP
o DECNET para a comunicação externa, quando o cliente e
o servidor estão em máquinas distintas.
Utilizando as rotinas de comunicação oferecidas pelo
sistema
operacional, o sistema X se torna independente do
protocolo que está sendo utilizado para a
cliente
com
o
rotinas para
a
servidor. Nos
comunicação
computadores, será
comunicação do
sistemas que não oferecem
entre
necessário
processos
e
entre
criá-las de alguma forma
para que se possa fazer a implementação do sistema X.
Além das rotinas
para
comunicação
oferecidas pelo
sistema Unix 4.3 BSD, o sistema X utiliza um grande número
de
outras rotinas oferecidas por este sistema operacional
como suporte durante a
execução
de
um
processo.
Estas
rotinas muitas vezes não são padrão entre outros sistemas
Unix-like. Desta forma, ao
sistema
X
se
transportar
e
adaptar
o
para outros sistemas operacionais Unix-like, é
necessário criar novas rotinas no sistema que irá suportar
o X Window e/ou
trechos
em
que
modificar
são
o
código
do
sistema X
nos
chamadas algumas rotinas oferecidas
pelo sistema operacional.
CAPITULO 111
ARQUITETURAS PARA UM TERMINAL X
A idéia de um Terminal X tem como
finalidade
básica
dotar um sistema computacional ou uma rede de computadores
de
um
serviço
de
exibição
gráfico.
O nome Terminal X
origina-se do inglês ItXTerminalt1que por sua vez
expressão
da
I1XWindow Terminalt1.Essa expressão confunde-se
com outras como "X Window
Display
vem
Display
StationI1 [12] na
Stationtt ou
intenção
de
I1Network
representar
a
finalidade básica descrita de um Terminal X.
Os Terminais X surgiram nos EUA no final de 1988 [12]
e situam-se entre os
terminais
de
texto
alfanuméricos,
semigráficos ou gráficos, e as estações de trabalho com ou
sem
disco. Seu surgimento só foi possível graças a grande
difusão, através dos usuários de sistemas
computacionais,
do
se
sistema
X
Window.
Os
Terminais
X
baseiam
na
arquitetura deste sistema para serem implementados.
Uma
das
proporcionar
estação
de
complexidade
maiores
ao
usuário
trabalho
de
vantagens
um
ambiente
gráfica
hardware
dos
e
Terminais
é
similar ao de uma
possuindo
custo
X
no
entanto
inferiores
[13].
Utilizando um Terminal X, um usuário pode entrar na rede a
qual o terminal está
ligado
e
ter
acesso
as
diversas
aplicações em diferentes llhostsll,
exibindo-as em múltiplas
janelas na tela do monitor gráfico do terminal.
111.1.
Motivação para o Desenvolvimento dos Terminais X
A
grande
utilização
interface com o usuário
aqueles
que
utilizam
do
de
sistema
X
Window
como
computadores, principalmente
sistema
operacional com filosofia
Unix, fez com que fosse colocado em prática o conceito
utilização
da
um ambiente gráfico distribuído. O usuário
de
de um determinado sistema, que esteja ligado a uma rede de
computadores e que interage com seu computador através
sistema
X,
pode
executar
aplicações gráficas em outros
sistemas que estão ligados a rede e exibir
no
seu
computador.
os
resultados
Isto é possível pois a utilização do
modelo cliente/servidor pelo sistema X Window permite
a
do
que
aplicação possa ser executada em sistemas distintos ao
sistema que executa o servidor X
e
que
irá
exibir
os
resultados da aplicação.
Este tipo de ambiente distribuído, é desejável quando
se
está
ligado
a
uma
rede
através
trabalho com recursos gráficos, de
processamento, e
a
aplicação
executada de forma viável, um
desempenho
maior
utiliza-se
os
processamento
do
que
sistemas
que
baixa
gráfica
sistema
o
de
de uma estação de
da
capacidade de
exige,
para ser
computacional
estação.
maior
Neste
com
caso,
capacidade
de
estejam ligados a rede para a execução
da aplicação. Através
do
protocolo
X,
a
aplicação
se
comunica
com
o
servidor X que é executado na estação de
trabalho e exibe os resultados nesta.
Esta forma de se utilizar as estações de trabalho com
capacidade gráfica, fez com que as
ser
estações
passassem
a
utilizadas com duas finalidades práticas. A primeira,
na qual a
estação
aplicação
pode
gráfica
executar
não
ao
muito
é
mesmo
tempo,
cliente/aplicação
como
o
servidor
finalidade,
qual
o
cliente/aplicação
complexo
na
e
exige
processamento
um
para
sistema
de
executá-lo,
a
complexa,
gráfico.
maior
tanto
bastante
é
de
funciona praticamente como um terminal/servidor
o
segunda
A
capacidade
estação
a
de
trabalho
ligado
a
rede. Este servidor recebe através da rede, dados enviados
por outro sistema para serem exibidos na sua tela gráfica.
A
utilização
do
sistema
X
Window
no
segundo
caso é
fundamental pois a padronização do protocolo X permite que
implantada,
a
possa
a execução da aplicação. Além
ser
utilizado
para
biblioteca
X
qualquer sistema que possua
disto, qualquer estação de trabalho que esteja
executando
o servidor X, pode ser utilizada para exibir os resultados
de qualquer aplicação.
A
utilização
das
estações
de
trabalho, em certas
aplicações, como terminais/servidores gráficos de uma rede
de computadores, motivou a idéia da criação de um
mais
simples
que
a
própria estação. Este sistema teria
como finalidade ser um servidor gráfico dentro do
X
Window
e
sistema
sistema
receberia requisições de serviços através
-30-
protocolo X
estivesse
transmitido pela
ligado
A
[14].
fato de não ser necessário
controlá-lo.
O
programa
rede
a
qual
o
servidor
sua simplicidade residiria no
um
sistema
servidor
operacional
seria
o
para
único a ser
executado pelo hardware deste sistema gráfico. Além disto,
111.2.1.
Ar
icional Usando Rede
A arquitetura tradicional de um Terminal X origina-se
naturalmente da arquitetura de
uma
simplificada, de
o que foi descrito no item
acordo
com
estação
de
trabalho
anterior.
Um
basicamente
de
e
nesta
arquitetura,
para
dar
suporte
ao
sistema
X
para suportar a comunicação através de uma rede
de computadores [15]. Além disto, possui
média
consiste
um processador e memória local executando
as funções necessárias
Window
X,
Terminal
ou
alta
um
monitor
de
resolução, monocromático ou colorido, um
teclado, um dispositivo de
apontamento
e
posicionamento
(flmouself),
e uma interface que permita a conexão a redes
de computadores, normalmente através do
Pode
padrão
Ethernet.
também possuir um processador auxiliar para realizar
as tarefas de exibição gráficas.
Tal como
Terminais
as
estações
também
X
de
trabalho
sem
disco,
não o possuem e, além disto, não são
dotados de um sistema operacional. Assim sendo, também
forma
similar
da
de
as estações sem disco, a carga do programa
necessário para gerenciar e executar suas funções é
através
os
feita
rede. Para isto, o Terminal X se comunica com
um computador, através de um programa de carga do sistema,
que deve estar preparado para fornecer o programa servidor
necessário ao terminal. O nome (endereço) deste computador
é solicitado durante a inicialização dos ~erminaisX.
forma
alternativa
para
a
carga
deste
servidor é através da utilização de ROM,
uma
mesmo
quando
Uma
programa
é
feita
cópia do programa armazenado na ROM para a memória de
trabalho do Terminal X [16].
Basicamente um
sistema
X
e
Terminal
X
executa
o
servidor
do
é capaz de se comunicar com vários sistemas
computacionais
protocolo
interligados
padrão,
em
rede,
normalmente
implementado em um meio Ethernet.
padrão
o
É
através
TCP/IP
em cima
ou
do
executado
em
o
cliente/aplicação,
determinado
que
computador, e
DECNET,
protocolo
está
sendo
o servidor, no
Terminal X. O fato da comunicação com outros
computadores
feita normalmente através de Ethernet, onde a taxa de
transmissão de dados é da ordem de 10 Mbps, é
para
o
fundamental
desempenho do sistema X quando executado de forma
distribuída através dos Terminais X. A velocidade com
as
um
utilizado na rede que são trocadas as mensagens do
protocolo X entre
ser
de
mensagens
servidor e,
são
que
trocadas entre o cliente/aplicação e o
conseqüentemente,
a
velocidade
com
que
a
aplicação exibe os resultados, depende diretamente da taxa
de transmissão do meio de comunicação entre os Terminais X
e
os
sistemas
computacionais
que executam a aplicação.
Quanto maior for esta taxa, menor será
o
tempo
entre
a
execução da aplicação e a visualização dos seus resultados
em um Terminal X.
111.2.2.
Arquitetura Alternativa Usando Interface Serial
Uma
similar
arquitetura
a
arquitetura
processador
e
memória
teclado e de um
invés
de
se
para
tradicional,
um
Terminal X é
utilizando-se
um
local, além de um monitor, de um
I1mouser1.Porém,
nesta
arquitetura,
ao
utilizar a interface para a interligação do
Terminal X a outros
conexão
alternativa
através
sistemas
computacionais
baseada
na
de rede, utiliza-se uma interface seria1
do tipo RS232-C para interligá-lo diretamente a
um
único
sistema computacional [ 1 5 ] . Este sistema é que está ligado
através
de
uma
rede
a
outros
sistemas. As aplicações
distribuídas através da rede, se comunicam com o
Terminal
X através deste sistema computacional.
servidor
O
X
separado em duas partes. Uma sendo
é
executada no Terminal X e a outra executada no
ao
qual
computador
o terminal está ligado. A divisão é feita de tal
forma que através da linha de comunicação serial que
o
X
Terminal
ao
computador, só
passam
liga
informações
necessárias para a exibição gráfica na tela do monitor
Terminal
X
do
e sinalizações de entradas provenientes deste
~151.
Nesta arquitetura, para que não fique muito
apresentação
do
resultado
de
uma
receber
através
comandos
capacidade
da linha serial comandos gráficos de
alto nível. Isto ocorre, pois caso
somente
gráficos
para
o
o
X
Terminal
uma
pixels
imagem
levaria
processador
dezenas
de
segundos.
Desta
forma,
de
O
do Terminal X deve executar um programa capaz
desenhe
traçado
serial
de, por exemplo, centenas de milhares de
de receber comandos gráficos do tipo trace reta,
área,
receba
traçado de pixel por
pixel da tela a ser exibida, a passagem pela linha
de
a
aplicação na tela do
Terminal X, é necessário que o terminal possua
de
lenta
padrão
imagens.
preencha
e outros, para diminuir o tempo de
Normalmente, coloca-se
junto
ao
-34-
gráfico dedicado ao traçado de primitivas gráficas. Com
utilização
a
do processador gráfico, as primitivas gráficas
são transmitidas, através
da
linha
serial, no
formato
próprio para o processador.
arquitetura para a implementação de Terminais X
Esta
possui uma vantagem quanto a complexidade
relação
a
arquitetura
tradicional.
interface para a conexão a redes de
rotinas
para
implementar
esta
e
o
Por
custo
não
possuir
computadores nem
menos
alternativa
complexo
arquitetura
do
que
tradicional.
gráficos
e
que
computadores. A conexão de
seriais
aqueles
Sua
aplicação
porte
estejam
um
implementados
típica
que
não
ligados
Terminal
X
a
a
pela
é
em
possuam
redes
de
interfaces
destes sistemas, permitiria ao usuário do sistema
o acesso a um
sistema
da
têm um menor custo e um hardware
sistemas computacionais de médio
recursos
as
conexão através de algum
protocolo padrão, os Terminais X implementados através
arquitetura
em
X
exibí-las
ambiente
Window
em
gráfico
podendo
janelas
na
distribuído
executar
tela
do
através
do
múltiplas tarefas e
monitor
gráfico
do
Terminal X.
111.3.
Arquitetura Utilizada no Terminal
O
Implementado
objetivo final deste trabalho é a implementação de
um Terminal X, baseado na arquitetura tradicional descrita
no item 111.2.1, para o
sistema
sistema
operacional
Plurix,
um
com filosofia Unix desenvolvido no NCE/UFRJ. Para
-36Somente após a implementação desta estação de
que
será
possível
interligar
computacional, que execute
o
trabalho
é
o Terminal X a um sistema
Plurix
e
que
possua
uma
interface de comunicação padrão Ethernet.
Os
dois motivos anteriores, levaram então a que este
trabalho passasse por uma etapa intermediária na
Terminal
X
se
baseia
na
arquitetura
utilizada
na
o
alternativa,
utilizando interface serial, descrita no item
arquitetura
qual
A
111.2.2.
implementação tem
ainda
uma
variação em relação ao que foi definido neste item uma vez
que, por não ser possível ligar o Pegasus-32X a
computadores,
não
possível
e
clientes/aplicações por
outros
redes
distribuir
sistemas
de
os
computacionais.
Desta forma, esses clientes devem ser executados também no
Pegasus.
definição
A
do
hardware do Terminal X incluindo um
processador gráfico, capaz de executar diversas primitivas
gráficas,
tornou
utilizando
a
viável
a
arquitetura
implementação do
alternativa.
sistema X Window foi dividido em duas
com
a
definição
desta
O
servidor
partes,
arquitetura,
terminal
sendo
do
de
acordo
uma
delas
executada no Pegasus-32X e a outra no hardware do Terminal
X, conforme e mostrado na figura
entre
as
duas
gráficos e
hardware
a
do
partes
se
sinalizações
Terminal
(111.1).
restringe
de
A
comunicação
somente a comandos
entrada
provenientes
do
X. 0s comandos gráficos utilizados
são transmitidos a nível das
primitivas
gráficas
que
o
I
I
CLIENTE
"7
I
TERMINAL X
I
I
I
I
I
FIGURA
.1
processador
gráfico
executa.
maneira transmitir ponto
exibidas
na
tela
do
a
Não
ponto
monitor
do
é
as
necessário
desta
imagens
serem
a
terminal, e com isto,
diminui-se o fluxo de informações passadas entre o Pegasus
e o Terminal X. Desta forma, é possível interligar as duas
partes do servidor X através de uma linha
seria1
com
transmissão
velocidade
é
a
taxa
de
máxima
9600
das
bps.
de
comunicação
Essa
taxa
interfaces
de
seriais
existentes no Pegasus-32X.
A
segunda
etapa
só
se
tornará
possível,
ao ser
implementada tanto a estação de trabalho com interface
comunicação
padrão
Ethernet,
como
o
protocolo
TCP/IP para conexão do Plurix a redes de
implementação da
primeira
de
padrão
computadores.
A
etapa foi feita de forma mais
transparente possível quanto a arquitetura utilizada, para
que a passagem para a segunda etapa possa
ser
feita
sem
IMPLEMENTAÇÃO DO CLIENTE
O trabalho de implementação do cliente do
sistema
X
Window consiste fundamentalmente em implantar a biblioteca
X
no
sistema
computacional onde o cliente/aplicação irá
ser executado. A biblioteca X, que implementa a
de
interface
programação de baixo nível dentro do sistema X Window,
fornece
as
rotinas
necessárias
para
que
O
cliente/aplicação faça a conexão com o servidor X desejado
e solicite todas as tarefas necessárias para a exibição de
seus objetivos.
implantação
A
da
biblioteca X dentro de um sistema
computacional, permite
a
clientes dentro
sistema.
deste
implementação
deverá, depois de compilado, ser
biblioteca
X
necessárias
Cada
programa
ligado
para
o
de
as
sua
diversos
cliente
rotinas
da
execução.
O
procedimento é similar ao das bibliotecas existentes para
as
diversas
linguagens
de programação, utilizadas pelos
programas escritos nas respectivas linguagens.
A biblioteca X é fornecida junto as demais partes
sistema
pela
X
Window
biblioteca
X
original.
estão
do
Todas as rotinas oferecidas
escritas
na
linguagem
de
programação C e utilizam diversas rotinas, inclusive as de
-40-
chamada
ao sistema, existentes na biblioteca C do sistema
Unix 4.3 BSD. O trabalho de implantação
consiste
na
adaptação
de
suas
da
rotinas
existente no sistema operacional sobre
o
biblioteca
X
a biblioteca C
qual
ela
será
implantada, seguido da compilação dos diversos modulos que
A primeira etapa da implantação da
sistema
Pegasus/Plurix
consiste
sistema, o mecanismo original de
com
o
servidor
X.
módulos onde estão
A
em
biblioteca
adaptar
comunicação
X
para
do
no
este
cliente
biblioteca X original possui dois
todas
as
rotinas
responsáveis pela
comunicação entre o cliente e o servidor:
- XC0nnDis.c;
- X1ibInt.c.
Destes
dois
módulos,
somente o módulo XConnDis.~possui
chamadas a rotinas do sistema operacional que tratam com o
protocolo de comunicação a ser utilizado
entre
o
cliente
e
o
para
o
diálogo
servidor. O módulo XC0nnDis.c é o
responsável pela implementação da conexão do cliente com o
servidor. As demais trocas de mensagens entre o cliente
o
e
servidor, para as quais utiliza-se as rotinas do módulo
XlibInt.~,são feitas de forma transparente quanto ao tipo
de protocolo utilizado.
operacional
Isto
fornece um
possível o acesso ao
acontece, pois
descritor
canal
de
através
comunicação
o
do
sistema
qual
criado
é
pela
conexão do cliente com servidor. O cliente passa a receber
e
enviar
descritor.
mensagens
mensagens
Cabe
que
ao
para
sistema
passam
o
servidor
operacional
através
deste
formatar
as
no canal de acordo com o protocolo
utilizado para a criação do mesmo.
ulo para Conexão
O módulo
XC0nnDis.c
original
está
preparado
para
izar rotinas do sistema Unix 4.3 BSD que implementam a
conexão
do
cliente com o servidor através dos protocolos
Wnix domainI1,para a comunicação local, TCP/IP ou DECNET,
para a comunicação remota.
protocolo
módulo,
a
ser
opção
A
utilizado
definindo-se
para
quanto
ocorre
o
na
ao
tipo
de
compilação deste
pré-processador
qual
dos
ll#ifdefll
existentes para cada protocolo será utilizado. A
escolha de um determinado protocolo implica na
de
chamadas
protocolo
a
para
servidor.
rotinas do
sistema
que
realizar
conexão
do
Estas
a
rotinas
recebem
parâmetro, estruturas pré-definidas
utilizado.
Estas
estruturas
Unix 4.3 BSD, através de
("*.h")
utilização
utilizam
cliente
com
normalmente
para
cada
este
o
como
protocolo
são definidas, pelo sistema
arquivos
públicos
de
inclusão
e seus membros representam dados inerentes a cada
protocolo.
realização
Para a
módulo
XC0nnDis.c
premissa
já
no
citada
original, adotou-se
do
trabalho
de
implantação
do
sistema Pegasus/Plurix, baseado na
de
a
não
modificar
a
biblioteca
seguinte metodologia,
detalhada posteriormente.
Primeiramente, foi
que
X
será
necessário
fazer a escolha de uma das três opções oferecidas por este
módulo
quanto
ao tipo de protocolo. Feita a escolha, foi
necessário fazer um estudo de como se
entre
o
cliente
escolhido.
Isto
e
foi
o
servidor
feito
realiza
utilizando
através
da
a
conexão
o protocolo
análise
do
funcionamento das rotinas do sistema Unix 4.3 BSD chamadas
pelo
módulo
XC0nnDis.c
para
implementar
a
conexão
cliente-servidor no protocolo escolhido. Depois de feita a
análise, criaram-se as
rotinas
Pegasus/Plurix
as
emulam
que
dentro
do
ambiente
chamadas ao Unix, permitindo a
conexão do cliente com o servidor X.
Como
o
protocolos
Plurix
não
mencionados,
implementa
a
escolha
protocolo pode ser feita de forma
opções
existentes,
foi
nenhum
quanto
deve
unicamente
protocolo
que
ao
arbitrária.
três
tipo
de
Dentre
as
escolhida a de trabalhar como se
fosse possível utilizar o protocolo TCP/IP.
se
dos
ao
fato
pretende-se
Esta
escolha
simbólico de ser para este
desenvolver
as
rotinas
de
comunicação do Plurix.
o protocolo TCP/IP, o módulo XC0nnDis.c utiliza
Para
as chamadas ao
sistema
com o servidor X.
do
BSD
4.3
socket,
connect,
gethostbyname, durante o processo de conexão
gethostname,
dentro
Unix
Estas
contexto
do
chamadas
protocolo
Window, as seguintes funções [ 6
. socket
-
ao
sistema
possuem,
TCP/IP e do sistema X
81:
- cria um dos extremos do canal de
comunicação a ser utilizado para o diálogo com o
servidor X; o outro extremo do canal fica aberto
até
que
seja
feita
a conexão com o servidor;
devolve o descritor que identificará este canal;
. connect
- recebe como parâmetros o descritor
do canal criado pela chamada socket e o endereço
do
computador
onde
está
sendo
executado
o
canal indicado pelo descritor ao computador cujo
endereço
foi
recebido
como
parâmetro; se bem
sucedida completa a conexão entre o cliente e
o
servidor;
. gethostbyname
- recebe como parâmetro o nome
de um "hostil e devolve o endereço Internet desse
I1hostu; utilizada
para
a
identificação
do
endereço do computador, a partir de seu nome, no
qual o servidor X está sendo executado;
-
gethostname
qual
o
devolve
processo
executado; é
não recebeu
que
chamada
o
nome
a
o
nome do llhostll
no
chamou
está
sendo
pelo cliente quando este
do
I1hostl1 para
fazer
a
conexão com o servidor X e então assume o llhostll
que o está e
Feita
analise das rotinas do Unix 4.3 BSD utilizadas
para implementar a conexão cliente-servidor no
sistema
X
original, pôde-se partir para a implementação das rotinas
para emular as funções das chamadas
ambiente
Pegasus/Plurix.
anteriormente, o
mecanismos
que
sistema
chamadas
ao
computador
Como
Unix,
dentro
foi
mencionado
Pegasus/Plurix
possibilitem
computadores. O sistema
ao
a
sua
não
conexão
operacional
Plurix
não
uma
do
oferece
a redes de
não
fornece
sis
Pegasus-32X
possui
interface, tipo
Ethernet ou similar, que torne viável sua ligação a
redes
sistemas computacionais, partiu-se para a implementação do
cliente no
mesmo
sistema
que
o
servidor,
no
caso
o
um para cada I1FIFOl1.
rotinas
de
Como
a
possui
suas
originais para comunicação estruturadas em função
apenas
um
descritor
cliente-servidor,
para
seria
substancial no código destas
responsável
pela
realização
o
canal
de
comunicação
necessário
uma
rotinas.
própria
da
A
conexão
servidor devolve como resposta, o valor
canal
X
biblioteca
do
alteração
rotina
do cliente com
descritor
do
bidirecional criado através da conexão. A alteração
desta e de outras rotinas para
iria
contra
a
premissa
suportar dois
básica
descritos
utilizada
nesta
implementação de não modificar a biblioteca X original.
A outra forma encontrada foi
a
utilização
de
duas
interfaces de comunicação seriais do Pegasus interligadas.
Através
deste
mecanismo,
o
cliente
envia
e
recebe
mensagens por intermédio de uma linha serial. O servidor X
realiza o mesmo utilizando outra linha serial.
O
fio
de
transmissão de uma linha está ligado no fio de recepção da
outra
e
vice-versa.
No
Plurix, é necessário somente um
descritor para realizar operações de leitura e escrita
linhas
de
comunicação
em
seriais. Isto ocorre, pois linhas
seriais são canais de comunicação bidirecionais com acesso
através de um
compatível
único
com
as
dispositivo
rotinas
da
físico.
Esta
forma
é
bibiloteca X original, e
poderia ser utilizada.
Este tipo de implementação permite ainda a
de
um
ambiente
simulação
gráfico distribuído. A partir do momento
que se tenha um outro sistema computacional
executando
o
implantar naquele sistema a biblioteca X
Plurix, pode-se
e, através de uma de suas interfaces seriais, ligá-lo
Pegasus.
Desta
em outro
sistema
Pegasus.
Esta
ao
forma, pode-se criar um cliente/aplicação
enquanto
o
executado
servidor é
no
configuração poderia melhorar o desempenho
da aplicação executada, uma vez que o cliente e o servidor
estariam
sendo
executados
em
sistemas
computacionais
distintos e de forma paralela.
único
O
problema
da
interfaces seriais, é que a
dessas
interfaces
no
implementação utilizando
taxa
de
Pegasus
transmissão máxima
de
é
9600
prejudicaria a comunicação entre o cliente e
Porém,
bps.
o
Isto
servidor.
consideramos esta solução transitória. Como já foi
mencionado,
durante
este
trabalho
foi
iniciado
o
desenvolvimento de um ambiente que irá possibilitar o uso
do Plurix para se ter acesso a redes de
alta
taxa
solução
de
transmissão.
compatível
implementação
e
Por
disponível
computadores com
isto, e por ser a única
para
o
momento,
a
no Plurix da comunicação entre os processos
cliente e servidor foi realizada utilizando-se
interfaces
seriais.
Concebido
o mecanismo para intercomunicação entre os
processos cliente e servidor, a
que
emula
a
chamada
implementação
socket
dentro
da
do
Pegasus/Plurix consistiu na abertura (chamada ao
en
)
rotina
ambiente
sistema
de um canal seria1 llttyll
em modo llrawll
tanto para
transmissão como para recepção. O modo
pois
o
sistema
recebidos no
devolve
o
não
necessário
é
deve tratar os bytes transmitidos e
"ttyI1 utilizado.
A
chamada
implementada
descritor do canal llttyll
aberto. O canal I1ttyv1
aberto não deve
possuir
uma
login,
vez
que
deve
ser
controlado exclusivamente pelo processo cliente.
A chamada connect perdeu, dentro desta implementação,
sua
função pois a conexão com o outro extremo do canal de
feita
comunicação é
mensagem
pelo
fisicamente. Uma
cliente, o
servidor
vez
enviada
a
automaticamente
receberá pois deverá estar llescutandoll
o outro extremo
canal.
a
do
A rotina connect implementada retorna o valor zero
indicando que não houve erro na sua execução, para
manter
compatibilidade com a rotina original do Unix 4.3 BSD.
As chamadas gethostname e gethostbyname perdem também
seu
sentido, pois
nesta
implementação o
precisa saber o endereço nem o
servidor
X
está
necessários na
sendo
nome
do
executado.
implementação
cliente
sistema
Estes
onde
dados
original, pois
não
a
o
são
rotina
connect utiliza essas informações para completar a conexão
com
o
servidor.
As
rotinas
implementadas
respectivamente o nome I1Pegasus1le um
estrutura, simplesmente para
ponteiro
devolvem
para
uma
manter a compatibilidade a
nível do código original do módulo XConnDis.~
O módulo da biblioteca X responsável por fornecer
rotinas
para
servidor
a
troca
como
é,
X1ibInt.c.
de
foi
Estas
as
mensagens entre o cliente e o
mencionado
rotinas
anteriormente,
utilizam
basicamente
o
duas
chamadas ao sistema Unix 4.3 BSD, a readv e a writev, para
implementar a comunicação do cliente com o servidor.
A função destas duas chamadas ao sistema é, dentro do
contexto da comunicação do cliente com o servidor, receber
e transmitir mensagens. Para
recebem
como
parâmetro
o
executar
descritor
esta
tarefa
obtido
durante
conexão do cliente com o servidor. Este descritor
o
elas
a
permite
acesso, através do sistema operacional, ao canal criado
para a comunicação.
recebidas
são
E
importante lembrar que as
mensagens
e enviadas através das chamadas readv e writev,
totalmente
implementado no
transparentes
canal
de
quanto
ao
comunicação. Cabe ao sistema,
através do descritor
recebido, identificar
utilizado
os
e
tratar
protocolo
bytes
que
o
protocolo
fluem na comunicação
cliente-servidor de acordo com este protocolo.
O sistema operacional Plurix não possui
readv
e
writev
colocá-las na
sendo
biblioteca
necessário
C
do
as
chamadas
implementá-las
Plurix.
Estas
e
rotinas
realizam a mesma ação das chamadas read e write existentes
no Plurix. A diferença é que a rea
e a write recebem como
parâmetros, além do descritor mencionado, um ponteiro para
um
buffer
e
o
número
de
bytes que devem ser lidos ou
escritos neste buffer, enquanto a readv e a writev recebem
-50-
um vetor de estruturas cujos membros são buffers para
ou
escrever
baseada
na
[8].
ler
A implementação da readv e da writev foi
utilização
fornecidas pelo Plurix.
das
duas
chamadas
similares
editor-ligador
rotinas
de
internas
distintos
da
módulos
objeto
definidas
biblioteca
X
e
do
Plurix.
utilizadas
original,
identificadores diferenciados
a
Algumas
em
têm
módulos
os
seus
partir do décimo quarto
caractere. Na criação dos programas-objeto destes módulos,
são gerados pelo montador identificadores
essas
rotinas.
Isto
ocorre, pois
o
idênticos
editor-ligador de
programas-objeto do Plurix resolve referências a
globais
com
identificadores
de,
no
caracteres. Certamente o editor-ligador do
trabalha
com
para
símbolos
máximo,
Unix
treze
4.3
BSD
identificadores de, pelo menos, trinta e um
caracteres.
O padrão ANSI da linguagem C recomenda que
mínimo
de
caracteres
similares, porém
com
o
número
considerados em identificadores de
diferenças
nos
treze
primeiros
caracteres. Essas definições foram inseridas em um arquivo
de
inclusão
utilizado por todos os módulos que compõem a
biblioteca X.
Foi necessário resolver também uma
incompatibilidade
provisória
entre
o código da linguagem C apresentado nos
módulos da biblioteca X original e o código analisado pelo
compilador do Plurix. No início deste trabalho, não
sido
havia
ainda implementado no compilador a geração de código
para atribuições feitas
mudar
todas
as
entre
atribuições
estruturas.
~ecessitou-se
de estruturas existentes no
código original, por chamadas a rotina do sistema
cópia
para
a
física das regiões de memória onde estavam situadas
as estruturas em questão. Somente algum
implantada
a
biblioteca
X
tempo
depois
de
no Plurix é que o compilador
passou a aceitar este tipo de atribuição.
IV.2.2.
Inclusão de Rotinas na Biblioteca C
Além das chamadas ao
necessárias para
IV.1,
sistema, mencionadas
implementar
a
no
item
comunicação
do
cliente com o servidor, mais uma rotina foi implementada e
incluída na biblioteca C do Plurix.
Esta rotina, chamada ffs,
é
utilizada
pelo
módulo
X0penDis.c da biblioteca X. Sua função é devolver o número
de
ordem
do
primeiro
bit
menos
significativo, de uma
máscara de bits, que está em 1 (um).
Outras duas rotinas, a bcopy e a
utilizadas
por
módulos
bzero,
também
são
da biblioteca X e não existem na
biblioteca C do Plurix. Porém, elas podem ser substituídas
pelas rotinas do Plurix memc y
[17],
que
e
memset
respectivamente
realizam funções idênticas. A substituição foi
realizada fazendo-se definições para o pré-processador
de
troca dos identificadores dessas rotinas. Essas definições
foram
inseridas
em
um arquivo de inclusão utilizado por
todos os módulos da biblioteca X.
Implan ação dos Arquivos de
IV.2.3.
Diversos arquivos
para
a
compilação dos
pertenciam ao
foram
de
ambiente
-
-
inclusão
módulos
Plurix.
( " * . h v v ) necessários
da
biblioteca
Alguns
destes
X
não
arquivos
fornecidos junto a biblioteca X e outros pertenciam
ao ambiente do sistema Unix 4.3 BSD.
Os
arquivos
implantados
fornecidos
nos
pela
respectivos
X
biblioteca
diretórios
em
foram
que
são
procurados pelos módulos da biblioteca que os incluem.
arquivos
Os
pertencentes ao ambiente do sistema Unix tiveram
que ser implementados a partir de suas definições
obtidas
em manuais deste sistema.
Além
dos
arquivos
de
inclusão,
implantar um arquivo fornecido junto a
serve
como
base
biblioteca
do
cliente
correspondente
percorrido, para a
sistema
X
que
com
o
Este arquivo é aberto pela rotina da biblioteca
responsável pelo tratamento destes erros, para
mensagem
necessário
de dados para a informação de eventuais
erros ocorridos durante a comunicação
servidor.
foi
de
ao
abertura
arquivos
é
erro
do
ocorrido.
arquivo,
definido
na
enviar
O
a
caminho
árvore
do
a nível de código. Por
isto, o arquivo deve ser colocado no diretório determinado
pelo código da rotina.
trabalho
O
de
requisitados pelos
implantação de
módulos
da
todos
biblioteca
os
nos
seus
respectivos diretórios, é de fundamental importância
para
atender
mínimo
possível a
biblioteca X implantada. Futuras versões desta
biblioteca
não
a
premissa
de
modificar
o
X
arquivos
necessitam de alterações já que encontram um ambiente
no Plurix preparado para a biblioteca X.
Incompatibilidades com os Utilitários do Plurix
IV.2.4.
Junto a biblioteca X original é fornecido um
Makefile
para
a
compatíveis com
interpretado
para
make,
implantação da biblioteca X em sistemas
o
por
a
arquivo
Unix
4.3
Este
BSD.
arquivo
é
um utilitário deste sistema, denominado
execução
das
tarefas
necessárias
na
implantação da biblioteca.
O
formato
do
incompatibilidades
arquivo
com
o
~ a k e f i l e fornecido
formato
dos
possui
arquivos
tipo
Makefile reconhecidos pelo utilitário make do Plurix [17].
Com
isto,
foi
necessário
analisar
descritos no arquivo Makefile original
os
e
procedimentos
implementar
um
novo arquivo Make ile para o Plurix.
Dentre os procedimentos descritos no arquivo Make
original, existe um que utiliza o utilitário awk do Unix.
-55Este utilitário não foi implementado no
sistema
Plurix.
procedimento, o utilitário a w k recebe como entrada
Neste
uma rotina escrita
em
interpretada
utilitário.
para
pelo
modificar
existente
na
um
uma
linguagem
determinado
biblioteca
e
própria
para
ser
O a w k utiliza esta rotina
arquivo
gerar
um
de
novo
inclusão
arquivo
de
inclusão com um formato pré-definido.
Para
utilizado
implementação
um
outro
do
procedimento
sistema
possuia o utilitário a w k . Foi
mudanças
na
rotina
descrito
foi
computacional com Unix, que
necessário
recebida
como
fazer pequenas
entrada
pelo
awk
utilizado, pois também existiam incompatibilidades quanto
a
linguagem
interpretada por
este
awk
e
a linguagem
interpretada pelo a w k do sistema Unix 4.3 BSD.
A l t e r a ç õ e s na B i b l i o t e c a
IV.3.
Mesmo sendo o trabalho de implantação da biblioteca X
feito de forma a não alterar o código original dos módulos
desta
biblioteca,
Essas
alterações
algumas mudanças
foram
realizadas
foram
tipicamente quando a
biblioteca X utiliza recursos existentes no
4.3
BSD
inevitáveis.
sistema
Unix
que possuem similares no sistema Plurix, mas que
funcionam de forma diferente.
A
grande
chamadas
ao
maioria
das
sistema Unix
mudanças
concentrou-se nas
que têm chamadas similares no
sistema Plurix, porém são incompatíveis sob algum aspecto.
A
incompatibilidade
divergência
existiu
em
três
casos
básicos:
quanto ao nome da chamada, quanto ao nome dos
parâmetros passados para a chamada e
quanto
a
forma
da
chamada retornar o seu resultado.
Os dois primeiros casos foram resolvidos colocando-se
em arquivos de inclusão utilizados por todos os módulos da
biblioteca,
definições
para
o
pré-processador
substituição dos identificadores utilizados no
Unix
de
para
aqueles utilizados no Plurix.
No
terceiro caso, foi inevitável fazer alterações no
código das rotinas que utilizam a chamada ioctl
que,
por
ser independente de implementação, é incompatível quanto a
forma
de
retornar
o
seu
resultado.
No
Unix
4.3 BSD
implementado num VAX, esta chamada recebe como parâmetro o
endereço da posição de
resultado
o
de
seu
resultado
atribuição do valor retornado
endereço
de
onde
deve
retornar
seu
No Plurix, esta chamada retorna diretamente
[8].
valor
memória
memória
passado
[17],
a
devendo
variável
como
haver
uma
localizada
no
parâmetro na chamada
i o c t l do Unix de Berkeley.
Foi necessário também fazer alterações em arquivos de
inclusão
tipicamente
concentrar
todas
existentes
as
na
dependências
utilizado dentro do universo dos Unix
alterações
biblioteca
X
quanto
sistema
ao
compatíveis.
para
Essas
ocorreram por causa das variações dos nomes de
alguns arquivos
públicos
de
inclusão
no
universo
dos
sistemas Unix compatíveis.
IMPLEMENTAÇÃO DO TERMINAL X
O
desenvolvimento de um Terminal X divide-se em duas
etapas: a implementação
fornecer
os
de
uma
base
de
hardware para
recursos necessários para o funcionamento do
sistema X Window e a implementação do servidor do
X
sobre
o
hardware
criado, gerenciando
sistema
os
recursos
de
forma
existentes e comunicando-se com os clientes.
O hardware do Terminal X
suportar
a
arquitetura
foi
definido
a
utilizada neste trabalho, para a
implementação do terminal. A implementação, conforme
foi
definido no item 111.3, prevê a passagem do Terminal X por
uma
etapa
intermediária, na qual o terminal se baseia na
arquitetura alternativa, utilizando interface
etapa
final,
serial.
o terminal passa a ser implementado através
da arquitetura tradicional, ligado diretamente a redes
computadores.
feita
de
A
definição
maneira
arquitetura
Na
a
sem a necessidade de
do hardware do Terminal X foi
permitir
alternativa
de
para
mudanças
a
evolução
natural
da
a arquitetura tradicional,
no
trabalho
implementado
durante a etapa intermediária.
A implementação do servidor X foi feita de acordo com
as
características
da
arquitetura
utilizada
para
a
-59-
implementação do Terminal X. O servidor
foi
dividido
em
duas partes, de forma a permitir sua implementação sobre a
arquitetura
alternativa.
Uma
parte
do
servidor
desenvolvida sobre o sistema operacional Plurix
no
foi
executado
computador Pegasus-32X. Esta parte, apesar de estar no
Pegasus, possui dependências quanto as características do
hardware
Terminal X. A outra parte, executada sobre o
do
hardware do terminal, é responsável pela interação
com
o
Sua
função
direta
hardware gráfico e com os dispositivos de entrada.
básica
oferecidos pelo
ligar
é
os
recursos
de
hardware
Terminal X a parte do servidor executada
no Pegasus.
O
trabalho
de
implementação do
servidor
X
foi
realizado, analogamente ao desenvolvimento do hardware, de
forma a permitir a passagem para a arquitetura tradicional
sem
a
necessidade
de
redefinir o trabalho realizado. O
protocolo utilizado para a comunicação das duas partes
que
se
dividiu o servidor, foi implementado de forma que
para se juntar essas duas partes,
consiste
basicamente
na
o
eliminação
trabalho
necessário
deste protocolo. As
rotinas que necessitam de serviços gráficos passam
ligadas
em
diretamente
aos
a
ser
procedimentos responsáveis pela
execução dos serviços.
V.1.
Definição do Wardware do Terminal X
A definição do hardware do Terminal X
hardware
das
se
baseou
no
estações de trabalho com recursos gráficos.
velocidade de
Com
38.4
Kbps.
respeito a futura implementação do Terminal X na
arquitetura tradicional, algumas
foram
realizadas.
previsões
de
hardware
Foi utilizado um circuito lltimerll
para
implementar as funções que necessitam de contagem de tempo
no servidor X. Essas funções são supridas
na
alternativa, pelas
fornecidas pelo
rotinas
de
sistema operacional Plurix. A
ficará
no
Terminal
X
relógio
parte
do
arquitetura
servidor
X
que
nesta arquitetura não utilizará o
"tirnerf1implementado .
Foi feita uma previsão no hardware desenvolvido
permitir
a
implementação de uma interface Ethernet. Esta
interface não foi implementada, pois
no
item
para
111.3
implementação
não
a
seria
conforme mencionado
utilizada na primeira fase da
comunicação
através
de
rede.
A
implementação, por motivo de compatibilidade de circuitos,
foi
deixada
para ser realizada quando existir um sistema
computacional que utilize o Plurix e permita a conexão
ao
Terminal X através de interface Ethernet.
Na
parte
gráfica
conhecimentos mais
eletrônicos
do Terminal X, foram colocados os
recentes
existentes
para
a
respeito
de
circuitos
a
exibição
de
imagens em
monitores através de varredura. A resolução escolhida
de
1280
por
1024
pixels
a
serem
exibidos na tela do
monitor. Definiu-se ainda, que seria utilizada uma
de
foi
conversão de cores (lllook-up
tableI1) com
256
tabela
posições.
Isto significa que a memória de imagem deve ter no
mínimo
oito planos de 1280x1024 bits. Na implementação, a memória
de
imagem teve oito planos de 2048x1024 bits. O número de
planos da memória de imagem
é
definido
como
sendo
sua
profundidade e representa, através da utilização da tabela
de
cores,
o
número
máximo de variações de cores que um
determinado pixel da tela pode ter.
Para controlar a exibição no monitor das
armazenadas
na
memória
de
imagem,
foi
informações
utilizado
processador gráfico comercial, o ACRTC HD63484 da
um
Hitachi
[19]. Este processador não só rèaliza a tarefa de exibição
como
capaz
é
de executar diversas primitivas gráficas a
partir
de
comandos
retas,
círculos,
recebidos.
elipses,
Pode-se
áreas,
traçar
polígonos
pontos,
e desenhar
padrões através da passagem dos respectivos comandos junto
com
os
parâmetros
diretamente usadas
presentes
em
utilização
desejados
pelo
todos
de
um
os
sistema
processador
também
funções
são
X ~ i n d o we devem estar
X
servidores
procedimentos não só diminui o
Estas
[19].
implementados.
para
tempo
de
executar
execução,
A
estes
como
irá diminuir o fluxo de informações passadas entre
o Pegasus e o Terminal X.
Conforme foi mencionado, a tabela para
cores
deve
possuir
informação digital do
informação
é
conversão
de
256 entradas. Na sua saída, tem-se a
código
dividida
em
da
três
cor
selecionada.
Esta
grupos R, G e B (llredll,
llgreenll
e llbluell).
Foi determinado que se teria oito
bits
de
informação
para
cada um destes grupos. Isto nos dá a
possibilidade de escolher 256 cores em um universo
de
16
Mega (1024x1024) cores.
informação que
A
sai
da
tabela de cores deve ser
convertida na informação analógica da intensidade com
devem
tela
ser
do
llacesosll
os fósforos vermelho, verde e azul na
monitor.
Isto
digitais-analógicos com
nos
leva
oito
a
bits
três
de
resolução desejada e de acordo com as
monitores
que
conversores
entrada.
Para a
características de
comerciais, a frequência de conversão deve ser
da ordem de 108 MHz.
Para implementar a tabela de cores e
foi utilizado
o
circuito
integrado
os
conversores
Bt458 da Brooktree
[20]. Este circuito possui
internamente uma
cores
que
e
três
conversores
desejadas. O Bt458 deve
ser
satisfazem
alimentado
tabela
de
as condições
com
um
relógio
(llclockll)
com a freqüência de conversão acima mencionada.
Foram utilizados circuitos integrados com
tecnologia
ECL
para implementar esta função.
ação do Servidor X
O
código
do
X
Window, colocado em domínio público
pelo MIT, fornece junto as demais partes do
implementação
sistema, uma
de um servidor X. Esse servidor, denominado
I1sampleserver" ou
servidor modelo
,
é
dependente
da
arquitetura do sistema computacional com recursos gráficos
para
a
qual
foi
concebido.
A
finalidade
desta
implementação é ser usada como base para o desenvolvimento
de novos servidores em sistemas com arquiteturas distintas
A arquitetura do Terminal
X
difere
da
arquitetura
para o qual o llsampleserverI1 foi desenvolvido em diversos
,pontos. Por
exemplo,
o Terminal X possui um processador
dedicado capaz de traçar primitivas
servidor modelo
realiza
gráficas
enquanto
o
o cálculo destas primitivas por
algoritmos de software e faz acesso diretamente a
memória
de imagem para traçá-las.
Além
disto,
existem
as
diferenças
sistema operacional. De forma similar a
servidor modelo
também
foi
com relação ao
biblioteca
quanto
a
comunicação
incompatibilidades com
o
o
desenvolvido para o sistema
Unix 4.3 BSD. Os mesmos problemas mencionados no
IV
X,
capítulo
cliente-servidor
~lurix, aparecem
no
e
as
servidor
modelo.
Apesar
das diferenças, pela complexidade que envolve
as diversas funções que são executadas
implementação
modelo de
servidor
do
servidor para
servidor
fornecido.
o
A
pelo
serem
a
Terminal X partiu do
estrutura
de
como
o
X é subdividido foi mantida. As partes do código
do servidor modelo foram analisadas quanto
de
servidor,
utilizadas
Aquelas nas
no
servidor
uais foi detectada a
a
ser
a
viabilidade
implementado.
compatibilidade,
foram
e acesso aos arquivos necessários.
Na
camada
DDX
estão
concentradas
dependências do servidor modelo quanto as
do
hardware
todas
as
características
gráfico sobre o qual ele deve ser executado.
Esta camada é responsável pela interação do servidor com o
sistema operacional
sobre
o
hardware
na
intenção de
gráfico.
É
realizar
importante lembrar, que o
servidor modelo está preparado para interagir
com
operações
diretamente
a memória de imagem e isto é feito através do sistema
operacional.
A
interface
procedimentos
para
extensões
define
uma
sistema
X
Window
aceita
feitas
de
forma
realidade,
a possibilidade de se criar
extensões as suas funções básicas. Essas
ser
de
padrões necessários para a implementação de
novas funções no servidor modelo fornecido. Na
o
série
extensões devem
padronizada
nas
diversas
implementações de servidores
X.
alterado poderá
compatível com uma aplicação
não
ficar
Sem
isto, um
desenvolvida para outro servidor, sem
funções.
A
interface
No
é
novas
especificada por
[22].
servidor implementado para o Terminal X, a camada
DIX foi implantada no Plurix praticamente sem
A
as
para extensões no servidor modelo,
fornecido junto ao sistema X Window,
FISHER
utilizar
servidor
camada
OS,
foi modificada
de
forma
arquitetura do Terminal X e para ficar
a
alterações.
atender
a
compatível com
o
Plurix.
Na
camada DDX foram feitas diversas modificações
em relação ao código fornecido pelo servidor modelo. Neste
trabalho não foi necessário realizar
a
implementação
de
extensões para as funções básicas oferecidas pelo servidor
modelo.
Implantação da Camada DIX no Terminal X
V.2.2.
camada
A
DIX
do
servidor modelo foi implantada no
código
Terminal X para ser executada no ~egasus/Plurix. O
das
rotinas
que
compõem
esta
camada
é
praticamente
independente do sistema operacional e do hardware gráfico.
Somente
as
rotinas
maPPoc, reaPPoc
e
já
no
mencionadas
biblioteca
camada
C
DIX
do
se
para
gerenciamento
de
memória,
free, e as rotinas ffç, bcopy e bzero,
item
IV.2.2,
sistema.
resumiu
a
O
são
solicitadas
a
trabalho de implantação da
problemas
idênticos
aos
já
mencionados no item IV.2.
Problemas
com relação aos compiladores do Plurix, já
hav iam sido resolvidos durante a implantação da biblioteca
X. O problema do editor-ligador
similar
ao
ocorreu
com
que
foi
relação
explicado
a
foi
no
atribuição
resolvido
de
forma
item IV.2.1. O mesmo
de
estruturas,
não
implementada, no início deste trabalho, pelo compilador C
do Plurix. Este problema apareceu igualmente
nas
rotinas
das camadas OS e DDX, sendo resolvido da mesma £orma.
Com relação a incompatibilidade do utilitário make do
Plurix
e
do
Unix 4.3 BSD, um novo arquivo Makefile para
compilar a camada DIX, teve de ser criado. O mesmo ocorreu
para as camadas OS e DDX. A falta do
novamente
sentida
durante
a
utilitário
implantação da camada DIX.
Dois arquivos pertencentes a esta camada, o
initatoms.~, são
Xat0m.h
e
o
gerados a partir da passagem através do
awk, do arquivo BuiltInAtoms
Estes
foi
awk
presente
na
mesma
camada.
dois arquivos estão relacionados com a definição de
atoms e não devem ser editados livremente.
Um atom para o sistema X Window
numérico
único
que
é
corresponde a
um
identificador
uma
Ivstring1l de
caracteres utilizada para identificação de,
por
exemplo,
tipos de variáveis pertencentes ao sistema X. Mudanças nos
atoms
pré-definidos
ou
mesmo
na
ordem
aparecem nos arquivos gerados pelo awk,
forçar
qual
eles
equivalente
a
uma nova versão I1minorl1para o servidor do sistema
X. Por isso, existe a necessidade dos
serem
é
na
gerados
linguagem
por
um
procedimento
interpretada pelo
recorreu-se
utilitário
a
outro
awk
para
referidos arquivos
utilitário
sistema
gerar
fixo
awk.
escrito
em
Novamente
computacional que possui o
os
arquivos
Xat0m.h
e
initat0ms.c.
Na camada DIX estão as principais rotinas do servidor
X.
Pode-se destacar a rotina para iniciar todo o ambiente
que implementa
controlado pelo servidor, o Ivdispatcher1l
política
lvround-robinllpara
existentes, as
rotinas
que
distribuir
iniciam
a
as
a
tarefas
execução
das
requisições
feitas
ao servidor e as rotinas responsáveis
pelo gerenciamento de todos os
As
rotinas
de
desses
módulos
código
compiladas
as
necessárias
trabalho.
Os
compilação
foi
na
realizada
cada
da
da
módulos
a
ter
em
média
3.000
linguagem C. A compilação
de
forma
a
só
serem
camada DIX, que estavam sendo
instante
detalhes
destes
deles
escrito
rotinas
em
oferecidos pelo
da camada DIX estão agrupadas em módulos
extensos, chegando vários
linhas
recursos
da
implementação
metodologia
serão
deste
utilizada para a
descritos
no
próximo
capítulo.
Implementação da Camada OS no Terminal X
V.2.3.
A
camada
OS
é
a
responsável
pela
interação
servidor com o sistema operacional. Essa interação
com
o
intuito
do
servidor
se
do
dá
realizar dois procedimentos
básicos: a comunicação com os diversos clientes do sistema
X Window e o acesso a arquivos existentes no sistema com a
finalidade de obter informações contidas nestes
O
trabalho
de
implementação da camada OS fornecida pelo
servidor modelo, consiste na modificação e
rotinas
adaptação
das
que interagem com o Unix 4.3 BSD para a interação
com o Plurix e com a arquitetura definida para o
X.
.A
arquivos.
Cornunicagão com os Clientes
o Sistema X
Terminal
-70-
Nos
módulos connection.~,io.c e WaitF0r.c da camada
OS do servidor modelo, estão concentradas todas as rotinas
utilizadas para fazer a conexão com novos clientes e,
vez
feita
a
conexão,
realizar
uma
a comunicação com esses
clientes.
O servidor modelo
está
preparado
para
realizar
a
conexão com novos clientes através do protocolo TCP/IP. Os
demais
protocolos, mencionados no capítulo anterior, não
estão implementados no servidor fornecido. Assim sendo,
o
servidor modelo chama rotinas do sistema Unix 4.3 BSD que
utilizam o protocolo citado, para realizar a conexão.
Como na primeira etapa da implementação do Terminal X
não foi
utilizado
o
alterar
todas
rotinas que utilizam essas chamadas ao
as
protocolo
sistema para
adaptá-las
arquitetura,
conforme
a
TCP/IP,
arquitetura
foi
utilizada.
de
duas
Essa
foi definido no capítulo anterior,
determina que o servidor irá se comunicar com
através
necessário
interfaces
seriais
o
cliente,
do
Pegasus
interligadas.
A adaptação do
X
Terminal
foi
características e
servidor modelo
feita
a
de
forma
funcionalidade
arquitetura
a
a
da
preservar
do
as
implementação
utilizando o protocolo TCP/IP. Com isto, a passagem para a
segunda
etapa
utilizado
o
rapidamente.
prevista
protocolo
Para
neste
TCP/IP,
atingir
trabalho, na
será
qual
realizada
será
mais
este objetivo, foi necessário
entender como é feita a implementação utilizando o TCP/IP,
para depois fazer a
adaptação
arquitetura utilizando
a
linhas seriais.
Na
inicialização do
servidor
chamada
pertencente
CreateWellKnownSockets,
connection.~, que
é
a rotina
ao
modulo
cria uma porta dentro do protocolo TCP
denominada well-known port. Esta porta terá um número fixo
para todas as implementações de
redes TCP/IP.
servidores
Window
X
Quando um cliente deseja iniciar a conexão
com um servidor, deverá enviar o pedido de conexão para
endereço
do
IP
Os
o
sistema na rede que executa o servidor e
para a porta fixa dos servidores X
TCP.
em
dentro
do
protocolo
servidores X ficam sempre llescutandoll
esta porta
na espera de novas conexões. A partir
recebido
do
momento
que
é
o pedido de conexão, uma nova porta no protocolo
TCP é criada.
servidor, o
Esta
porta
é
que
irá
indicar,
para
o
canal de comunicação estabelecido com o novo
cliente. A partir deste instante, toda a comunicação com o
novo
cliente
well-known port
pedidos
de
descrita,
, bind
é
feita
desta
nova
porta
e
a
permanece aberta para a llescutall
de novos
conexão.
o
através
Para
servidor
realizar
modelo
toda
utiliza
a
operação
as
chamadas
e acce t do sistema Unix 4.3 BSD.
Na implementação no Terminal X, a chamada socke
substituída pela chamada open do Plurix. A chamada open é
utilizada para abrir canais seriais I1ttyl1 em
tanto
para
transmissão
como para
modo
recepção, de
forma
similar ao que foi descrito para o cliente no item IV.l.l.
Uma vez abertos os canais
descritores
para
os
llttyll,
o
canais
servidor
possui
os
de comunicação com os quais
será feita a comunicação com os clientes. Desta
forma,
a
well-known port é trocada pelos descritores dos canais por
onde é feita a comunicação com os clientes.
A chamada bind, que atribui o número fixo a porta TCP
do
servidor
perdeu sua função nesta implementação. A
X,
chamada accept, que cria uma nova porta para a comunicação
com o cliente que pediu conexão, foi trocada pela
fcntl
do
Plurix.
Esta
chamada
troca foi realizada somente para
preservar as características do código do servidor modelo.
Como a chamada accept cria um novo descritor para
cliente,
a
chamada
fcntl
o
novo
foi utilizada para duplicar o
descritor do canal seria1 já aberto, criando assim um novo
descritor para o mesmo canal. A partir do momento
esta
operação
realizada, a
é
comunicação
com
em
que
o novo
cliente será feita através do novo descritor.
O módulo io.c contém
pela
transmissão de
as
duas
informações
rotinas
aos
responsáveis
clientes
e
pela
recepção de requisições destes clientes. Estas rotinas, no
servidor modelo,
descritor
do
recebem
canal
de
uma
estrutura
comunicação
que
possui
o
com o cliente. Esta
funcionalidade foi preservada na implementação do servidor
no Terminal X, através dos descritores dos canais
criados
para
a
comunicação
seriais
cliente-servidor.
utilizadas, pelo servidor modelo, as chamadas
ao
São
sistema
read e writev, para implementar as funções de comunicação.
A
chamada read é idêntica no Plurix e a chamada writev já
havia sido implementada no Plurix durante a implantação da
biblioteca X.
A rotina de
do
select,
transmissão
utiliza
também
canal
o
processo
desejado,
através
chamada
Unix 4.3 BSD, quando tenta escrever e o canal
de comunicação está bloqueado pelo sistema.
coloca
a
de
Esta
chamada
em estado de espera pela liberação do
durante
um
tempo
máximo
determinado
parâmetro passado para a chamada. Com isto, o
processo não ocupa o processador do sistema em
um
lrlooplr
de espera pela liberação do canal. Esta chamada não possui
similar
no
Plurix
nem
existem
ainda
mecanismos
permitam sua simulação. A solução adotada
processo
servidor
em
um
llloopllfinito
liberação do canal desejado, tornando
menos
eficiente
sob
o
foi
ponto
de
esta
vista
que
colocar
o
de espera pela
implementação
de ocupação do
processador do sistema.
O
módulo
WaitF0r.c
WaitForSomething.
possui
uma
Única
rotina,
a
Esta rotina é chamada pelo lldispatcherll
esperando que exista
da camada DIX para realizar um llloopll
algum cliente pedindo conexão, ou
existente
de entrada
envie
seja
que
algum
cliente
já
uma requisição, ou que algum dispositivo
ativado.
Novamente
é
utilizada,
pelo
servidor modelo, a chamada ao sistema select para realizar
a
espera
por
um
determinado
tempo,
sem
processador do sistema. Neste caso, a chamada
utilizar
selec
o
substituída pela
chamada
do
Plurix
passando um
ioctl
parâmetro para saber se existem informações nos canais
comunicação
com
os
clientes
ou
no
canal
que
implementação, de
forma
menos eficiente, pois
espera
sendo
o
semelhante
processo
executado
pelo
recebe
X.
sinalizações de entrada provenientes do Terminal
de
Esta
ao caso anterior, é
ficará
em
processador
llloopllde
do
sistema
Pegasus.
No módulo WaitF0r.c existe ainda a utilização
lltimerll
do
sistema
para
contar
a
um
o tempo desde a última
ativação de um dispositivo de entrada.
com
de
Isto
realizado
é
intenção de preservar o fósforo da tela do monitor
servidor
X.
Quando
o
servidor
não
for
conectado
ao
utilizado
durante um período de tempo determinado, a tela
é apagada. Ela só é acesa novamente caso seja feita alguma
sinalização de entrada. A chamada ao l1tirnerl1e a estrutura
que contém
sistemas
a
informação
Unix
4.3
BSD
de
e
tempo
Plurix.
são
diferentes
Modificações
nos
foram
realizadas de forma a compatibilizar a função descrita com
os recursos oferecidos pelo Plurix.
. Acesso
aos Arquivos Utilizados pelo Servidor X
O servidor X Window modelo
interage
com
o
sistema
operacional para ter acesso a três tipos de informações: a
uma
base
de
dados sobre cores, a uma lista dos sistemas
computacionais que podem fazer conexão com
o
servidor
e
aos arquivos que contêm as fontes de caracteres utilizadas
A
partir
do
momento
biblioteca libdbm no
dados,
em
que
Plurix, pôde-se
foi
implantada
gerar
a
base
a
de
no diretório que o servidor X a procura. Esta base
é gerada a partir de um arquivo de dados que contém o nome
de várias cores e
seus
respectivos
níveis
RGB
(vvredlv,
Ivgreenvv
e Ilbl~e~~).
Este arquivo é fornecido juntamente com
o
sistema
X
Window.
foram alteradas
as
Depois
chamadas
de gerada a base de dados,
as
rotinas
da
biblioteca
feitas pelos módulos 0sinit.c e oscolor.~,para a
libdbm,
passagem
de
ponteiros
como
parâmetros
no
lugar
de
estruturas.
O
módulo
primeira
fase
executados
access.~é o responsável pela interação do
da
também
implementação do
no
Pegasus,
a
Terminal
lista
sistemas habilitados a conexão não foi
dos
X,
sendo
nomes dos
construida.
Assim
sendo,
o
procedimento
de
considerado e as rotinas
utilizadas
na
consulta não foi inicialmente
do
módulo
implementação
do
access.~ não
servidor
X
foram
realizada
durante a primeira etapa deste trabalho.
Os módulos fi1eio.c e fi1enames.c são utilizados para
o acesso, através do sistema operacional, aos arquivos que
contêm as fontes de caracteres utilizadas pelo servidor X.
Estes módulos utilizam as chamadas ao sistema open, read e
c l o s e que são idênticas no
Poucas
mudanças
foram
Unix
4.3
necessárias
BSD
e
no
Plurix.
para
a
implantação
destes módulos.
O último módulo pertencente a camada OS é o
Este
módulo
uti1s.c.
possui rotinas utilitárias responsáveis pela
colocação de mensagens
de
erro,
pelo
processamento
da
linha de comando de chamada ao servidor, pela impressão do
"helptt do servidor e pelos procedimentos de interrupção e
reinício do servidor. Esse módulo
também
foi
implantado
sem a necessidade de se realizar mudanças significativas.
Irnplernentação da Camada DDX no Terminal X
V.2.4.
Na
camada
DDX
estão
todas as rotinas responsáveis
pela interação do servidor X Window com
exibição
gráfica
e
com
O
teclado e o llmousell.
consiste
normalmente
dois
são
hardware
dispositivos
hardware
de
memória de imagem, onde
os
o
para
para
de entrada, o
exibição
gráfica
dispositivos básicos:
desenhadas
as
imagens
a
que
aparecerão
cores,
na tela do monitor, e a tabela de conversão de
onde
armazenada
feita
é
na
a
transformação
da
informação
memória de imagem para o código digital da
cor correspondente.
O servidor modelo fornecido junto ao sistema X Window
interage, utilizando as rotinas
dispositivos gráficos
operacional.
São
e
de
utilizadas
e
open, close, read
da
camada
DDX,
com
os
entrada, através do sistema
as
chamadas
ao
sistema
para fazer o acesso a cada um
write
deste dispositivos independentemente. Na implementação
do
servidor do Terminal X isto ocorreu de forma distinta. As
rotinas da camada DDX, utilizando as
mesmas
chamadas
ao
sistema, fazem o acesso a todos esses dispositivos através
de
um
único canal de comunicação serial I1ttyr1
que liga o
Pegasus ao Terminal X. Além disto, essas
comunicam
diretamente com
Terminal X
possui
um
a
memória
processador
rotinas
não
se
de imagem, pois o
gráfico
dedicado
ao
Pegasus
ao
controle desta memória.
Através
Terminal
X,
da
linha
serial
as
rotinas
que
enviam
liga
o
requisições,
para
o
processador gráfico e para programação da tabela de cores,
e lêem as sinalizações de entrada, provenientes do teclado
e do llmousell.
No Terminal X, o processador MC68000 executa
o
programa
responsável
pela
comunicação com o Pegasus.
Esta programa recebe as requisições, faz
o
processamento
necessário e se comunica com o processador gráfico HD63484
ou
com
o
Bt458
para
realizar a função requisitada. Em
-79-
relação ao teclado e ao wmouse~l,
o mesmo programa verifica
o estado destes
mensagens
dispositivos,
sinalizando
a
enviando
para
ocorrência
de
o
Pegasus
ações
nos
respectivos dispositivos.
mecanismo
O
utilização
do
diferenças
entre
de
comunicação
processador
a
com
gráfico
arquitetura
o
hardware
são
para
e
a
as
principais
a
qual
foi
implementado o servidor modelo e a arquitetura do Terminal
X.
Mesmo
tarefas
assim, devido a quantidade e a complexidade das
realizadas pela
implementação
desta
camada
camada
DDX,
o
trabalho
no Terminal X foi baseado na
camada DDX do servidor modelo e dividido em
Na
primeira
de
duas
etapas.
etapa, as rotinas que compõem esta camada no
servidor modelo,
adaptadas ou
foram
analisadas
reescritas
para
diferenças existentes entre as
e,
posteriormente,
o Terminal X, conforme as
duas
arquiteturas.
Nesta
etapa, procurou-se otimizar o tempo necessário para que se
tivesse
uma
implementação
do Terminal X funcionando. Na
segunda etapa, será feita uma otimização no desempenho
do
Terminal
as
XI
aproveitando-se
funcionalidades oferecidos
HD63484.
Esta
divisão
[ll] como estratégia
modelo
deste
sobre
processador
a
implementação do
sistemas gráficos,
trabalho, devido
todas
gráfico
proposta ainda por ANGEBRANNDT
é
para
outros
pelo
melhor
a
utilização
servidor
o que é o caso
do
processador
gráfico.
A
camada
DDX
do
servidor modelo é subdividida em
-80-
cinco outras subcamadas:
- MI ("Machine IndependentI1);
- CFB (I1ColorFrame Buffer1I);
- MFB (llMonochrome
Frame Bufferw);
- SNF (I1ServerNatural FormatI1);
-
Interface com hardware.
Para descrever a função de cada uma
dessas
subcamadas
é
necessário definir alguns conceitos e termos associados ao
sistema
X
Window
e
em
fornecido. A partir disto,
particular,
será
ao servidor modelo
possível
explicar
essas subcamadas foram implementadas no Terminal X.
. Termos e Conceitos Associados
ao Sistema X
como
-81-
denominado lltilell
ou ladrilho e outro denominado I1stipplel1
ou pontilhado.
Um I1tilef1
é um padrão onde os pontos podem ter várias
O número de cores que cada ponto de um lltilell
pode
cores.
ter é determinado pela
sistema.
No
profundidade
Terminal
X,
corresponde a um byte, pois
cada
a
dos
lldrawablesll
do
ponto
memória
de
de
um
lltile'l
imagem, onde
estão as janelas, possui profundidade igual a oito.
é um padrão onde os pontos são binários,
Um tlstipplell
OU
um.
seja, um I1stipplel1é um lltilell
com profundidade igual a
O
ponto
utilizada
uma
que possuir o bit em I1lf1
significa que será
determinada
cor,
I1foreground colortl (cor de
desenhar).
"stipple1I que possuir o bit em
utilizada
a
normalmente
O
denominada
ponto
11011identifica
I1background colorfl (cor de
llstipplell
seja opaco ou haverá ausência
de
de um
que
será
fundo) caso o
cor
no
caso
contrário.
. Funcionamento da Camada DDX no Servidor Modelo
Umas
das
funções
da
interface de software para
virtual.
camada
um
DDX
é
dispositivo
fornecer
de
hardware
Este dispositivo deve fornecer um conjunto de 16
primitivas de desenho que permitem a execução de todas
operações
gráficas, definidas
no
sistema
X,
as
sobre as
Essas primitivas incluem cópia
janelas e os llpixmapsll.
imagens,
uma
de
preenchimento de polígonos e arcos, e desenho de
pontos,
linhas,
retângulos, arcos
definir
também, para
largura
das
linhas
preenchimento.
textos.
Pode-se
as primitivas onde é pertinente, a
e
Alem
e
o
estilo
destas
sistema X, outras primitivas
ou
primitivas
gráficas
padrão
para
definidas
pelo
devem
existir
na
camada DDX para uso interno do servidor, como por exemplo,
o preenchimento de áreas utilizado na criação das janelas.
A
função
da
subcamada
MI (I1MachineIndependent"),
pertencente a camada DDX do servidor
uma
simulação
por
software
do
modelo,
Pixblit.
independente
do
A
hardware
idéia
fornecer
dispositivo de hardware
virtual, construído a partir de primitivas
denominadas
é
desta
gráfico
mais
simples,
subcamada
sobre
o
qual
é
ser
serão
aplicadas as primitivas gráficas oferecidas pelo servidor.
Desta
forma,
esta
subcamada
pode ser transportada para
diferentes sistemas, deixando o trabalho de
características do
hardware
para
adaptação
as
as subcamadas de mais
baixo nível que implementam as primitivas Pixblit.
As
subcamadas
("Monochrome
Frame
CFB
("Colar Frame
BufferI1)
implementam respectivamente as
fornecem
Buffer1I) e
MFB
as
que
primitivas
rotinas
Pixblit
sobre
"dra~ables~~
com diversas cores (profundidade maior que um)
e
com
duas
cores
(profundidade igual a um). As rotinas
destas subcamadas devem ser adaptadas
do
hardware
dos
as
características
diferentes sistemas para os quais sejam
transportadas. Além das primitivas Pixblit, as
CFB
subcamadas
e MFB devem fornecer as demais primitivas gráficas de
uso interno do
alterar
a
servidor
tabela
de
e
as
cores,
rotinas
para
iniciar
e
caso ela exista no sistema
implementado.
É
são
importante notar que as rotinas
necessárias mesmo
que
da
subcamada
MFB
o sistema, sobre o qual está
sendo implementado o servidor X, tenha a memória de imagem
com profundidade maior que um. Isto
sistema
X
se
explica,
pois
o
de profundidade igual a
trabalha com llpixmapsll
um para a criação
l1pixmapsW são
de
padrões
do
tipo
l~drawables", qualquer
I1stipplel1. Como
primitiva pode ser
aplicada a eles.
A subcamada SNF (ssServer
Natural FormatVs) contém
rotinas
para
caracteres no
tratamento
formato
SNF.
as
com
arquivos
de
fontes
de
0s
arquivos
de
fontes
de
caracteres são obtidos neste formato através da compilação
das
fontes
de
caracteres
formato BDF (uma pequena
fornecidas
variação
do
pelo sistema X no
Adobe
2.1
Bitmap
Distribution
Format da Adobe Systems, Inc.). O compilador
de fontes de
caracteres
servidor modelo.
Uma
é
vez
fornecido
juntamente
compilados, os
do
servidor
e
as
o
arquivos das
fontes são abertos pelas rotinas já mencionadas da
OS
com
fontes necessitadas
camada
são obtidas
através das rotinas da subcamada SNF.
A ultima subcamada da camada DDX é a responsável pela
interface com o hardware gráfico, com a tabela
com
de
cores,
Esta subcamada no servidor
o teclado e com o llmousell.
modelo é que chama as rotinas do sistema operacional
abrir,
ler,
escrever
e
fechar
estes
para
dispositivos.
servidor modelo fornece diversos exemplos dessa
O
interface
para sistemas estrangeiros como SUN, IBM, DEC e outros.
. Metodologia
Utilizada na Implementação da Camada DDX
Conforme
descrito
anteriormente
a metodologia para
implementação da camada DDX no Terminal X foi definida
em
duas etapas. Na primeira etapa o compromisso maior foi com
simplicidade
e,
conseqüentemente, com
o
tempo para se
colocar o Terminal X funcionando. Numa segunda etapa,
são
feitas as diversas otimizações e neste caso o compromisso
maior é com o desempenho do sistema.
~ s s i msendo, na primeira etapa
servidor X
da
implementação
do
no Terminal X, foram utilizadas as rotinas da
subcamada MI. As rotinas da
subcamada MFB
também
foram
-85-
As rotinas da subcamada CFB foram reescritas para
interação
a
com I1drawables1Ide profundidade igual a oito, a
profundidade da
memória
de
imagem
do
Terminal
X.
As
primitivas Pixblit foram escritas utilizando as primitivas
fornecidas pelo
processador gráfico do Terminal X. Foram
criadas rotinas que replicam um lltilell
por uma determinada
área, rotinas para
preenchimento
de
traçado
de
retas
e
pontos
e
para
áreas. Essas rotinas enviam os comandos
para execução das respectivas informações através da linha
seria1 que comunica o Pegasus com o
rotinas
desta
Terminal
X.
Algumas
subcamada que são fornecidas pelo servidor
modelo, tiveram que ser preservadas para a
I1drawablest1
do tipo llpixmapsll.
interação
com
-86-
controle dos
dispositivos
exibição da memória
de
de hardware responsáveis pela
imagem
na
tela
do
monitor
do
Terminal X.
Na
segunda
etapa da implementação da camada DDX, as
rotinas da subcamada MI,
responsáveis
pelas
primitivas
gráficas definidas pelo sistema X Window, serão reescritas
para
o
aproveitamento integral das primitivas oferecidas
pelo processador gráfico HD63484. Desta
mais
necessário,
na
será
maior parte dos casos, a utilização
das primitivas Pixblit, oferecidas
para a interação
forma, não
pela
subcamada
CFB,
TESTES E AVALIAÇÃO DA IMPLEMENTAÇÃO
VI.l.
Tes es Realizados
0s
testes
foram iniciados pelo hardware do Terminal
X. Primeiramente, foi testada a parte do hardware
geral,
de
uso
ou seja, aquela que não é dedicada ao uso gráfico.
O processador MC68000 foi colocado em
funcionamento para
executar um programa monitor, gravado em ROM, para teste e
depuração dos demais circuitos. A partir deste monitor foi
realizado
o teste da memória de 1 Mbytes e das interfaces
seriais.
No monitor foi implementada uma rotina para
programas
para
serem
executados
carregar
na memória do sistema.
Essa rotina foi desenvolvida de forma a carregar programas
no
formato
interfaces
executável, recebidos através
seriais.
Esses
programas
de
eram
Pegasus-32X e enviados através de uma de
suas
uma
gerados
das
no
interfaces
seriais para o Terminal X.
Por esse mecanismo, foi possível o desenvolvimento de
um
segundo
programa monitor mais complexo. Esse programa
foi criado com a finalidade de testar o hardware
Através
deste, pôde-se
programar
e
gráfico.
testar as diversas
-88primitivas
HD63484.
gráficas
Foi
existentes
testado
o
no
gráfico
controle do processador gráfico
sobre a memória de imagem e
a
proveniente
pelos
desta
processador
memória
utilização
da
informação
conversores
Foram feitos também os teste para o
acesso
a
do Bt458.
tabela
de
conversão de cores situada no Bt458. Finalmente, o monitor
colorido
foi
ligado
ao hardware do Terminal X e pôde-se
visualizar as operações do
processador
gráfico
sobre
a
memória de imagem.
Uma
vez
testado
todo
o
hardware
do
~erminalX,
passou-se para a implementação de um programa
X
sistema
Window
no
Pegasus-32X.
Para
cliente
isso,
do
foram
utilizados quatro programas clientes cujos fontes escritos
em linguagem C, são fornecidos juntamente com o sistema
original.
criado
Esses
com
programas
a
Pegasus/Plurix.
implantação
Resolvidos
incompatibilidade das
pois
os
foram
compilados no ambiente
da
os
chamadas
X
biblioteca
problemas
ao
sistema
X
no
iniciais
de
operacional,
aplicativos também são desenvolvidos para o Unix
4.3 BSD, obteve-se quatro programas clientes executáveis e
que utilizam diversas chamadas as rotinas da biblioteca X.
Esses
servidor
X
aplicativos
foram
funcionando, para
executados, ainda
comunicação
de
uma
linha
serial. Nesse pedido, o cliente envia sua
versão no sistema X
natural
o
observação do protocolo X
para pedido de conexão, transmitido através de
de
sem
(no caso versão
11.2)
e
a
ordem
como é feito o acesso, no computador em que é
-89-
executado, aos dois
bytes
de
uma
palavra
de
bits
16
(acesso na ordem I1little-endien"ou I1big-endianV1)
.
Duas
linhas
de
comunicação seria1 que não possuiam
LOGIN foram interligadas no Pegasus e foi implementado
Plurix para a abertura
das
linhas
seriais
não
um
estavam
inicializando corretamente essas linhas em modo llrawll.
Os
bytes recebidos estavam sendo alterados pois eram tratados
pelo
sistema
operacional
cliente,
quanto
problema
foi
parâmetros
tanto
na
transmissão
pelo
na recepção pelo programa de teste. Esse
resolvido
rapidamente
passando-se
os
corretos para a abertura das linhas seriais em
modo llrawll.
A
partir
destes
testes,
passou-se
para
a
implementação do servidor X no Pegasus. Essa implementação
foi
feita
somente
por
os
testados.
partes,
módulos
Dentro
do
de
sendo
analisados
servidor X
cada
módulo,
que
foram
e
compilados
estavam
sendo
separadas
as
rotinas que não estavam sendo testadas, colocando-se elas
entre comentários. Nas rotinas que estavam em teste, foram
inseridos
passagem
llprintfll
com
por
aquele
o
nome da rotina para indicar a
ponto.
Essa
metodologia
foi
fundamental para o desenvolvimento do servidor X dentro do
-90-
ambiente Pegasus/Plurix e Terminal X, pois conforme já foi
mencionado,
diversos módulos do servidor X são extensos e
cada um possui internamente um grande número
de
rotinas.
Sem a utilização desta metodologia, diante da complexidade
e
da
quantidade
das funções executadas pelo servidor X,
seria difícil localizar, em caso de erro, em
qual
rotina
estava o problema.
As
primeiras rotinas compiladas foram as que iniciam
o servidor X. Essas rotinas são responsáveis por
as
diversas
parâmetros
servidor
estruturas utilizadas
com
as
pelo
características do
atribuir
servidor X os
hardware
que
o
irá controlar. Além disto, essas rotinas iniciam
o hardware gráfico, preenchendo a tabela de cores
com
um
determinado conteúdo, criando a janela raiz que ocupa toda
a
tela
de exibição do monitor do Terminal X, colocando o
cursor inicial na tela, monitorando o teclado e o
e
llmousell
criando as cores iniciais para desenho (l1foregroundW)e
fundo (I1backgroundn).Para implementação das
iniciam
rotinas
que
o hardware, foi necessário o teste da comunicação
do Pegasus com
o
Terminal
X
e
o
teste
do
protocolo
definido para requisição das operações a serem realizadas
pelo Terminal X.
Depois foram testadas as rotinas do servidor para
leitura
e
escrita
no
canal
de
comunicação
a
seria1
estabelecido com o cliente. Foi iniciada a comunicação do
cliente
com
o
servidor, através da análise por parte do
servidor do protocolo X para conexão enviado pelo
cliente
-91-
e
a
resposta
do
servidor
enviando
características do hardware gráfico e
dos
recursos
já
criados.
Esses
exemplo, a janela raiz, a tabela de
para
os
o cliente as
identificadores
recursos
cores
incluem, por
inicial
e
as
cores de lrforegroundlr
e de llbackgroundll
iniciais.
Uma
vez
cliente
e
testada
servidor,
individualmente cada
utilizadas
desta
e
pelos
estabelecida
começaram
uma
quatro
forma, testar
a conexão entre o
a
ser
testadas
das requisições do protocolo X
clientes mencionados.
Pode-se
a implementação de todas as funções
desempenhadas pelo servidor X, juntamente com as operações
realizadas pelo hardware do
possível
Pegasus
testar
com
operações
o
Terminal
X.
Foi
igualmente
o protocolo criado para a comunicação do
Terminal
gráficas
e
X,
enviando
requisições para
lendo sinalizações provenientes do
" m o ~ s ee~do
~ teclado. Para a implementação das
operações
realizadas pelo Terminal X, foram utilizados como base os
programas monitores construidos para teste do hardware
do
Terminal X.
A
utilização dos programas clientes fornecidos junto
ao sistema X Window facilitou bastante
A
testes.
operação
diversas rotinas da
deles
serem
desses
biblioteca
compilados
e
a
realização
dos
programas, utilizando
X,
foi
analisada
executados.
as
antes
Através
da
visualização dos resultados obtidos na tela do Terminal X,
durante a
observar
execução
tanto
os
desses
programas
erros
existentes
clientes, pôde-se
como
constatar
a
correta operação das rotinas do servidor X e
VI.2.
do
Terminal
Avaliação da Irnplementação
Uma
primeira avaliação da implementação realizada do
Terminal X nos permite dizer que o objetivo principal
alcançado.
foi
Pôde-se, em um período de tempo relativamente
curto, dotar o sistema operacional Plurix de uma interface
gráfica padrão, o sistema X Window.
Numa
podem
análise
ser
mais
profunda,
sugeridas.
a
capítulo V,
implementação
Conforme
primeira
da
algumas
já
otimização
foi
deve
modificações
mencionado
no
ser
na
feita
camada DDX do servidor. A segunda etapa
da implementação desta camada, descrita naquele
pode
ser
considerada
fundamental para
capítulo,
melhoria
a
do
desempenho do servidor dentro do Terminal X implementado.
Esta afirmação
realizados
com
os
foi
comprovada
quatro
anterior. A execução das
prejudicada
pelo
fato
clientes
tarefas
através
dos
testes
mencionados no item
gráficas
foi
bastante
de não se estar utilizando todo o
potencial oferecido pelo processador gráfico. A utilização
do
processador
gráficas
de
somente
mais
baixo
para
o
nível,
traçado
primitivas
tornou o servidor menos
eficiente pois as primitivas de mais
sendo implementadas por software.
de
alto
nível
estavam
Além
disto,
rotinas para
realizadas
outras
"clipping1I de
por
do
áreas,
software, em
primitivas de mais
partir
funções, como
alto
instante
utilizado
para
o
realizar
também
em
nível
que
traçado
o
exemplo as
tiveram
função da
também
que
emulação
por
ser
das
A
software.
processador gráfico seja
destas
primitivas
I1clippingl1 por
o
por
pode-se
intermédio
do
processador, pois esta é uma das funções que ele oferece.
A pouca utilização do
também
o
fluxo
de
desta
pelos
Pegasus
linha
mais o desempenho do
gráfico
Terminal
X.
Como
a
não é alta isto prejudicou ainda
sistema
demais motivos
ao
implementado.
explicados, pode-se
Por
esse
afirmar
haverá uma melhora considerável no desempenho do
X,
aumentou
informações na linha de comunicação
seria1 que interliga o
velocidade
processador
e
que
Terminal
quando este passar pela segunda etapa da implementação
da camada DDX do servidor X utilizado.
Um outro fator a ser analisado é a ligação do cliente
com
o
seriais
servidor, implementada através
duas
linhas
do Pegasus. A respeito deste mecanismo, foi feito
um teste bastante conclusivo. No lugar de
cliente
de
juntamente com
se
executar
o
o servidor no Pegasus, o cliente
foi implementado em outro computador que utiliza o sistema
operacional ~lurix.Esse computador, um
adquirido pelo
NCE/UFRJ
EBC
32010,
foi
durante o desenvolvimento deste
trabalho. O EBC 32010 é um supermicrocomputador baseado no
microprocessador MC68010 e sua capacidade de processamento
-94-
é
inferior a do Pegasus-32X.
A
execução
do
cliente no
EBC
32010
permitiu
a
constatação que, na implementação realizada do ~erminalX,
a
velocidade
da comunicação entre o cliente e o servidor
não é relevante em
relação
ao
desempenho do
sistema.
Pôde-se observar que a limitação do sistema está realmente
na
implementação
do
servidor.
conclusão, foi utilizada uma
seria1
Para
das
se
chegar
linhas de
a esta
comunicação
do EBC 32010 para ligá-lo ao Pegasus. Os programas
clientes,
já
mencionados
no
item
anterior,
foram
implementados no EBC, depois de implantada a biblioteca X
neste sistema, e o servidor X foi mantido no Pegasus.
Como os dois processos passaram a ser
sistemas
executados
em
computacionais distintos, esperava-se um aumento
na velocidade de
visualização
das
requisições enviadas
pelo cliente ao Terminal X. Porém, o que foi observado foi
que o servidor executado no Pegasus não conseguia retirar,
em
tempo
hábil, as requisições recebidas e o I1bufferl1do
Plurix, executado no
acumular
Pegasus, não
estas mensagens.
Desta
era
suficiente para
forma, depois de algum
tempo de execução, o servidor perdia parte
das
mensagens
enviadas pelo cliente interrompendo a execução deste.
Só
foi possível a execução dos aplicativos/clientes
do sistema X no EBC 32010 e
do
através
rotina XSync da biblioteca X.
da
utilização
da
servidor X
no
Pegasus,
Esta rotina é utilizada para sincronizar o cliente
com
o
-95-
servidor, pois
o
servidor
só
irá atendê-la depois que
executa todas as requisições já existentes. Ao atendê-la o
servidor responde ao cliente e só então este continua
sua
execução.
Este teste serviu não só para confirmar a necessidade
de
otimizações no servidor X, como também para comprovar
uma das características do sistema
ambiente distribuído, com
sistema
computacional
arquitetura, que
só
e
a
do
era
X.
Pôde-se
execução
na
outro.
segunda
implementação do Terminal X, quando então ele
ligado
por
meio
de
redes
de
utilização
das
linhas de
biblioteca
fase da
ser
alta velocidade a outros
comunicação
disto, teve-se a oportunidade de se testar
da
Esta
poderá
sistemas que utilizem o Plurix, pode ser simulada
da
um
do cliente em um
servidor em
prevista
criar
através
serial. Além
a
implantação
X realizada no ambiente Pegasus/Plurix, em
um outro computador distinto que também utiliza o Plurix.
A avaliação final que se pode fazer da
implementação
realizada do Terminal X é que ela foi totalmente válida e
a
metodologia utilizada
deficiências apareceram
foi
igualmente
correta.
As
nos pontos onde foram previstas,
mas foram totalmente compensadas pela possibilidade que se
teve de rapidamente poder executar aplicações/clientes
sistema
X
Window
no
sistema
visualizar seus resultados no
fato
a
Terminal X.
continuação
do
Plurix
Somente
e
este
trabalho
e ajuda
inclusive, a indicar outras áreas do servidor que
estejam
já
incentiva
operacional
do
O
trabalho
implementação
operacional
explicado
pois
desenvolvido
de
uma
Plurix.
no
oferece
permitiu
interface
Esta
gráfica
a
rápida
no
sistema
interface, conforme
já
foi
capítulo 11, é uma interface de baixo nível
somente rotinas
gráficas
básicas
para
implementação de aplicações.
Outras
bibliotecas
podem
ser implementadas sobre a
biblioteca básica já existente. Estas
seu
transporte
facilitado,
pois
bibliotecas
são
teriam
desenvolvidas
utilizando as rotinas básicas padronizadas pelo sistema
Window
que
foram
implementadas no
Dentre
mais
alto
destacar
a
Toolkit, fornecida junto ao próprio
X
sistema X Window, a Motif, definida
existentes,
as
bibliotecas de
três:
nível
Plurix.
X
e
pode-se
desenvolvida
pela
Open Software Foudation, e a Looking Glass, oferecida pela
Visix Software.
Estas
bibliotecas
são
utilizadas por
fabricantes de sistemas computacionais gráficos
diversos
e
existe
atualmente uma disputa sobre qual delas se tornará padrão
para o desenvolvimento dos aplicativos
gráficos
executados nesses sistemas computacionais.
a
serem
-98-
Estudos
estão
sendo
feitos sobre cada uma das três
bibliotecas mencionadas, enquanto aguarda-se
de
qual
delas
será
a
definição
utilizada pela maioria dos sistemas
gráficos. Pretende-se implantar a que
for
definida
como
padrão, sobre a biblioteca básica do sistema X Window. Com
isto, os aplicativos já desenvolvidos para utilizarem esta
interface
gráfica
de alto nível, podem ser transportados
para o ambiente Plurix/Terminal X. Da mesma forma, pode-se
desenvolver
softwares
aplicativos
no
Terminal
X
e
transportá-los para outros sistemas distintos que possuam
a mesma interface gráfica.
Além da implantação de bibliotecas de mais alto nível
sobre a interface gráfica implementada,
atuação
áreas
trabalho,
já
como
foram
definidas
otimização
a
do
dentro
comunicação utilizando
o
e a
para
a
protocolo TCP/IP. Outras áreas
podem ser citadas de forma a dotar o Terminal X de
gráficos
deste
servidor
implementação da interface Ethernet e das rotinas
recursos
de
podem ser adotadas para a continuação do trabalho
desenvolvido. Algumas
próprio
outras
mais
sofisticados
e
outros
também
para
gerenciar os recursos já oferecidos pelo sistema X Window.
Uma área interessante é
(llPhigs+Extension
o
estudo
definidas pela
Organizationgl) para
extensão
PEX
to XI1) que está sendo definida para o
protocolo X Window. A interface Phigs+ é
rotinas
da
o
ISO
um
conjunto
de
(I1International Standards
desenvolvimento
de
aplicações
gráficas que fazem a exibição de imagens com a perspectiva
-99-
em
três
dimensões
(3D). Esse conjunto de rotinas requer
uma grande quantidade de
destas
imagens
acelerador
e
comum
é
gráfico
processamento
para
a
a
para
definição
a
exibição
de um hardware
execução, de
forma
mais
eficiente, das diversas tarefas associadas as rotinas para
a
exibição
em 3D. A extensão PEX vem sendo definida pelo
X,
MIT para possibilitar a implantação, sobre o protocolo
das rotinas Phigs+. Isto permitirá que o servidor X receba
requisições
para
execução
de
funções
3D, podendo-se
definir e implementar um hardware acelerador gráfico
para
ser controlado pelo servidor X.
Além
estudo
desta
de
área,
existe
algoritmos
gerenciadores
de
também a possibilidade do
para
janelas
serem
utilizados
nos
para o sistema X Window e para
implementar algumas funções mais complexas definidas neste
sistema. Estas
funções
armazenamento de
outras
imagens
é
procedimento
alguma
sobre
as
está
exemplo,
o
imagens
originais.
Este
definido para o sistema X Window, porém a
área
atualização
da
memória
de
imagem
oculta se torna visível, é deixada a
cargo do cliente que é dono
exibida
incluir, por
imagens que são ocultas quando se exibe
responsabilidade de
quando
podem
contida.
da
janela
~eixar esta
na
qual
tarefa
a
a
área
cargo do
servidor X exige o estudo de um algoritmo para implementar
esta função, pois a quantidade de memória, além da memória
de imagem,
necessária
ocultas
teoricamente, infinita pois o sistema X Window
é,
não limita
o
número
para
máximo
o
armazenamento
de
janelas
que
das
áreas
podem
se
-101-
REFERÊNCIAS
i11
BIBLIOGRAFICAS
FALLER, N. et alii, "0 Projeto PEGASUS-32X/PLURIX",
Anais do XVII Conqresso
Nacional
de
Informática,
Rio de Janeiro, Nov. 1984.
121
FALLER,
N.,
ANIDO,
M.
L.
e
llTécnicasde Projeto Utilizadas
Supermicrocomputador
Operacional
SALENBAUCH,
na
Construção
PEGASUS-32X
PLURIXI1, Anales
de
e
do
La
P.,
do
Sistema
Convención
Informática Latina. CIL 85, Barcelona, Abr. 1985.
i31
FALLER,
N.
e
multiprocessing
SALENBAUCH,
UNIX-like
Proceedinqs
o£
the
Workstation
Operatinq
P.,
I1PLURIX:
Operating
Second
IEEE
System,
A
System1I
Workshop
on
29-36,
PP
Washington, Set. 1989.
i41
SCHEIFLER,
R.W.
e
GETTYS, J.,
"The X
Window
SystemI1,ACM Transactions on Graphics, vol. 5,
no.
2, pp. 233-248, 1986.
i51
WESTMORE,
R.J.,
"A
Window-Based
Graphics
Store ArchitectureV1,
ACM Transactions on
Frame
Graphics,
vol. 7, no. 4, pp. 233-248, 1988.
161
COMER,
D. ,
Principies,
I1Internetworkinq
Protocols
and
with
TCP/IP
-
Architecturerl, New
[7I
SCHEIFLER, R.W., GETTYS, J. e NEWMAN, R., ItXWindow
-
System
C
Librarv
and
Protocol
Referencett.
Bedford, Digital Press, 1st Edition, 1988.
L81
4.3
BERKELEY
SOFTWARE
DISTRIBUTION,
"UNIX
Proqrammerts Manualtt, U.S.A, Berkeley University,
7th Edition, 1986.
i91
POUNTAIN, D., IfTheX Window Sy~tern~~,
BYTE, vol. 14,
no. 1, pp. 353-360, 1989.
[10]
GETTYS, J., "Network Windowing Using the
Systemtf, Dr.
Dobb's
X
Window
Journal, vol. 14, no. 3, pp.
42-53, 1989.
[ll]
ANGEBRANNDT, S. et alii,
the
X
v11
Sample
tfStrategies for
Porting
Server", X Window v11.2 System
Manuals, Massachusetts
Institute
of
Technology,
1988.
[12]
MANUEL,
T.,
ItNow,Low-Cost Terminais Can Run Like
Work Stationsu, Electronics, vol. 61, no.
18, pp.
45-46, 1988.
[13]
BALDWIN,
H.,
ttWhy A11
The
~houting Over
X
terminal^?^^, Unix World, vol. 6, no. 10, supplement
Unix Networking, pp. 75-80, 1989.
-104Specif ication" ,
X
W i n d oi~ v11.2
Svstem
Manuals,
Massachusetts Institute o£ Technology, 1988.