y'a t'il un moyen de supprimer ces message
"vous devez avoir l'autorisation........"
"continué" "confirmé"
parfois uniquement pour renommer un dossier ?
la valeur "enabled" n'est pas valable pour "netsh int tcp set global autotuninglevel="
Exact. L'aide de NETSH donne d'ailleurs ces valeurs possibles :
- disabled : définir la fenêtre de réception à sa valeur par défaut.
- highlyrestricted : autoriser l'agrandissement de la fenêtre de réception au-delà de sa valeur par défaut, en faisant preuve d'une extrême prudence.
- restricted : autoriser l'agrandissement de la fenêtre de réception au-delà de sa valeur par défaut, en limitant l'agrandissement dans certains scénarios.
- normal : autoriser l'agrandissement de la fenêtre de réception dans presque tous les scénarios.
- experimental : autoriser l'agrandissement de la fenêtre de réception dans les scénarios extrêmes. AVERTISSEMENT : cette option pouvant avoir un impact considérable sur les performances dans des scénarios courants, doit être utilisée uniquement à titre expérimental.
à noter que, perso, j'ai obtenu des résultats très intéressants avec "experimental".
@-salutations
Michel Claveau
Bonjour !
la valeur "enabled" n'est pas valable pour "netsh int tcp set global
autotuninglevel="
Exact. L'aide de NETSH donne d'ailleurs ces valeurs possibles :
- disabled : définir la fenêtre de réception à sa valeur par défaut.
- highlyrestricted : autoriser l'agrandissement de la fenêtre de
réception au-delà de sa valeur par défaut, en faisant preuve d'une
extrême prudence.
- restricted : autoriser l'agrandissement de la fenêtre de réception
au-delà de sa valeur par défaut, en limitant l'agrandissement dans
certains scénarios.
- normal : autoriser l'agrandissement de la fenêtre de réception
dans presque tous les scénarios.
- experimental : autoriser l'agrandissement de la fenêtre de
réception dans les scénarios extrêmes. AVERTISSEMENT : cette option
pouvant avoir un impact considérable sur les performances dans des
scénarios courants, doit être utilisée uniquement à titre expérimental.
à noter que, perso, j'ai obtenu des résultats très intéressants avec
"experimental".
la valeur "enabled" n'est pas valable pour "netsh int tcp set global autotuninglevel="
Exact. L'aide de NETSH donne d'ailleurs ces valeurs possibles :
- disabled : définir la fenêtre de réception à sa valeur par défaut.
- highlyrestricted : autoriser l'agrandissement de la fenêtre de réception au-delà de sa valeur par défaut, en faisant preuve d'une extrême prudence.
- restricted : autoriser l'agrandissement de la fenêtre de réception au-delà de sa valeur par défaut, en limitant l'agrandissement dans certains scénarios.
- normal : autoriser l'agrandissement de la fenêtre de réception dans presque tous les scénarios.
- experimental : autoriser l'agrandissement de la fenêtre de réception dans les scénarios extrêmes. AVERTISSEMENT : cette option pouvant avoir un impact considérable sur les performances dans des scénarios courants, doit être utilisée uniquement à titre expérimental.
à noter que, perso, j'ai obtenu des résultats très intéressants avec "experimental".
@-salutations
Michel Claveau
P
Merci à vous deux, j'ai réparé mon erreur
-- Bien cordialement, Georges Aide toi le ciel t'aidera : http://papynet.mvps.org/Forums.htm Pour prendre contact : http://minilien.com/?1xjHkMIEp0 Pages XP : http://papynet.mvps.org/XP/XP.htm Vista : http://papynet.mvps.org/Vista/Vista.htm
Merci à vous deux, j'ai réparé mon erreur
--
Bien cordialement, Georges
Aide toi le ciel t'aidera : http://papynet.mvps.org/Forums.htm
Pour prendre contact : http://minilien.com/?1xjHkMIEp0
Pages XP : http://papynet.mvps.org/XP/XP.htm Vista :
http://papynet.mvps.org/Vista/Vista.htm
-- Bien cordialement, Georges Aide toi le ciel t'aidera : http://papynet.mvps.org/Forums.htm Pour prendre contact : http://minilien.com/?1xjHkMIEp0 Pages XP : http://papynet.mvps.org/XP/XP.htm Vista : http://papynet.mvps.org/Vista/Vista.htm
Olivier
Bonjour Michel,
Merci pour les fonctions/constantes. Mais, il manque (notamment) la racine du C: (rien de prévu pour ce cas...)
Hmmm, c: ? à moins que %windir% ou que le csidl WINDOWS ne permettent de résoudre ce cas ? (Note: On ne devrait pas avoir à s'en servir...)
- difficile de les utiliser, pour un logiciel acheté "fini".
Oui, mais... C'est ce pour quoi la "virtualisation" effective avec l'uac activé est censée être faite...
- cela nécessiterait de le recompiler les logiciels, et, de préférence avec les outils MS.
Oui, afin de respecter les règles définies par l'OS si ce n'était déjà le cas. et Non: n'importe quel outil de développement digne de ce nom permet d'accèder à ces fonctions et/ou de développer une librairie spécifique qui se charge au run-time. La modularité est faite pour ça.
Pour les développeurs, il sera plus simple de choisir d'autres répertoires/emplacements. En plus, ils seront indépendant des constantes MS, et de leurs évolutions aléatoires.
Ces constantes permettent de s'affranchir du problème, si MS change les règles, les valeurs retournées par ces fonctions _sont_censées_ être les bonnes. D'autre part, un choix ignorant les contraintes liées à l'OS peut se révèler calamiteux.
Ceci dit, c'est l'éternel débat... doit-on, en tant que développeur, respecter les règles fixées par l'OS, ou non :-)
Pour ma part, je les respecte (c'est l'option par défaut) et fais tout ce que je peux pour pouvoir proposer une alternative que l'utilisateur final pourra choisir en _toute_connaissance_de_cause_ et s'il le désire, mais _rien_à_ce_niveau_ ne devrait être prédéterminé. Bien sûr cela a un coût, non négligeable... et les programmeurs préfèrent s'attacher aux fonctionnalités de leurs logiciels, plutôt qu'à l'environnement dans lequel ils travaillent.
Finalement, la désactivation de l'UAC, c'est encore plus simple...
Pour un programmeur qui ne _veut_ pas jouer le jeu de l'OS, Oui... Mais cela peut aussi provoquer d'autres problèmes que ceux évoqués ici (mais déjà évoqués sur d'autres fils de discussion). Il suffit de voir le nombre de messages concernant les difficultés d'installation d'un programme et/ou des "incompatibilités" ou "plantages" communément admis dans ces forums.
Mais bon... ça n'est que mon avis... :-)
@Bientôt -- Olivier
Bonjour Michel,
Merci pour les fonctions/constantes. Mais, il manque (notamment) la racine
du C: (rien de prévu pour ce cas...)
Hmmm, c: ? à moins que %windir% ou que le csidl WINDOWS ne permettent de
résoudre ce cas ? (Note: On ne devrait pas avoir à s'en servir...)
- difficile de les utiliser, pour un logiciel acheté "fini".
Oui, mais... C'est ce pour quoi la "virtualisation" effective avec l'uac
activé est censée être faite...
- cela nécessiterait de le recompiler les logiciels, et, de préférence
avec les outils MS.
Oui, afin de respecter les règles définies par l'OS si ce n'était déjà le
cas. et Non: n'importe quel outil de développement digne de ce nom permet
d'accèder à ces fonctions et/ou de développer une librairie spécifique qui
se charge au run-time. La modularité est faite pour ça.
Pour les développeurs, il sera plus simple de choisir d'autres
répertoires/emplacements. En plus, ils seront indépendant des constantes
MS, et de leurs évolutions aléatoires.
Ces constantes permettent de s'affranchir du problème, si MS change les
règles, les valeurs retournées par ces fonctions _sont_censées_ être les
bonnes.
D'autre part, un choix ignorant les contraintes liées à l'OS peut se révèler
calamiteux.
Ceci dit, c'est l'éternel débat... doit-on, en tant que développeur,
respecter les règles fixées par l'OS, ou non :-)
Pour ma part, je les respecte (c'est l'option par défaut) et fais tout ce
que je peux pour pouvoir proposer une alternative que l'utilisateur final
pourra choisir en _toute_connaissance_de_cause_ et s'il le désire, mais
_rien_à_ce_niveau_ ne devrait être prédéterminé.
Bien sûr cela a un coût, non négligeable... et les programmeurs préfèrent
s'attacher aux fonctionnalités de leurs logiciels, plutôt qu'à
l'environnement dans lequel ils travaillent.
Finalement, la désactivation de l'UAC, c'est encore plus simple...
Pour un programmeur qui ne _veut_ pas jouer le jeu de l'OS, Oui...
Mais cela peut aussi provoquer d'autres problèmes que ceux évoqués ici (mais
déjà évoqués sur d'autres fils de discussion). Il suffit de voir le nombre
de messages concernant les difficultés d'installation d'un programme et/ou
des "incompatibilités" ou "plantages" communément admis dans ces forums.
Merci pour les fonctions/constantes. Mais, il manque (notamment) la racine du C: (rien de prévu pour ce cas...)
Hmmm, c: ? à moins que %windir% ou que le csidl WINDOWS ne permettent de résoudre ce cas ? (Note: On ne devrait pas avoir à s'en servir...)
- difficile de les utiliser, pour un logiciel acheté "fini".
Oui, mais... C'est ce pour quoi la "virtualisation" effective avec l'uac activé est censée être faite...
- cela nécessiterait de le recompiler les logiciels, et, de préférence avec les outils MS.
Oui, afin de respecter les règles définies par l'OS si ce n'était déjà le cas. et Non: n'importe quel outil de développement digne de ce nom permet d'accèder à ces fonctions et/ou de développer une librairie spécifique qui se charge au run-time. La modularité est faite pour ça.
Pour les développeurs, il sera plus simple de choisir d'autres répertoires/emplacements. En plus, ils seront indépendant des constantes MS, et de leurs évolutions aléatoires.
Ces constantes permettent de s'affranchir du problème, si MS change les règles, les valeurs retournées par ces fonctions _sont_censées_ être les bonnes. D'autre part, un choix ignorant les contraintes liées à l'OS peut se révèler calamiteux.
Ceci dit, c'est l'éternel débat... doit-on, en tant que développeur, respecter les règles fixées par l'OS, ou non :-)
Pour ma part, je les respecte (c'est l'option par défaut) et fais tout ce que je peux pour pouvoir proposer une alternative que l'utilisateur final pourra choisir en _toute_connaissance_de_cause_ et s'il le désire, mais _rien_à_ce_niveau_ ne devrait être prédéterminé. Bien sûr cela a un coût, non négligeable... et les programmeurs préfèrent s'attacher aux fonctionnalités de leurs logiciels, plutôt qu'à l'environnement dans lequel ils travaillent.
Finalement, la désactivation de l'UAC, c'est encore plus simple...
Pour un programmeur qui ne _veut_ pas jouer le jeu de l'OS, Oui... Mais cela peut aussi provoquer d'autres problèmes que ceux évoqués ici (mais déjà évoqués sur d'autres fils de discussion). Il suffit de voir le nombre de messages concernant les difficultés d'installation d'un programme et/ou des "incompatibilités" ou "plantages" communément admis dans ces forums.
Mais bon... ça n'est que mon avis... :-)
@Bientôt -- Olivier
leon73
bonjour j'ai suivi vos conseils mais depuis je n'ai plus de message de mon antivirus "avast" disant que la base c'est mise a jour j'ai un message disant que Windows ne peut pas me dire le message !!!!!! lol ! merci a tous
"leon73" a écrit dans le message de news:
Bonjour
y'a t'il un moyen de supprimer ces message "vous devez avoir l'autorisation........" "continué" "confirmé" parfois uniquement pour renommer un dossier ?
merci
bonjour
j'ai suivi vos conseils
mais depuis je n'ai plus de message de mon antivirus "avast" disant que la
base c'est mise a jour
j'ai un message disant que Windows ne peut pas me dire le message !!!!!!
lol !
merci a tous
"leon73" <serge-by@wanadoo.fr> a écrit dans le message de
news:C96A7857-9559-4CF8-A33F-74B82F010915@microsoft.com...
Bonjour
y'a t'il un moyen de supprimer ces message
"vous devez avoir l'autorisation........"
"continué" "confirmé"
parfois uniquement pour renommer un dossier ?
bonjour j'ai suivi vos conseils mais depuis je n'ai plus de message de mon antivirus "avast" disant que la base c'est mise a jour j'ai un message disant que Windows ne peut pas me dire le message !!!!!! lol ! merci a tous
"leon73" a écrit dans le message de news:
Bonjour
y'a t'il un moyen de supprimer ces message "vous devez avoir l'autorisation........" "continué" "confirmé" parfois uniquement pour renommer un dossier ?
