ID do artigo: 169321 - Última revisão: segunda-feira, 11 de julho de 2005 - Revisão: 2.5

INFO: Ativação do COM servidores e estações do Windows NT

Vista lado a ladoClique aqui para exibir o artigo traduzido e o artigo original em inglês, lado a lado.
Tradução automáticaExibir Aviso de Isenção de Tradução Automática
Exibir os produtos aos quais esse artigo se aplica.
Dica do SistemaEste artigo aplica-se a um sistema operativo diferente do que está a utilizar. Foi desactivado o conteúdo do artigo, que pode não ser relevante para si.

Nesta página

Expandir tudo | Recolher tudo

Sumário

Quando um cliente solicita um objeto de classe para uma classe registrado, COM retorna um objeto de classe existente ou inicia um processo que está registrado como contendo o objeto de classe solicitada. O processo de obtenção de uma referência de objeto de classe para um cliente solicitante (ou não que resulta na criação do processo ou "Iniciando") é chamado de "Ativação".

Sob determinadas condições, COM pode iniciar um novo processo do servidor mesmo quando um objeto de classe existente está em execução e foi registrado como usar vários. Além disso, quando COM cria um novo processo que o processo pode ser iniciado em um novo ambiente de segurança conhecido como uma "estação de janela" em vez de compartilhamento de uma estação de janela existente, como a estação de janela interativa. (Para obter mais informações em estações de janela, procure a documentação do SDK do Win32 para essa frase.)

Noções básicas sobre algoritmos do COM para criação de novos processos e estações de janela durante uma solicitação de ativação é importante por vários motivos. Primeiro, COM pode criar mais de uma instância de processo de um objeto de classe de uso de vários devido a problemas de segurança. Segundo, servidores de "uso único" sempre serão iniciados em processos separados, mas elas podem ou não podem ser iniciadas em estações de janela separada. Essa diferença pode se manifestar ao código do aplicativo em determinados casos incomuns, como quando dois servidores tentam se comunicar por meio de mensagens de janela ou instalações de comunicação segura, como COM ou RPC. Em terceiro lugar, como o número de estações de janela que podem ser criados simultaneamente no Windows NT é limitado, é importante saber quando o servidor COM obtém uma nova estação de janela.

Este artigo examina a cenários de ativação diferente e explica quando são criadas novos processos e estações de janela.
Voltar para o início

Mais Informações

Quando cria um novo processo de servidor COM ou atribui uma nova estação de janela para um novo processo de servidor depende de vários fatores:
  1. A identidade de segurança sob a qual a classe COM é definida para iniciar. A identidade de uma classe pode ser definida por meio da ferramenta DCOMCNFG e é especificada por RunAs valor sob a chave AppID para a classe nomeadas.
  2. Uso único vs várias uso registro por objetos de classe.
  3. Identifier(SID) segurança do processo de cliente (isso é o valor numérico que representa uma identidade/entidade de segurança/conta de usuário específico em um ambiente Windows NT).
  4. O identificador de logon (LUID) do cliente processo. (um novo identificador de logon é gerado para cada logon exclusivo em um computador executando o Windows NT. Este logon poderia ser através de um usuário digitando um nome de usuário e senha no prompt de logon do NT ou através de uma chamada para o win32 API LogonUser.)
  5. Ativação remota versus local.
  6. Estação da janela do cliente.
Voltar para o início

Uso de várias classes

Uma classe de uso de vários é uma classe que está registrada com (via CoRegisterClassObject() API) especificando o sinalizador REGCLS_MULTIPLEUSE. Para classe, COM normalmente usa a mesma instância do processo do servidor para todas as solicitações de ativação do cliente. No entanto, para classes configurados para ser executado sob a segurança dos usuários iniciar e, em alguns outros casos, COM inicia uma nova instância do processo de servidor para solicitações de ativação do serviço. Quando uma nova instância do processo do servidor, portanto, é iniciada, é possível que o processo do servidor obtém uma nova estação de janela bem. Examinaremos os vários cenários abaixo, mas primeiro, abordaremos resumidamente por que COM inicia novos processos que contém objetos de classe solicitado quando uma instância do objeto de classe já está registrada como uma classe de "uso de vários".

Primeiro, quando uma classe COM (com mais precisão, quando um AppID associado com uma classe COM) está registrado com o sistema para ser executado como "o usuário iniciar", o administrador do sistema definiu uma determinada diretiva de segurança com relação a essa classe. A diretiva é que um ativador deve receber um objeto de classe dentro de um processo que está executando no mesmo contexto de segurança o código de ativação.

Esta diretiva de segurança pode entram em conflito com o comportamento de ter apenas um objeto de fábrica de classe para todas as solicitações de ativação (como indicado pela REGCLS_MULTIPLEUSE) definidas pelo servidor. COM prioriza a diretiva de segurança sobre o comportamento do aplicativo. Como resultado, uso de vários servidores registrados para executar como "o usuário inicia" irão se comportar não acordo com para as regras normais de uso de várias. Um novo processo será iniciado para cada entidade de segurança ativando.

Em segundo lugar, se um processo não iniciado por COM sendo executado em um contexto de segurança diferente do especificado para o CLSID determinado registra esse CLSID, esse registro será fail(CoRegisterClassObject will return an error code CO_E_WRONG_SERVER_IDENTITY in this case). E, se uma solicitação de ativação mais tarde chega um novo processo será iniciado por COM o contexto de segurança especificado para o AppID/CLSID. COM não pode confiar em código chamando CoRegisterClassObject() (uma operação não segura), ele somente pode confiar em configuração do Registro (o registro é um banco de dados seguro) para determinar qual objeto de classe para uso e como executá-lo. Esse comportamento impede que a máquina ilícito falsificação de objetos de classe por usuários não autorizados.

Com isso em mente, nós agora retornar à edição de novos processos e estações de janela quando são criadas quando o uso de vários servidores são iniciados pelo COM. Observe que LUID do cliente não importa de qualquer forma no caso de classe de uso de várias.
  1. Identidade de segurança "Usuário interativo". No caso em que o AppID da classe de COM um uso de vários é configurado para executar como a identidade de "Usuário interativo", o primeiro processo de servidor e seu objeto de classe serão usados por COM para atender a todas as solicitações de ativação subseqüente. Esta instância do servidor terá a estação de janela interativa, se houver (se nenhum usuário estiver conectado localmente e todas as solicitações de ativação falhará). Conforme mencionado acima, se um processo não iniciado pelo COM e não em execução na estação de janela interativa registra o CLSID, esse registro falhará. E, se mais tarde chega uma solicitação de ativação, um novo processo será iniciado com o contexto de segurança do usuário interativo. Esse comportamento impede a falsificação ilícito de objetos de classe. Como nenhum processo de servidor adicionais nunca é iniciado por COM, a pergunta de novas estações de janela é moot. O SID do cliente, seu LUID ou se ele é local ou remoto não importa nesse caso.
  2. Identidade de segurança "Deste usuário". Da mesma forma, se uma classe de COM uso de vários é AppID está configurado para executar como "Este usuário" (uma ID de segurança predefinidos), o primeiro servidor processar e seu objeto de classe será usado por COM para atender a todas as solicitações de ativação subseqüente. Esta primeira instância do servidor terá sua própria estação de janela criada como parte da criação de processo primeira. Como nenhum processo de servidor adicionais nunca é iniciado por COM, a pergunta de estações de janela adicionais é moot. O SID do cliente, seu LUID ou se ele é local ou remoto não importa nesse caso. Observe que uma nova estação de janela será ser criada quando você iniciar a primeira instância de uma classe/AppID configurado para ser executado como "Usuário", mesmo se o mesmo usuário fizer logon no momento no winstation interativo. COM usa nunca winstation interativo para iniciar um servidor configurado para executar como "Usuário" porque que poderia resultar em comportamento diferente para a classe dependendo o problema não relacionado da identidade do usuário conectado no momento. Como observado acima, se um processo não iniciado pelo COM e não sendo executado na conta especificada em "Usuário" tenta registrar o CLSID, que o registro falhará e se uma solicitação de ativação mais tarde chega um novo processo serão iniciados na conta "Usuário". Esse comportamento impede a falsificação ilícito de objetos de classe. Por outro lado, se o processo registrado para um CLSID determinado/IDAPL está configurado para executar como "Usuário", será criado na conta do usuário apropriadas por alguns agente diferente COM (por exemplo, ele é executar por usuário interativo quando o usuário interativo é o mesmo usuário como "Usuário" ou ele é iniciado por meio de CreateProcess() por um serviço em execução no mesmo contexto de segurança como "Este usuário") e em seguida, ele registra seus objetos de classe REGCLS_MULTIPLEUSE, COM irá usar o objeto de classe existente em execução para satisfazer subseqüentes as solicitações de ativação de qualquer cliente.
  3. Identidade de segurança "Iniciando o usuário". Nesse caso, AppID a classe do é definido como iniciar sob o idenitity "Iniciando o usuário" (essa é também conhecido como uma classe "Ativar como ativador"). cliente a. local. Primeiro, considere o caso de máquina local. Há duas regras: 1. cada SID de cliente ativação diferente fará com que COM para iniciar uma nova instância do processo do servidor até mesmo na estação de janela mesmo. 2. Mesmo para correspondência de SIDs (como o caso onde o mesmo usuário estiver conectado mais de uma vez para uma única máquina NT), cada estação de janela de outro cliente local fará com que COM para iniciar uma nova instância do processo do servidor. Em outras palavras, inicialização usuário identidade uso de vários servidores nunca são compartilhados entre estações de janela. Todos os processos do cliente com o mesmo SID e estações de janela mesmo compartilharão um processo de único servidor a mesma estação de janela. Desde que o servidor compartilha a estação de janela do cliente não novas estações de janela são criadas. Por exemplo, suponha que você interativamente fez logon como a_domain\a_user. Você executar várias instâncias do cliente, que irá conectar à instância mesma do servidor (que tem a estação de janela interativa). Agora vamos digamos que você tenha um cliente, que é um serviço, que é definido para iniciar iniciar a_domain\a_user. Este serviço iniciará uma nova instância do servidor COM. Isso acontece porque o COM fará com que uma nova instância do servidor a ser iniciado porque o processo do serviço tem uma estação de janela diferente a estação de janela interativa--mesmo que a identidade do processo service(client) seja o mesmo que a identidade do processo do servidor em execução (a_domain\a_user). No entanto, observe que nenhuma nova estação de janela é criada para o processo do servidor COM. O servidor ainda herdará estação da janela do serviço. Se o serviço é configurado para iniciar em LocalSystem e interagir com a área de trabalho (consulte caixa de seleção "Permitir Service para interaja com o Desktop" no serviço de miniaplicativo no painel de controle), em seguida, o serviço será executado na estação de janela interativa ou winsta0. Nesse caso COM ainda será iniciar uma nova instância do servidor (SID do cliente que é LocalSystem nesse caso é diferente do SID do servidor que é a_domain\a_user) na estação de janela interativa. b. remoto cliente. No caso de ativação remota, COM ignora estação da janela do cliente porque o cliente remoto, diferentemente o local caso acima. A regra aqui é que cada cliente novo SID fará com que uma nova instância do processo do servidor para ser iniciado e cada novo processo do servidor terá uma nova estação de janela. Ativação subseqüente solicitações por clientes remotos com o mesmo que SID reutilizará que a existente registrado objeto de classe, bem como sua estação de processo e janela. Por exemplo, suponha que você fez logon como a_domain\a_user em máquinas diferentes 10. Os clientes de todos os essas máquinas irão se conectar à mesma instância do servidor na máquina do servidor. Um cliente de uma máquina a_domain\b_user iniciará uma nova instância do servidor e uma nova estação de janela. Os chamadores remotos com o mesmo SID como um usuário local que tenha iniciado o servidor COM registrado para o CLSID solicitado reutilizará o objeto de classe existente. No entanto, a ordem na qual o servidor COM é iniciado é importante nesse caso. Se o servidor é iniciado pelo cliente local primeiro, o cliente remoto com o mesmo SID se conectará a este servidor. Por outro lado, se o servidor é iniciado pelo cliente remoto primeiro, um cliente local com o mesmo SID será iniciar uma nova instância do servidor. Isso vai volta para as regras de estação de janela mencionadas acima. Para clientes locais, a estação de janela do cliente e o servidor deve corresponder à, para clientes remotos que estação da janela do cliente será ignorada. Por exemplo, se cliente local a_domain\a_user inicia o servidor pela primeira vez, cliente remoto a_domain\a_user conectará ao servidor. Por outro lado, se o cliente remoto a_domain\a_user inicia o servidor pela primeira vez, em seguida, a_domain\a_user cliente local iniciará uma nova instância do servidor e uma nova estação de janela. LUID do cliente não importa nesse caso.
  4. Servidores baseados em serviço de COM. Uma classe/AppID de COM que é fornecido em um serviço Win32 é prática necessidade um servidor de uso de vários desde serviços podem ser iniciados apenas uma vez. Nesse caso, na primeira solicitação de ativação, um novo processo é iniciado em sua própria estação de janela. Há duas exceções a esta: a. Se o serviço é definido para iniciar sob a conta do sistema local, ele herdará a uma estação de janela predefinida do sistema. b. Se o serviço estiver definido para iniciar sob a conta do sistema local e pode interagir com a área de trabalho, ele herdará a estação de janela interativa ou winsta0. Todas as solicitações de ativação subseqüente, local ou remoto, são manipuladas pelo objeto de classe do serviço. Conforme mencionado acima, se um processo não iniciado pelo COM e não em execução como o serviço especificado registra o CLSID, esse registro falhará e se uma solicitação de ativação mais tarde chega serviço registrado serão iniciados. Esse comportamento impede a falsificação ilícito de objetos de classe.
Voltar para o início

Classes de uso único

Observação: Devem ser evitados único usar classes tanto quanto possível. Registro de uso único é uma configuração herdada e destina-se para oferecer suporte mais antigos COM aplicativos e para facilitar a portagem de aplicativos não-COM herdados para COM. É altamente recomendável que novas classes ser projetado para oferecer suporte a registro de objeto de classe de uso de várias. Isso é especialmente verdadeiro em caso de servidores com identidade "Este usuário", onde uso único classes fazer com que os exatamente opostos efeito das classes multi-use. Eles crie um novo servidor processo e nova estação de janela por ativação e, como discutimos abaixo, isso pode causar problemas de recursos no Windows NT.

Uma classe de uso único é aquele que está registrado no COM (via API CoRegisterClassObject()) especificando o sinalizador REGCLS_SINGLEUSE. Para classe, COM será sempre iniciar uma nova instância do processo de servidor da classe para cada solicitação de ativação de qualquer cliente (local ou remoto). Para fins deste artigo, é a pergunta restante: quando o servidor terá uma nova estação de janela bem?
  1. Identidade de segurança "Usuário interativo". Levar o caso em que a classe de uso único é definida por meio de sua AppID para iniciar sob a identidade de "Usuário interativo". Nesse caso, cada nova instância do processo do servidor sempre irá compartilhar a estação de janela interativa, se houver (se nenhum usuário estiver conectado localmente e todas as solicitações de ativação falhará). Nenhuma estação de janela novo será criada pelo COM.
  2. Identidade de segurança "Deste usuário". Agora considere o caso em que a ID da classe COM uso único está definida como executado sob a identidade "Este usuário". Nesse caso, a regra é muito simples. Cada novo ativação cliente inicia um novo processo em uma nova estação de janela. Isso é verdadeiro independentemente do se o usuário especificado como "Este usuário" é conectado à estação de janela interativa ao tempo de qualquer um das solicitações de ativação.
  3. Identidade de segurança "Iniciando o usuário". cliente a. local. No cenário de ativação de máquina local, o processo do servidor sempre obterá estação da janela do cliente. Nenhuma estação de janela novo nunca é criadas. Por exemplo, suponha que você interativamente fez logon como a_domain\a_user e executar várias instâncias do programa cliente. Cada nova instância resultante do servidor terá a estação de janela interativa. Agora suponha que o cliente seja um serviço executado sob a conta sistema local. Nesse caso o servidor COM compartilharão a estação de trabalho do processo de serviço. b. remoto cliente. No caso de ativação remota, COM ignora estação da janela do cliente, já que o cliente remoto. Como sempre, um novo processo de instância do servidor será iniciado para cada ativação remota. As regras são: 1. para cada novo cliente remoto SID, será criada uma nova estação de janela para o processo do servidor. 2. Para cada novo cliente remoto LUID, será criada uma nova estação de janela para o processo do servidor. 3. Todos os clientes remotos com o mesmo par SID/LUID criará servidores que irão compartilhar a mesma estação de janela. Por exemplo, você fez na máquina cliente remoto como a_domain\a_user. Este cliente inicia o servidor remoto receberá uma nova estação de janela. Agora, se a_domain\a_user iniciar uma segunda instância do aplicativo cliente do mesmo computador cliente que por sua vez, inicia uma nova cópia do servidor no computador remoto, esse servidor irá compartilhar estação de janela do servidor original. Agora, suponha que você faça logon no outro computador como a_domain\a_user novamente e executar o cliente a partir daí. A instância correspondente do servidor terá uma nova estação de janela. Isso demonstra que, mesmo se o cliente SIDs forem iguais, como o segundo cliente tem um LUID diferente, seu processo de servidor obterá uma nova estação de janela.
  4. Servidores baseados em serviço de COM. Classes de uso único nunca devem ser implementados como serviços do Windows NT. Não faz sentido, porque ele não é possível executar várias instâncias de um processo de serviço do Windows NT.
Voltar para o início

Tabela Summarizing cenários

--------------------------------------------------------------------------- 
       |                      Multiple-Use Server
       |             (class factory has requested reuse)
       |                       Activation Modes
       |-------------------------------------------------------------------
       |   Interactive     | As "This       |As "Launching    | Win32
Client |      User         |   User"        |   user"         | service
				
Local  | Process launched  | Process        | Process         | Service
       | in the            | launched in a  | launched client | started on
       | interactive window| new window     | window station  | first
       | station on first  | station on     | on first        | activation
       | activation        | first          | request,        | request
       | request,          | activation     | subsequent      | (new winsta
       | subsequent        | request,       | requests from   | or system/ 
       | requests get      | subsequent     | the same SID/   | interactive
       | existing class    | requests get   | window station  | winsta
       | object,           | existing class | get existing    | depending
       | activations fail  | object         | class object, no| on service
       | if no user logged |                | sharing of class| config),
       | on locally        |                | objects across  | subsequent
       |                   |                | window stations | requests
       |                   |                | even if same SID| get
-------|                   |                |-----------------| existing
Remote |                   |                | Process launched| class
       |                   |                | in new winsta on| objects
       |                   |                | first activation|
       |                   |                | request by a    |
       |                   |                | SID, subsequent |
       |                   |                | remote requests |
       |                   |                | by the same SID |
       |                   |                | get existing    |
       |                   |                | class object;   |
       |                   |                | class launched  |
       |                   |                | by local user   |
       |                   |                | reused by remote|
       |                   |                | callers with    |
       |                   |                | same SID        |
---------------------------------------------------------------------------

--------------------------------------------------------------------------- 
       |                      Single-Use Server
       |          (new process created for each activation request)
       |                       Activation Modes
       |-------------------------------------------------------------------
       |   Interactive     | As "This       |As "Launching    | Win32
Client |      User         |   User"        |   user"         | service
				
Local  | Process always    | Process always | Process always  | N/A(only
       | launched in the   | launched in a  | launched in     | one
       | interactive       | new window     | the window      | activation
       | window station,   | station        | station of      | possible)
       | if no interactive |                | client process  |
       | window station    |                |                 |
       | activation fails  |                |                 |
-------|                   |                |-----------------|
Remote |                   |                | if both SID and |
       |                   |                | LUID of the     |
       |                   |                | client match    |
       |                   |                | previous client |
       |                   |                | activation,     |
       |                   |                | process launched|
       |                   |                | in existing     |
       |                   |                | window station, |
       |                   |                | otherwise in new|
       |                   |                | windowstation   |
---------------------------------------------------------------------------
Voltar para o início

Estações de janela e recursos do Windows NT

Nesta seção examinaremos as implicações da criação de novas estações de janela no Windows NT e como que deve afetar a configuração do servidor COM. Como você verá, há um limite para o número de estações de janela que podem ser criados em um computador Windows NT. Quando esse limite for excedido, o Windows NT irá falhar uma tentativa de iniciar uma nova instância do processo do servidor por COM. Normalmente, uma mensagem de erro semelhante à seguinte aparece:
Inicialização da biblioteca de vínculo dinâmico
d:\WINNT\system32\kernel32.dll falha. O processo é
Finalizando de forma anormal.
No Windows NT, cada estação de janela tem pelo menos uma área de trabalho associada a ele. Windows NT usa uma pilha de memória especial para todos os aplicativos windows em execução em uma área de trabalho. Por padrão, cada heap da área de trabalho consome 3 MB de memória. Windows NT tem um limite não configurável de 48 MB para criar pilhas de área de trabalho. Isso significa que o número máximo de estações de janela que podem ser criados em um computador Windows NT é 16 (provavelmente menos como uma estação de janela pode conter mais de uma área de trabalho). Para aumentar esse número, você pode reduzir o tamanho de heap da área de trabalho padrão editando o registro usando o Editor do Registro.

Aviso: Usar o Editor do Registro incorretamente pode causar problemas sérios no sistema que talvez exijam a reinstalação do Windows NT para corrigi-los. Microsoft não garante que problemas resultantes do uso do Editor do Registro possam ser solucionados. Use esta ferramenta de sua responsabilidade.

O valor nomeado é necessário editar aparece sob a seguinte chave: 
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
   Manager\SubSystems
você precisa editar o valor nomeado "Windows". Ele é uma seqüência de caracteres REG_SZ. Editar a seqüência e procure "seção compartilhada = 1024, 3072". Modificar isso ler "seção compartilhada = 1024, 3072, 512". Você precisa reiniciar o computador para esta alteração tenha efeito. Fazendo essa alteração, você está especificando o tamanho de heap de 3 MB (padrão) para área de trabalho da estação de janela interativa e 512 KB para todos os não - interativo áreas de trabalho (o primeiro parâmetro é obsoleto mas não deve ser alterado). Esta alteração permitirá que a criação de aproximadamente menor do que 48 MB/512 KB ou 96 estações de janela.

Observação: A estação de janela pode conter várias áreas de trabalho dentro dele. Na discussão dos servidores "Iniciando o usuário" acima, sempre que a estação de trabalho do processo de cliente local mencionada, ele deve ser considerado como um formulário mais curto para "estação de janela e área de trabalho". Configuração "Iniciando o usuário" realmente é destinada a servidores ciente herdados não-DCOM e deve ser usada raramente. Esses servidores herdados esperam executar em suas próprias áreas de trabalho. Portanto, para MULTIPLEUSE "Iniciando o usuário" servidores, cada processo do cliente em uma área de trabalho diferente dentro a mesma estação de trabalho gera um novo processo de servidor a ser iniciado na área de janela estação/trabalho. Para SINGLEUSE "Iniciando o usuário" herda de servidores, novamente, o servidor windows estação/desktop do processo do cliente.

No Windows NT 4.0 Service Pack 4.0, COM tentativas de reutilizar estações de janela. Antes para isso, se um servidor é definido como RunAs um usuário específico e se várias instâncias do processo do servidor são iniciadas, cada processo terá sua própria estação de janela. Isso leva a estação da janela limitações descrevem acima. No SP4, COM tentará criar todos os servidores de RunAs (ou seja, não "Ativar como ativador" ou "Iniciando usuário") definidos para execução sob o mesmo usuário identidade (ou símbolo) na estação de janela mesmo.

Isso elimina a necessidade para ajustar o tamanho de heap da área de trabalho nesses casos onde vários processos do servidor executados com o mesmo token. Se, em sua configuração, todos os servidores são definidos como RunAs o mesmo usuário ou várias instâncias do mesmo processo do servidor de RunAs executar, em seguida, você deve reduzir não heapsize a área de trabalho conforme sugerido no artigo. É recomendável que você deixar o valor padrão (3 M) nesse caso. Isso ocorre porque, se você reduzir o heap da área de trabalho, em seguida, o sistema pode criar mais janela estações/áreas de trabalho; no entanto, o número de processos pode ser executado em um estação de janela/desktop se tornam cada vez menor.

Por outro lado, em sua configuração, se você tiver vários servidores que executam com tokens diferentes, em seguida, você enfrentará as limitações de estação de janela. Nesse caso, você deve seguir as sugestões no artigo para reduzir o tamanho de heap da área de trabalho.
Voltar para o início

Referências

Para obter informações adicionais sobre o problema de heap da área de trabalho, consulte o seguinte artigo na Base de dados de Conhecimento da Microsoft:

142676  (http://support.microsoft.com/kb/142676/EN-US/ ) Como corrigir erros comuns de arquivo User32.dll
Voltar para o início
A informação contida neste artigo aplica-se a:
  • Microsoft OLE 4.0 nas seguintes plataformas
    • Microsoft Platform Software Development Kit-January 2000 Edition
Voltar para o início
Palavras-chave: 
kbmt kbapi kbdcom kbenv kbinfo kbinterop kbkernbase kbprogramming kbusage KB169321 KbMtpt
Voltar para o início
Tradução automáticaTradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 169321  (http://support.microsoft.com/kb/169321/en-us/ )
Voltar para o início