INFO: Sistema de grupo de multimídia e diretrizes de design de API

O grupo de sistemas multimídia do Microsoft está fazendo uma grande quantidade de design de sistema e a implementação. Este artigo comentários nas áreas de design de sistema.

Definições

Duas observações sobre um canal:

1. Um módulo pode alocar recursos para um canal. Por exemplo, um identificador para uma janela é um canal, que tem memória, um procedimento de janela e muitos outros recursos associados a ele.
2. O canal identifica exclusivamente o usuário da interface para o módulo. Isso permite que o módulo executar funções exclusivamente em cada canal aberto. Por exemplo, cada identificador de arquivo representa um arquivo diferente que foi aberto. Cada identificador de arquivo pode ter atributos diferentes (leitura, gravação, leitura/gravação, binário e assim por diante).

Separar a interface do driver de interface do módulo

Separar o aplicativo o hardware é uma das principais tarefas do software do sistema. Camadas do sistema operacional são separadas do hardware por meio do uso de drivers. A interface de sistema para o aplicativo deve ocultar mecanismos dos drivers tanto quanto possível. Isso permite alterar a mecânica de um driver em uma versão posterior do software de sistema. Isso também preserva a formalidade da interface; aplicativos são impedidos de acessar diretamente o hardware.

Cada aplicativo também deve ser separado de drivers no sistema. O driver API não deve depender onde o driver está localizado, o que ele é denominado ou qual formulário demora (DLL, VxD e assim por diante).

Um driver deve proteger o gravador de aplicativo do seu funcionamento interno para aplicar o princípio de ocultar informações. Se houver muitas informações, o gravador de aplicativo pode optar por acessar diretamente o hardware, que compromete a separação da funcionalidade fornecida pelo driver de mecanismo e o sistema API.

Cada módulo deve ter uma função de inicialização

Solicitando o aplicativo para chamar uma função de prefixo antes de usar um módulo de sistema e uma função postfix depois usar um módulo de sistema fornece três benefícios principais, da seguinte maneira:

1. As versões posteriores do driver podem facilmente virtualizar recursos porque o driver defies um canal para toda a comunicação. O driver pode manter recursos separados para cada canal de comunicação, que é necessário para virtualização.
   
   Observe que a virtualização completa não precisa ser feito na primeira implementação do módulo. Desde que a interface requer a chamadas de prefixo e postfix, chamadas subseqüentes prefixo podem falhar com uma mensagem de erro apropriado. Versões futuras do sistema podem manipular corretamente várias solicitações para o recurso do sistema.
2. O módulo de sistema pode alocar recursos quando o canal é alocado (quando a função de prefixo é chamada), em vez de quando o sistema for inicializado. Módulos que não são chamados consomem sem recursos. Alocação de recursos para todos os módulos é adiada tempo possível.
3. O sistema pode resolver conflitos entre clientes por meio de identificação fornecido pelos canais.

Nome da interface

Durante o processo de criação de um novo módulo, use a interface as convenções de um módulo existente de nomenclatura com funcionalidade semelhante. Por exemplo, uma interface que negociações com arquivos teria uma interface de prefixo que contenham a palavra "abrir" e uma interface postfix contendo a palavra "Fechar". Estenda convenções de nomenclatura para áreas funcionais semelhantes. Uma interface de fluxo também teria um "abrir" e uma função "Fechar".

Se o módulo tem novas funcionalidades, as funções podem ter nomes exclusivos, como função de midiOutStop do driver de MIDI. Se o módulo é semelhante, mas não o mesmo que outro módulo, use o nome da função para distinguir entre módulos. Por exemplo, as funções de CreateWindow e CreateWindowEx no Windows criar janelas, mas CreateWindowEx também permite que um aplicativo especificar outros atributos.

O objetivo é fornecer os programadores familiarizados com módulos existentes uma base pela qual a aprender rapidamente a nova interface.

Prefixo nomes de função com o nome do módulo (abreviado, se necessário). Isso permite que a documentação para classificar em ordem alfabética, nomes de função mantendo funções relacionadas juntas. Mais importante, ele permite a facilitar a identificação do módulo ao qual pertence uma função.

Nome de definição

Prefixo os nomes de constantes e estruturas de dados com o nome do módulo (abreviado, se necessário). Por exemplo, STRM_SEEK é uma constante no grupo STRM. Isso permite que facilitar a identificação do módulo ao qual pertence uma estrutura de dados ou definição.

Como outro exemplo, MIDIOUTCAPS é a estrutura de recursos do dispositivo para o módulo de saída de MIDI. Usando a convenção de nomenclatura desenvolvido aqui e simetria (discutido detalhadamente na segunda parte deste artigo), o módulo de entrada de MIDI estrutura de recursos do dispositivo deve ser chamado MIDIINCAPS.

Use prefixos adicionais conforme apropriado para identificar o uso da definição. Por exemplo, MOERR_NODRIVER é uma definição no módulo de saída de MIDI para descrever um erro, que nenhum driver apresentam.

Registrando drivers com o módulo

A maioria dos sistemas desenvolvidos por grupo multimídia permitem que os drivers de dispositivo para ser instalado pelo fabricante original do equipamento (OEM) ou até mesmo pelo usuário final (concedida a um programa de instalação apropriado). Existem duas maneiras principais para esses drivers para se comunicar com o módulo principal.

A primeira é colocar uma entrada no arquivo System.ini. Quando o módulo pai for carregado, ele carrega o driver do filho e inicia a comunicação com o filho.

Outro método é para o driver filho chamar o pai ao se registrar como um cliente. Este segundo método presume que há um método adequado disponível para carregar o filho. O Windows fornece esse mecanismo.

Exigir um driver para se registrar com o módulo manipulador fornece quatro benefícios:

1. Drivers podem ser instalados, adicionando-a "módulos ao carregar" lista. Isso é muito mais fácil de criar uma linha para o arquivo System.ini.
2. O módulo de manipulador é mais geral porque ele não assume a presença de determinados drivers. Isso melhora a portabilidade do sistema e reduz interdependências entre drivers e manipuladores. Essa vantagem também se aplica a drivers carregados por um processo pai.
3. Um driver pode passar informações sobre si mesmo, como seus pontos de entrada e de nome para seu pai durante o registro. Isso ainda mais separa o módulo pai do driver. Desde que o formato dos dados de interface é fixo, as alterações independentes podem ser feitas em pai e o driver.
4. Instalação de tempo de execução de drivers é possível. A natureza inerente de registro torna instalar novos drivers enquanto o sistema está sendo executado muito mais fácil. Isso também simplifica a implementação de virtualização.

Simetria de nomes de função

• Cada função Open deve ter uma função Fechar e cada Get funcionar uma função PUT.
• Funções relacionadas em áreas separadas devem funcionam da mesma maneira. Por exemplo, se a saída de MIDI tiver um abrir, a entrada de MIDI também deve ter um abrir. Além disso, os parâmetros e valores de retorno devem ser o mais semelhantes possível. Isso facilitará a tarefa do programador de aprender as novas APIs. Isso se aplica mesmo se a implementação atual não usa a API simetria. Consulte "Designing para implementação em etapas," abaixo.

Simetria de convenções de nomeação

• Nome definido constantes e tipos de áreas relacionadas devem todos ser nomeados usando as mesmas convenções. Por exemplo, LPMIDICALLBACK e LPWAVECALLBACK.
• Se já existir uma convenção de nomenclatura para um tipo de função, aderir a ele. Exemplo: use a busca e fala funções para mover dentro de um sistema de arquivos.
• Se qualquer parte de uma convenção existente for usado, pouco desvio dele é permitido. Por exemplo, uma combinação de funções de busca e GET para mover dentro de um sistema de arquivos não seria o produto de um bom design porque ela confunde uma convenção existente.
• Se ainda não existir uma convenção, crie uma nova convenção de nomenclatura para evitar coisas confusas. Exemplo: BATER e RESPONDA.

Design para implementação em etapas

A maioria das implementações de qualquer tamanho deve ser feito em etapas incrementais de funcionalidade. Mais e mais recursos são adicionados os módulos até que todo o design é implementado completamente. Para módulos grandes ou complexos, esse processo pode ocorrer nos vários anos. No entanto, o design original deve prever a funcionalidade completa, final, não apenas as metas de curto prazo. Por exemplo, mesmo que permitir que vários usuários de um módulo não será implementada na primeira fase, esse recurso deve ser criado na API do. Dessa forma, o impacto sobre os usuários do módulo será ser mínimo uma vez concluída a implementação.

Evite colocar limites arbitrários na funcionalidade devido aos detalhes de implementação atual. Por exemplo, mesmo se somente um usuário pode ter um recurso alocado hoje, isso pode não ser true. Especificamente, a função abrir deve retornar um identificador para o recurso que é então passado para funções que manipulam o recurso. No futuro, quando vários usuários do recurso é implementado, não será necessário alterar outras funções ou outros aplicativos.

Em um sistema com base em mensagem, funções devem retornar um código de "mensagem não reconhecida" para mensagens inesperadas que é diferente do código "Ocorreu um erro". Em seguida, quando uma versão futura do driver contém funcionalidade estendida, um aplicativo pode determinar se a versão instalada do driver oferece suporte aos novos recursos. Caso contrário, o aplicativo pode executar ação alternativa apropriada.

Um projeto criado para ser criado em fases também definiu etapas de andamento. Isso torna muito mais fácil controlar o progresso enquanto o módulo está em construção.

Criar um módulo em fases também torna mais fácil verificar que o módulo foi criado corretamente. Teste recebe incrementos de funcionalidade em vez do produto inteiro para o fim do ciclo de desenvolvimento.

Relatório de erros

Uma chamada de função pode falhar por várias razões. É melhor se a chamada pode retornar a causa específica do erro ao observar que a chamada falhou. Funções que retornam outros dados, estrutura ou uma alça de causar problemas de determinado porque há um conjunto limitado de valores que sempre são inválidos.

Três abordagens para relatório de erros são:

1. Ignorá-la (não recomendado).
2. Fornece uma separada chamada "o que foi esse erro?". Isso é mais complicado do que parece porque, em um sistema de multitarefa, pode haver vários usuários do módulo ao mesmo tempo"." Isso torna a determinar o que foi o último erro para um determinado aplicativo difícil.
3. Retornar o identificador ou estrutura em um parâmetro e retornar o código de erro como o retorno de função. Isso parece ser a melhor opção e é a abordagem usada pelos / 2.

Agora que o código de erro está disponível, o que deve ser feito com ele? Para permitir para internacionalização e códigos de erro adicionais, o aplicativo não deve associar o código de erro com uma mensagem. Em vez disso, fornecem uma função em cada API que retorna a mensagem de texto para um código de erro especificado. Esta função pode ser nomeada GetTextErrorInformation, por exemplo.

Buffers fornecidos pelo cliente

É desejável para o aplicativo cliente fornecer todos os buffers que irá acessar. Se um módulo de sistema aloca e mantém buffers, muitos problemas de implementação podem ocorrer quando um buffer é tornado visível para o aplicativo cliente. Três vantagens de buffers fornecidos pelo cliente são:

1. Se o software do sistema é executado no nível de privilégio diferente ou em uma CPU diferente, ou caso contrário é separado do aplicativo cliente, o software do sistema pode acessar facilmente o buffer. No entanto, em nível de privilégio mais baixo do cliente, ou se o cliente e o sistema operacional estiverem em CPUs diferentes, pode ser extremamente difícil (se não impossível) para disponibilizar um buffer fornecido pelo sistema para o cliente.
2. Quando o aplicativo fornece os buffers, o aplicativo tem controle completo sobre quanta memória o módulo do sistema usa.
3. O aplicativo é responsável por relatar um erro de falta de memória. Isso remove uma condição de erro a chamada do sistema.