Compatibilité de mon appli

Signaler
Messages postés
15
Date d'inscription
mercredi 4 avril 2007
Statut
Membre
Dernière intervention
4 juin 2007
-
Messages postés
7741
Date d'inscription
mercredi 1 septembre 2004
Statut
Membre
Dernière intervention
24 septembre 2014
-
bonjour

je dévelloppe une appli sous VB6 et le PC que j'utilise est sous Windows2000.

Mon application est-elle immédiatement compatible avec Win98 ? et Win NTServer?

Ou bien dois-je effectuer quelques modifications?


Merci beaucoup

8 réponses

Messages postés
7668
Date d'inscription
samedi 5 novembre 2005
Statut
Membre
Dernière intervention
22 août 2014
26
Tout dépend des composants que ton application utilise éventuellement et des fonctions de l'Api de Windows dont elle se sert éventuellement. Certains de ces composants et Dll peuvent ne pas "aller" sur toutes les versions de Windows ou ne pas (pour certaines fonctions) retourner les mêmes valeurs ou encore entraîner les mêmes effets.
Messages postés
15
Date d'inscription
mercredi 4 avril 2007
Statut
Membre
Dernière intervention
4 juin 2007

Ok et il n'ya pas une maniére pour être sur que ça passe?

Parceque je dois mettre mon logiciel sur un réseau ultra-sécurisé(les
machines qui y ont accés ont pas de port usb,pas de lecteur
disquette,pas de lecteur cd...)donc je dois passer par un service
spéciale de l'entreprise pour mettre mon logiciel sur ce réseau et je
me vois mal essayer de bidouiller en rajoutant des dll ou d autres
trucs sur ces réseaux(qui n'ont evidemment pas d'accés internet)
Messages postés
7668
Date d'inscription
samedi 5 novembre 2005
Statut
Membre
Dernière intervention
22 août 2014
26
C'est au moment où tu développes ton application qu'il t'appartient de vérifier (en te documentant) la compatibilité des composants que tu ajouterais et des fonctions de l'Api de Windows que tu déclarerais.
En ce qui concerne les composants "ajoutés" : une chose est certaine : plus tu rechercheras ton "confort de développement", plus tu t'exposeras à des risques de compatibilité. Il vaut toujours mieux travailler un peu plus et améliorer l'indpendance de ton application en faisant, au besoi, plutôt appel à l'API de Windows (car les fonctions de cette API sont en règle générale beaucoup moins souvent susceptibles de se heuter à des problèmes de compatibilité. Beaucoup moins souvenbt ne voulant pas dire jamais, toutefois).
Messages postés
7668
Date d'inscription
samedi 5 novembre 2005
Statut
Membre
Dernière intervention
22 août 2014
26
Je reviens, avec une autre préoccupation qui doit te "hanter" également en matière de perennité de ton application :

Dans le même ordre d'idée : il est (tout au moins à mon point de vue) extrêmement maladroit de "piloter" depuis VB des applications externes (telles Word, Excel, etc...) car ce "pilotage" induit l'écriture de lignes de codes susceptibles d'être comprises par ces applications (mais qui peuvent être différentes selon les versions installées sur la machine "cliente" .. Pire, le "clent" peut décider, demain, d'installer une nouvelle version de ces applications. Celà a déjà été le cas entre avant et après VBA et sera vraisemblablement à nouveau le cas un jour ou l'autre !...)
.
Messages postés
7668
Date d'inscription
samedi 5 novembre 2005
Statut
Membre
Dernière intervention
22 août 2014
26
Je reviens et ajoute ceci :

Quelles que soient les précautions prises : on ne distribue jamais une application sans passer par deux étapes importantes :

1) étape de qualification simple (dite de "grattage") au cours de laquelles plusieurs intervenants cherchent à faire "planter" l'application (saisies incohérentes, frappes de touches simultanément, recherches des cas particuliers etc...)
2) étape de qualification "avancée" : tests sur plusieurs machines de performances différentes et de systèmes d'exploitation différents.

Voilà donc....
.
Messages postés
15
Date d'inscription
mercredi 4 avril 2007
Statut
Membre
Dernière intervention
4 juin 2007

tu dis"Dans le même ordre d'idée : il est (tout au moins à mon point de vue)
extrêmement maladroit de "piloter" depuis VB des applications externes
(telles Word, Excel, etc...)"

or c'est le principe meme de mon programme(je suis en stage et je fais ce qu'on me demande c tout).

Et je n'ai pas plusieurs personnes qui pourraient consacré un peu de
temps à essaayer de débusquer des bugs de mon prog,le service ou je
suis est déja trés juste niveau planning. Et les accés aux machines
sont trés limités(toujours par sécurité) donc je ne peu pas effectuer
une série de test sur différentes machines.

Merci pour tes conseils mais dans mon cas je ne peut pas tous les appliquer
Messages postés
7668
Date d'inscription
samedi 5 novembre 2005
Statut
Membre
Dernière intervention
22 août 2014
26
Je ne peux dans ce cas que compatir...

Prends donc toutefois la précaution (surtout si tu es en stage car celà montrera ton sérieux et ton esprit consciencieux) d'appeler l'attention de ton responsable de stage sur ces aspects. Il ne pourra que t'en féliciter, d'une part et, d'autre part, nul ne popurra te reprocher de ne pas avoir su prévenir (surtout en ce qui concerne les risques induits par  un "pilotage" en ce qui concerne la pérennité de ce que l'on te fait ainsi développer, puisque celà t'est demandé et n'est donc pas ton choix). Je te conseille même d'inclure quelques lignes à ce propos dans ton rapport de fin de stage.


Bonne chance.
Messages postés
7741
Date d'inscription
mercredi 1 septembre 2004
Statut
Membre
Dernière intervention
24 septembre 2014
41
Je viens mettre mon grain de sel.

la compatibilité multiplateforme est un point délicat du développement notamment concernat Win98. En effet si généralement on obtient un bon taux de compatibilité entre NT4.0, W2000, WinXP qui sont tous des noyaux NT, il en va tout autrement de Win98 et Millenium qui eux ne sont pas basés sur un noyau NT.

Pour avoir un peu plus de chance de compatibilité, il faut s'assurer ne pas utiliser explicitement des api windows propre à W2000 et rester le plus possible dans l'utilisation des composants classiques de VB6. De même il faut faire attention lorsqu'on rajoute des références au projet.

De plus si une application développée avec W2000, pour peu qu'elle n'utilise pas de fonctions vraiment spécifique du système, assure genralement une compatibilité ascendante (compatible XP), il en va autrement pour la compatibilité descendante (NT4.0). En effet, NT4.0 étant la génération precedente de l'os par rapport à W2000, il faut s'assurer que l'appli n'utilise pas de fonctions nouvellement introduite avec W2000.
Ainsi dans mon ancienne boite, pour résoudre très simplement ce problème en acord avec le client (un très grand groupe industriel mondial), la solution utlisée a été de recompiler l'application sur chaque plateforme et de distruber un installable par plateforme couverte. Certe ce n'est pas forcément très pro comme solution.

La seule solution qu'il te reste c'est de faire des tests appronfondis et poussés sur chaque plateforme visée.



Concernant le développement pour Office, le problème est identique. Si tu développe sur ton PC pour Office 2003, toutes les autres machines devraient normalement avoir Office 2003 ensuite pour fonctionner. Quelque fois ça passe si la version d'Office n'est pas la même, mais souvent ça pose problème.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #