Suis-je en mode Service de Windows?

Bonjour,

Avons-nous un moyen de savoir si on est lancé en tant que service de Windows, à part avec nom de l’utilisateur connecté ?

En fait ceci est très mal géré par 4D, lorsqu’on tourne en tant que service on ne devrait avoir aucune interface dans le service, et accéder à l’interface en lançant un 4D “client” du service…

Avec le serveur 2016 l’interface est affichable (mais pas par défaut) et ne permet plus d’interaction, c’est galère garantie !

Merci !

https://livedoc.4d.com/4D-Language-Reference-17-R6/4D-Environment/Get-application-info.301-4311317.en.htmlGet application info>

Damned !

Merci Vincent ! :pray:

Sauf que visiblement ça ne fonctionne pas…

En mode normal la propriété n’est pas présente

En mode service non plus je suppose, mais c’est plus difficile d’en être certain, en tout cas ça n’est pas détecté par mon code…

:frowning:

Voici le Le lire informations système sur mon serveur qui tourne dans un service de windows :

Info Système : { “machineName”: “SRV-JFA”, “accountName”: “Système”, “userName”: “”, “osVersion”: “Microsoft Windows Server 2016 Standard 10.0.14393”, “uptime”: 6630, “physicalMemory”: 16620188, “osLanguage”: “fr”, “processor”: “Intel® Core™ i3-8100 CPU @ 3.60GHz”, “cores”: 4, “cpuThreads”: 4, “networkInterfaces”: [ { “type”: “ethernet”, “name”: “Broadcom NetXtreme Gigabit Ethernet”, “ipAddresses”: [ { “ip”: “172.20.24.27”, “type”: “ipv4” } ] }, { “type”: “ethernet”, “name”: “Remote NDIS Compatible Device”, “ipAddresses”: [ { “ip”: “169.254.0.2”, “type”: “ipv4” }, { “ip”: “fe80::21e8:b06d:ba5f:c6fb”, “type”: “ipv6” } ] } ], “model”: “Dell Inc.”, “volumes”: [ { “mountPoint”: “C:”, “capacity”: 62914556, “available”: 39810480, “filesystem”: “NTFS”, “disk”: { “interface”: “ide”, “identifier”: “\\.\PHYSICALDRIVE0”, “description”: “Disk drive”, “size”: 234428512 } }, { “mountPoint”: “D:”, “capacity”: 976629756, “available”: 897464920, “filesystem”: “NTFS”, “disk”: { “interface”: “ide”, “identifier”: “\\.\PHYSICALDRIVE1”, “description”: “Disk drive”, “size”: 976760032 } }, { “mountPoint”: “E:”, “capacity”: 167470076, “available”: 103846252, “filesystem”: “NTFS”, “disk”: { “interface”: “ide”, “identifier”: “\\.\PHYSICALDRIVE0”, “description”: “Disk drive”, “size”: 234428512 } } ] }

Ça y est, compris !

C’est dans Lire information application !!!

Mais faut être en 17R5, donc ça n’est pas pour moi. :roll:

Bonjour,

La commande Get application info est disponible à partir de la v17R3.

https://blog.4d.com/get-info-about-the-running-application/

Oui, 17R3 ça ne change pas grand chose, nous n’utilisons plus les R, qui contiennent par définition du code en version ß en déploiement.

Donc j’attendrais la v18 pour pouvoir utiliser ça, hélas.

Merci,
Jacques

: Jacques FADEUILHE

les R […] qui contiennent par définition du code en version ß en
déploiement.
Heu… je n’ai pas compris ça ainsi : une R contient de nouvelles fonctionnalités, certes, mais dont la phase ß est validée. La v18, d’après ce qu’on nous a expliqué, n’est que la v18r0, fille de la dernière des v17r…

Le seul ennui avec les r, c’est si tu en adoptes une qui a LE bug bien pénible qui n’agresse que toi, tu es obligé d’attendre la r suivante pour la correction. Mais c’est vrai de n’importe quelle version, r ou pas r, il me semble.

Bonjour Arnaud,

Effectivement, c’est du ß “Validé”. Il faut sans doute plutôt parler de préversion, de fonctionnalités généralement en devenir.

Je trouve ce système très très bien, et je l’utilise dans le cadre de développements “sur mesure”. Mais pour Ajaris, dans le cadre d’un produit avec plusieurs centaines d’utilisateurs, c’est trop risqué.

Les R n’ont pas de versions correctives, pas de “night build”, il faut effectivement attendre la R suivante qui elle même ne contient pas les dernières corrections de la version courante, mais uniquement celles “validées à temps”.

Heureusement les gros problèmes sont devenus rares avec 4D, merci aux équipes, mais ayant déjà eu de grosses frayeurs nous ne nous y risquons plus.

Actuellement en v17.1, qui à bien stabilisé la v17, je suis en manque de pas mal de choses qui sont dans les R et espère que la 18 arrivera vite !

Mais du coup, je ne sais pas si mon serveur est installé comme service. :roll:

Ce que je voulais dire est que, en suivant ce raisonnement, avec la 18 “tout court”, ce sera tout aussi risqué ; ce sera a minima la 18.1.

Sauf qu’en cas de pb bloquant je peux espérer une 18.0 night build xxx qui corrige.

Et de plus, en v18.0 les fonctionnalités qui étaient en friche dans les R sont déjà bien avancées…

La 18 pour moi est plus l’aboutissement des R qu’une nouvelle R avec des nouvelles fonctions.

: Jacques FADEUILHE

La 18 pour moi est plus l’aboutissement des R qu’une nouvelle R avec
des nouvelles fonctions.
Si tu regardes la v17, c’était plutôt R² : on n’avait strictement rien vu d’orda dans les 16R qui ont précédé ! :wink:

: Jacques FADEUILHE

Sauf qu’en cas de pb bloquant je peux espérer une 18.0 night build
xxx qui corrige.

Je n’ai pas une vision totale sur l’ensemble des bugs mais je pense que ton soucis est un non-soucis.
Les versions R sont de plus en plus stables et si le délai pour fixer un bug en R est de 3 mois je ne pense pas qu’il soit beaucoup plus court dans la ligne des versions classiques.

Oui Bertrand,

Sauf que nous avons été bien plantés en 16R, et que chat échaudé…

La 16.x corrigeais, mais pas la 16R+1, qui était déjà sur les rails de sortie. Bilan plusieurs mois d’attente.

S’il y a dans une R un élément incontournable, ou dans la phase de dev, quand je sais que la version sortira avant notre déploiement, le R est envisageable. Mais sinon non.