Windows 2000
C
O Microsoft Windows é um sistema operacional multitarefa
e preemptivo de 32 bits para o Pentium da Intel e micropro-
cessadores posteriores. Sucessor do sistema operacional Win-
dows NT, foi chamado anteriormente de Windows NT Version
5.0. Os objetivos essenciais do sistema são portabilidade, segu-
rança, compatibilidade com o Portable Operating System
C.1
Em meados dos anos 1980, a Microsoft e a IBM desenvolve-
ram em cooperação o sistema operacional OS/2, que foi escrito
em linguagem de montagem para sistemas monoprocessado-
res Intel 80286. Em 1988, a Microsoft decidiu inovar e desen-
volver um sistema operacional portável com “nova tecnologia”
(ou NT) que suportasse as interfaces de programação de apli-
cações (APIs) tanto do OS/2 quanto do POSIX. Em outubro
de 1988, Dave Cutler, o arquiteto do sistema operacional DEC
VAX/VMS, foi contratado e ficou encarregado da construção
desse novo sistema operacional.
Originalmente, a equipe pensou em usar a API do OS/2
como ambiente nativo do NT, mas durante o desenvolvi-
mento, ele foi alterado para usar a API do Windows de 32
bits (ou API Win32) refletindo a popularidade do Windows
3.0. As primeiras versões do NT foram o Windows NT 3.1 e
o Windows NT 3.1 Advanced Server. (Na época, o Windows
de 16 bits estava na versão 3.1.) O Windows NT 4.0 adotou a
interface de usuário do Windows 95 e incorporou software de
servidor Web e de navegador da Internet. Além disso, roti-
nas de interface de usuário e código gráfico foram transfe-
ridos para o kernel visando melhorar o desempenho, com
o efeito colateral de diminuir a confiabilidade do sistema.
Embora versões anteriores do NT tenham sido portadas para
outras arquiteturas de microprocessadores, o Windows des-
continuou esta prática devido a fatores de mercado. Assim,
portabilidade refere-se, agora, à portabilidade entre sistemas
com arquitetura Intel. O Windows usa uma arquitetura de
C.2 Princípios de Projeto
Os objetivos de projeto que a Microsoft estabeleceu para o
Windows incluem extensibilidade, portabilidade, confiabili-
dade, compatibilidade, desempenho e suporte internacional.
Extensibilidade refere-se à capacidade de um sistema ope-
racional acompanhar os avanços na tecnologia de computação.
Para facilitar as mudanças no tempo, os desenvolvedores imple-
mentaram o Windows usando uma arquitetura em camadas. O
executivo do Windows que executa em modalidade protegida
APÊNDICE
Interface (POSIX ou IEEE Std. 1003.1), suporte a multiproces-
sadores, extensibilidade, suporte internacional e compatibi-
lidade com aplicações MS-DOS e Microsoft Windows. Neste
apêndice, discutimos os objetivos essenciais deste sistema, sua
arquitetura em camadas que o torna tão fácil de usar, o sistema
de arquivos, redes e a interface de programação.
História
microkernel (como o Mach) e, portanto, melhorias podem ser
feitas em uma parte do sistema operacional sem afetar, subs-
tancialmente, outras partes. Com a inclusão dos Serviços de
Terminal, o Windows é um sistema operacional multiusuário.
O Windows foi lançado em 2000 e incorporou mudanças
significativas. Ele adicionou um serviço de diretório com base
no X.500, melhor suporte à conexão de rede, suporte a disposi-
tivos plug-and-play, um novo sistema de arquivos com suporte
a armazenamento hierárquico e um sistema de arquivos distri-
buído, bem como suporte a mais processadores e mais memória.
Há quatro versões do Windows. A versão Professional des-
tina-se ao uso em computadores desktop. As outras três são
versões de servidor: Server, Advanced Server e Datacenter
Server, que diferem principalmente quanto ao montante de
memória e ao número de processadores que suportam. Elas
usam o mesmo kernel e código do sistema operacional, mas as
versões Windows Server e Advanced Server são configuradas
para aplicações cliente-servidor e podem atuar como servido-
res de aplicações em LANs NetWare e Microsoft. Atualmente,
o Windows Datacenter Server suporta até 32 processadores e
até 64 GB de RAM.
Em 1996, foram vendidas mais licenças do Windows NT
Server do que todas as versões de licenças UNIX. O interes-
sante é que o código básico do Windows é da ordem de 30
milhões de linhas de código. Compare este tamanho com o
código básico do Windows NT 4.0: cerca de 18 milhões de
linhas de código.
ou de kernel, fornece os serviços básicos do sistema. Acima do
executivo, vários subsistemas de servidor operam em moda-
lidade de usuário. Entre eles estão os subsistemas ambien-
tais que emulam diferentes sistemas operacionais. Logo, todos
os programas escritos para MS-DOS, Microsoft Windows e
POSIX podem ser executados no Windows no ambiente apro-
priado. (Consulte a Seção C.4 para mais informações sobre
subsistemas ambientais.) Devido à estrutura modular, subsis-

temas ambientais adicionais podem ser adicionados sem afetar
o executivo. Além disso, o Windows usa drivers carregáveis no
sistema de I/O e, portanto, novos sistemas de arquivos, novos
tipos de dispositivos de I/O e novos tipos de conexão de rede
podem ser adicionados enquanto o sistema está em execução.
O Windows usa um modelo cliente-servidor, como o sistema
operacional Mach, e suporta processamento distribuído por
chamadas de procedimento remotas (RPCs) como definido
pela Open Software Foundation.
Um sistema operacional é portável quando ele pode ser
movido de uma arquitetura de hardware para outra com, rela-
tivamente, poucas alterações. O Windows foi projetado para
ser portável. Como o sistema operacional UNIX, a maior parte
do sistema é escrita em C e C++. Todo o código dependente do
processador fica isolado em uma biblioteca de vínculo dinâ-
mico (DLL), chamada camada de abstração de hardware
(HAL – hardware-abstraction layer). Uma DLL é um arquivo
mapeado para o espaço de endereçamento de um processo de
tal modo que quaisquer funções da DLL parecem fazer parte
do processo. As camadas superiores do Windows dependem
da HAL, e não do hardware subjacente, o que ajuda o Windows
a ser portável. A HAL manipula o hardware diretamente, iso-
lando o resto do Windows das diferenças de hardware entre as
plataformas em que ele executa.
Confiabilidade é a capacidade de manipular condições de
erro, inclusive a capacidade de o sistema operacional proteger
a si próprio e a seus usuários de software defeituoso ou mali-
cioso. O Windows resiste a defeitos e ataques usando proteção
de hardware para memória virtual e mecanismos de proteção
de software para recursos do sistema operacional. Além disso,
o Windows vem com um sistema de arquivos nativo – o sis-
tema de arquivos NTFS – que se recupera automaticamente de
muitos tipos de erros que acometem os sistemas de arquivos
após uma queda do sistema. O Windows NT 4.0 recebeu uma
classificação de segurança C-2 do governo dos Estados Unidos,
o que significa um nível moderado de proteção contra softwa-
res defeituosos e ataques maliciosos.
O Windows fornece compatibilidade, no nível do código-
fonte, a aplicações que seguem o padrão IEEE 1003.1 (POSIX).
C.3 Componentes do Sistema
A arquitetura do Windows é um sistema de módulos em
camadas, como mostrado na Figura C.1. As camadas prin-
cipais são a HAL, o kernel e o executivo, todas executadas
em modalidade protegida, e um grande conjunto de subsis-
temas que opera em modalidade de usuário. Os subsistemas
de modalidade de usuário pertencem a duas categorias. Os
subsistemas ambientais emulam diferentes sistemas operacio-
nais; os subsistemas de proteção fornecem funções de segu-
rança. Uma das principais vantagens desse tipo de arquitetura
é que as interações entre os módulos são mantidas simples. O
resto desta seção descreve essas camadas e subsistemas.
C.3.1 Camada de Abstração de Hardware
A HAL é a camada de software que oculta diferenças de hardware,
dos níveis superiores do sistema operacional, para ajudar a
Windows 2000  4 5
Portanto, essas aplicações podem ser compiladas para execu-
ção no Windows sem alterações no código-fonte. Além disso,
o Windows pode operar os binários executáveis de muitos
programas compilados para arquiteturas Intel X86 que exe-
cutem sob o MS-DOS, o Windows de 16 bits, o OS/2, o LAN
Manager e o Windows de 32 bits, por intermédio dos subsis-
temas ambientais mencionados anteriormente. Esses subsis-
temas ambientais dão suporte a vários sistemas de arquivos,
inclusive o sistema de arquivos FAT do MS-DOS, o sistema
de arquivos HPFS do OS/2, o sistema de arquivos de CD,
ISO9660, e o NTFS. A compatibilidade binária do Windows,
no entanto, não é perfeita. No MS-DOS, por exemplo, as apli-
cações podem acessar portas de hardware diretamente. Por
questões de confiabilidade e segurança, o Windows proíbe tal
acesso.
O Windows é projetado para alcançar bom desempenho.
Os subsistemas que compõem o Windows podem se comu-
nicar uns com os outros eficientemente por meio de um
recurso de chamada de procedimento local (LPC) que for-
nece transmissão de mensagens de alto desempenho. Exceto
no kernel, os threads dos subsistemas do Windows podem
sofrer preempção por threads de prioridade mais alta. Logo,
o sistema pode responder rapidamente a eventos exter-
nos. Além disso, o Windows é projetado para multiproces-
samento simétrico; em um computador multiprocessador,
vários threads podem ser executados ao mesmo tempo. A
escalabilidade atual do Windows é limitada, comparada com
a do UNIX.
O Windows também é projetado para uso internacional.
Ele dá suporte a diferentes localidades por meio da API de
suporte ao idioma nacional (NLS – national language sup-
port). A API NLS fornece rotinas especializadas para a forma-
tação de data, hora e moeda de acordo com costumes nacionais
diferenciados. Comparações de cadeias de caracteres são espe-
cializadas para levar em conta diferentes conjuntos de caracte-
res. O UNICODE é o código de caracteres nativo do Windows;
o suporte a caracteres ANSI é feito convertendo-os em caracte-
res UNICODE antes de sua manipulação (conversão de 8 bits
para 16 bits).
tornar o Windows portável. A HAL exporta uma interface de
máquina virtual que é usada pelo kernel, pelo executivo e pelos
drivers de dispositivos. Uma vantagem desta abordagem é que
apenas uma única versão de cada driver de dispositivo é neces-
sária – ela pode ser executada em todas as plataformas de hard-
ware sem portar o código do driver. A HAL também dá suporte ao
multiprocessamento simétrico. Por motivos de desempenho,
os drivers de I/O (e os drivers gráficos do Windows) podem
acessar o hardware diretamente.
C.3.2 Kernel
O kernel do Windows fornece a base para o executivo e os sub-
sistemas. O kernel nunca é removido da memória e sua execu-
ção nunca sofre preempção. Ele tem quatro responsabilidades
principais: scheduling de threads, manipulação de interrup-
4 6   Apêndice C

processo aplicações aplicações aplicações aplicações aplicações

de login OS/2 Win16 Win32 MS-DOS POSIX

subsistema VDM VDM subsistema

de segurança Win18 MS-DOS POSIX

pacote de
autenticação

banco de dados do
gerenciador de contas subsistema
de segurança Win32 modalidade
de usuário

executivo
gerenciador de I/O
recurso de
monitor de gerenciador gerenciador
sistema de gerenciador gerenciador chamada de
arquivos referência de de plug de memória gerenciador
de objetos de processos procedimento
gerenciador segurança and play virtual de janelas
de caches local
drives de
dispositivos
kernel drivers de
drives de
rede dispositivos
gráficos
camada de abstração de hardware

hardware

Figura C.1 Diagrama de blocos do Windows.

ções e exceções, sincronização em baixo nível de processado-
res e recuperação após falta de energia. Examinamos cada uma
delas a seguir.
O kernel é orientado a objetos. Um tipo de objeto no Win-
dows é um tipo de dado definido pelo sistema, com um con-
junto de atributos (ou valores de dados) e um conjunto de
métodos (isto é, funções ou operações). Um objeto é apenas
uma instância de um tipo de objeto específico. O kernel exe-
cuta seu trabalho usando um conjunto de objetos do kernel
cujos atributos armazenam os dados do kernel e cujos métodos
executam as atividades do kernel.
O kernel usa dois conjuntos de objetos: objetos despa-
chantes e objetos de controle. Os objetos despachantes con-
trolam o despacho e a sincronização no sistema. Exemplos
desses objetos são eventos, mutants, mutexes, semáforos,
threads e timers. O objeto evento é usado para registrar a
ocorrência de um evento e sincronizar esta ocorrência com
alguma ação. O mutant fornece exclusão mútua em modali-
dade de kernel ou de usuário, com a noção de propriedade.
O mutex, disponível apenas em modalidade de kernel, for-
nece exclusão mútua sem deadlock. Um objeto semáforo age
como um contador ou porta para controlar a quantidade
de threads que acessam um recurso. O objeto thread é uma
entidade executada pelo kernel e associada a um objeto pro-
cesso. Os objetos timer são usados para controlar o tempo e
para sinalizar limites de tempo excedidos quando operações
demoram demais e têm de ser interrompidas.
O segundo conjunto de objetos do kernel é composto pelos
objetos de controle. Esses objetos incluem chamadas de pro-
cedimento assíncronas, interrupções, objetos de notificação de
energia, objetos de status de energia, objetos processo e objetos
perfil. O sistema usa uma chamada de procedimento assíncrona
(APC) para interromper um thread em execução e chamar um
procedimento. O objeto interrupção vincula uma rotina de
serviço de interrupção a uma fonte de interrupção. O sistema
usa o objeto notificação de energia para chamar automatica-
mente uma rotina especificada, após uma queda de energia, e
o objeto status de energia, para verificar se a energia falhou.
Um objeto processo representa as informações de espaço de
endereçamento virtual e de controle necessárias à execução do
conjunto de threads associado a um processo. Para concluir,
o sistema usa o objeto perfil para medir o período de tempo
usado por um bloco de código.
C.3.2.1 Threads e Scheduling
Como muitos outros sistemas operacionais modernos, o Win-
dows usa as noções de processos e threads para código executá-
vel. O processo tem um espaço de endereçamento de memória
virtual, além de informações como uma prioridade básica e afi-
nidade com um ou mais processadores. Cada processo tem um
ou mais threads, que são as unidades de execução despacha-
das pelo kernel. Cada thread tem seu próprio estado que inclui
uma prioridade, afinidade com o processador e informações de
contabilidade.
Os seis estados possíveis associados aos threads são: pronto,
disponível, em execução, em espera, em transição e encerrado.
O estado pronto significa que o thread está esperando para

ser executado. O thread pronto de prioridade mais alta é pas-
sado para o estado disponível, significando que ele será o pró-
ximo thread a ser executado. Em um sistema multiprocessador,
há um thread no estado disponível para cada processador. Um
thread está em execução quando está sendo executado em um
processador. Ele será executado até sofrer preempção por um
thread de prioridade mais alta, até terminar, até seu quantum de
tempo terminar ou até invocar uma chamada de sistema bloquea-
dora, como em caso de I/O. Um thread está no estado de espera
quando está aguardando um sinal, como na conclusão de uma
operação de I/O. Um novo thread está no estado de transição
enquanto espera pelos recursos necessários para execução. Um
thread entra no estado encerrado quando termina a execução.
O despachante usa um esquema de prioridades de 32 níveis
para determinar a ordem de execução dos threads. As prio-
ridades são divididas em duas classes. A classe variável con-
tém threads que têm prioridades de 0 a 15 e a classe de tempo
real contém threads com prioridades variando de 16 a 31. O
despachante usa uma fila para cada prioridade do scheduling
e percorre o conjunto de filas, da mais alta a mais baixa, até
encontrar um thread que esteja pronto para ser executado. Se
um thread tem afinidade com um processador específico, mas
este processador não está disponível, o despachante o ignorará
e continuará procurando por um thread que esteja pronto para
ser executado. Se nenhum thread pronto for encontrado, o des-
pachante executará um thread especial chamado thread ocioso.
Quando o quantum de tempo de um thread expira, este
thread é interrompido; se o thread estiver na classe de prio-
ridade variável, sua prioridade é reduzida. No entanto, a prio-
ridade nunca é reduzida para um valor menor do que o da
prioridade base. A redução da prioridade do thread tende a
limitar o consumo da CPU por threads limitados por com-
putação. Quando um thread de prioridade variável é liberado
de uma operação de espera, o despachante aumenta a prio-
ridade. O nível do aumento depende do motivo pelo qual o
thread estava esperando; por exemplo, um thread em espera
por I/O de teclado receberia um grande aumento de priori-
dade, enquanto um thread em espera por uma operação de
disco receberia um aumento moderado. Essa estratégia tende a
fornecer bons tempos de resposta para threads interativos que
estejam usando mouse e janelas. Ela também habilita threads
limitados por I/O a manterem os dispositivos de I/O ocupa-
dos enquanto permite que threads limitados por computação
usem ciclos avulsos da CPU em background. Tal estratégia é
usada por vários sistemas operacionais de compartilhamento
de tempo, inclusive o UNIX. Além disso, a janela corrente, com
a qual o usuário está interagindo, recebe um aumento de prio-
ridade para melhorar seu tempo de resposta.
O scheduling pode ocorrer quando um thread entra no
estado pronto ou de espera, quando um thread termina ou
quando uma aplicação muda a prioridade ou a afinidade com
o processador de um thread. Se um thread de tempo real de
prioridade mais alta passa para o estado pronto enquanto um
thread de prioridade mais baixa está em execução, o thread de
prioridade mais baixa sofrerá preempção. Esta preempção for-
nece ao thread de tempo real acesso preferencial à CPU quando
ele precisar deste acesso. No entanto, o Windows não é um sis-
Windows 2000  4 7
tema operacional de tempo real crítico, porque ele não garante
que um thread de tempo real comece a ser executado dentro de
um limite de tempo específico.
C.3.2.2 Exceções e Interrupções
O kernel também fornece a manipulação de interceptações para
exceções e interrupções geradas por hardware ou software. O
Windows define várias exceções independentes de arquitetura
que incluem violação de acesso à memória, estouro de intei-
ros, estouro positivo ou negativo de ponto flutuante, divisão de
inteiro por zero, divisão de ponto flutuante por zero, instrução
ilegal, desalinhamento de dados, instrução privilegiada, erro
de leitura de página, violação de página de proteção, cota de
arquivo de paginação excedida, ponto de interrupção de depu-
rador e depurador passo a passo.
O manipulador de interceptações pode tratar exceções sim-
ples; as outras são manipuladas pelo despachante de exceções
do kernel. O despachante de exceções cria um registro de exce-
ção contendo a razão da exceção e encontra um manipulador
de exceções que possa lidar com ela.
Quando ocorre uma exceção em modalidade de kernel, o
despachante de exceções simplesmente chama uma rotina para
localizar o manipulador de exceções. Se nenhum manipulador
for encontrado, ocorre um erro fatal de sistema e o usuário é
deixado com a infame “tela azul da morte”, que significa falha
do sistema.
A manipulação de exceções é mais complexa para processos de
modalidade de usuário porque um subsistema ambiental (como o
sistema POSIX) pode estabelecer uma porta de depurador e uma
porta de exceção para cada processo que ele cria. Se uma porta
de depurador for registrada, o manipulador de exceções envia
a exceção a esta porta. Se a porta de depurador não for encon-
trada ou não manipular essa exceção, o despachante tenta encon-
trar, então, um manipulador de exceções apropriado. Se nenhum
manipulador for encontrado, o depurador é chamado novamente
para poder capturar o erro para depuração. Se nenhum depurador
estiver em execução, uma mensagem é enviada à porta de exceção
do processo para dar ao subsistema ambiental uma chance de tra-
duzir a exceção. Por exemplo, o ambiente POSIX traduz mensa-
gens de exceção do Windows para sinais POSIX antes de enviá-las
ao thread que causou a exceção. Para concluir, se nada mais fun-
cionar, o kernel simplesmente encerra o processo que contém o
thread causador da exceção.
O despachante de interrupções do kernel manipula interrup-
ções chamando uma rotina de serviço de interrupção (como em
um driver de dispositivo) ou uma rotina interna do kernel. A
interrupção é representada por um objeto interrupção que con-
tém todas as informações necessárias à manipulação da inter-
rupção. O uso de um objeto interrupção torna fácil associar
rotinas de serviço de interrupções a uma interrupção sem que
seja preciso acessar o hardware de interrupções diretamente.
Várias arquiteturas de processador, como Intel e DEC
Alpha, têm diferentes tipos e números de interrupções.
Para portabilidade, o despachante de interrupções mapeia
as interrupções de hardware para um conjunto padrão. As
interrupções são priorizadas e servidas em ordem de prio-
4 8   Apêndice C

níveis de
interrupção tipos de interrupções

verificação de máquina ou erro de bus

falta de energia
notificação entre processadores (solicita que outro processador
atue; isto é, despache um processo ou atualize a TLB)
relógio (usado para rastrear o tempo)
perfil
interrupções de hardware tradicionais IRQ de PCs
despacho e chamada de procedimento adiada (DPC)(kernel)
chamada de procedimento assíncrona (APC)
passiva

Figura C.2 Níveis de solicitações de interrupções no Windows.

ridade. Há 32 níveis de interrupções (IRQLs - interrupt C.3.2.3 Sincronização de Processadores em Baixo Nível
request levels) no Windows. Oito são reservados para uso do
Outra responsabilidade do kernel é fornecer a sincronização
kernel; os outros 24 representam interrupções de hardware
de processadores em baixo nível. Ele faz isso usando chama-
por meio da HAL (embora a maioria dos sistemas x86 use
das de procedimento assíncronas (APCs). O mecanismo da
apenas 16 linhas). As interrupções no Windows são defini-
APC é semelhante ao mecanismo DPC mas é usado de modo
das na Figura C.2.
mais geral. O mecanismo da APC habilita threads a definirem
O kernel usa uma tabela de despacho de interrupções para
uma chamada de procedimento que ocorrerá inesperadamente
vincular cada nível de interrupção a uma rotina de serviço. Em
em algum momento futuro. Por exemplo, muitos serviços do
um computador multiprocessador, o Windows mantém uma
sistema aceitam uma rotina de modalidade de usuário como
tabela de despacho de interrupções separada para cada processa-
parâmetro. Em vez de invocar uma chamada de sistema sín-
dor e o IRQL de cada processador pode ser configurado indepen-
crona que bloqueará o thread até ser concluída, um thread de
dentemente para mascarar interrupções. Todas as interrupções
usuário pode invocar uma chamada de sistema assíncrona e
que ocorrem em um nível igual ao IRQL de um processador ou
fornecer uma APC. O thread de usuário continuará em execu-
menor do que ele, são bloqueadas até que o IRQL seja abaixado
ção. Quando o serviço do sistema terminar, o thread de usuá-
por um thread de nível do kernel. O Windows tira vantagem
rio será interrompido para executar a APC espontaneamente.
dessa propriedade no uso de interrupções de software para exe-
Uma APC pode ser enfileirada tanto em um thread do sis-
cutar funções do sistema. Por exemplo, o kernel usa interrupções
tema quanto em um thread de usuário, mas uma APC de moda-
de software para iniciar o despacho de um thread, para manipu-
lidade de usuário será executada apenas se o thread declarou a
lar timers e para dar suporte a operações assíncronas.
si próprio como passível de alerta. Uma APC é mais poderosa
O kernel usa a interrupção de despacho para controlar a
que uma DPC porque pode adquirir objetos e esperar neles,
mudança de contexto dos threads. Quando o kernel está em
causar erros de página e chamar serviços do sistema. Como
execução, ele aumenta o IRQL no processador para um nível
uma APC é executada no espaço de endereçamento do thread
acima do nível de despacho. Ao determinar que o despacho de
alvo, o executivo do Windows usa APCs para processamento
um thread é necessário, o kernel gera uma interrupção de des-
de I/O, extensivamente.
pacho, mas esta interrupção é bloqueada até que o kernel ter-
O Windows pode operar em máquinas multiprocessado-
mine o que está fazendo e diminua o IRQL. Nesse momento, a
ras simétricas e, portanto, o kernel deve impedir que dois de
interrupção de despacho pode ser servida e, portanto, o despa-
seus threads modifiquem uma estrutura de dados compar-
chante seleciona um thread para execução.
tilhada ao mesmo tempo. O kernel usa spinlocks, residentes
Quando o kernel decide que alguma função do sistema deve
na memória global, para conseguir exclusão mútua em mul-
eventualmente ser executada, porém não imediatamente, ele
tiprocessadores. Já que toda a atividade de um processador é
enfileira um objeto chamada de procedimento adiada (DPC),
interrompida quando um thread está tentando adquirir um
contendo o endereço da função a ser executada, e gera uma
spinlock, o thread que mantém um spinlock não sofre preemp-
interrupção de DPC. Quando o IRQL do processador cai o sufi-
ção e, assim, pode terminar sua execução e liberar o lock o mais
ciente, os objetos DPC são executados. O IRQL da interrupção de
rapidamente possível.
DPC é, normalmente, mais alto do que o de threads de usuário e,
assim, as DPCs interromperão a execução de threads de usuário.
Para evitar problemas, as DPCs restringem-se a um nível bem
C.3.2.4 Recuperação após Queda de Energia
simples. Elas não podem modificar a memória de um thread; A responsabilidade final do kernel é fornecer recuperação após
criar, adquirir ou esperar em objetos; chamar serviços do sis- queda de energia. Uma interrupção por queda de energia que
tema; ou gerar erros de página. tem a segunda prioridade mais alta, notifica o sistema opera-

cional sempre que a perda de energia é detectada. O objeto
notificação de energia fornece um modo para que o driver de
dispositivo registre uma rotina a ser chamada quando a ener-
gia é restaurada, de forma a assegurar que os dispositivos sejam
posicionados no estado apropriado quando da recuperação.
Para sistemas suportados por baterias, o objeto status de ener-
gia é útil. Antes de começar uma operação crítica, o driver exa-
mina o objeto status de energia para determinar se a energia
faltou ou não. Se o driver determina que não faltou energia, ele
aumenta o IRQL de seu processador de falta de energia, exe-
cuta a operação e reposiciona o IRQL. Esta sequência de ações
bloqueia a interrupção por queda de energia até o término da
operação crítica.
C.3.3 Executivo
O executivo do Windows fornece um conjunto de serviços que
todos os subsistemas ambientais podem usar. Os serviços estão
agrupados da seguinte forma: gerenciador de objetos, geren-
ciador de memória virtual, gerenciador de processos, recurso
de chamada de procedimento local, gerenciador de I/O, moni-
tor de referência de segurança e gerenciador de plug-and-play.
C.3.3.1 Gerenciador de Objetos
Como um sistema orientado a objetos, o Windows usa objetos
para todos os seus serviços e entidades. Exemplos de objetos
são os objetos diretório, objetos link simbólico, objetos semá-
foro, objetos evento, objetos processo e objetos thread, objetos
porta e objetos arquivo. A função do gerenciador de objetos é
supervisionar o uso de todos os objetos. Quando um thread
quer usar um objeto, ele chama o método open do geren-
ciador de objetos para obter um manipulador para o objeto.
Os manipuladores fornecem uma interface padronizada para
todos os tipos de objetos. Como um manipulador de arquivo, o
manipulador de objetos é um manipulador exclusivo para um
processo, conferindo a capacidade de acesso a um recurso do
sistema e sua manipulação.
Já que o gerenciador de objetos é a única entidade que pode
gerar um manipulador de objeto, este é o local adequado para a
verificação de segurança. Por exemplo, o gerenciador de obje-
tos verifica se um processo tem o direito de acessar um objeto
quando o processo tenta abrir este objeto. O gerenciador de
objetos também pode impor cotas, como o montante máximo
de memória que um processo pode alocar.
O gerenciador de objetos pode rastrear os processos que
estão usando cada objeto. Cada cabeçalho de objeto contém
uma contagem do número de processos que têm manipulado-
res para este objeto. Quando o contador chega a zero, o objeto é
excluído do espaço de nomes (se for um objeto temporário em
vez de permanente, como explicado a seguir). O próprio Win-
dows frequentemente usa ponteiros (em vez de manipuladores)
para acessar objetos, por isso o gerenciador de objetos tam-
bém mantém uma contagem de referências que ele incrementa
quando o Windows ganha acesso a um objeto e decrementa
quando o objeto não é mais necessário. Quando a contagem de
referências de um objeto temporário chega a zero, o objeto é
excluído da memória. Objetos permanentes representam enti-
Windows 2000  4 9
dades físicas, como drives de disco, e não são excluídos quando
a contagem de referências e o contador de manipuladores aber-
tos chegam a zero.
Os objetos são manipulados por um conjunto padrão de
métodos: create, open, close, delete, query name,
parse e security. Os três últimos objetos precisam de
explicação:
• query name é chamado quando um thread tem um mani-
pulador para um objeto mas deseja saber o nome do objeto;
• parse é usado pelo gerenciador de objetos na busca de um
objeto pelo seu nome;
• security é chamado quando um processo abre ou altera a
proteção de um objeto.
O executivo do Windows permite que um objeto receba um
nome. O espaço de nomes é global e, portanto, um processo
pode criar um objeto nomeado e um segundo processo pode
abrir, então, um manipulador para o objeto e compartilhá-lo
com o primeiro processo. Um processo que esteja abrindo um
objeto nomeado pode solicitar que a busca diferencie ou não
maiúsculas de minúsculas.
Um nome pode ser permanente ou temporário. Um nome
permanente representa uma entidade, como um drive de disco,
que permanece mesmo se nenhum processo a está acessando.
Um nome temporário só existe enquanto algum processo man-
tém um manipulador para o objeto.
Embora o espaço de nomes não seja diretamente visível
através de uma rede, o método parse do gerenciador de obje-
tos é usado para ajudar no acesso a um objeto nomeado de
outro sistema. Quando um processo tenta abrir um objeto que
resida em um computador remoto, o gerenciador de objetos
chama o método parse que chama, então, um redirecionador
de rede para encontrar o objeto.
Nomes de objetos são estruturados como nomes de cami-
nho de arquivos no MS-DOS e no UNIX. Os diretórios são
representados por um objeto diretório que contém os nomes
de todos os objetos no diretório. O espaço de nomes de objetos
pode aumentar pela inclusão de domínios de objetos que são
conjuntos de objetos autocontidos. Exemplos de domínios de
objetos são disquetes e drives de disco rígido. É fácil ver como
o espaço de nomes é estendido quando um disquete é adicio-
nado ao sistema: o disquete tem seu próprio espaço de nomes
que é enxertado no espaço de nomes existente.
Os sistemas de arquivos do UNIX têm links simbólicos
e, portanto, vários apelidos ou aliases podem referenciar o
mesmo arquivo. Da mesma forma, o Windows implementa um
objeto link simbólico. Uma das maneiras pelas quais o Win-
dows usa links simbólicos é no mapeamento de nomes de dri-
ves para as letras de drives padrão do MS-DOS. As letras de
drives são apenas links simbólicos que podem ser remapeados
para atender às preferências do usuário.
Um processo obtém um manipulador de objeto criando
um objeto, abrindo um objeto existente, recebendo um mani-
pulador duplicata de outro processo ou herdando um mani-
pulador de um processo pai, semelhante à maneira como
um processo do UNIX obtém um descritor de arquivo. Esses
manipuladores são todos armazenados na tabela de obje-
5 0   Apêndice C
tos do processo. Uma entrada da tabela de objetos contém os
direitos de acesso do objeto e define se o manipulador deve
ser herdado por processos filhos. Quando um processo é con-
cluído, o Windows fecha automaticamente todos os manipu-
ladores abertos para o processo.
Quando um usuário é autenticado pelo processo de login,
um objeto token de acesso é anexado ao processo do usuário.
O token de acesso contém informações como ID de segurança,
IDs de grupos, privilégios, grupo primário e lista de controle
de acesso default. Esses atributos determinam quais serviços e
objetos podem ser usados por um determinado usuário.
No Windows, cada objeto é protegido por uma lista de con-
trole de acesso que contém os IDs de segurança e os direitos de
acesso concedidos a cada processo. Quando um processo tenta
acessar um objeto, o sistema compara o ID de segurança no
token de acesso do processo com a lista de controle de acesso
do objeto, para determinar se o acesso deve ser permitido. Essa
verificação é realizada apenas quando um objeto é aberto e,
portanto, serviços internos do Windows que usam ponteiros e
não abrem um manipulador para o objeto ignoram a verifica-
ção de acesso.
Geralmente, o criador do objeto determina a lista de con-
trole de acesso para o objeto. Se nenhuma lista é fornecida
explicitamente, uma lista pode ser herdada do objeto criador
ou uma lista default pode ser obtida a partir do objeto token de
acesso do usuário.
Um campo do token de acesso controla a auditoria do
objeto. As operações auditadas são registradas no log de audi-
toria do sistema com uma identificação do usuário. O campo
de auditoria pode verificar esse log para descobrir tentativas de
invasão do sistema ou de acesso a objetos protegidos.
C.3.3.2 Gerenciador de Memória Virtual
A parte do executivo do Windows relacionada à memó-
ria virtual é o gerenciador de memória virtual (VM – vir-
tual memory). O projeto do gerenciador de VM presume que
o hardware subjacente suporta o mapeamento virtual-físico,
um mecanismo de paginação e uma coerência de cache trans-
parente em sistemas multiprocessadores e permita que várias
entradas da tabela de páginas sejam mapeadas para o mesmo
quadro de página. O gerenciador de VM do Windows usa um
esquema de gerenciamento com base em páginas, com um
tamanho de página de 4 KB. Páginas de dados que são atribuí-
das a um processo, mas não estão na memória física, são arma-
zenadas no arquivo de paginação em disco.
O gerenciador de VM usa endereços de 32 bits e, portanto,
cada processo tem um espaço de endereçamento virtual de 4
GB. Os 2 GB superiores são idênticos para todos os proces-
sos e são usados pelo Windows em modalidade de kernel. Os 2
GB inferiores são distintos para cada processo e são acessíveis
tanto por threads de modalidade de usuário quanto de kernel.
Certas configurações do Windows reservam apenas 1 GB para
uso do sistema operacional, permitindo que um processo use 3
GB como espaço de endereçamento.
O gerenciador de VM do Windows usa um processo de dois
passos para alocar memória. O primeiro passo reserva uma
parte do espaço de endereçamento do processo. O segundo
passo consigna a alocação atribuindo espaço no arquivo de
paginação do Windows. O Windows pode limitar o espaço
que um processo consome no arquivo de paginação impondo
uma cota à memória consignada. Um processo pode descon-
signar a memória que não está mais usando para liberar sua
cota de paginação. Porque a memória é representada por obje-
tos, quando um processo (o pai) cria um segundo processo
(o filho), ele pode manter a capacidade de acessar a memória
virtual do filho. É assim que os subsistemas ambientais con-
seguem gerenciar a memória de seus processos clientes. Por
razões de desempenho, o gerenciador de VM permite que um
processo privilegiado tranque páginas selecionadas na memó-
ria física, assegurando que as páginas não sejam removidas
para o arquivo de paginação.
Dois processos podem compartilhar memória obtendo
manipuladores para o mesmo objeto memória, mas esta abor-
dagem pode ser ineficiente, já que todo o espaço de memória
de um objeto deve ser consignado antes que um dos processos
possa acessar o objeto. O Windows fornece uma alternativa,
chamada objeto seção, para representar um bloco de memória
compartilhada. Após obter um manipulador para um objeto
seção, o processo pode mapear apenas a porção requerida da
memória. Esta porção da memória é denominada uma visão.
O mecanismo da visão também habilita um processo a aces-
sar um objeto que seja grande demais para caber na cota de
seu arquivo de paginação. O sistema pode usar a visão para
percorrer o espaço de endereçamento do objeto, uma parte
de cada vez.
Um processo pode controlar o uso de um objeto seção
de memória compartilhada de muitas maneiras. O tamanho
máximo de uma seção pode ser limitado. A seção pode usar
espaço em disco, como suporte, tanto no arquivo de paginação
do sistema como em um arquivo comum (um arquivo mapeado
para a memória). Uma seção pode ser baseada, significando
que a seção aparece no mesmo endereço virtual para todos os
processos que a acessam. Para concluir, a proteção de memória
das páginas da seção pode ser configurada como somente de
leitura, leitura-gravação, somente de execução, página de pro-
teção ou cópia após gravação. Essas duas últimas configurações
de proteção precisam ser melhor explicadas.
• Uma página de proteção lança uma exceção se for acessada;
a exceção pode ser usada, por exemplo, para detectar se um
programa defeituoso está iterando além do final de um array.
• O mecanismo de cópia após gravação permite que o geren-
ciador de VM economize memória. Quando dois processos
querem cópias independentes de um objeto, o gerenciador
de VM insere apenas uma cópia compartilhada na memória
física, mas ativa a propriedade de cópia após gravação para
esta região de memória. Se um dos processos tenta alterar
dados em uma página de cópia após gravação, o gerenciador
de VM faz primeiro uma cópia privada da página para uso do
processo.
A tradução de endereços virtuais no Windows usa várias
estruturas de dados. Cada processo tem um diretório de
páginas que contém 1.024 entradas de diretório de páginas

entrada 0
do diretório
de páginas
entrada 0 entrada
da tabela 1023 da
tabela de de páginas 0 tabela de
páginas páginas
página página
de 4K de 4K
Figura C.3 Formato da memória virtual.
Figura C.4 Tradução de endereço virtual físico.
com 4 bytes de tamanho. Normalmente, o diretório de pági-
nas é privado, mas pode ser compartilhado entre processos
se o ambiente assim demandar. Cada entrada de diretório de
páginas aponta para uma tabela de páginas que contém 1.024
entradas de tabela de páginas (PTEs – page-table entries)
com 4 bytes de tamanho. Cada PTE aponta para um quadro de
página de 4 KB na memória física. O tamanho total de todas
as tabelas de páginas de um processo é de 4 MB e, portanto, o
gerenciador de VM transferirá essas tabelas para disco quando
necessário. Consulte a Figura C.3 para ver um diagrama desta
estrutura.
Um inteiro de 10 bits pode representar todos os valores de
0 a 1.023. Logo, um inteiro de 10 bits pode selecionar qualquer
entrada no diretório de páginas ou em uma tabela de páginas.
Essa propriedade é usada quando um ponteiro de endereço vir-
tual é convertido em um endereço em bytes na memória física.
Um endereço de memória virtual de 32 bits é dividido em três
inteiros, como mostrado na Figura C.4. Os primeiros 10 bits
do endereço virtual são usados como um subscrito do diretó-
rio de páginas. Esse endereço seleciona uma entrada do dire-
tório de páginas que aponta para uma tabela de páginas. A
unidade de gerenciamento de memória (MMU) usa os próxi-
mos 10 bits do endereço virtual para selecionar uma PTE desta
tabela de páginas. A PTE aponta para um quadro de página na
memória física. Os 12 bits restantes do endereço virtual apon-
tam para um byte específico neste quadro de página. A MMU
cria um ponteiro para este byte específico na memória física
Windows 2000  5 1
entrada
diretório 1023 do
de páginas diretório
de páginas
entrada 0 entrada
da tabela de 1023 da
tabela de páginas 1023 tabela de
páginas páginas
página página
de 4K de 4K
deslocamento
de página
concatenando 20 bits da PTE com os 12 bits inferiores do ende-
reço virtual. Logo, a PTE de 32 bits tem 12 bits sobrando; esses
bits descrevem a página. A PTE do Pentium reserva 3 bits para
uso do sistema operacional. O resto dos bits especifica se a
página foi manipulada, foi acessada, é armazenável em cache, é
somente de leitura, é write through,* é de modalidade de Ker-
nel ou é válida; portanto, eles descrevem o estado da página
na memória. Para mais informações gerais sobre esquemas de
paginação, consulte a Seção 7.4.
Uma página pode estar em um de seis estados: válido, livre,
zerado, disponível, modificado ou inválido. Uma página válida
é a que está em uso por um processo ativo. Uma página livre é
uma página não referenciada em uma PTE. Uma página zerada
é uma página livre que foi zerada e está pronta para uso ime-
diato. Uma página disponível foi removida do conjunto de tra-
balho de um processo. Uma página modificada foi gravada,
mas ainda não foi descarregada em disco. As páginas disponí-
veis e modificadas são consideradas páginas em transição. Para
concluir, uma página inválida não pode ser utilizada porque
um erro de hardware foi detectado.
A estrutura real da PTE do arquivo de páginas é mostrada
na Figura C.5. A PTE contém 5 bits para a proteção da página,
20 bits para o deslocamento no arquivo de páginas, 4 bits para
a seleção do arquivo de paginação e 3 bits que descrevem o
estado da página. Essa PTE do arquivo de páginas aparece-
*Gravação feita sincronamente tanto no cache quanto na memória de
retaguarda. (N.R.T.)
5 2   Apêndice C
endereço de página
Figura C.5 Entrada do arquivo de páginas na tabela de páginas.
ria como uma página inválida para o hardware. Como códi-
gos executáveis e arquivos mapeados para a memória já têm
uma cópia em disco, não precisam de espaço em um arquivo de
paginação. Se uma dessas páginas não está na memória física, a
estrutura da PTE é a descrita a seguir: o bit mais significativo é
usado para especificar a proteção da página, os 28 bits seguintes
são usados para indexar uma estrutura de dados do sistema que
indica um arquivo e o deslocamento dentro do arquivo para a
página, e os 3 bits inferiores especificam o estado da página.
É difícil que processos compartilhem uma página se cada
processo tem seu próprio conjunto de tabelas de páginas porque
cada processo terá sua própria PTE para o quadro de página.
Quando uma página compartilhada não se encontra na memó-
ria física, o endereço físico terá de ser armazenado nas PTEs
de cada processo que a compartilhe. Todos os bits de proteção
e bits de estado da página dessas PTEs terão de ser configura-
dos e atualizados consistentemente. Para evitar tais problemas,
o Windows usa um endereçamento indireto. Para cada página
que é compartilhada, o processo tem uma PTE que aponta para
uma entrada protótipo na tabela de páginas, em vez de para
o quadro de página. A PTE protótipo contém o endereço do
quadro de página e os bits de proteção e de estado. Portanto, o
primeiro acesso de um processo a uma página compartilhada
gera um erro de página. Após o primeiro acesso, acessos adi-
cionais são executados normalmente. Se a página for marcada
como somente de leitura, o gerenciador de VM faz uma cópia
após gravação e o processo, efetivamente, não terá mais uma
página compartilhada. Páginas compartilhadas nunca apare-
cem no arquivo de páginas, mas são encontradas no sistema
de arquivos.
O gerenciador de VM rastreia todas as páginas de memória
física em um banco de dados de quadros de página. Há uma
entrada para cada quadro de página. A entrada aponta para a
PTE que aponta para o quadro de página e, assim, o gerencia-
dor de VM pode manter o estado da página. Os quadros de
página são encadeados para formar, por exemplo, a lista de
páginas zeradas e a lista de páginas livres.
Quando ocorre um erro de página, o gerenciador de VM
censura a página extraviada, colocando-a no primeiro quadro
da lista de livres. Mas ele não para por aí. Pesquisas mostram
que a referência de um thread à memória tende a ter uma pro-
priedade de localidade: quando uma página é usada, é provável
que páginas adjacentes sejam referenciadas em futuro próximo.
(Pense na iteração sobre um array ou na busca das instruções
sequenciais que formam o código executável de um thread.)
Devido à localidade, quando o gerenciador de VM censura
uma página, ele também censura algumas páginas adjacentes,
arquivo
proteção de
páginas
o que tende a reduzir a quantidade total de erros de páginas.
Para mais informações sobre localidade, consulte a Seção 8.6.1.
Se não houver quadros de página disponíveis na lista de
livres, o Windows usa uma política de substituição FIFO, por
processo, para tomar páginas de processos que estejam usando
mais do que seu tamanho de conjunto de trabalho mínimo.
O Windows monitora os erros de página de cada processo
que está em seu tamanho de conjunto de trabalho mínimo e
ajusta o tamanho do conjunto de trabalho de acordo. Especi-
ficamente, quando um processo é iniciado sob o Windows, ele
recebe um tamanho de conjunto de trabalho default de 30 pági-
nas. O Windows verifica periodicamente este tamanho rou-
bando uma página válida do processo. Se o processo continuar
a execução sem gerar um erro de página relacionado à página
roubada, seu conjunto de trabalho é reduzido de 1 e a página é
adicionada à lista de páginas livres.
C.3.3.3 Gerenciador de Processos
O gerenciador de processos do Windows fornece serviços para
criação, exclusão e uso de threads e processos. Ele não tem
conhecimento dos relacionamentos pai-filho ou das hierar-
quias de processos; tais refinamentos são deixados para o sub-
sistema ambiental específico que possui o processo.
Um exemplo de criação de processos no ambiente Win32 é
descrito a seguir. Quando uma aplicação Win32 chama Crea-
teProcess, uma mensagem é enviada ao subsistema Win32,
que chama o gerenciador de processos para criar um processo.
O gerenciador de processos chama o gerenciador de objetos
para criar um objeto processo e, então, retorna o manipulador
do objeto ao Win32. O Win32 chama o gerenciador de proces-
sos novamente para criar um thread para o processo e, para
concluir, o Win32 retorna manipuladores para o novo processo
e o novo thread.
C.3.3.4 Recurso de Chamada de Procedimento Local
O sistema operacional usa o recurso de chamada de procedi-
mento local (LPC) para passar solicitações e resultados entre
processos cliente e servidor, dentro de uma única máquina.
Especificamente, ele usa a LPC para solicitar serviços aos vários
subsistemas do Windows. A LPC é semelhante, em muitos
aspectos, aos mecanismos de RPC usados por muitos sistemas
operacionais para processamento distribuído entre redes, mas
é otimizada para uso dentro de um sistema Windows.
A LPC é um mecanismo de transmissão de mensagens. O
processo servidor publica um objeto porta de conexão global-

mente visível. Quando um cliente quer serviços de um subsis-
tema, ele abre um manipulador para o objeto porta de conexão
do subsistema e, então, envia uma solicitação de conexão para
esta porta. O servidor cria um canal e retorna um manipulador
ao cliente. O canal é composto por um par de portas de comuni-
cação privadas: uma para mensagens do cliente para o servidor e
a outra para mensagens do servidor para o cliente. Os canais de
comunicação dão suporte a um mecanismo de retorno de cha-
mada e, portanto, o cliente e o servidor podem aceitar solicita-
ções quando, normalmente, estariam esperando uma resposta.
Quando um canal LPC é criado, uma de três técnicas de
transmissão de mensagens deve ser especificada.
1. A primeira técnica é adequada a mensagens pequenas (até
256 bytes). Neste caso, a fila de mensagens da porta é usada
como memória intermediária e as mensagens são copiadas
de um processo para o outro.
2. A segunda técnica é para mensagens maiores. Neste caso,
um objeto seção de memória compartilhada é criado para
o canal. As mensagens enviadas pela fila de mensagens da
porta contêm um ponteiro e informações de tamanho refe-
rentes ao objeto seção. Isso evita a necessidade da cópia de
mensagens grandes: o emissor insere dados na seção com-
partilhada e o receptor pode visualizá-los diretamente.
3. A terceira técnica de transmissão de mensagens por LPC,
chamada LPC rápida, é usada por componentes de exibição
gráfica do subsistema Win32. Quando um cliente solicita
uma conexão que usará a LPC rápida, o servidor posiciona
três objetos: um thread servidor dedicado para manipular
solicitações, um objeto seção de 64 KB e um objeto par de
eventos. O objeto par de eventos é um objeto de sincroni-
zação usado pelo subsistema Win32 para fornecer notifica-
ção quando o thread cliente copia uma mensagem para o
servidor Win32 ou vice-versa. As mensagens LPC são pas-
sadas no objeto seção e a sincronização é executada pelo
objeto par de eventos. A LPC rápida tem diversas vantagens.
O objeto seção elimina a cópia de mensagens, pois repre-
senta uma região de memória compartilhada. O objeto par
de eventos elimina o overhead do uso do objeto porta para
passar mensagens contendo ponteiros e comprimentos. O
thread servidor dedicado elimina o overhead da determi-
nação de qual thread cliente está chamando o servidor, já
que existe um thread servidor por thread cliente. Por fim,
o kernel dá preferência no scheduling a esses threads servi-
dores dedicados, para melhorar o desempenho. A desvanta-
gem é que a LPC rápida usa mais recursos do que os outros
dois métodos e, portanto, ela é usada pelo subsistema Win32
somente para o gerenciador de janelas e interfaces de dispo-
sitivos gráficos.
C.3.3.5 Gerenciador de I/O
O gerenciador de I/O é responsável por sistemas de arquivos,
gerenciamento de caches, drivers de dispositivos e drivers de
rede. Ele controla os sistemas de arquivos instaláveis que estão
carregados e gerencia buffers para solicitações de I/O. Fun-
ciona com o gerenciador de VM para fornecer I/O de arquivo
mapeado para a memória e controla o gerenciador de caches
Windows 2000  5 3
do Windows que manipula o armazenamento em cache para
todo o sistema de I/O. O gerenciador de I/O suporta operações
síncronas e assíncronas, fornece tempos limite para drivers e
tem mecanismos para que um driver chame outro.
O gerenciador de I/O converte as solicitações que recebe
para uma forma padrão denominada pacote de solicitaçoes
de I/O (IRP – I/O request packet). Em seguida, ele encami-
nha o IRP ao driver correto para processamento. Quando
a operação é concluída, o gerenciador de I/O recebe o IRP
do driver que executou, mais recentemente, uma operação e
completa a solicitação.
Em muitos sistemas operacionais, o armazenamento em
cache é feito pelo sistema de arquivos. Mas o Windows usa um
recurso de armazenamento em cache centralizado. O geren-
ciador de caches fornece serviços de cache para todos os com-
ponentes sob controle do gerenciador de I/O e funciona em
conjunto com o gerenciador de VM. O tamanho do cache muda
dinamicamente, de acordo com o montante de memória livre
disponível no sistema. Lembre-se de que os 2 GB superiores
do espaço de endereçamento de um processo compõem a área
do sistema; ela é idêntica para todos os processos. O gerencia-
dor de VM aloca até metade desse espaço ao cache do sistema.
O gerenciador de caches mapeia arquivos para esse espaço de
endereçamento e usa os recursos do gerenciador de VM para
manipular o I/O de arquivos.
O cache é dividido em blocos de 256 KB. Cada bloco do
cache pode manter uma visão (isto é, uma região mapeada para
a memória) de um arquivo. Cada bloco do cache é descrito por
um bloco de controle de endereços virtuais (VACB – virtual-
address control block) que armazena o endereço virtual e o
deslocamento da visão no arquivo, assim como o número de
processos que a estão usando. Os VACBs residem em um único
array mantido pelo gerenciador de caches.
Para cada arquivo aberto, o gerenciador de caches mantém
um array separado de índices de VACBs. Esse array tem um
elemento para cada porção de 256 KB do arquivo; logo, um
arquivo de 2 MB, por exemplo, teria um array de índices de
VACBs com 8 entradas. Uma entrada do array de índices
de VACBs aponta para o VACB se esta porção do arquivo
está no cache; caso contrário, ela é null.
Quando o gerenciador de I/O recebe uma solicitação de
leitura de nível de usuário, ele envia um IRP ao gerenciador
de caches (a menos que a solicitação peça especificamente
uma leitura fora do cache). O gerenciador de caches calcula
a entrada no array de índices de VACBs do arquivo que cor-
responda ao deslocamento em bytes da solicitação. A entrada
aponta para a visão no cache ou é null. Se for null, o gerencia-
dor de caches aloca um bloco do cache (e a entrada correspon-
dente no array de VACBs) e mapeia a visão para este bloco do
cache. Em seguida, o gerenciador de caches tenta copiar dados
do arquivo mapeado para o buffer do chamador. Se a cópia
for bem-sucedida, a operação é concluída. Se a cópia falhar, é
devido a um erro de página, o que provoca o envio, pelo geren-
ciador de VM, de uma solicitação de leitura fora do cache para
o gerenciador de I/O. O gerenciador de I/O solicita ao driver
de dispositivo apropriado que leia os dados e os retorna ao
gerenciador de VM que os carrega no cache. Os dados, agora
5 4   Apêndice C
I/O armazenado
gerenciador em cache
de caches
cópia de dados
gerenciador erro de página
de VM
Figura C.6 I/O de arquivo.
no cache, são copiados no buffer do chamador e a solicitação
de I/O é concluída. A Figura C.6 apresenta uma visão geral de
todas essas operações. Quando possível, para operações de I/O
síncronas, armazenadas em cache e sem lock, o I/O é manipu-
lado pelo mecanismo de I/O rápido. Este mecanismo simples-
mente copia dados para páginas do cache ou a partir de páginas
do cache, diretamente, e usa o gerenciador de caches para exe-
cutar qualquer I/O necessário.
Uma operação de leitura no nível do kernel é semelhante,
exceto pelo fato de que os dados podem ser acessados direta-
mente no cache, em vez de serem copiados em um buffer no
espaço do usuário. Para usar metadados do sistema de arqui-
vos, ou estruturas de dados que descrevem o sistema de arqui-
vos, o kernel usa a interface de mapeamento do gerenciador de
caches para ler os metadados. Para modificar os metadados, o
sistema de arquivos usa a interface de fixação do gerenciador
de caches. A fixação de uma página a tranca em um quadro de
página da memória física para que o gerenciador de VM não
possa mover ou remover a página. Após atualizar os metada-
dos, o sistema de arquivos solicita ao gerenciador de caches que
libere a página. Como a página foi modificada, ela é marcada
como manipulada e, portanto, o gerenciador de VM descarre-
gará a página em disco. É bom ressaltar que os metadados são
realmente armazenados em um arquivo normal.
Para melhorar o desempenho, o gerenciador de caches
mantém um pequeno histórico de solicitações de leitura e tenta
prever solicitações futuras. Se o gerenciador de caches encon-
tra um padrão nas três solicitações anteriores, como um acesso
sequencial para diante ou para trás, ele pode buscar dados no
cache antes de a próxima solicitação ser submetida pela apli-
cação. Desta forma, a aplicação pode encontrar seus dados já
armazenados em cache e não tem de esperar por I/O de disco.
As funções OpenFile e CreateFile da API Win32 podem
receber o flag FILE_FLAG_SEQUENTIAL_SCAN, que é uma
dica para o gerenciador de caches tentar fazer a pré-busca de
192 KB antecipadamente às solicitações do thread. Normal-
mente, o Windows executa operações de I/O em porções de 64
KB ou 16 páginas; logo, tal leitura antecipada é três vezes maior
do que o montante normal.
processo
I/O
gerenciador de I/O
sistema de
arquivos
I/O não
armazenado
em cache
drive de disco
O gerenciador de caches também é responsável por solicitar
ao gerenciador de VM que descarregue o conteúdo do cache. O
comportamento default do gerenciador de caches é a gravação
retardada do cache: ele acumula gravações por 4 a 5 segundos
e, então, o thread gravador do cache é ativado. Quando a gra-
vação do cache é requerida, um processo pode posicionar um
flag ao abrir o arquivo ou pode chamar uma função explícita de
descarga do cache quando necessário.
Um processo de gravação rápida poderia, potencialmente,
preencher todas as páginas livres do cache antes que o thread
gravador do cache tivesse uma chance de despertar e descarre-
gar as páginas em disco. O gravador do cache impede que um
processo inunde o sistema agindo da seguinte forma: quando
o montante de memória livre no cache se torna baixo, o geren-
ciador de caches bloqueia, temporariamente, os processos que
tentam gravar dados e desperta o thread gravador do cache
para descarregar páginas em disco. Se o processo de gravação
rápida for, na verdade, um redirecionador de rede de um sis-
tema de arquivos de rede, seu bloqueio por muito tempo pode
fazer com que transferências da rede expirem e sejam retrans-
mitidas. Esta retransmissão desperdiçaria largura de banda da
rede. Para evitar tal desperdício, os redirecionadores de rede
podem solicitar ao gerenciador de caches que não deixe um
grande backlog de gravações acumularem no cache.
Já que um sistema de arquivos de rede tem de transferir
dados entre um disco e a interface de rede, o gerenciador de
caches também fornece uma interface DMA para transferir
os dados diretamente. A transferência direta de dados evita a
cópia de dados por meio de um buffer intermediário.
C.3.3.6 Monitor de Referência de Segurança
A natureza orientada a objetos do Windows habilita-o a usar um
mecanismo uniforme para executar validação de acesso e verifi-
cações de auditoria, em tempo de execução, para cada entidade
no sistema. Sempre que um processo abre um manipulador para
um objeto, o monitor de referência de segurança verifica o token
de segurança do processo e a lista de controle de acesso do objeto
para ver se o processo tem os direitos necessários.

C.3.3.7 Gerenciador de Plug-and-Play
O sistema operacional usa o gerenciador de plug-and-play
(PnP) para reconhecer e se adaptar a mudanças na configu-
ração de hardware. Para o PnP funcionar, tanto o dispositivo
quanto o driver devem dar suporte ao padrão PnP. O geren-
ciador de PnP reconhece automaticamente dispositivos insta-
lados e detecta alterações em dispositivos durante a operação
do sistema. O gerenciador também controla os recursos usa-
dos por um dispositivo, assim como recursos que poderiam
ser usados, e é responsável por carregar os drivers apropria-
dos. Este gerenciamento de recursos de hardware – principal-
mente interrupções e amplitudes da memória de I/O – tem o
objetivo de determinar uma configuração de hardware em que
todos os dispositivos possam operar. Por exemplo, se o dispo-
sitivo B pode usar apenas a interrupção 5 mas o dispositivo A
pode usar a 5 ou a 7, então, o gerenciador de PnP poderia atri-
buir a interrupção 5 ao dispositivo B e a 7 ao dispositivo A. Em
versões anteriores, o usuário teria de remover o dispositivo A e
reconfigurá-lo para usar a interrupção 7 antes de instalar o dis-
positivo B. Portanto, o usuário tinha de estudar os recursos do
sistema antes de instalar um novo hardware e tinha de determi-
nar quais recursos de hardware os dispositivos estavam usando.
A proliferação de dispositivos PCCARD e USB também exige
que a configuração dinâmica de recursos seja suportada.
C.4 Subsistemas Ambientais
Os subsistemas ambientais são processos de modalidade de
usuário dispostos acima dos serviços nativos do executivo
do Windows para habilitar o Windows a executar programas
desenvolvidos para outros sistemas operacionais, inclusive o
Windows de 16 bits, o MS-DOS e o POSIX, e aplicações baseadas
em caracteres para o OS/2 de 16 bits. Cada subsistema ambien-
tal fornece uma API ou um ambiente de aplicações.
O Windows usa o subsistema Win32 como o ambiente ope-
racional principal; portanto, esse subsistema inicia todos os pro-
cessos. Quando uma aplicação é executada, o subsistema Win32
chama o gerenciador de VM para carregar o código executável da
aplicação. O gerenciador de memória retorna um status ao Win32
informando que tipo de executável é o código. Se o código não é
um executável nativo do Win32, o ambiente Win32 verifica se o
subsistema ambiental apropriado está em execução; se o subsis-
tema não está em execução, ele é iniciado como um processo de
modalidade de usuário. O Win32 cria, então, um processo para
executar a aplicação e passa o controle ao subsistema ambiental.
O subsistema ambiental usa o recurso LPC do Windows
para obter serviços do kernel para o processo. Esta abordagem
ajuda o Windows a ser robusto porque a correção dos parâme-
tros, passados a uma chamada de sistema, pode ser verificada
antes que a rotina real do kernel seja invocada. O Windows
proíbe que as aplicações misturem rotinas de APIs de ambien-
tes diferentes. Por exemplo, uma aplicação Win32 não pode
chamar uma rotina POSIX.
Como cada subsistema é executado como um processo de
modalidade de usuário separado, a queda de um deles não afeta
os outros. A exceção é o Win32, que fornece todos os recursos
Windows 2000  5 5
O gerenciador de PnP manipula a reconfiguração dinâmica
como descrito a seguir. Primeiro, ele obtém uma lista de disposi-
tivos a partir de cada driver de bus (por exemplo, PCI, USB). Em
seguida, ele carrega o driver instalado (ou instala um, se neces-
sário) e envia um comando add-device ao driver apropriado
de cada dispositivo. O gerenciador de PnP descobre a atribuição
ótima de recursos e, então, envia um comando start-device
a cada driver, junto com a atribuição de recursos para este dispo-
sitivo. Se um dispositivo precisa ser reconfigurado, o gerenciador
de PnP envia um comando query-stop que pergunta ao dri-
ver se o dispositivo pode ser desabilitado temporariamente. Se o
driver puder desabilitar o dispositivo, todas as operações penden-
tes serão concluídas e novas operações serão impedidas de come-
çar. Em seguida, o gerenciador de PnP envia um comando stop;
ele pode, então, reconfigurar o dispositivo com outro comando
start-device.
O gerenciador de PnP também suporta outros comandos,
como query-remove. Este comando é usado quando o
usuário está se preparando para ejetar um dispositivo PCCARD
e opera de um modo semelhante a query-stop. O comando
surprise-remove é usado quando um dispositivo falha ou,
o que é mais provável, quando um usuário remove um dispositivo
PCCARD sem usar o utilitário PCCARD para interrompê-lo antes.
O comando remove solicita que o driver pare de usar o dispositivo
e libere todos os recursos que tenham sido alocados a ele.
de teclado, mouse e exibição gráfica. Se ele falhar, o sistema é
efetivamente desabilitado.
O ambiente Win32 categoriza as aplicações como gráficas ou
baseadas em caracteres. Uma aplicação baseada em caracteres é
aquela em que a saída interativa vai para uma tela ASCII de 80
por 24. O Win32 transforma a saída de uma aplicação baseada
em caracteres em uma representação gráfica em uma janela. Essa
transformação é fácil: sempre que uma rotina de saída é cha-
mada, o subsistema ambiental chama uma rotina Win32 para
exibir o texto. O ambiente Win32 executa esta função para todas
as janelas baseadas em caracteres, por isso ele pode transferir
texto de tela entre janelas por meio da área de transferência. Essa
transformação funciona tanto para aplicações MS-DOS quanto
para aplicações POSIX de linha de comando.
C.4.1 Ambiente MS-DOS
O ambiente MS-DOS não tem a complexidade dos outros sub-
sistemas ambientais do Windows. Ele é fornecido por uma
aplicação Win32 chamada máquina DOS virtual (VDM – vir-
tual DOS machine). Pelo fato de a VDM ser apenas um pro-
cesso de modalidade de usuário, ela é paginada e despachada
como qualquer outro thread do Windows. A VDM tem uma
unidade de execução de instruções para executar ou emular
instruções do Intel 486. A VDM também fornece rotinas para
emular a BIOS de ROM do MS-DOS e serviços de interrupção
de software “int 21” e tem drivers de dispositivos virtuais para
tela, teclado e portas de comunicação. A VDM tem como base
o código-fonte do MS-DOS 5.0; ela fornece à aplicação, pelo
menos, 620 KB de memória.
5 6   Apêndice C
O shell de comandos do Windows é um programa que cria
uma janela que se parece com um ambiente MS-DOS. Ele pode
operar tanto executáveis de 16 quanto de 32 bits. Quando uma
aplicação MS-DOS é executada, o shell de comandos inicia um
processo da VDM para executar o programa.
Se o Windows está em execução em um processador x86,
aplicações gráficas MS-DOS são executadas em modalidade de
tela inteira e aplicações de caracteres podem executar em tela
inteira ou em uma janela. Se o Windows está em execução em
uma arquitetura de processador diferente, todas as aplicações
MS-DOS são executadas em janelas. Algumas aplicações MS-
DOS acessam o hardware de disco diretamente, mas elas não
podem ser executadas no Windows porque o acesso a disco é
privilegiado para proteção do sistema de arquivos. Em geral,
aplicações MS-DOS que acessam o hardware diretamente, não
podem ser executadas sob o Windows.
Como o MS-DOS não é um ambiente multitarefa, foram
escritas algumas aplicações que se apropriam da CPU - por
exemplo, usando loops contínuos para causar atrasos ou pausas
na execução. O mecanismo de prioridades do despachante do
Windows detecta esses atrasos e estrangula automaticamente
o consumo da CPU (e faz com que a aplicação ofensiva opere
incorretamente).
C.4.2 O Ambiente do Windows de 16 Bits
O ambiente de execução Win16 é fornecido por uma VDM que
incorpora software adicional, chamado Windows on Windows,
para fornecer as rotinas e rotinas stub* do kernel do Windows
3.1 às funções do gerenciador de janelas e da interface de dis-
positivos gráficos (GDI - graphical-device-interface). As rotinas
stub chamam as sub-rotinas apropriadas do Win32 – conver-
tendo, ou traduzindo, endereços de 16 bits em endereços de 32
bits. Aplicações que se baseiam na estrutura interna do geren-
ciador de janelas de 16 bits ou na GDI, podem não funcionar
porque o Windows on Windows não implementa realmente a
API de 16 bits.
O Windows on Windows pode operar em multitarefa
com outros processos no Windows, mas ele se parece com
o Windows 3.1 em muitos aspectos. Apenas uma aplica-
ção Win16 pode ser executada de cada vez e todas as apli-
cações têm um único thread, residem no mesmo espaço
de endereçamento e compartilham a mesma fila de entra-
das. Essas características implicam que uma aplicação que
pare de receber entradas bloqueará todas as outras aplica-
ções Win16, como no Windows 3.x, e uma aplicação Win16
pode fazer cair outras aplicações Win16 corrompendo o
espaço de endereçamento. Vários ambientes Win16 podem
coexistir, no entanto, com o uso do comando start /separate
win16application na linha de comando.
C.4.3 Ambiente Win32
Como mencionado anteriormente, o principal subsistema do
Windows é o Win32. Ele executa aplicações Win32 e geren-
*Stubs são rotinas que não contêm código executável. Eles funcionam como
espaços reservados para funções que precisam ser totalmente implementadas.
(N.R.T.)
cia todo o I/O de teclado, mouse e tela. Como é o ambiente de
controle, foi projetado para ser extremamente robusto. Vários
recursos do Win32 contribuem para esta robustez. Diferente
dos processos no ambiente Win16, cada processo Win32 tem
sua própria fila de entradas. O gerenciador de janelas despacha
todas as entradas do sistema para a fila de entradas do processo
apropriado e, portanto, um processo defeituoso não bloqueia
as entradas de outros processos. O kernel do Windows tam-
bém fornece execução multitarefa preemptiva, o que habilita o
usuário a encerrar aplicações que tenham falhado ou não sejam
mais necessárias. Além disso, o Win32 valida todos os obje-
tos antes de usá-los para impedir falhas que, de outro modo,
poderiam ocorrer se uma aplicação tentasse usar um manipu-
lador inválido ou errado. O subsistema Win32 verifica o tipo
do objeto para o qual um manipulador aponta, antes de usar
o objeto. As contagens de referências mantidas pelo gerencia-
dor de objetos impedem que objetos sejam excluídos enquanto
ainda estão sendo usados e impedem seu uso após terem sido
excluídos.
C.4.4 Subsistema POSIX
O subsistema POSIX foi projetado para executar aplicações
POSIX que sigam o padrão POSIX.1 que é baseado no modelo
UNIX. As aplicações POSIX podem ser iniciadas pelo sub-
sistema Win32 ou por outra aplicação POSIX. As aplicações
POSIX usam o servidor PSXSS.EXE do subsistema POSIX,
a biblioteca POSIX de vínculo dinâmico PSXDLL.DLL e o
gerenciador POSIX de sessão de console POSIX.EXE.
Embora o padrão POSIX não especifique impressão, as
aplicações POSIX podem usar impressoras transparentemente
por meio do mecanismo de redirecionamento do Windows.
As aplicações POSIX têm acesso a qualquer sistema de arqui-
vos do sistema Windows; o ambiente POSIX impõe permissões
como as do UNIX em árvores de diretórios. Vários recursos do
Win32 não são suportados pelo subsistema POSIX, incluindo
arquivos mapeados para a memória, conexão de rede, gráficos
e troca dinâmica de dados.
C.4.5 Subsistema OS/2
Embora o Windows tenha sido projetado originalmente para
fornecer um ambiente operacional OS/2 robusto, o sucesso do
Microsoft Windows levou a uma mudança; durante o desen-
volvimento inicial do Windows, o ambiente Windows tornou-
se o default. Consequentemente, o Windows fornece apenas
recursos limitados no subsistema ambiental OS/2. Aplica-
ções baseadas em caracteres OS/2 1.x só podem ser executa-
das, no Windows, em computadores Intel x86. Aplicações OS/2
de modalidade real podem ser executadas em todas as plata-
formas usando o ambiente MS-DOS. Aplicações limitadas que
tenham código dual tanto para MS-DOS quanto para OS/2,
são executadas no ambiente OS/2, a menos que este ambiente
esteja desabilitado.
C.4.6 Subsistemas de Login e Segurança
Antes que um usuário possa acessar objetos no Windows, ele
deve ser autenticado pelo subsistema de login. Para ser auten-

ticado, um usuário deve ter uma conta e fornecer a senha para
esta conta.
O subsistema de segurança gera tokens de acesso para
representar usuários no sistema. Ele chama um pacote de
autenticação para fazer a autenticação usando informações
do subsistema de login ou do servidor de rede. Normalmente,
o pacote de autenticação simplesmente procura as informa-
ções da conta em um banco de dados local e verifica se a
C.5 Sistema de Arquivos
Historicamente, os sistemas MS-DOS têm usado o sistema
de arquivos tabela de alocação de arquivos (FAT). O sistema
de arquivos FAT de 16 bits tem várias deficiências, inclusive
fragmentação interna, uma limitação de tamanho de 2 GB e a
falta de proteção de acesso para arquivos. O sistema de arqui-
vos FAT de 32 bits resolveu os problemas de fragmentação e
tamanho, mas seu desempenho e recursos ainda são fracos em
comparação com sistemas de arquivos modernos. O sistema de
arquivos NTFS é muito melhor. Ele foi projetado para incluir
muitos recursos, como recuperação de dados, segurança, tole-
rância a falhas, arquivos e sistemas de arquivos grandes, fluxos
de dados múltiplos, nomes UNICODE e compressão de arqui-
vos. Por razões de compatibilidade, o Windows dá suporte aos
sistemas de arquivos FAT e HPFS do OS/2. No entanto, enfati-
zamos aqui o NTFS, o sistema de arquivos básico do Windows.
C.5.1 Formato Interno
A entidade básica do NTFS é o volume. Um volume é criado
pelo utilitário administrador de discos do Windows e é baseado
em uma partição lógica de disco. O volume pode ocupar uma
parte de um disco, um disco inteiro ou se estender por vários
discos.
O NTFS não lida com setores individuais de um disco; em
vez disso, ele usa o cluster como unidade de alocação de disco.
Um cluster é um grupo de setores de disco que compõe uma
potência de 2. O tamanho do cluster é configurado quando um
sistema de arquivos NTFS é formatado. O tamanho default do
cluster é o tamanho do setor para volumes até 512 MB, 1 KB
para volumes até 1 GB, 2 KB para volumes até 2 GB e 4 KB
para volumes maiores. Este tamanho de cluster é muito menor
do que o do sistema de arquivos FAT de 16 bits e o tamanho
pequeno reduz o nível de fragmentação interna. Como exem-
plo, considere um disco de 1.6 GB com 16.000 arquivos. Se você
usar um sistema de arquivos FAT de 16 bits, 400 MB podem ser
perdidos para a fragmentação interna porque o tamanho do
cluster é de 32 KB. Sob o NTFS, apenas 17 MB seriam perdidos
para armazenar os mesmos arquivos.
O NTFS usa números de cluster lógicos (LCNs – logical clus-
ter numbers) como endereços de disco. Ele os atribui numerando
clusters do início para o fim do disco. Usando este esquema,
o sistema pode calcular um deslocamento no disco físico (em
bytes) multiplicando o LCN pelo tamanho do cluster.
Um arquivo do NTFS não é um simples fluxo de bytes como
no MS-DOS ou no UNIX; em vez disso, ele é um objeto estru-
turado composto por atributos. Cada atributo de um arquivo é
um fluxo de bytes independente que pode ser criado, excluído,
Windows 2000  5 7
senha está correta. O subsistema de segurança gera, então, o
token de acesso para o ID do usuário, contendo os privilé-
gios, limites de cota e IDs de grupo apropriados. Sempre que
o usuário tenta acessar um objeto no sistema, como ao abrir
um manipulador para o objeto, o token de acesso é passado
ao monitor de referência de segurança que verifica privilégios
e cotas. O pacote de autenticação default, para domínios do
Windows, é o Kerberos.
lido e gravado. Alguns atributos são padrão para todos os arqui-
vos, inclusive o nome do arquivo (ou nomes, se o arquivo tem
aliases), a hora da criação e o descritor de segurança que especi-
fica o controle de acesso. Outros atributos são específicos de cer-
tos tipos de arquivos. Por exemplo, arquivos do Macinstosh têm
dois atributos de dados, a ramificação de recursos e a ramifica-
ção de dados. Um diretório tem atributos que implementam um
índice para os nomes de arquivos do diretório. Em geral, podem
ser adicionados atributos conforme necessário e eles são acessa-
dos com o uso de uma nomenclatura nome do arquivo:atributo.
A maioria dos arquivos de dados tradicionais tem um atributo
de dados não nomeado que contém todos os dados do arquivo. É
bom ressaltar que o NTFS só retorna o tamanho do atributo não
nomeado em resposta a operações de consulta de arquivo, como
na execução do comando dir. É claro que alguns atributos são
pequenos e outros são grandes.
Cada arquivo do NTFS é descrito por um ou mais regis-
tros de um array armazenado em um arquivo especial cha-
mado tabela de arquivos mestre (MFT - master file table).
O tamanho de um registro é determinado quando o sistema
de arquivos é criado; ele varia de 1 a 4 KB. Atributos peque-
nos são armazenados no próprio registro da MTF e são cha-
mados atributos residentes. Atributos grandes, como dados
volumosos não nomeados, são chamados atributos não resi-
dentes; eles são armazenados em uma ou mais extensões contí-
guas no disco e um ponteiro para cada extensão é armazenado
no registro da MFT. Para um arquivo minúsculo, até mesmo o
atributo de dados pode caber dentro do registro da MFT. Se um
arquivo tem muitos atributos – ou se é altamente fragmentado
de modo que muitos ponteiros sejam necessários para apon-
tar para todos os fragmentos – um registro da MFT pode não
ser suficientemente grande. Neste caso, o arquivo é descrito
por um registro chamado registro de arquivo base que contém
ponteiros para registros de estouro que armazenam os pontei-
ros e atributos adicionais.
Cada arquivo de um volume NTFS tem um ID exclusivo
chamado referência de arquivo. A referência de arquivo é uma
quantidade de 64 bits composto por um número de arquivo
de 48 bits e um número de sequência de 16 bits. O número de
arquivo é o número do registro (isto é, a posição no array) na
MFT que descreve o arquivo. O número de sequência é incre-
mentado sempre que uma entrada da MFT é reutilizada. Esse
incremento habilita o NTFS a executar verificações de consis-
tência interna, como a captura de uma referência antiga a um
arquivo excluído depois que a entrada da MFT foi reutilizada
para um novo arquivo.
5 8   Apêndice C
Como no MS-DOS e no UNIX, o espaço de nomes do
NTFS é organizado como uma hierarquia de diretórios. Cada
diretório usa uma estrutura de dados chamada árvore B+ para
armazenar um índice dos nomes de arquivo do diretório. Esse
esquema é usado porque elimina o custo da reorganização da
árvore e porque cada caminho, da raiz da árvore até uma folha,
tem o mesmo comprimento dos outros caminhos. A raiz de
índices de um diretório contém o nível de topo da árvore B+.
Em um diretório grande, este nível de topo contém ponteiros
para extensões de disco que armazenam o resto da árvore. Cada
entrada do diretório contém o nome e a referência de arquivo
do arquivo, assim como uma cópia do marcador de tempo de
atualizações e do tamanho do arquivo, extraídas dos atributos
residentes do arquivo na MFT. Cópias dessas informações são
armazenadas no diretório e, portanto, uma listagem de diretó-
rio pode ser gerada eficientemente - dado que todos os nomes
de arquivos, tamanhos e horas de atualizações estão disponí-
veis no próprio diretório, não há necessidade de coletar esses
atributos nas entradas da MFT para cada um dos arquivos.
Os metadados do volume NTFS são todos armazenados
em arquivos. O primeiro arquivo é a MFT. O segundo arquivo,
que é usado durante a recuperação se a MFT está danificada,
contém uma cópia das 16 primeiras entradas da MFT. Os pou-
cos arquivos seguintes também são especiais. Eles são chama-
dos arquivo de log, arquivo de volume, tabela de definição de
atributos, diretório raiz, arquivo de mapa de bits, arquivo de
inicialização e arquivo de clusters inválidos. O arquivo de log
(Seção C.5.2) registra todas as atualizações de metadados para
o sistema de arquivos. O arquivo de volume contém o nome
do volume, a versão do NTFS que formatou o volume e um bit
que informa se o volume pode ter sido corrompido e precisa
de verificação de consistência. A tabela de definição de atri-
butos indica que tipos de atributos são usados no volume e que
operações podem ser executadas em cada um deles. O diretó-
rio raiz é o diretório do nível de topo na hierarquia do sistema
de arquivos. O arquivo de mapa de bits indica os clusters de
um volume que são alocados a arquivos e os que estão livres.
O arquivo de inicialização contém o código de inicialização
do Windows e deve ficar localizado em um endereço de disco
específico para poder ser encontrado facilmente por um carre-
gador de bootstrap simples da ROM. O arquivo de inicializa-
ção também contém o endereço físico da MFT. Para concluir, o
arquivo de clusters inválidos registra quaisquer áreas inválidas
do volume; o NTFS usa este registro para recuperação de erros.
C.5.2 Recuperação
Em muitos sistemas de arquivos simples, a falta de energia na
hora errada pode danificar as estruturas de dados do sistema
de arquivos tão gravemente que o volume inteiro fica desorde-
nado. Muitas versões do UNIX armazenam metadados redun-
dantes no disco e se recuperam de quedas usando o programa
fsck para verificar todas as estruturas de dados do sistema
de arquivos e restaurá-las eficazmente a um estado consistente.
Restaurá-las envolve, então, a exclusão de arquivos danificados
e a liberação de clusters de dados que tenham sido gravados
com dados do usuário, mas não tenham sido apropriadamente
registrados nas estruturas de metadados do sistema de arqui-
vos. Essa verificação pode ser um processo lento e resultar na
perda de um número significativo de dados.
O NTFS usa uma abordagem diferente para a robustez do
sistema de arquivos. No NTFS, todas as atualizações em estru-
turas de dados do sistema de arquivos são executadas dentro
de transações. Antes de uma estrutura de dados ser alterada, a
transação grava um registro de log que contém informações de
reexecução e anulação de execução; depois que a estrutura de
dados foi alterada, a transação grava um registro de consigna-
ção no log para indicar que foi bem-sucedida. Após uma queda,
o sistema pode restaurar as estruturas de dados do sistema de
arquivos a um estado consistente processando os registros do
log, reexecutando primeiro as operações de transações con-
signadas e desfazendo, então, as operações de transações que
não foram consignadas com sucesso antes da queda. Periodica-
mente (usualmente a cada 5 segundos), um registro de ponto
de verificação é gravado no log. O sistema não precisa de regis-
tros de log antes do ponto de verificação para se recuperar de
uma queda. Eles podem ser descartados para que o arquivo de
log não cresça sem limites. Na primeira vez em que um volume
NTFS é acessado após a inicialização do sistema, o NTFS exe-
cuta automaticamente a recuperação do sistema de arquivos.
Esse esquema não garante que todos os conteúdos dos
arquivos de usuário estejam corretos após uma queda; ele asse-
gura apenas que as estruturas de dados do sistema de arquivos
(os arquivos de metadados) não estão danificadas e refletem
algum estado consistente que existia antes da queda. Seria pos-
sível estender o esquema de transações aos arquivos de usuá-
rios, mas o overhead prejudicaria o desempenho do sistema de
arquivos.
O log é armazenado no terceiro arquivo de metadados, no
começo do volume. Ele é criado com um tamanho máximo fixo
quando o sistema de arquivos é formatado. Tem duas seções: a
área de registros de log, que é uma fila circular de registros de
log, e a área de reinicialização, que mantém informações de
contexto na área de registros de log, como a posição em que o
NTFS deve iniciar a leitura durante uma recuperação. Na ver-
dade, a área de reinicialização mantém duas cópias de suas
informações e, portanto, a recuperação é possível mesmo que
uma cópia tenha sido danificada durante a queda.
A funcionalidade de registro em log é fornecida pelo ser-
viço de arquivo de log do Windows. Além de gravar os regis-
tros de log e executar ações de recuperação, o serviço de
arquivo de log controla o espaço livre no arquivo de log. Se o
espaço livre se torna muito pequeno, o serviço de arquivo de
log enfileira transações pendentes e o NTFS interrompe todas
as novas operações de I/O. Após as operações em curso serem
concluídas, o NTFS chama o gerenciador de caches para des-
carregar todos os dados e, então, reconfigura o arquivo de log e
executa as transações enfileiradas.
C.5.3 Segurança
A segurança de um volume NTFS é derivada do modelo de
objetos do Windows. Um atributo descritor de segurança é
armazenado no registro da MFT de cada objeto arquivo. Esse
 Windows 2000  5 9

disco 1 (2.5 GB) disco 2 (2.5 GB)

disco C: (FAT) 2 GB

drive lógico D: (NTFS) 3 GB

Figura C.7 Conjunto de volumes em dois drives.

atributo contém o token de acesso do proprietário do arquivo volta ao primeiro disco, alocando o segundo bloco de 64 KB.
e uma lista de controle de acesso que define os privilégios de Um conjunto de stripes forma um grande volume lógico, mas
acesso concedidos a cada usuário que tenha acesso ao arquivo. o formato físico pode melhorar a largura de banda de I/O por-
que, para um I/O volumoso, todos os discos podem transferir
C.5.4 Gerenciamento de Volumes e dados em paralelo. Para mais informações sobre RAID, con-
Tolerância a Falhas sulte a Seção 11.7.
O FtDisk é o driver de disco tolerante a falhas do Windows. Uma variação dessa ideia é o conjunto de stripes com pari-
Quando instalado, ele fornece diversas maneiras de combinar dade, mostrado na Figura C.9. Esse esquema também é cha-
drives de disco múltiplos em um volume lógico para melhorar mado RAID nível 5. Suponha que um conjunto de stripes tenha
o desempenho, a capacidade ou a confiabilidade. oito discos. Sete deles armazenarão stripes de dados, com um
Uma forma de combinar múltiplos discos é concatená- stripe de dados em cada disco, e o oitavo disco armazenará um
los logicamente para formar um grande volume lógico, como stripe de paridade para cada stripe de dados. O stripe de pari-
mostrado na Figura C.7. No Windows, este volume lógico, cha- dade contém o resultado do bitwise exclusive or* dos
mado um conjunto de volumes, pode ser composto por até stripes de dados. Se algum dos oito stripes for destruído, o sis-
32 partições físicas. Um conjunto de volumes contendo um
volume NTFS pode ser estendido sem afetar os dados já arma- disco 1 (2 GB) disco 2 (2 GB)
zenados no sistema de arquivos. Os metadados do mapa de bits
do volume NTFS são simplesmente estendidos para abranger
o novo espaço adicionado. O NTFS continua a usar o mesmo
mecanismo de LCN que ele usa para um único disco físico e o
driver FtDisk fornece o mapeamento de um deslocamento
no volume lógico para o deslocamento em um disco específico.
Outra maneira de combinar múltiplas partições físicas é
intercalar seus blocos à moda round-robin para formar o que
é chamado conjunto de stripes, como mostrado na Figura C.8.
Esse esquema também é chamado RAID nível 0 ou disk stri-
ping.* O FtDisk usa um tamanho de stripe de 64 KB. Os drive lógico C: 4 GB
primeiros 64 KB do volume lógico são armazenados na pri-
meira partição física, os segundos 64 KB são armazenados na
segunda partição física e assim por diante, até cada partição Figura C.8 Conjunto de stripes em dois drives.
ter contribuído com 64 KB de espaço. Em seguida, a alocação

*Disk striping é o processo de dividir um corpo de dados em blocos e espalhar *Um bitwise XOR toma dois padrões de bits de igual tamanho e executa a
esses blocos de dados por diversas partições em diversos discos. Cada stripe operação exclusive or lógico em cada par de bits corrrespondentes.
tem o tamanho da menor partição. (N.R.T.) (N.R.T.)
6 0   Apêndice C

disco 1 (2 GB) disco 2 (2 GB) disco 3 (2 GB)

paridade 0–15 LCNs 0–15 LCNs 16–31

LCNs 32–47 paridade 16–31 LCNs 48–63

LCNs 64–79 LCNs 80–95 paridade 32–47

paridade 48–63 LCNs 96–111 LCNs 112–127

drive lógico C: 4 GB

Figura C.9 Conjunto de stripes com paridade em três drives.

tema pode reconstruir os dados calculando o exclusive or
dos sete restantes. Esta capacidade de reconstruir dados torna
o array de discos muito menos propenso à perda de dados em
caso de falha no disco.
Observe que uma atualização em um stripe de dados tam-
bém requer o recálculo do stripe de paridade. Portanto, sete
gravações concorrentes em sete stripes de dados diferentes tam-
bém demandariam atualizações em sete stripes de paridade. Se
os stripes de paridade estivessem todos no mesmo disco, este
disco poderia ter sete vezes a carga de I/O dos discos de dados.
Para evitar a criação deste gargalo, espalhamos os stripes de
paridade por todos os discos, atribuindo-os segundo o estilo
round-robin. Para construir um conjunto de stripes com pari-
dade, precisamos de um mínimo de três partições de tamanho
igual, localizadas em três discos separados.
Um esquema ainda mais robusto é chamado espelhamento
de disco ou RAID nível 1; ele é mostrado na Figura C.10. Um
conjunto de espelhos é composto por duas partições de tama-
nho igual em dois discos. Quando uma aplicação grava dados
em um conjunto de espelhos, o FtDisk grava os dados nas
duas partições para que os conteúdos de dados das duas par-
tições sejam idênticos. Se uma partição falhar, o FtDisk tem
outra cópia seguramente armazenada no espelho. Os conjuntos
de espelhos também podem melhorar o desempenho porque
solicitações de leitura podem ser divididas entre os dois espe-
lhos, dando a cada espelho metade da carga de trabalho. Para
proteção contra a falha de um controlador de disco, podemos
anexar os dois discos de um conjunto de espelhos a dois con-
troladores de disco separados. Este esquema é chamado con-
junto duplex.
Para lidar com setores de disco danificados, o FtDisk usa
uma técnica de hardware chamada reserva de setores e o NTFS
usa uma técnica de software chamada remapeamento de clus-
ters. A reserva de setores é um recurso de hardware fornecido
por muitos drives de disco. Quando um drive de disco é forma-
tado, a reserva de setores cria um mapa dos números de blo-
cos lógicos relacionados a setores válidos no disco. Ela também
deixa setores adicionais não mapeados, como reservas. Se um

disco 1 (2 GB) disco 2 (2 GB)

drive C: 2 GB cópia do drive C: 2 GB

Figura C.10 Conjunto de espelhos em dois drives.


setor falhar, o FtDisk instruirá o drive de disco a substituí-lo
por um reserva. O remapeamento de clusters é uma técnica de
software executada pelo sistema de arquivos. Se um bloco de
disco fica danificado, o NTFS o substitui por um bloco dife-
rente não alocado alterando quaisquer ponteiros afetados na
MFT. O NTFS também garante que o bloco inválido nunca seja
alocado a qualquer arquivo.
Quando um bloco de disco é danificado, costuma ocorrer
perda de dados. Mas a reserva de setores ou o remapeamento
de clusters podem ser combinados com volumes tolerantes a
falhas, como os conjuntos de stripes, para mascarar a falha em
um bloco de disco. Se uma leitura falha, o sistema reconstrói
os dados perdidos lendo o espelho ou calculando a paridade
exclusive or em um conjunto de stripes com paridade.
Os dados reconstruídos são armazenados em uma nova loca-
ção obtida pela reserva de setores ou pelo remapeamento de
clusters.
C.5.5 Compressão
O NTFS pode executar a compressão de dados em arquivos
individuais ou em todos os arquivos de dados de um diretó-
rio. Para comprimir um arquivo, o NTFS divide os dados do
arquivo em unidades de compressão, que são blocos de 16
clusters contíguos. Quando cada unidade de compressão é gra-
vada, um algoritmo de compressão de dados é aplicado. Se o
resultado couber em menos de 16 clusters, a versão compri-
mida é armazenada. Em uma leitura, o NTFS pode determinar
se os dados foram comprimidos: se o foram, o tamanho da uni-
dade de compressão armazenada é inferior a 16 clusters. Para
melhorar o desempenho, ao ler unidades de compressão con-
tíguas, o NTFS executa pré-buscas e descompressões antes das
solicitações das aplicações.
Para arquivos dispersos ou arquivos que contenham zeros
em sua maioria, o NTFS usa outra técnica para economizar
espaço. Clusters contendo somente zeros não são realmente
C.6 Conexão de rede
O Windows suporta conexão de redes entre pares e cliente-ser-
vidor. Ele também tem recursos para gerenciamento de rede.
Os componentes de conexão de rede do Windows fornecem
transporte de dados, comunicação entre processos, comparti-
lhamento de arquivos por uma rede e o recurso de enviar jobs
de impressão a impressoras remotas.
Para descrever a conexão de rede no Windows, referimo-nos
a duas interfaces internas de conexão de rede: a especificação da
interface de dispositivos de rede (NDIS – network device inter-
face specification) e a interface do driver de transporte (TDI
– transport driver interface). A interface NDIS foi desenvol-
vida em 1989 pela Microsoft e a 3Com para separar os adap-
tadores de rede dos protocolos de transporte de modo que um
possa ser alterado sem afetar o outro. A NDIS reside na inter-
face entre as camadas de controle do link de dados e de controle
de acesso à mídia, no modelo OSI, e habilita muitos protoco-
los a operarem sobre muitos adaptadores de rede diferentes. Em
termos do modelo OSI, a TDI é a interface entre a camada de
transporte (camada 4) e a camada de sessão (camada 5). Essa
Windows 2000  6 1
alocados ou armazenados em disco. Em vez disso, lacunas são
deixadas na sequência de números de clusters virtuais armaze-
nados na entrada da MFT do arquivo. Ao ler um arquivo, se o
NTFS encontra uma lacuna nos números de clusters virtuais,
ele apenas preenche com zeros esta parte do buffer do chama-
dor. Esta técnica também é usada pelo UNIX.
C.5.6 Pontos de Reanálise
Os pontos de reanálise são um novo recurso do sistema de
arquivos. Efetivamente, eles retornam um código de erro
quando acessados. Os dados de reanálise informam, então, ao
gerenciador de I/O, o que fazer.
Os pontos de montagem são formas de pontos de reaná-
lise usados na organização de arquivos. Diferente dos siste-
mas UNIX, versões anteriores do Windows não forneciam
um modo de criar uma junção lógica de partições. Cada par-
tição recebia uma letra de drive diferente de todas as demais
partições. Isso significava, entre outras coisas, que se um
sistema de arquivos ficasse cheio, a estrutura de diretórios
tinha de ser alterada para adicionar mais espaço. Os pontos
de montagem permitem a criação de um novo volume em
outro drive, a transferência dos dados antigos para o novo
volume e, então, a montagem do novo volume no local origi-
nal. Os dados parecem estar no mesmo local de antes e, por-
tanto, ainda podem ser usados pelos programas instalados. O
ponto de montagem é implementado como um ponto de rea-
nálise com dados de reanálise contendo o nome verdadeiro
do volume.
O recurso de serviços de armazenamento remoto tam-
bém usa pontos de reanálise. Quando um arquivo é transferido
para armazenamento off-line, os dados do arquivo original são
substituídos por um ponto de reanálise que contém informa-
ções sobre onde este arquivo está. Quando o arquivo é acessado
posteriormente, ele é recuperado e o ponto de reanálise é subs-
tituído pelos dados do arquivo.
interface habilita qualquer componente da camada de sessão a
utilizar qualquer mecanismo de transporte disponível. (Racio-
cínio semelhante levou ao mecanismo de fluxos do UNIX.) A
TDI suporta tanto o transporte com base em conexão quanto o
transporte sem conexão e tem funções para enviar qualquer tipo
de dado.
C.6.1 Protocolos
O Windows implementa protocolos de transporte como dri-
vers. Esses drivers podem ser carregados e descarregados dina-
micamente a partir do sistema, embora na prática o sistema
normalmente tenha de ser reinicializado após uma alteração.
O Windows vem com vários protocolos de conexão de rede.
O protocolo bloco de mensagens de servidor (SMB –
server message-block) foi introduzido pela primeira vez no
MS-DOS 3.1. O sistema usa o protocolo para enviar solicita-
ções de I/O pela rede. O protocolo SMB tem quatro tipos de
mensagens. As mensagens Session control são coman-
dos que iniciam e terminam uma conexão do redirecionador
6 2   Apêndice C
para um recurso compartilhado no servidor. O redirecionador
usa mensagens File para acessar arquivos no servidor. O sis-
tema usa mensagens Printer para enviar dados a uma fila de
impressão remota e receber de volta informações de status; a
mensagem Message é usada na comunicação com outra esta-
ção de trabalho.
O sistema básico de entrada/saída de rede (NetBIOS –
network basic input/output system) é uma interface de abstra-
ção de hardware para redes, análoga à interface de abstração de
hardware BIOS projetada para PCs executando o MS-DOS. O
NetBIOS, desenvolvido no início dos anos 1980, tornou-se uma
interface padrão de programação de rede. O NetBIOS é usado
para estabelecer nomes lógicos na rede, estabelecer conexões
lógicas, ou sessões, entre dois nomes lógicos na rede e suportar
transferência de dados confiável para uma sessão, via solicita-
ções tanto do NetBIOS quanto do SMB.
A interface de usuário estendida do NetBIOS (NetBEUI
– NetBIOS extended user interface) foi introduzida pela IBM
em 1985 como um protocolo de conexão de rede simples e efi-
ciente para até 254 máquinas. É o protocolo default da conexão
de rede em pares do Windows 95 e do Windows for Work-
groups. O Windows usa o NetBEUI quando quer compartilhar
recursos com essas redes. Entre as limitações do NetBEUI estão
o fato de ele usar o nome real de um computador como ende-
reço e de não dar suporte a roteamento.
A suíte de protocolos TCP/IP, usada na Internet, tornou-se
a infraestrutura de conexão de rede padrão de fato; ela é ampla-
mente suportada. O Windows usa o TCP/IP para se conectar
com uma ampla variedade de sistemas operacionais e plata-
formas de hardware. O pacote TCP/IP do Windows inclui o
protocolo simples de gerenciamento de rede (SNMP - Sim-
ple Network-Management Protocol), o protocolo dinâmico de
configuração de hosts (DHCP - Dynamic Host-Configuration
Protocol), o serviço de nomes de Internet do Windows (WINS
- Windows Internet Name Service) e suporte ao NetBIOS.
O protocolo de transmissão ponto a ponto (PPTP –
Point-To-Point Tunneling Protocol) é fornecido pelo Win-
dows para a comunicação entre módulos de servidores de
acesso remoto executados em máquinas Windows Server e
outros sistemas clientes que estejam conectados pela Inter-
net. Os servidores de acesso remoto podem criptografar
dados enviados pela conexão e suportam redes virtuais pri-
vadas multiprotocolares na Internet.
Os protocolos NetWare da Novell (serviço de datagrama
IPX na camada de transporte SPX) são amplamente usados em
LANs de PCs. O protocolo NWLink do Windows conecta o
NetBIOS a redes NetWare. Combinado a um redirecionador
(como o Client Service for NetWare da Microsoft ou o NetWare
Client for Windows da Novell), esse protocolo habilita um
cliente Windows a se conectar a um servidor NetWare.
O Windows usa o protocolo de controle de link de dados
(DLC – data-link control) para acessar mainframes IBM e
impressoras HP conectados diretamente à rede. A não ser nes-
ses casos, esse protocolo não é usado por sistemas Windows.
O protocolo AppleTalk foi projetado como uma cone-
xão de baixo custo pela Apple para permitir que computa-
dores Macintosh compartilhem arquivos. Sistemas Windows
podem compartilhar arquivos e impressoras com computado-
res Macintosh, por meio do AppleTalk, desde que um servidor
Windows na rede esteja executando o pacote Windows Servi-
ces for Macintosh.
C.6.2 Mecanismos de Processamento
Distribuído
Embora o Windows não seja um sistema operacional distri-
buído, ele suporta aplicações distribuídas. Os mecanismos
que dão suporte ao processamento distribuído no Windows
incluem o NetBIOS, pipes nomeados e mailslots, sockets do
Windows, chamadas de procedimento remotas e a troca dinâ-
mica de dados na rede (NetDDE, - network dynamic data
exchange).
No Windows, as aplicações NetBIOS podem se comunicar
pela rede usando NetBEUI, NWLink ou TCP/IP.
Pipes nomeados são mecanismos de troca de mensagens
orientados a conexões. Eles foram desenvolvidos originalmente
como uma interface de alto nível para conexões NetBIOS por
uma rede. Um processo também pode usar pipes nomeados
para se comunicar com outros processos na mesma máquina.
Como os pipes nomeados são acessados por meio da interface
do sistema de arquivos, os mecanismos de segurança usados
para objetos arquivo também se aplicam a eles.
O nome de um pipe nomeado tem um formato chamado
convenção de nomeação uniforme (UNC – uniform naming
convention). Um nome UNC tem a aparência de um nome
de arquivo remoto típico. O formato de um nome UNC é \\
server_name\share-name\x\y\z, no qual server_
name identifica um servidor na rede; share_name identifica
qualquer recurso que esteja disponível aos usuários da rede,
tais como diretórios, arquivos, pipes nomeados e impressoras;
e a parte \x\y\z é um nome de caminho de arquivo normal.
Mailslots são mecanismos de troca de mensagens sem cone-
xão. Eles não são confiáveis porque uma mensagem enviada a
um mailslot pode ser perdida antes que o receptor pretendido
a receba. Mailslots são usados em aplicações de distribuição,
como na busca de componentes na rede; eles também são usa-
dos pelo serviço Windows Computer Browser.
O Winsock é a API de sockets do Windows. É uma inter-
face da camada de sessão amplamente compatível com sockets
UNIX, com algumas extensões Windows. Ele fornece uma
interface padronizada para muitos protocolos de transporte
que podem ter diferentes esquemas de endereçamento, de
modo que qualquer aplicação Winsock possa ser executada em
qualquer pilha de protocolos compatível com o Winsock.
Uma chamada de procedimento remota (RPC) é um meca-
nismo cliente-servidor que habilita uma aplicação em uma
máquina a fazer uma chamada de procedimento para código
em outra máquina. O cliente chama um procedimento local
– uma rotina stub – que empacota seus argumentos em uma
mensagem e os envia pela rede a um processo servidor espe-
cífico. A rotina stub do lado do cliente é então bloqueada.
Enquanto isso, o servidor desempacota a mensagem, chama
o procedimento, empacota os resultados de retorno em uma
mensagem e os envia de volta ao stub do cliente. O stub do

cliente é desbloqueado, recebe a mensagem, desempacota os
resultados da RPC e os retorna ao chamador. Esse empacota-
mento de argumentos também é denominado marshalling.
O mecanismo de RPC do Windows segue o amplamente
usado padrão de ambiente de computação distribuída para
mensagens RPC e, portanto, programas escritos para usar
RPCs do Windows são altamente portáveis. O padrão RPC
é detalhado. Ele oculta muitas das diferenças de arquitetura
entre computadores, como os tamanhos de números binários
e a ordem de bytes e bits em palavras do computador, especifi-
cando formatos de dados padrão para mensagens RPC.
O Windows pode enviar mensagens RPC usando o Net-
BIOS, o Winsock em redes TCP/IP ou pipes nomeados em
redes LAN Manager. O recurso LPC, discutido anteriormente,
é semelhante à RPC, exceto pelo fato de que, na LPC, as mensa-
gens são passadas entre dois processos em execução no mesmo
computador.
É tedioso e propenso a erros escrever o código que empa-
cota e transmite argumentos, desempacota e executa o procedi-
mento remoto, empacota e envia os resultados de retorno e os
desempacota e os retorna ao chamador. Felizmente, no entanto,
grande parte desse código pode ser gerada automaticamente a
partir de uma simples descrição dos argumentos e resultados
de retorno.
O Windows fornece a Linguagem de Definição de Inter-
faces da Microsoft para a descrição dos nomes de procedi-
mentos remotos, argumentos e resultados. O compilador
desta linguagem gera arquivos de cabeçalho que declaram os
stubs dos procedimentos remotos e os tipos de dados do argu-
mento e das mensagens de valores de retorno. Ele também gera
código-fonte para as rotinas de stub usadas no lado do cliente
e para um desempacotador e despachante no lado do servidor.
Quando a aplicação é vinculada, as rotinas de stub são incluídas.
Quando a aplicação executa o stub da RPC, o código gerado
manipula o resto.
O modelo de objetos componentes (COM – Component
Object Model) é um mecanismo para a comunicação entre pro-
cessos desenvolvido para o Windows. Os objetos COM forne-
cem uma interface bem definida para a manipulação dos dados
do objeto. O Windows tem uma extensão chamada DCOM que
pode ser usada por uma rede, utilizando o mecanismo de RPC
para fornecer um método transparente de desenvolvimento de
aplicações distribuídas.
C.6.3 Redirecionadores e Servidores
No Windows, uma aplicação pode usar a API de I/O do sis-
tema para acessar arquivos em um computador remoto como
se eles fossem locais, contanto que o computador remoto
esteja executando um servidor MS-NET, como o fornecido
pelo Windows ou pelo Windows for Workgroups. Um redi-
recionador é o objeto do lado do cliente que encaminha soli-
citações de I/O a arquivos remotos, onde elas são atendidas
por um servidor. Por questões de desempenho e segurança,
os redirecionadores e servidores são executados em modali-
dade de kernel.
Especificamente, o acesso a um arquivo remoto ocorre
como descrito a seguir.
Windows 2000  6 3
• A aplicação chama o gerenciador de I/O para solicitar que
um arquivo seja aberto com um nome de arquivo no formato
UNC padrão.
• O gerenciador de I/O constrói um pacote de solicitação de
I/O, como descrito na Seção C.3.3.5.
• O gerenciador de I/O reconhece que o acesso é para um
arquivo remoto e chama um driver conhecido como prove-
dor múltiplo de convenção universal de nomeação (MUP –
multiple universal-naming-convention provider).
• O MUP envia o pacote de solicitação de I/O assincronamente
a todos os redirecionadores registrados.
• Um redirecionador que possa atender à solicitação responde
ao MUP. Para não fazer a mesma pergunta a todos os redire-
cionadores no futuro, o MUP usa um cache para lembrar do
redirecionador que pode manipular este arquivo.
• O redirecionador envia a solicitação de rede para o sistema
remoto.
• Os drivers de rede do sistema remoto recebem a solicitação e
a passam ao driver do servidor.
• O driver do servidor envia a solicitação ao driver apropriado
do sistema de arquivos local.
• O driver de dispositivo apropriado é chamado para acessar
os dados.
• Os resultados são retornados ao driver do servidor que envia
os dados de volta ao redirecionador solicitante. O redirecio-
nador retorna, então, os dados à aplicação chamadora por
meio do gerenciador de I/O.
Um processo semelhante ocorre para aplicações que usam a
API de rede Win32 em vez dos serviços UNC, exceto pelo fato
de que é usado um módulo chamado roteador multiprovedor,
em vez de um MUP.
Por razões de portabilidade, os redirecionadores e servi-
dores usam a API TDI no transporte de rede. As próprias soli-
citações são expressas em um protocolo de nível mais alto que,
por default, é o protocolo SMB mencionado na Seção C.6.1.
A lista de redirecionadores é mantida no banco de dados do
registro do sistema.
C.6.4 Domínios
Muitos ambientes de rede têm grupos naturais de usuários,
como alunos de um laboratório de computação na escola ou
empregados de um departamento em uma empresa. Com fre-
quência, é desejável que todos os membros do grupo possam
acessar recursos compartilhados nos diversos computadores
do grupo. Para gerenciar os direitos de acesso globais desses
grupos, o Windows usa o conceito de domínio. Anteriormente,
esses domínios não tinham qualquer relação com o sistema de
nome de domínio (DNS) que mapeia nomes de hosts na Inter-
net para endereços IP; agora, no entanto, eles estão intima-
mente relacionados.
Especificamente, um domínio no Windows é um grupo
de estações de trabalho e servidores Windows que comparti-
lham uma política de segurança comum e um banco de dados
de usuários. Já que agora o Windows usa o protocolo Kerbe-
6 4   Apêndice C
ros para crédito e autenticação, um domínio no Windows é
a mesma coisa que uma região no Kerberos. Versões anterio-
res do NT usavam a ideia de controladores de domínio pri-
mário e de backup; agora, todos os servidores de um domínio
são controladores de domínio. Além disso, versões anteriores
demandavam a configuração de créditos unidirecionais entre
domínios. O Windows usa uma abordagem hierárquica com
base no DNS e permite créditos transitivos que possam fluir
para cima e para baixo na hierarquia. Esta abordagem reduz o
número de créditos requeridos para n domínios, de n*(n – 1)
para O(n). As estações de trabalho do domínio confiam que
o controlador de domínio forneça informações corretas sobre
os direitos de acesso de cada usuário (via o token de acesso do
usuário). Todos os usuários podem restringir o acesso a suas
próprias estações de trabalho, independente do que qualquer
controlador de domínio tenha a dizer.
Já que uma empresa pode ter muitos departamentos e uma
escola pode ter muitas turmas, faz-se necessário, com frequên-
cia, gerenciar vários domínios dentro da mesma organização.
Uma árvore de domínios é uma hierarquia de nomeação DNS
contígua para o gerenciamento de vários domínios. Por exem-
plo, bell-labs.com pode ser a raiz da árvore, com research.bell-
labs.com e pez.bell-labs.com como filhos – domínios research
e pez. Uma floresta é um conjunto de nomes não contíguos.
Um exemplo seriam as árvores bell-labs.com e/ou lucent.com.
Porém, uma floresta pode ser composta por apenas uma árvore
de domínios.
Os créditos de confiança podem ser estabelecidos, entre
domínios, de três formas: unidirecional, transitiva e de vínculo
cruzado. Versões do NT até a versão 4.0 só permitiam o estabe-
lecimento de créditos de confiança unidirecionais. Um crédito
unidirecional é exatamente o que seu nome sugere: o domínio
A é informado de que pode confiar no domínio B. No entanto,
B não confiará em A a menos que outro relacionamento seja
configurado. Sob um crédito transitivo, se A confia em B e B
confia em C, então, A, B e C confiam uns nos outros, porque
créditos transitivos são bidirecionais por default. Créditos tran-
sitivos são habilitados, por default, para novos domínios em
uma árvore e só podem ser configuradas entre domínios de
uma floresta. O terceiro tipo, um crédito de vínculo cruzado,
é útil para reduzir o tráfego de autenticação. Suponha que os
C.7 Interface do Programador
A API Win32 é a interface básica para os recursos do Windows.
Esta seção descreve cinco aspectos principais da API Win32:
o acesso a objetos do kernel, o compartilhamento de objetos
entre processos, o gerenciamento de processos, a comunicação
entre processos e o gerenciamento da memória.
C.7.1 Acesso a Objetos do Kernel e Seu
Compartilhamento
O kernel do Windows fornece muitos serviços que os progra-
mas aplicativos podem usar. Os programas aplicativos obtêm
esses serviços manipulando objetos do kernel. Um processo
ganha acesso a um objeto do kernel de nome XXX chamando
domínios A e B sejam nós folhas e que os usuários de A usem,
com frequência, recursos de B. Se um crédito transitivo padrão
for usado, as solicitações de autenticação têm de seguir para
cima até o ancestral comum dos dois nós folhas; mas, se A e B
têm estabelecido um crédito de vínculo cruzado, as autentica-
ções podem ser enviadas diretamente ao outro nó.
C.6.5 Resolução de Nomes em Redes
TCP/IP
Em uma rede IP, a resolução de nomes é o processo de con-
versão de um nome de computador em um endereço IP, como
na resolução de www.bell-labs.com para 135.104.1.14. O Win-
dows fornece vários métodos de resolução de nomes, incluindo
o Windows Internet Name Service (WINS), a resolução distri-
buída de nomes, o sistema de nomes de domínio (DNS), um
arquivo de hosts e um arquivo LMHOSTS. A maioria desses
métodos é usada por muitos sistemas operacionais e, portanto,
descrevemos aqui apenas o WINS.
Sob o WINS, dois ou mais servidores WINS mantêm um
banco de dados dinâmico de vinculações nome-para-endereço IP,
junto com software cliente de consulta aos servidores. Pelo menos
dois servidores são usados, para que o serviço WINS possa sobre-
viver à falha em um servidor e para que a carga de trabalho de
resolução de nomes possa ser distribuída por várias máquinas.
O WINS usa o protocolo dinâmico de configuração de hosts
(DHCP). O DHCP atualiza configurações de endereço auto-
maticamente no banco de dados WINS, sem intervenção do
usuário ou do administrador, como descrito a seguir. Quando
um cliente DHCP é inicializado, ele transmite uma mensagem
discover. Cada servidor DHCP que recebe a mensagem res-
ponde com uma mensagem offer contendo um endereço IP
e informações de configuração para o cliente. O cliente sele-
ciona, então, uma das configurações e envia uma mensagem
request ao servidor DHCP selecionado. O servidor DHCP
responde, com o endereço IP, as informações de configuração
anteriormente fornecidas e uma concessão para este endereço.
A concessão dá ao cliente o direito de usar o endereço IP por
um período de tempo especificado. Quando o tempo de con-
cessão está a meio caminho de expirar, o cliente tenta renovar a
concessão para este endereço. Se a concessão não for renovada,
o cliente terá de obter uma nova.
a função CreateXXX para abrir um manipulador para XXX.
Esse manipulador é exclusivo para este processo. Dependendo
do objeto que está sendo aberto, se a função create falhar, ela
pode retornar 0 ou uma constante especial chamada INVA-
LID_HANDLE_VALUE. Um processo pode fechar qualquer
manipulador chamando a função CloseHandle e o sistema
pode excluir o objeto se a contagem de processos usuários do
objeto chegar a 0.
O Windows fornece três formas de compartilhar objetos
entre processos. A primeira forma é a herança, por um processo
filho, de um manipulador para o objeto. Quando o pai chama
a função CreateXXX, ele fornece uma estrutura SECURI-
TIES_ATTRIBUTES com o campo bInheritHandle
 Windows 2000  6 5

Figura C.11 Código para que um filho compartilhe um objeto herdado sem manipulador.

posicionado como TRUE. Este campo cria um manipulador
passível de ser herdado. Em seguida, o processo filho pode ser
criado, passando um valor TRUE para o argumento bInhe-
ritHandle da função CreateProcess. A Figura C.11
mostra um exemplo de código que cria um manipulador para
semáforo herdado por um processo filho.
Supondo que o processo filho saiba quais manipulado-
res estão sendo compartilhados, o pai e o filho podem obter a
comunicação entre processos por meio dos objetos comparti-
lhados. No exemplo da Figura C.11, o processo filho obteria o
valor do manipulador a partir do primeiro argumento da linha
de comando e poderia, então, compartilhar o semáforo com o
processo pai.
A segunda forma de compartilhar objetos é o fornecimento,
por um processo, de um nome ao objeto, quando este é criado,
e a abertura deste nome pelo segundo processo. Este método
apresenta duas desvantagens. Em primeiro lugar, o Windows
não fornece um modo de verificar se um objeto com o nome
selecionado já existe. Em segundo lugar, o espaço de nomes de
objetos é global, sem levar em consideração o tipo do objeto.

Processo A

Processo B

Figura C.12 Código para compartilhamento de um objeto na busca de nome.

Processo A quer dar ao processo B acesso a um semáforo

Processo A

envia o valor do semáforo ao Processo B

usando uma mensagem ou um objeto memória compartilhado

Processo B

usa b_semaphore para acessar o semáforo

Figura C.13 Código para compartilhamento de um objeto passando um manipulador.

6 6   Apêndice C
Por exemplo, duas aplicações podem criar um objeto chamado
pipe quando dois objetos distintos – e possivelmente diferentes
– são desejados.
Os objetos nomeados apresentam a vantagem de que
processos não relacionados podem compartilhá-los ime-
diatamente. O primeiro processo chama uma das funções
CreateXXX e fornece um nome no parâmetro lpszName.
O segundo processo pode obter um manipulador para compar-
tilhar este objeto chamando OpenXXX (ou CreateXXX) com
o mesmo nome, como mostrado no exemplo da Figura C.12.
A terceira forma de compartilhar objetos é por meio da
função DuplicateHandle. Este método requer algum
outro método de comunicação entre processos para passar o
manipulador duplicado. Dados um manipulador para um pro-
cesso e o valor de um manipulador dentro deste processo, um
segundo processo pode obter um manipulador para o mesmo
objeto e, assim, compartilhá-lo. Um exemplo desse método é
mostrado na Figura C.13.
C.7.2 Gerenciamento de Processos
No Windows, um processo é uma instância de uma aplicação
em execução e um thread é uma unidade de código passível de
ser incluída no schedule pelo sistema operacional. Logo, um
processo contém um ou mais threads. O processo é iniciado
quando algum outro processo chama a rotina CreatePro-
cess. Essa rotina carrega as bibliotecas de vínculo dinâmico
usadas pelo processo e cria um thread primário. Threads adi-
cionais podem ser criados pela função CreateThread. Cada
thread é criado com sua própria pilha que, por default, tem
1 MB, a menos que seja especificado diferentemente em um
argumento de CreateThread. Como algumas funções C
de tempo de execução mantêm o estado em variáveis estáticas,
como errno, uma aplicação multithreads precisa se proteger
do acesso não sincronizado. A função encapsuladora begin-
threadex fornece sincronização apropriada.
Cada biblioteca de vínculo dinâmico ou arquivo executá-
vel, carregado no espaço de endereçamento de um processo,
é identificado por meio de um manipulador de instância. O
valor do manipulador de instância é, na verdade, o endereço
virtual onde o arquivo é carregado. Uma aplicação pode obter
o manipulador para um módulo em seu espaço de endereça-
mento, passando o nome do módulo para GetModuleHan-
dle. Se o nome passado é NULL, o endereço base do processo
é retornado. Os 64 KB inferiores do espaço de endereçamento
não são usados e, portanto, um programa defeituoso que tente
eliminar a referencia de um ponteiro NULL gerará uma viola-
ção de acesso.
As prioridades no ambiente Win32 são baseadas no modelo
de scheduling do Windows, mas nem todos os valores de prio-
ridade podem ser selecionados. O Win32 usa quatro classes de
prioridades:
• IDLE_PRIORITY_CLASS (prioridade nível 4)
• NORMAL_PRIORITY_CLASS (prioridade nível 8)
• HIGH_PRIORITY_CLASS (prioridade nível 13)
• REALTIME_PRIORITY_CLASS (prioridade nível 24)
Os processos são, tipicamente, membros da NORMAL_
PRIORITY_CLASS, a menos que o pai do processo seja da
IDLE_PRIORITY_CLASS ou que outra classe tenha sido
especificada quando CreateProcess foi chamada. A classe
de prioridade de um processo pode ser alterada com a função
SetPriorityClass ou com a passagem de um argumento
para o comando START. Por exemplo, o comando START /
REALTIME cbserver.exe executaria o programa cbser-
ver na REALTIME_PRIORITY_CLASS. Apenas usuá-
rios com o privilégio de aumento de prioridade de scheduling
podem passar um processo para a REALTIME_PRIORITY_
CLASS. Administradores e usuários avançados têm este privi-
légio por default.
Quando um usuário está executando um programa intera-
tivo, o sistema precisa fornecer um desempenho especialmente
bom para este processo. Portanto, o Windows tem uma regra de
scheduling especial para processos da NORMAL_PRIORITY_
CLASS. O Windows distingue o processo de foreground que
está correntemente selecionado na tela dos processos de back-
ground que não estão correntemente selecionados. Quando
um processo passa para foreground, o Windows aumenta o
quantum do scheduling de algum fator – normalmente, 3. (Este
fator pode ser alterado por meio da opção de desempenho na
seção do sistema no painel de controle.) Esse aumento dá ao
processo de foreground três vezes mais tempo para ser execu-
tado antes que uma preempção de compartilhamento de tempo
ocorra.
Um thread começa com uma prioridade inicial determi-
nada por sua classe, mas a prioridade pode ser alterada pela
função SetThreadPriority. Esta função usa um argu-
mento que especifica uma prioridade relativa à prioridade base
de sua classe:
• THREAD_PRIORITY_LOWEST: base − 2
• THREAD_PRIORITY_BELOW_NORMAL: base − 1
• THREAD_PRIORITY_NORMAL: base + 0
• THREAD_PRIORITY_ABOVE_NORMAL: base + 1
• THREAD_PRIORITY_HIGHEST: base + 2
Duas outras designações também são usadas no ajuste da
prioridade. Lembre-se, da Seção C.3.2, de que o kernel tem
duas classes de prioridades: 16−31 para a classe de tempo
real e 0−15 para a classe de prioridade variável. THREAD_
PRIORITY_IDLE estabelece a prioridade 16 para thre-
ads de tempo real e 1 para threads de prioridade variável.
THREAD_PRIORITY_TIME_CRITICAL estabelece a
prioridade 31 para threads de tempo real e 15 para threads
de prioridade variável.
Como discutimos na Seção C.3.2, o kernel ajusta a priori-
dade de um thread dinamicamente, dependendo de o thread
ser limitado por I/O ou limitado por CPU. A API Win32 for-
nece um método para desabilitar esse ajuste por meio das
funções SetProcessPriorityBoost e SetThread-
PriorityBoost.
Um thread pode ser criado em estado suspenso, o que sig-
nifica que ele não será executado até que outro thread o torne
elegível por meio da função ResumeThread. A função

SuspendThread faz o oposto. Essas funções posicionam
um contador de modo que se um thread for suspenso duas
vezes, ele tenha de ser retomado duas vezes antes que possa ser
executado.
Para sincronizar o acesso concorrente a objetos compar-
tilhados por threads, o kernel fornece objetos de sincroniza-
ção, como semáforos e mutexes. Além disso, a sincronização
de threads pode ser obtida com o uso das funções WaitFor-
SingleObject e WaitForMultipleObjects. Outro
método de sincronização da API Win32 é a seção crítica. Uma
seção crítica é uma região de código sincronizada que só pode
ser executada por um thread de cada vez. Um thread estabelece
uma seção crítica chamando InitializeCriticalSec-
tion. A aplicação deve chamar EnterCriticalSection
antes de entrar na seção crítica e LeaveCriticalSec-
tion após sair da seção crítica. Essas duas rotinas garantem
que, se vários threads tentam entrar na seção crítica concorren-
temente, apenas um thread de cada vez tenha permissão para
prosseguir; os outros esperarão na rotina EnterCritical-
Section. O mecanismo da seção crítica é um pouco mais
rápido do que os objetos de sincronização do kernel.
Uma fibra é um código de modalidade de usuário que é
incluído no schedule de acordo com um algoritmo de schedu-
ling definido pelo usuário. Um processo pode ter várias fibras,
assim como pode ter vários threads. Uma diferença importante
entre threads e fibras é que enquanto os threads podem execu-
tar concorrentemente, apenas uma fibra de cada vez tem per-
missão para executar, mesmo em hardware multiprocessador.
Esse mecanismo foi incluído no Windows para facilitar a por-
tabilidade das aplicações legadas do UNIX escritas para um
modelo de execução de fibras.
O sistema cria uma fibra chamando ConvertThrea-
dToFiber ou CreateFiber. A principal diferença entre
essas funções é que CreateFiber não inicia a execução da
fibra que foi criada. Para iniciar a execução, a aplicação deve
chamar SwitchToFiber. A aplicação pode encerrar uma
fibra chamando DeleteFiber.
C.7.3 Comunicação entre Processos
Uma forma pela qual as aplicações Win32 podem executar a
comunicação entre processos é compartilhando objetos do kernel.
Outra forma é transmitindo mensagens, uma abordagem que é
particularmente popular em aplicações de GUI do Windows.
aloca 16 MB no topo de nosso espaço de endereçamento
consigna os 8 MB superiores do espaço alocado
faz algo com a memória
agora, desconsigna a memória
libera todo o espaço de endereçamento alocado
Figura C.14 Fragmentos de código para alocação de memória virtual.
Windows 2000  6 7
Um thread pode enviar uma mensagem a outro thread
ou a uma janela chamando PostMessage, PostThread-
Message, SendMessage, SendThreadMessage ou
SendMessageCallback. A diferença entre postar uma
mensagem e enviar uma mensagem é que as rotinas de posta-
gem são assíncronas: elas retornam imediatamente e o thread
chamador não sabe quando a mensagem é realmente liberada.
As rotinas de envio são síncronas: elas bloqueiam o chamador
até que a mensagem tenha sido liberada e processada.
Além de enviar uma mensagem, um thread pode enviar
dados com a mensagem. Os dados devem ser copiados porque
os processos têm espaços de endereçamento separados. O sis-
tema copia os dados chamando SendMessage para enviar
uma mensagem do tipo WM_COPYDATA com uma estrutura
de dados COPYDATASTRUCT contendo o tamanho e o ende-
reço dos dados a serem transferidos. Quando a mensagem
é enviada, o Windows copia os dados em um novo bloco de
memória e fornece o endereço virtual do novo bloco ao pro-
cesso receptor.
Diferente dos threads no ambiente Windows de 16 bits,
cada thread Win32 tem sua própria fila de entradas a partir da
qual ele recebe mensagens. (Todas as entradas são recebidas
por meio de mensagens.) Essa estrutura é mais confiável do
que a fila de entradas compartilhada do Windows de 16 bits
porque, com filas separadas, uma aplicação travada não pode
bloquear entradas das outras aplicações. Se uma aplicação
Win32 não chamar GetMessage para manipular eventos
em sua fila de entradas, a fila ficará cheia; após, aproximada-
mente, cinco segundos, o sistema marcará a aplicação como
“Não Respondendo”.
C.7.4 Gerenciamento da Memória
A API Win32 fornece várias maneiras de uma aplicação usar
memória: memória virtual, arquivos mapeados para a memó-
ria, heaps e armazenamento local de threads.
Uma aplicação chama VirtualAlloc para reservar ou
consignar memória virtual e VirtualFree para descon-
signar ou liberar memória. Essas funções habilitam a aplica-
ção a especificar o endereço virtual em que a memória está
alocada. Elas operam com múltiplos do tamanho de página
da memória e o endereço inicial de uma região alocada deve
ser maior do que 0x10000. Veja exemplos dessas funções na
Figura C.14.
6 8   Apêndice C
abre o arquivo ou cria se ele não existir
cria o mapeamento do arquivo com 8 MB de tamanho
agora, obtém uma visão do espaço mapeado
faz algo com o arquivo mapeado
agora, desfaz o mapeamento do arquivo
Figura C.15 Fragmentos de código para mapeamento de um arquivo para a memória.
Um processo pode trancar algumas de suas páginas consig-
nadas na memória física chamando VirtualLock. O número
máximo de páginas que um processo pode trancar é 30, a menos
que o processo chame primeiro SetProcessWorkingSet-
Size para aumentar o tamanho máximo do conjunto de
trabalho.
Uma segunda forma pela qual uma aplicação pode usar
a memória é mapeando um arquivo para a memória em seu
espaço de endereçamento. O mapeamento da memória também
é uma forma conveniente de dois processos compartilharem
memória: ambos mapeiam o mesmo arquivo para sua memó-
ria virtual. O mapeamento da memória é um processo de vários
estágios, como podemos ver no exemplo da Figura C.15.
Se um processo quiser mapear algum espaço de endereça-
mento apenas para compartilhar uma região da memória com
outro processo, nenhum arquivo será necessário. O processo
pode chamar CreateFileMapping com um manipulador
de arquivo igual a 0xffffffff e um tamanho específico. O objeto
mapeamento de arquivo resultante pode ser compartilhado por
herança, por busca de nome ou por duplicação.
Os heaps fornecem uma terceira forma de as aplicações
usarem memória. Um heap no ambiente Win32 é apenas uma
região de espaço de endereçamento reservado. Quando um pro-
cesso Win32 é inicializado, ele é criado com um heap default
de 1 MB. Como muitas funções Win32 usam o heap default,
o acesso ao heap é sincronizado para proteger as estruturas de
dados de alocação de espaço do heap contra danos causados por
reserva um espaço para uma variável
configura-a com o valor 10
obtém o valor
libera o índice
Figura C.16 Código para armazenamento dinâmico local de threads.
atualizações concorrentes feitas por múltiplos threads. O Win32
fornece várias funções de gerenciamento de heaps para que um
processo possa alocar e gerenciar um heap privado. �����������
São as fun-
ções HeapCreate, HeapAlloc, HeapRealloc, Heap-
Size, HeapFree e HeapDestroy. A API Win32 também
fornece as funções HeapLock e HeapUnlock para habili-
tar um thread a obter acesso exclusivo a um heap. Diferente de
VirtualLock, essas funções executam apenas sincronização;
elas não trancam páginas na memória física.
Uma quarta forma de as aplicações usarem memória é por
meio de um mecanismo de armazenamento local de threads.
Normalmente, funções que dependem de dados globais ou
estáticos não funcionam apropriadamente em um ambiente
multithreads. Por exemplo, a função C strtok de tempo de
execução usa uma variável estática para rastrear sua posição
corrente ao analisar uma cadeia de caracteres. Para que dois
threads concorrentes executem strtok corretamente, eles
precisam de variáveis de posição corrente separadas. O meca-
nismo de armazenamento local de threads aloca memória glo-
bal por thread. Ele fornece métodos dinâmicos e estáticos para
criação de armazenamento local de threads. O método dinâ-
mico é ilustrado na Figura C.16.
Para usar uma variável estática local de thread, a aplicação
declara a variável como descrito a seguir para assegurar que
cada thread tenha sua própria cópia privada:
_ _declspec(thread) DWORD cur_pos = 0;

C.8
A Microsoft projetou o Windows para ser um sistema opera-
cional extensível e portável – capaz de se beneficiar de novas
técnicas e novo hardware. O Windows suporta ambientes ope-
racionais múltiplos e multiprocessamento simétrico. Também
suporta uma ampla variedade de ambientes de aplicações
devido ao uso que faz de objetos do kernel para fornecer ser-
viços básicos, além do suporte à computação cliente-servidor.
Por exemplo, o Windows pode executar programas compila-
dos para MS-DOS, Win16, Windows 95, Windows e POSIX.
Exercícios
C.1 Cite algumas razões pelas quais a transferência do código
gráfico do Windows 2000, da modalidade de usuário para
a modalidade de kernel, pode diminuir a confiabilidade do
sistema. Quais dos objetivos de projeto originais do Windows
2000 são violados por tal degradação?
C.2 O gerenciador de VM do Windows usa um processo de dois
estágios para alocar memória. Identifique vários aspectos para
os quais esta abordagem é benéfica.
C.3 Discuta algumas vantagens e algumas desvantagens da
estrutura de tabela de páginas usada no Windows.
C.4 Qual é o número máximo de erros de página que poderia
ocorrer no acesso de (a) um endereço virtual e (b) um
endereço virtual compartilhado? Que mecanismo de hardware
a maioria dos processadores fornece para diminuir esses
números?
C.5 Qual é a finalidade de uma entrada protótipo da tabela de
páginas no Windows?
Notas Bibliográficas
Solomon e Russinovich [2000] fornecem uma visão geral do
Windows e detalhes técnicos consideráveis sobre os meca-
nismos internos e componentes do sistema. Tate [2000] é
uma boa referência sobre o uso do Windows. O Microsoft
Windows Server Resource Kit (Microsoft [2000b]) é um
conjunto de seis volumes, útil para o uso e implantação do
Windows. A Microsoft Developer Network Library (Micro-
Windows 2000  6 9
Resumo
Ele fornece memória virtual, armazenamento em cache inte-
grado e scheduling preemptivo. O Windows suporta um
modelo de segurança mais forte do que os de sistemas ope-
racionais anteriores da Microsoft e inclui recursos de inter-
nacionalização. O Windows opera em uma ampla variedade
de computadores e, portanto, os usuários podem selecionar
e atualizar o hardware para que se ajuste a seus orçamentos e
requisitos de desempenho, sem precisar alterar as aplicações
que executam.
C.6 Quais são os passos que o gerenciador de caches deve percorrer
para copiar dados para dentro e para fora do cache?
C.7 Quais são os principais problemas envolvidos na execução de
aplicações do Windows de 16 bits em uma VDM? Identifique
as soluções selecionadas pelo Windows para cada um
desses problemas. Para cada solução, cite pelo menos uma
desvantagem.
C.8 Que alterações seriam necessárias para que o Windows execute
um processo que use um espaço de endereçamento de 64 bits?
C.9 O Windows tem um gerenciador de caches centralizado. Quais
são as vantagens e desvantagens deste gerenciador de caches?
C.10 O Windows usa um sistema de I/O dirigido por pacotes.
Discuta os prós e contras da abordagem de I/O dirigido por
pacotes.
C.11 Considere um banco de dados na memória principal com 1
terabyte. Que mecanismos você poderia usar no Windows
para acessar este banco de dados?
soft [2000a]), emitida trimestralmente, fornece muitas
informações sobre o Windows e outros produtos da Micro-
soft. Iseminger [2000] fornece uma boa referência sobre o
Active Directory do Windows. Richter [1997] oferece uma
discussão detalhada sobre a criação de programas que usem
a API Win32. Silberschatz et al. [2010] apresentam uma boa
discussão sobre as árvores B+.