INFORMAZIONI: Attivazione di server COM e stazioni Windows NT

Traduzione articoli Traduzione articoli
Identificativo articolo: 169321 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

Quando un client richiede un oggetto di classe per una classe registrato, COM restituisce un oggetto di classe esistente oppure avvia un processo che viene registrato come contenente l'oggetto classe richiesta. Il processo di ottenere un riferimento all'oggetto classe per un richiedente client (indipendentemente dal fatto che risultati nel processo di creazione o "avvio") è in è di denominato "attivazione".

In determinate condizioni, COM potrebbe avviare un nuovo processo server anche quando un oggetto di classe esistente è in esecuzione e che è stato registrato come utilizzo di più. Inoltre, quando COM crea un nuovo processo di tale processo può essere avviato in un nuovo ambiente di protezione noto come "stazione finestra" anziché la condivisione di una stazione finestra esistente, ad esempio la stazione finestra interattiva. (Per ulteriori informazioni su postazioni, cercare nella documentazione SDK per tale frase.)

La comprensione di algoritmi di COM per la creazione di nuovi processi e postazioni durante una richiesta di attivazione è importante per diversi motivi. Innanzitutto, COM possono creare più istanze di processo di un oggetto classe di utilizzo di più causa di problemi di protezione. In secondo luogo, "utilizzo singolo" server verrà avviato sempre in processi distinti, ma può essere o non può essere avviati in postazioni separato. Questa differenza potrebbe manifestarsi al codice dell'applicazione in alcuni casi particolari, ad esempio quando due server COM tenta di comunicare tramite messaggi di finestra o funzionalità di comunicazione protetta, ad esempio COM o RPC. In terzo luogo, poiché il numero di postazioni che contemporaneamente possono essere creati in Windows NT è limitato, è importante sapere quando il server COM Ottiene una nuova stazione finestra.

In questo articolo viene esaminato l'attivazione di diversi scenari e viene spiegato quando vengono creati nuovi processi e postazioni.

Informazioni

Quando crea un nuovo processo server COM o si assegna una nuova stazione finestra a un nuovo processo server dipende da diversi fattori:
  1. L'identità di protezione in cui è impostata la classe COM per l'avvio. L'identità di una classe può essere impostata mediante lo strumento DCOMCNFG e viene specificato per il valore nella chiave AppID per la classe denominato RunAs.
  2. Utilizzo singolo e registrazione di utilizzo di più dagli oggetti di classe.
  3. Identifier(SID) di protezione del processo client (questo è il valore numerico che rappresenta una particolare utente account/identità/identità di protezione in un ambiente Windows NT).
  4. L'identificatore di accesso (LUID) della client processo (per ogni accesso univoco a un computer che eseguono Windows NT viene generato un nuovo identificatore di accesso. Potrebbe essere l'accesso a un utente di digitare un nome utente e una password al prompt di accesso NT o tramite una chiamata all'API LogonUser win32.)
  5. Attivazione remota e locale.
  6. La stazione finestra del client.

Utilizzo di più classi

Una classe di utilizzo di più è una classe che è registrata con COM (tramite API CoRegisterClassObject()) che specifica il flag REGCLS_MULTIPLEUSE. Per una classe COM utilizza in genere la stessa istanza di processo del server per le richieste di attivazione dei client. Tuttavia, per le classi sono configurate per l'esecuzione con la protezione degli utenti avvio e in alcuni casi altri, COM avvia una nuova istanza del processo server per le richieste di attivazione del servizio. Quando pertanto viene avviata una nuova istanza del processo del server, è possibile che il processo del server ottiene anche una nuova stazione finestra. Esamineremo i vari scenari riportati di seguito, ma prima verranno illustrati brevemente perché COM avvia nuovi processi contenente oggetti di classe richiesto quando un'istanza dell'oggetto di classe è già registrata come classe "utilizzo di più".

Primo, quando una classe COM (più precisamente, quando un AppID associato una classe COM) è registrato con il sistema deve essere eseguito come "l'utente di avvio", l'amministratore di sistema ha impostato un determinato criterio di protezione relativamente a tale classe. Il criterio è che un attivatore deve essere assegnato un oggetto della classe all'interno di un processo è in esecuzione nello stesso contesto di protezione il codice di attivazione.

Questo criterio di protezione può entrare in conflitto con il comportamento definita dal server di disporre di un solo oggetto factory di classe per tutte le richieste di attivazione (come indicato da REGCLS_MULTIPLEUSE). COM assegna una priorità i criteri di protezione sul comportamento dell'applicazione. Utilizzo di più server registrato per l'esecuzione come "l'utente di avvio" di conseguenza, non funzioneranno in base alle normali regole di utilizzo di più. Verrà avviato un nuovo processo per ogni identità di protezione attivazione.

In secondo luogo, se un processo non viene avviato da COM in esecuzione in un contesto di protezione diverso da quello specificato per il CLSID specificato registra tale CLSID, tale registrazione verrà fail(CoRegisterClassObject will return an error code CO_E_WRONG_SERVER_IDENTITY in this case). E, se una richiesta di attivazione in un secondo momento arriva un nuovo processo verrà avviato da COM con il contesto di protezione specificato per il CLSID/AppID. Codice chiamata CoRegisterClassObject() (operazione non protetta) non considerato attendibile da COM, è possibile attendibile solo l'impostazione del Registro di sistema (Registro di sistema è un database protetto) per determinare quale oggetto di classe da utilizzare e come eseguirlo. Questo comportamento impedisce illecita a livello di computer lo spoofing di oggetti di classe da utenti non autorizzati.

Con quello presente, viene ora restituito al problema di quando vengono creati nuovi processi e postazioni quando utilizzo di più server vengono avviati da COM. Si noti che il LUID del client non ha importanza in alcun modo nel caso di utilizzo di più classe.
  1. Identità di protezione "Utente interattivo". Nel caso in cui è configurato il AppID della classe COM utilizzo di più per l'esecuzione come identità "Utente interattivo", il primo processo del server e la classe object verrà utilizzati da COM per tutte le richieste successive l'attivazione. Questa istanza del server avrà la stazione finestra interattiva, se presente (se nessun utente è connesso localmente quindi tutte le richieste di attivazione avranno esito negativo). Come indicato in precedenza, se un processo non è avviata da COM e non è in esecuzione nella postazione interattiva registra il CLSID, tale registrazione non riuscirà. E, se una richiesta di attivazione arriva in un secondo momento, un nuovo processo verrà avviato con il contesto di protezione dell'utente interattivo. Questo comportamento impedisce lo spoofing illeciti di oggetti di classe. Poiché nessun processo server aggiuntivi viene avviato mai da COM, la domanda di nuovo postazioni è opinabile. Il SID del client, il LUID o se è locale o remoto non ha importanza in questo caso.
  2. Identità di protezione "Utente". Analogamente, se una classe COM di utilizzo di più AppID è configurato per eseguire come "utente" (un ID di protezione predefiniti), il primo server di elaborare e l'oggetto di classe verrà utilizzata da COM per tutte le richieste successive l'attivazione. Questa istanza del prima server avranno la propria postazione creato come parte della prima creazione del processo. Poiché nessun processo server aggiuntivi viene avviato mai da COM, la domanda di ulteriori postazioni è opinabile. Il SID del client, il LUID o se è locale o remoto non ha importanza in questo caso. Si noti che verrà essere creata una nuova stazione finestra quando si avvia la prima istanza di una classe o AppID configurato per l'esecuzione come "L'utente", anche se lo stesso utente attualmente connesso nella winstation interattivo. COM utilizza mai la winstation interattivo per avviare un server configurato per eseguire come "L'utente", poiché potrebbe comportare un comportamento diverso per la classe in base al numero di non correlato dell'identità dell'utente attualmente connesso. Come indicato in precedenza, se un processo non è avviata da COM e non in esecuzione nell'account specificato in "L'utente" tenta di registrare il CLSID che registrazione avrà esito negativo e se una richiesta di attivazione arriva in seguito un nuovo processo verrà avviati nel conto "L'utente". Questo comportamento impedisce lo spoofing illeciti di oggetti di classe. D'altra parte, se il processo è registrato per un CLSID/APPID specificato è configurato per eseguire come "L'utente", in base viene creato l'account utente appropriato alcuni agente diverso da COM nel (ad esempio, viene eseguito dall'utente interattivo quando l'utente interattivo è lo stesso utente come "L'utente" o tramite CreateProcess() verrà avviata da un servizio in esecuzione nel contesto di protezione stesso come "utente"), e registra quindi gli oggetti di classe REGCLS_MULTIPLEUSE COM utilizzerà l'oggetto di classe in esecuzione esistente per soddisfare successive richieste di attivazione in ingresso da qualsiasi client.
  3. "Avvio utente" identità di protezione. In questo caso, AppID della classe è impostata per l'avvio in idenitity il "Avvio di User" (questo è noto anche come una classe "Attiva come Activator"). client a. locale. Prima si consideri il caso di computer locale. Esistono due regole: 1. ogni client diversi attivazione SID causerà COM avviare una nuova istanza del processo server anche nella postazione stesso. 2. Anche per la corrispondenza SID (ad esempio il caso in cui lo stesso utente è connesso più di una volta a un singolo computer NT), ogni postazione diversi client locale causerà COM avviare una nuova istanza del processo del server. In altre parole, avvio server di utilizzo di più identità utente non sono condivisi tra le postazioni. Tutti i processi client con lo stesso SID e postazioni stesso condividerà un processo singolo server nella postazione stesso. Poiché il server condivide la stazione finestra del client non vengono creata nessuna nuova stazione finestra. Si supponga ad esempio, che si è in modo interattivo connessi come a_domain\a_user. È eseguire più istanze del client, ognuno dei quali verrà connettersi all'istanza stessa del server (che ha la stazione finestra interattiva). A questo punto è possibile ad esempio è un client, che è un servizio, che è impostato per l'avvio avvia in a_domain\a_user. Questo servizio verrà avviata una nuova istanza del server COM. Ciò accade perché COM causerà una nuova istanza del server per essere avviata poiché il processo del servizio dispone di una postazione diversa dalla stazione finestra interattiva--anche se l'identità del processo service(client) è lo stesso l'identità del processo server in esecuzione (a_domain\a_user). Si noti tuttavia che nessuna nuova stazione finestra viene creato per il processo del server COM. Il server ancora erediterà la stazione finestra del servizio. Se il servizio è impostato per avviare in LocalSystem e interagire con il desktop (fare riferimento a casella di controllo "Consenti Service per interagire con desktop" il servizio applet nel Pannello di controllo), quindi nella stazione finestra interattiva o winsta0 verrà eseguito il servizio. In questo caso COM ancora avvii una nuova istanza del server (SID del client che è LocalSystem in questo caso è diverso da quello del SID del server, ovvero a_domain\a_user) nella postazione interattiva. b. remoto client. In caso di attivazione remota, COM ignora la stazione finestra del client, poiché il client è remoto, a differenza del caso locale precedente. La regola di qui è che ogni nuovo client SID causerà una nuova istanza del processo server di essere avviato e che ogni nuovo processo server otterrà una nuova stazione finestra. Attivazione successive richieste da client remoti con lo stesso che SID riutilizzerà che esistenti registrati oggetto di classe, nonché la stazione di processo e la finestra. Ad esempio, si supponga che si è connessi come a_domain\a_user su 10 computer diversi. I client da tutti i computer si connetteranno alla stessa istanza del server sul computer server. Un client da un computer a_domain\b_user avvierà una nuova istanza di server e una nuova stazione finestra. I chiamanti remoti con lo stesso SID come utente locale che ha avviato il server COM registrato per il CLSID richiesto riutilizza l'oggetto di classe esistente. Tuttavia, l'ordine in cui è avviato il server COM è in questo caso importante. Se il server viene avviato dal client locale prima, il client remoto con lo stesso SID si connetterà a questo server. D'altra parte, se il server viene avviato dal client remoto prima, quindi un client locale con lo stesso SID verrà avviato una nuova istanza del server. Questo torna alle regole di stazione finestra menzionate in precedenza. Per i client locali, deve corrispondere la stazione finestra del client e il server per client remoti che viene ignorata la stazione finestra del client. Ad esempio, se a_domain\a_user client locale viene innanzitutto avviato il server, client remoto a_domain\a_user si connetterà al server. Al contrario, se il client remoto a_domain\a_user viene innanzitutto avviato il server, quindi a_domain\a_user client locale verrà avviata una nuova istanza di server e una nuova stazione finestra. Il LUID del client non ha importanza in questo caso.
  4. Server COM basati su servizi. Un COM classe o AppID compresso in un servizio Win32 è pratico necessità un server di utilizzo di più poiché servizi possono essere avviate una sola volta. In questo caso, alla prima richiesta di attivazione viene avviato un nuovo processo nella propria postazione. Esistono due eccezioni a questo: a. Se il servizio è impostato per l'avvio con l'account LocalSystem, erediterà una stazione finestra predefiniti di sistema. b. Se il servizio è impostato per l'avvio con l'account LocalSystem e può interagire con il desktop, erediterà la stazione finestra interattiva o winsta0. Tutte le richieste successive l'attivazione, locale o remoto, vengono gestite dall'oggetto di classe del servizio. Come indicato sopra, se un processo non viene avviato da COM e non in esecuzione come il servizio specificato registra il CLSID, tale registrazione riuscirà e se una richiesta di attivazione arriva in un secondo momento il servizio registrato verrà avviati. Questo comportamento impedisce lo spoofing illeciti di oggetti di classe.

Classi di utilizzo singolo

Nota: Le classi di utilizzo singolo evitare quanto possibile. Registrazione utilizzo singolo è un'impostazione legacy ed è progettata per supportare le applicazioni COM precedente e per facilitare il porting delle applicazioni legacy non COM com. È consigliabile che nuove classi essere progettato per supportare la registrazione oggetto di classe di utilizzo di più. Questo è particolarmente vero nel caso di server con identità "L'utente", in cui le classi di utilizzo singolo causano effetto di classi multiuso invertiti. Processo e la nuova stazione finestra per l'attivazione consente di creare un nuovo server e di come è illustrato di seguito, questo può causare problemi di risorse in Windows NT.

Una classe di utilizzo singolo è quello che viene registrato con COM (tramite l'API CoRegisterClassObject()) che specifica il flag REGCLS_SINGLEUSE. Per una classe COM verrà sempre avviato una nuova istanza del processo del server della classe per ogni richiesta di attivazione da qualsiasi client (locale o remoto). Ai fini di questo articolo, è la domanda rimanente: quando il server verrà visualizzato anche una nuova stazione finestra?
  1. Identità di protezione "Utente interattivo". Richiedere il caso in cui la classe di utilizzo singolo è impostata tramite l'AppID per avviare l'identità di "Utente interattivo". In questo caso, ogni nuova istanza del processo del server condividerà sempre la stazione finestra interattiva, se presente (se nessun utente è connesso localmente quindi tutte le richieste di attivazione avranno esito negativo). Nessuna nuova stazione finestra verrà creato da COM.
  2. Identità di protezione "Utente". Ora consideri il caso in cui AppId della classe COM di utilizzo singolo è impostato su eseguiti con l'identità "L'utente". In questo caso, la regola è molto semplice. Ogni nuova attivazione di client avvia un nuovo processo in una nuova stazione finestra. Questo vale indipendentemente se l'utente specificato come "L'utente" è connesso alla stazione finestra interattiva al momento delle richieste di attivazione.
  3. "Avvio utente" identità di protezione. client a. locale. Nello scenario di attivazione di computer locale, il processo del server verrà sempre visualizzata la stazione finestra del client. Nessuna nuova stazione finestra mai vengono creata. Ad esempio, si supponga che si è in modo interattivo connessi come a_domain\a_user e di eseguire più istanze del programma client. Ogni nuova istanza del server di risultante verrà visualizzata la stazione finestra interattiva. Si supponga ora che il client di un servizio in esecuzione con l'account sistema locale. Il server COM in questo caso condivideranno la stazione finestra del processo del servizio. b. remoto client. Nel caso l'attivazione remota, COM ignora la stazione finestra del client, poiché il client è remoto. Come sempre, verrà avviato un nuovo processo istanza server per ogni l'attivazione remota. Le regole sono: 1. per ogni nuovo client remoto SID, una nuova stazione finestra verrà creata per il processo del server. 2. Per ogni nuovo client remoto LUID, viene creata una nuova stazione finestra per il processo del server. 3. Tutti i client remoti con la stessa coppia SID/LUID verranno creato un server che condivide la stazione finestra stessa. Ad esempio, si è connessi al computer client remoto come a_domain\a_user. Il client avvia il server remoto verrà visualizzata una nuova stazione finestra. A questo punto, se una seconda istanza di applicazione client viene avviato da a_domain\a_user dalla stessa macchina client che a sua volta avvia una nuova copia del server sul computer remoto, questo server sarà condivise da postazione del server originale. Ora si supponga che si accede a un altro computer nuovamente come a_domain\a_user e da cui eseguire il client. L'istanza del server corrispondente avrà una nuova stazione finestra. Questo dimostra che anche se il SID del client sono uguali, poiché dal secondo client dispone di un LUID diverso, il processo server otterrà una nuova stazione finestra.
  4. Server COM basati su servizi. Le classi di utilizzo singolo non devono essere implementate come servizi di Windows NT. Non ha senso, perché non è possibile eseguire più istanze di un processo di servizio di Windows NT.

Tabella Summarizing scenari

---------------------------------------------------------------------------
       |                      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   |
				
---------------------------------------------------------------------------

Stazioni di finestra e risorse di Windows

In questa sezione esamineremo le implicazioni di creazione nuovo postazioni in Windows NT e come che deve influiscono sulla configurazione del server COM. Come si vedrà, vi è un limite al numero di postazioni che possono essere creati su un computer Windows NT. Quando viene superato tale limite, Windows NT avrà esito negativo un tentativo da COM di avviare una nuova istanza del processo del server. In genere, viene visualizzato un messaggio di errore simile a quello riportato di seguito:
Inizializzazione della libreria a collegamento dinamico
d:\winnt\system32\kernel32.dll non riuscita. Il processo è
chiusura in modo anomalo.
In Windows NT, ogni stazione finestra dispone di almeno un desktop associato. Windows utilizza un heap di memoria speciale per tutte le applicazioni di windows in esecuzione su un computer desktop. Per impostazione predefinita, ogni heap del desktop consuma 3 MB di memoria. Windows ha un limite non configurabile di 48 MB per la creazione di heap del desktop. Questo significa che il numero massimo di stazioni di finestra che può essere creato su un computer Windows NT è 16 (probabilmente meno poiché una stazione finestra può contenere più di un desktop). Per aumentare questo numero, è possibile ridurre la dimensione del heap del desktop modificando il Registro di sistema utilizzo dell'editor del registro.

Avviso: Utilizzo non corretto scopo può causare gravi a livello di sistema problemi che comportano la reinstallazione del sistema operativo per correggerli. Microsoft non è in grado di garantire che qualsiasi problema derivante dall'utilizzo non corretto dell'editor del Registro di configurazione possa essere risolto. Utilizzare questo strumento avviene pertanto a rischio esclusivo dell'utente.

Il valore denominato che è necessario modificare verrà visualizzato nella seguente chiave:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
   Manager\SubSystems
				
è necessario modificare il valore denominato "Windows". Si tratta di una stringa REG_SZ. Modificare la stringa e cercare "Shared sezione = 1024, 3072". Modificare qui per visualizzare "Shared sezione = 1024, 3072, 512". È necessario riavviare il computer per rendere effettive le modifiche. Apportando questa modifica, si specificano 3 MB (impostazione predefinita) di dimensione heap per desktop della stazione finestra interattiva e 512 KB per tutti i non - interattivo desktop (il primo parametro è obsoleto ma non deve essere modificato). Questa modifica non consentirà la creazione di circa inferiore a 48 MB o 512 KB o 96 postazioni.

Nota: Una stazione finestra può contenere più desktop in esso contenuti. Nella spiegazione dei server di "Avvio dell'utente" sopra citata ovunque la stazione finestra del processo client locale, deve essere considerato come un modulo più breve per "stazione finestra e desktop". "Avvio di User" impostazione realmente è destinato a server con supporto legacy non DCOM e deve essere utilizzato raramente. Tali server legacy prevedono l'esecuzione nel proprio desktop. Di conseguenza, per "Avvio dell'utente" MULTIPLEUSE server, ogni processo di client in un desktop diverso all'interno della stazione finestra stessa causa un nuovo processo server deve essere avviato in tale finestra stazione/desktop. Per "Avvio dell'utente" SINGLEUSE server, anche in questo caso, il server eredita windows stazione/desktop del processo del client.

In Windows NT 4.0 Service Pack 4.0 COM tenta di riutilizzare postazioni. Prima per, se un server è impostato su RunAs un utente specifico e se vengono avviate più istanze del processo del server, ciascun processo di ottenere la propria postazione. Questo comporta la stazione finestra limitazioni descrivono sopra. In SP4 COM tenterà di creare tutti i server RunAs (vale a dire, non "Attiva come Activator" o "Avvio dell'utente") impostati per essere eseguito con la stessa identità (o utente token) nella postazione stesso.

Questo elimina la necessità per regolare la dimensione dell'heap del desktop in questi casi in cui più processi server è eseguito con lo stesso token. Se, nella configurazione di tutti i server sono impostati su RunAs, nello stesso utente, o più istanze dello stesso processo server di RunAs eseguire, quindi è necessario non ridurre heapsize del desk top come indicato nell'articolo della. È consigliabile lasciare il valore predefinito (3 M) in questo caso. Ciò è dovuto al fatto che, se si riduce l'heap del desktop, quindi il sistema possibile creare ulteriori stazioni finestra/desktop; tuttavia, il numero di processi eseguibili in un stazione finestra/desktop diventare progressivamente più piccolo.

D'altra parte, nella configurazione, se sono presenti più server in esecuzione con token diverso, quindi si dovranno affrontare le limitazioni di stazione finestra. In questo caso, è necessario seguire i suggerimenti nell'articolo per ridurre la dimensione dell'heap del desktop.

Riferimenti

Per ulteriori informazioni sul problema heap del desktop, vedere il seguente articolo della Microsoft Knowledge Base riportato di seguito:

142676Come correggere gli errori più comuni del file User32.dll

Proprietà

Identificativo articolo: 169321 - Ultima modifica: lunedì 11 luglio 2005 - Revisione: 2.5
Le informazioni in questo articolo si applicano a:
  • Microsoft OLE 4.0 alle seguenti piattaforme
    • Microsoft Platform Software Development Kit-edizione gennaio 2000
Chiavi: 
kbmt kbapi kbdcom kbenv kbinfo kbinterop kbkernbase kbprogramming kbusage KB169321 KbMtit
Traduzione automatica articoli
Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 169321
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com