Voilà une question (difficile) que je n'ai jamais bien résolue et je ne
suis pas vraiment sûr qu'il y ait une réponse. Au cas où......
Je travaille actuellement sur une application (C++ / non MFC) qui doit
garantir que l'utilisateur ne modifie pas l'heure système. Sous Win9x,
cette garantie est impossible à donner mais on peut néanmoins mettre en
place des mesures préventives. Parmi celles-ci, l'appli essaye de
récupérer l'heure depuis un serveur SNTP. Cependant, il est hors de
question que ce mécanisme se déclenche s'il n'y a pas de connexion
active.
L'appel aux fonctions Winsock utilisées pour accéder au serveur SNTP
doit donc tout simplement échouer dans 100% des cas s'il n'y pas de
connexion active à Internet **et ne pas déclencher autodial**, pour mon
appli seulement bien sûr. Les réglages utilisateurs doivent rester
inchangés (ou être modifiés de manière temporaire).
Oui, je connais l'existence de la fonction InternetGetConnectedState
(WinInet) mais cette fonction n'est pas fiable et ne correspond pas au
besoin.
Merci d'avance.
--
Patrick Philippot
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
cette appli doit tourner sous NT/2000/XP hors, sous ces systemes les non administrateurs n'ont pas la permission de changer l'heure. une subtilité a du m'échapper, parceque la, on dirait "probleme reglé : utiliser les comptes". non ?
Christian, Ce n'est pas la solution pour moi. Comme je l'ai indiqué, cette appli va tourner comme service sous NT / 2000 / XP: pas d'HKCU disponible à un service tournant sous le compte SYSTEM.
cette appli doit tourner sous NT/2000/XP
hors, sous ces systemes les non administrateurs n'ont pas la permission de
changer l'heure.
une subtilité a du m'échapper, parceque la, on dirait "probleme reglé :
utiliser les comptes".
non ?
Christian,
Ce n'est pas la solution pour moi. Comme je l'ai indiqué, cette appli va
tourner comme service sous NT / 2000 / XP: pas d'HKCU disponible à un
service tournant sous le compte SYSTEM.
cette appli doit tourner sous NT/2000/XP hors, sous ces systemes les non administrateurs n'ont pas la permission de changer l'heure. une subtilité a du m'échapper, parceque la, on dirait "probleme reglé : utiliser les comptes". non ?
Christian, Ce n'est pas la solution pour moi. Comme je l'ai indiqué, cette appli va tourner comme service sous NT / 2000 / XP: pas d'HKCU disponible à un service tournant sous le compte SYSTEM.
Patrick Philippot
Patrick Philippot wrote:
Il me vient une autre idée: pourquoi ne pas utiliser IPHLPAPI.DLL (IP Helper API) et sa fonction GetIpForwardTable? Si la table de routage ne contient aucune entrée de type "Remote Route", c'est que la machine n'est pas connectée, que ce soit en dial-up, via cable ou ADSL. Cette API est dispo depuis Win98 (sauf NT pre-SP4). Avantage: cette info est remise à jour dès que la connexion est rompue.
J'ai testé ça et ça a l'air de bien fonctionner mais je me suis trompé sur ce qu'il fallait tester. En fait, il faut simplement vérifier si la table de routage possède une entrée par défaut sur une gateway (0.0.0.0). Si cette entrée existe, la machine est soit connectée en dial-up, par cable, par ADSL ou via un réseau mais elle a une connexion remote (valide ou non). En dial-up, cette entrée disparaît dès que l'on a raccroché le modem.
Je peux ensuite faire une tentative d'accès au serveur. Si la liaison est vraiment valide, l'accès va réussir. Si elle ne l'est pas, l'accès va échouer sans pour cela me jeter la dialog box de dial-up à la figure, ce qui est exactement ce que je veux. Seul inconvéneint Win95 et NT pre-SP4 ne supporte pas IPHLPAPI.DLL.
J'ai écrit un programme de test qui va être tourné sur différentes configs. Si les test sont concluants, je posterai le code.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Patrick Philippot wrote:
Il me vient une autre idée: pourquoi ne pas utiliser IPHLPAPI.DLL (IP
Helper API) et sa fonction GetIpForwardTable? Si la table de routage
ne contient aucune entrée de type "Remote Route", c'est que la machine
n'est pas connectée, que ce soit en dial-up, via cable ou ADSL. Cette
API est dispo depuis Win98 (sauf NT pre-SP4). Avantage: cette info est
remise à jour dès que la connexion est rompue.
J'ai testé ça et ça a l'air de bien fonctionner mais je me suis trompé
sur ce qu'il fallait tester. En fait, il faut simplement vérifier si la
table de routage possède une entrée par défaut sur une gateway
(0.0.0.0). Si cette entrée existe, la machine est soit connectée en
dial-up, par cable, par ADSL ou via un réseau mais elle a une connexion
remote (valide ou non). En dial-up, cette entrée disparaît dès que l'on
a raccroché le modem.
Je peux ensuite faire une tentative d'accès au serveur. Si la liaison
est vraiment valide, l'accès va réussir. Si elle ne l'est pas, l'accès
va échouer sans pour cela me jeter la dialog box de dial-up à la figure,
ce qui est exactement ce que je veux. Seul inconvéneint Win95 et NT
pre-SP4 ne supporte pas IPHLPAPI.DLL.
J'ai écrit un programme de test qui va être tourné sur différentes
configs. Si les test sont concluants, je posterai le code.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
Il me vient une autre idée: pourquoi ne pas utiliser IPHLPAPI.DLL (IP Helper API) et sa fonction GetIpForwardTable? Si la table de routage ne contient aucune entrée de type "Remote Route", c'est que la machine n'est pas connectée, que ce soit en dial-up, via cable ou ADSL. Cette API est dispo depuis Win98 (sauf NT pre-SP4). Avantage: cette info est remise à jour dès que la connexion est rompue.
J'ai testé ça et ça a l'air de bien fonctionner mais je me suis trompé sur ce qu'il fallait tester. En fait, il faut simplement vérifier si la table de routage possède une entrée par défaut sur une gateway (0.0.0.0). Si cette entrée existe, la machine est soit connectée en dial-up, par cable, par ADSL ou via un réseau mais elle a une connexion remote (valide ou non). En dial-up, cette entrée disparaît dès que l'on a raccroché le modem.
Je peux ensuite faire une tentative d'accès au serveur. Si la liaison est vraiment valide, l'accès va réussir. Si elle ne l'est pas, l'accès va échouer sans pour cela me jeter la dialog box de dial-up à la figure, ce qui est exactement ce que je veux. Seul inconvéneint Win95 et NT pre-SP4 ne supporte pas IPHLPAPI.DLL.
J'ai écrit un programme de test qui va être tourné sur différentes configs. Si les test sont concluants, je posterai le code.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Ambassadeur Kosh
ok, je n'ai pas d'autres pertinentes suggestions :) bon courage.
ok, je n'ai pas d'autres pertinentes suggestions :)
bon courage.
ok, je n'ai pas d'autres pertinentes suggestions :) bon courage.
Patrick Philippot
Patrick Philippot wrote:
En fait, il faut simplement vérifier si la table de routage possède une entrée par défaut sur une gateway (0.0.0.0). Si cette entrée existe, la machine est soit connectée en dial-up, par cable, par ADSL ou via un réseau mais elle a une connexion remote (valide ou non). En dial-up, cette entrée disparaît dès que l'on a raccroché le modem.
Bon, les tests avancent et ça se confirme (98, Me, NT4, 2000, XP - en dial-up et ADSL). Le procédé est simple (quelques lignes de code) et semble beaucoup plus fiable que les GetInternetConnectedState et autres APIS dont le résultat est plus qu'aléatoire. Et surtout, il n'y a aucun risque de déclencher autodial.
Ce qui me surprend, c'est que cette solution ne soit jamais proposée sur les différents sites de développement. Ou alors ceux qui y ont pensé la garde pour eux. J'ai déjà eu à régler ce problème il y a 2 ou 3 ans et j'avais utilisé une méthode assez peu élégante. Le code que j'ai vu sur ces différents sites est également en général peu efficace. Heureusement que j'ai lu un commentaire sur codeguru qui m'a mis la puce à l'oreille...
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
Patrick Philippot wrote:
En fait, il faut simplement vérifier si la table de routage
possède une entrée par défaut sur une gateway
(0.0.0.0). Si cette entrée existe, la machine est soit connectée en
dial-up, par cable, par ADSL ou via un réseau mais elle a une
connexion remote (valide ou non). En dial-up, cette entrée disparaît
dès que l'on a raccroché le modem.
Bon, les tests avancent et ça se confirme (98, Me, NT4, 2000, XP - en
dial-up et ADSL). Le procédé est simple (quelques lignes de code) et
semble beaucoup plus fiable que les GetInternetConnectedState et autres
APIS dont le résultat est plus qu'aléatoire. Et surtout, il n'y a aucun
risque de déclencher autodial.
Ce qui me surprend, c'est que cette solution ne soit jamais proposée sur
les différents sites de développement. Ou alors ceux qui y ont pensé la
garde pour eux. J'ai déjà eu à régler ce problème il y a 2 ou 3 ans et
j'avais utilisé une méthode assez peu élégante. Le code que j'ai vu sur
ces différents sites est également en général peu efficace. Heureusement
que j'ai lu un commentaire sur codeguru qui m'a mis la puce à
l'oreille...
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(remplacez .xx par .fr si vous répondez par e-mail)
En fait, il faut simplement vérifier si la table de routage possède une entrée par défaut sur une gateway (0.0.0.0). Si cette entrée existe, la machine est soit connectée en dial-up, par cable, par ADSL ou via un réseau mais elle a une connexion remote (valide ou non). En dial-up, cette entrée disparaît dès que l'on a raccroché le modem.
Bon, les tests avancent et ça se confirme (98, Me, NT4, 2000, XP - en dial-up et ADSL). Le procédé est simple (quelques lignes de code) et semble beaucoup plus fiable que les GetInternetConnectedState et autres APIS dont le résultat est plus qu'aléatoire. Et surtout, il n'y a aucun risque de déclencher autodial.
Ce qui me surprend, c'est que cette solution ne soit jamais proposée sur les différents sites de développement. Ou alors ceux qui y ont pensé la garde pour eux. J'ai déjà eu à régler ce problème il y a 2 ou 3 ans et j'avais utilisé une méthode assez peu élégante. Le code que j'ai vu sur ces différents sites est également en général peu efficace. Heureusement que j'ai lu un commentaire sur codeguru qui m'a mis la puce à l'oreille...
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.xx (remplacez .xx par .fr si vous répondez par e-mail)
