c'est quoi cette merde de vista

Ca prouve surtout que les développeurs sont nuls et/ou paresseux, et
que donc mieux vaut éviter les produits en question :-)

Peut-être, mais cela prouve aussi que pour faire tourner un programme sous
Vista, il faut que le programmeur consente à des efforts non négligeables,
les clefs de registre sont une chose, les répertoires une autre, les
signatures encore une autre, les fichiers manifest encore une autre...
Pour parfaire le tout, les fonctions qui permettent tout cela sont
dépendantes de l'OS: elle n'existent pas dans toutes les versions de Windows
et/ou ont une syntaxe et/ou un champ d'application différent.
Par exemple, un programme signé aura un comportement (gestion des droits non
seulement sur les fichiers, mais aussi sur les répertoires et les clés de
registre etc...) différent d'un programme non signé, même s'il est exécuté
en tant qu'administrateur...
Autre exemple, un fichier manifest pour XP est différent de celui de Vista,
il faut donc soit trouver un compromis (difficile à trouver) soit maintenir
plusieurs versions.
Par Ailleurs, le coût d'une signature électronique n'est pas négligeable (il
a été multiplié par 3 ou 4 depuis la sortie de Vista), et le parcours du
combattant nécessaire pour en obtenir une n'est pas trivial non plus.
Si encore les infos nécessaires pour tout cela étaient facile à trouver
(elles sont disséminées un peu partout) et à comprendre (beaucoup
d'inter-actions sur des niveaux différents) cela aiderait un peu :-)

Mais bon, il faut en passer par ce qu'ont décidé les concepteurs de l'OS
(pour info, même les programmeurs de chez MS se mélangent encore les
pinceaux, et je ne parle pas des pôvres gars qui se tapent le développement
des drivers).. Bref nous n'allons pas rallumer l'éternelle guéguerre
Administrateur/Développeur pour si peu ;-)

Pour en finir avec cette tirade, il faut investir du temps et des moyens non
négligeables simplement pour permettre à un programme pré-existant de
pouvoir fonctionner sous Vista.
Je ne suis pas certain que l'utilisateur final y trouve son avantage.


--
Olivier

On Fri, 17 Aug 2007 15:17:45 +0200, "Olivier"
<olivier@discussions.microsoft.com> wrote:

Bref nous n'allons pas rallumer l'éternelle guéguerre
Administrateur/Développeur pour si peu ;-)

Ben quand même un petit peu, parce que moi, culturellement, je suis
issue du monde Apple :-)
Et chez Apple, les développeurs ils ont été priés de se démerder avec
une boîte qui n'arrête pas de changer de processeurs et d'OS, ce qui
fait qu'à horizon assez court, l'existant ne fonctionne tout
simplement plus si les développeurs se bougent pas pour se mettre au
goût du jour. Ils le font, donc c'est faisable, hein...
Je dois avouer que perso, en tant qu'administrateur, les trop nombreux
développeurs Windows qui n'ont pas bougé d'un iota depuis Win95, ça
m'exaspère assez violemment :-)))) J'ai quand même du, assez récemment
installer du NETBEUI sur du XP, avec devant moi un mec parfaitement
convaincu d'être dans son bon droit en exigeant l'utilisation de cette
bouse, vous trouvez ça normal ???
--
Nina

culturellement, je suis issue du monde Apple :-)
Dans une vie antérieure je voguais sur la mer, aujourd'hui je surfe sur

internet :-)

changer de processeurs
Pour les langages de troisième génération ou plus, on change de compilateur,

le source n'a que très peu de modifications à subir, voire même aucune.

d'OS
Si l'OS est complètement différent, tout ce qui touche à l'OS doit être

réécrit, on peut cependant envisager de conserver le code non dépendant de
l'OS.
Si l'OS doit maintenir une compatibilité ascendente, ce qui existait
précédement doit continuer à fonctionner sans modification.
Si l'OS ne maintient que partiellement la compatibilité, il faut trouver les
moyens d'assurer que le programme puisse fonctionner dans tous les cas.

Pour ce qui concerne les différents moutures de Windows, le mot d'ordre est
de maintenir la compatibilité ascendente alors que l'OS lui même ne respecte
pas cette règle, même au sein d'une "même" version: une mise à jour ou un
service pack peut changer les règles du jeu, parfois de façon très
insidieuse. par exemple on conserve le nom d'une fonction du système, mais
son paramètrage est différent, ou bien sa valeur de retour est différente,
ou bien encore le prérequis est différent et n'existe pas dans la version ou
sous version précédente). On peut parfois passer pas mal de temps à
rechercher ces informations et à les assimiler, la documentation fournie
étant quelque peu "chevelue" :-)

MS est coutumier du fait de rompre ses propres règles à tout moment, alors
la majorité des autres éditeurs ne le sont pas.

Ils le font, donc c'est faisable, hein...
Tout est faisable, il y a seulement des cas de figure où la complexité

induite nuit au développement.

Je dois avouer que perso, en tant qu'administrateur, les trop nombreux
développeurs Windows qui n'ont pas bougé d'un iota depuis Win95, ça
m'exaspère assez violemment :-)))) J'ai quand même du, assez récemment
installer du NETBEUI sur du XP, avec devant moi un mec parfaitement
convaincu d'être dans son bon droit en exigeant l'utilisation de cette
bouse, vous trouvez ça normal ???

C'est vrai que netbeui est un truc plutôt moche, mais il y en a bien
d'autres :-)
La question est plutôt de savoir pourquoi son utilisation est requise dans
ce cas précis.

--
Olivier

On Fri, 17 Aug 2007 18:08:03 +0200, "Olivier"
<olivier@discussions.microsoft.com> wrote:

changer de processeurs
Pour les langages de troisième génération ou plus, on change de compilateur,

le source n'a que très peu de modifications à subir, voire même aucune.

d'OS
Si l'OS est complètement différent, tout ce qui touche à l'OS doit être

réécrit, on peut cependant envisager de conserver le code non dépendant de
l'OS.
Si l'OS doit maintenir une compatibilité ascendente, ce qui existait
précédement doit continuer à fonctionner sans modification.
Si l'OS ne maintient que partiellement la compatibilité, il faut trouver les
moyens d'assurer que le programme puisse fonctionner dans tous les cas.

Enfin là on parle d'être passé du 6800 au PPC, puis sur Intel, sur une
période de 20 ans, et au niveau OS d'un truc antédiluvien plein de
rustines qui tenait par miracle à un Unix :-)
Vous pouvez aller voir le blog de l'équipe de la MacBU, sur les
raisons du non portage de VBA sur les Mac Intel, pour avoir une idée
du bordel :
<http://www.schwieb.com/blog/2006/08/08/saying-goodbye-to-visual-basic/>

Pour ce qui concerne les différents moutures de Windows, le mot d'ordre est
de maintenir la compatibilité ascendente alors que l'OS lui même ne respecte
pas cette règle, même au sein d'une "même" version
Je n'en disconviens pas une seconde, et c'est anormal. Qunat à la

compatibilité ascendante, y a un bien un moment où il faut y renoncer
si on veut avancer.

MS est coutumier du fait de rompre ses propres règles à tout moment, alors
la majorité des autres éditeurs ne le sont pas.
Bah, je crois qu'il y en a pas un pour relever l'autre :-))))

C'est vrai que netbeui est un truc plutôt moche, mais il y en a bien
d'autres :-)
La question est plutôt de savoir pourquoi son utilisation est requise dans
ce cas précis.
Parce que le développeur a pas avancé d'un iota depuis son premier

Tandy ? Parce qu'en fait il voulait faire chauffeur routier, mais faut
passer le permis, alors que pour coder y en a pas besoin ?
;->>>>>>
--
Nina

Vous pouvez aller voir le blog de l'équipe de la MacBU, sur les
raisons du non portage de VBA sur les Mac Intel, pour avoir une idée
du bordel :

Ce cas particulier était, non pas bordélique, mais un problème complexe car
le langage (vba) utilisé pour les macros générait, au final, des blocs de
langage machine. Le langage machine est, comme son nom l'indique, un langage
dépendant du processeur et non un langage de troisième génération. De plus,
le pseudo code généré était lui aussi dépendant de la machine (ça c'est à
mon avis un non sens, un pseudo code n'étant en théorie qu'un code
symbolique).
Nous avions donc:
- Le langage de macro (vba) qui générait
- un pseudocode pas si pseudo que ça, lequel était transformé en
- code machine

En ce qui concerne l'environnement de développement (l'EDI, l'éditeur de
macro), il semblerait que le problème ait été du même ordre.

C'est un exemple intéressant de ce que la non abstraction de la machine peut
provoquer, et ce, à différents niveaux. La dépendance des différentes
couches du programme semble aussi avoir été un facteur prépondérant dans le
choix final d'abandon.

Qunat à la compatibilité ascendante, y a un bien un moment
où il faut y renoncer si on veut avancer.

La communication marketing n'évoquant jamais (ou presque) ce type de
contrainte, cela se fait forcément au détriment des utilisateurs, qui ont du
mal à comprendre qu'il faille encore sortir le porte-monnaie pour un
programme qu'ils possèdent déjà :-)

C'est pourquoi nous voyons de plus en plus fleurir de contrats basés sur la
souscription.
Ce qui nous amène tout doucement à l'idée, déjà ancienne (WinTerm), de Bill
Gates selon laquelle nous n'aurions plus d'ordinateur individuels, mais de
simple terminaux.
Il nous faudrait alors louer l'espace disque, les programmes et la
connectivité... Ce faisant, plus de problèmes de piratage, de maintenance
complexe ou autres "nuisances". ;-)

Aujourd'hui, avec MS, les systèmes d'exploitation ont une durée de vie de
plus en plus courte, la virtualisation des machines (vmware etc...) rendue
plus accessible au public devient donc maintenant une alternative
intéressante.

faut passer le permis, alors que pour coder y en a pas besoin ?
;->>>>>>

hmmm, c'est donc la guéguerre ? ;-o

--
Olivier

Salut !

installer du NETBEUI sur du XP, ... vous trouvez ça normal ?

Ben, il se trouve que j'aime beaucoup NetBeui, dans certains cas.

Pour quelques clients, l'installation de NetBeui, en plus de TCP/IP a rendu des applications jusqu'à
huit (8) fois plus rapide (ne pas oublier de décocher NetBios over TCP/IP).
En plus, ce n'est pas routable, ce qui est, tantôt un inconvénient, tantôt un avantage (ça permet de
limiter des postes à une branche de réseau, sans administration lourde, si on sucre TCP/IP). Et
puis, aucun conflit d'IP, aucun problème DHCP, etc.

Bon, OK, c'est quand même limité. Mais, ça supporte très bien la promiscuité de TCP/IP.

Et puis, bon, pourquoi ne pas vouloir l'installer ? Pour économiser 3 minutes d'installation ? Pour
préserver son pouvoir de décision en tant qu'Administrateur ? Par jalousie de ne pas y avoir pensé
le (la) premier(e) ? Pour un motif psychanalytique ? Pour faire "comme MS a dit" ?


@+

Michel Claveau

Et puis, bon, pourquoi ne pas vouloir l'installer ?

Je ne suis pas administrateur réseau, ni même un spécialiste des réseaux,
mais grosso-modo:

Netbeui (NetBios Extended User Interface) est un "protocole" (faute de
mieux, la discussion est toujours d'actualité) pas ou peu standardisé, peu
sécurisé (à l'origine il était prévu pour des petits réseaux fermés mais
l'encapsulation tcp/ip + netbeui peut être utilisée pour accèder
"illégalement", de l'extérieur, aux ressources du réseau), mais surtout
_très_ bavard (il a souvent tendance à broadcaster pour un rien) :-)

Je pense qu'un administrateur réseau n'aime pas trop qu'une brèche
potentielle puisse exister sur _son_ réseau, et/ou qu'un protocole bavard
puisse, sinon le saturer, mais l'encombrer sérieusement tout au moins.

Mais bon, laissons Nina répondre elle même.... ;-)

--
Olivier

Bonsoir !

Netbeui (NetBios Extended User Interface)

Attention à ne pas confondre Netbeui et NetBios. Le premier est un
protocole de transfert de données en réseau. Le second est un protocole
de résolution de noms.
Le premier utilise le second, d'où l'inclusion du nom dans l'acronyme,
et d'où la confusion fréquente entre les deux.

Pour le broascast de Netbios, une solution (parmi d'autres), c'est
WINS. Ceci étant, seuls les réseaux locaux importants seront vraiment
concernés. Par exemple, avec 100 postes, le gain est ridicule.


Enfin, dire que Netbeui est peu sécurisé, ça ressemble à du copié/collé
de propagande sans arguments techniques.
Les deux grosses faiblesse de Netbeui sont :
- manque cruel d'outils et de fonctionnalités ;
- il est devenu mal-aimé par Microsoft.


Pour Netbios, il y a eu UNE (grosse) faille. Mais elle est comblée
depuis plus de 6 ans. Pour info, j'ai 3 serveurs ouverts sur Internet,
avec Netbios activé et les routeurs configurés. Depuis 3 ans, AUCUNE
intrusion n'est intervenue. Et, c'est beaucoup plus simple et rapide
que du VPN...











--
@-salutations

Michel Claveau