WSCGetApplicationCategory, fonction (ws2spi.h)
Syntaxe
int WSCGetApplicationCategory(
[in] LPCWSTR Path,
[in] DWORD PathLength,
[in] LPCWSTR Extra,
[in] DWORD ExtraLength,
[out] DWORD *pPermittedLspCategories,
[out] LPINT lpErrno
);
Paramètres
[in] Path
Pointeur vers une chaîne Unicode qui contient le chemin de chargement de l’image exécutable de l’application. Cette chaîne observe les règles habituelles pour la résolution de chemin d’accès et peut contenir des chaînes d’environnement incorporées (telles que %SystemRoot%).
[in] PathLength
Longueur, en caractères, du paramètre path . Cette longueur n’inclut pas la fin NULL .
[in] Extra
Pointeur vers une chaîne Unicode qui représente les arguments de ligne de commande utilisés lors du démarrage de l’application spécifiée dans le paramètre Path. Le paramètre Extra est utilisé pour faire la distinction entre plusieurs instances distinctes d’une application lorsqu’elle est lancée avec une ligne de commande cohérente. Il s’agit de prendre en charge différentes catégorisations d’applications pour différentes instances de Svchost.exe ou de Rundll32.exe. Si seul le paramètre Path est requis et qu’aucun argument de ligne de commande n’est nécessaire pour faire la distinction entre les instances d’une application, le paramètre supplémentaire doit être défini sur NULL.
[in] ExtraLength
Longueur, en caractères, du paramètre supplémentaire. Cette longueur n’inclut pas la fin NULL .
[out] pPermittedLspCategories
Pointeur vers une valeur DWORD des catégories LSP autorisées qui sont autorisées pour toutes les instances de cette application. L’application est identifiée par la combinaison des valeurs des paramètres chemin d’accès et paramètres de supplémentaires.
[out] lpErrno
Pointeur vers le code d’erreur si la fonction échoue.
Valeur de retour
Si aucune erreur ne se produit, WSCGetApplicationCategory retourne ERROR_SUCCESS (zéro). Sinon, elle retourne SOCKET_ERRORet un code d’erreur spécifique est retourné dans le paramètre lpErrno.
Code d’erreur | Signification |
---|---|
Un ou plusieurs arguments ne se trouve pas dans une partie valide de l’espace d’adressage utilisateur. | |
Un ou plusieurs arguments ne sont pas valides. | |
Impossible de trouver le service en fonction des paramètres chemin d’accès et paramètres de supplémentaires.
L’erreur peut également être retournée si l’application que vous interrogez n’existe pas dans le Registre. Dans ce cas, l’erreur indique que l’application n’est pas catégorisée actuellement. |
|
Une erreur non récupérable s’est produite. Cette erreur est retournée dans plusieurs conditions, notamment : l’utilisateur ne dispose pas des privilèges d’administration nécessaires pour accéder au registre Winsock, ou une défaillance s’est produite lors de l’ouverture d’une entrée de catalogue Winsock ou d’une entrée d’ID d’application. |
Remarques
WSCGetApplicationCategory est utilisé pour récupérer les indicateurs de catégorie LSP associés à une instance d’application. Les applications peuvent déterminer quels comportements LSP sont acceptables dans le contexte de l’application. Par conséquent, en spécifiant des catégories LSP autorisées, une application peut autoriser uniquement les fournisseurs de services en couches qui implémentent des comportements acceptables à charger.
Le paramètre supplémentaire est requis lorsque la ligne de commande est utilisée pour faire la distinction entre différentes instances d’une application ou d’un service hébergé dans le même exécutable. Chaque instance peut avoir des besoins de catégorisation d’application différents. Svchost.exe et Rundll32.exe sont deux exemples où la ligne de commande est nécessaire pour différencier les différentes instances de processus. Pour SvcHost.exe, le commutateur -k <svcinstance> définit l’instance de processus.
Pour les services, l’utilisation du nom du service n’est pas suffisante, car le catalogue Winsock est global à un processus donné et un processus peut héberger plusieurs services.
Les sockets de fenêtre déterminent l’identité d’une application et récupère les catégories LSP autorisées pendant le premier appel à WSAStartup. Il s’agit de l’ensemble des catégories LSP autorisées pendant la durée de l’instance d’application. Les modifications suivantes apportées aux catégories LSP autorisées pour une identité d’application donnée ne seront pas récupérées tant que l’instance suivante de l’application n’est pas récupérée. Les catégories LSP autorisées ne sont pas mutables pendant la durée de vie de l’instance d’application.
Winsock 2 prend en charge les protocoles en couches. Un protocole en couches est un protocole qui implémente uniquement des fonctions de communication de niveau supérieur, tout en s’appuyant sur une pile de transport sous-jacente pour l’échange réel de données avec un point de terminaison distant. Un exemple de protocole en couches ou de fournisseur de services en couches serait une couche de sécurité qui ajoute le protocole au processus d’établissement de connexion afin d’effectuer l’authentification et d’établir un schéma de chiffrement mutuellement convenu. Un tel protocole de sécurité nécessite généralement les services d’un protocole de transport fiable sous-jacent tel que TCP ou SPX. Le terme protocole de base fait référence à un protocole tel que TCP ou SPX capable d’effectuer des communications de données avec un point de terminaison distant. Le terme protocole en couches est utilisé pour décrire un protocole qui ne peut pas être autonome.
Pendant l’initialisation du LSP, le fournisseur de services cloud doit fournir des pointeurs vers un certain nombre de fonctions SPI Winsock. Ces fonctions sont appelées pendant le traitement normal par la couche directement au-dessus du LSP (soit un autre LSP, soit Ws2_32.DLL).
Un fournisseur de services cloud qui implémente un système de fichiers installable (IFS) peut choisir de manière sélective de fournir des pointeurs vers des fonctions implémentées par elle-même ou de renvoyer les pointeurs fournis par la couche directement sous le fournisseur de services cloud. Les fournisseurs LSP non-IFS, car ils fournissent leurs propres handles, doivent implémenter toutes les fonctions SPI Winsock. Cela est dû au fait que chaque SPI exige que le fournisseur de services cloud mappe tous les handles de socket qu’il a créés au handle de socket du fournisseur inférieur (soit un autre LSP, soit le protocole de base).
Toutefois, tous les fournisseurs de services cloud effectuent leur travail spécifique en effectuant un traitement supplémentaire uniquement sur un sous-ensemble des fonctions SPI Winsock.
Il est possible de définir des catégories LSP basées sur le sous-ensemble de fonctions SPI qu’un fournisseur de services cloud implémente et la nature du traitement supplémentaire effectué pour chacune de ces fonctions.
En classant les fournisseurs de services cloud, ainsi que en classant les applications qui utilisent des sockets Winsock, il est possible de déterminer de manière sélective si un fournisseur de services cloud doit être impliqué dans un processus donné au moment de l’exécution.
Sur Windows Vista et versions ultérieures, un fournisseur de services partagés peut être classé en fonction de la façon dont il interagit avec les appels et données Windows Sockets. Une catégorie LSP est un groupe identifiable de comportements sur un sous-ensemble de fonctions WINSock SPI. Par exemple, un filtre de contenu HTTP est classé comme inspecteur de données (catégorie LSP_INSPECTOR). La catégorie LSP_INSPECTOR inspecte (mais ne modifie pas) les paramètres des fonctions SPI de transfert de données. Une application peut interroger la catégorie d’un LSP et choisir de ne pas charger le LSP en fonction de la catégorie LSP et de l’ensemble de catégories LSP autorisées de l’application.
Le tableau suivant répertorie les catégories dans laquelle un LSP peut être classé.
Catégorie LSP | Description |
---|---|
**LSP_CRYPTO_COMPRESS** | Le LSP est un fournisseur de chiffrement ou de compression de données. |
**LSP_FIREWALL** | Le LSP est un fournisseur de pare-feu. |
**LSP_LOCAL_CACHE** | Le LSP est un fournisseur de cache local. |
**LSP_INBOUND_MODIFY** | Le LSP modifie les données entrantes. |
**LSP_INSPECTOR** | Le LSP inspecte ou filtre les données. |
**LSP_OUTBOUND_MODIFY** | Le LSP modifie les données sortantes. |
**LSP_PROXY** | Le LSP agit en tant que proxy et redirige les paquets. |
**LSP_REDIRECTOR** | Le LSP est un redirecteur réseau. |
**LSP_SYSTEM** | Le LSP est acceptable pour une utilisation dans les services et les processus système. |
Un LSP peut appartenir à plusieurs catégories. Par exemple, un LSP de pare-feu/sécurité peut appartenir aux catégories inspecteur (LSP_INSPECTOR) et pare-feu (LSP_FIREWALL).
Si un LSP n’a pas d’ensemble de catégories, il est considéré comme étant dans la catégorie All Other. Cette catégorie LSP ne sera pas chargée dans les services ou les processus système (par exemple, lsass, winlogon et de nombreux processus svchost).
Exigences
Exigence | Valeur |
---|---|
client minimum pris en charge | Windows Vista [applications de bureau uniquement] |
serveur minimum pris en charge | Windows Server 2008 [applications de bureau uniquement] |
plateforme cible | Windows |
d’en-tête | ws2spi.h |
bibliothèque | Ws2_32.lib |
DLL | Ws2_32.dll |
Voir aussi
catégorisation des fournisseurs de services et des applications en couches