ca marche pas, tu as une idee pour resoudre ce probleme?
GCC. J'ai jamais été obligé de casser un système/changer de noyeau pour une application. Même sur de très vieille config
Vu la situation des drivers de CG et l'absence d'ABI/API stable sous Linux, on va dire que c'est de l'ironie...
On va dire que les proportions ca marche/ca nemarche pas sont plus grande sous windows que sous Linux, surtout en ce qui concerne les cartes graphiques/cartes sons (pour les cartes réseaux c'est une autre histoire par exemple). Mais présenter le problème comme un problème Linux alors que les pilotes windows que l'ont doit finir de désinstaller à la pince à épiler dans la base de registre sont légions, ca me fait plutôt rire.
Si c'est ton appli et que c'est toi qui fait les packages, ben tu t'es rate sur les dependances lors d'un upgrade
Toutes mes dépendances sont bonnes, le packages s'installe et se désinstalle proprement. Les versions 64 et 32 bits cohabitent très bien etc. Juste il n'est pas possible de dire à windows via les mecanisme msi qu'une bibliothèque 64 bits remplace une autre bibliothèque 32 bits lors de l'upgrade en 64 bits du dernier logiciel qui utilisait la bibliothèque 64bits.
vois pas bien ce que tu veux faire avec la liste des modifs effectues par Adobe au moment de l'installation
Au hasard un package MSI propre au lieu d'un pilotage en simulation frappe de touche de l'installation de leur package (qui est toujours mieux que de créer des packages par différence avant/après installation - d'accord)
Note que tu peux soit utiliser Process Monitor pour voir tous les acces a la base (et au disque), soit aller directement regarder dans le msi pour voir ce qui est fait
Ce n'est pas un package msi, connaissant adobe même si s'en était un il serait protégé et pour finir le monitoring des accès base de registre va m'apprendre qu'ils sont allés mettre la valeur 0x4500AEFF00 dans la clef {AE86423968-32-2566FFB7} ce qui peut presque palier à l'absence de doc, mais pas complètement.
[^] # Re: D'apres toi ?
Posté par Jerome Herman . En réponse au journal Quand on veut, on peut.. Évalué à 2.
GCC. J'ai jamais été obligé de casser un système/changer de noyeau pour une application. Même sur de très vieille config
Vu la situation des drivers de CG et l'absence d'ABI/API stable sous Linux, on va dire que c'est de l'ironie...
On va dire que les proportions ca marche/ca nemarche pas sont plus grande sous windows que sous Linux, surtout en ce qui concerne les cartes graphiques/cartes sons (pour les cartes réseaux c'est une autre histoire par exemple). Mais présenter le problème comme un problème Linux alors que les pilotes windows que l'ont doit finir de désinstaller à la pince à épiler dans la base de registre sont légions, ca me fait plutôt rire.
Si c'est ton appli et que c'est toi qui fait les packages, ben tu t'es rate sur les dependances lors d'un upgrade
Toutes mes dépendances sont bonnes, le packages s'installe et se désinstalle proprement. Les versions 64 et 32 bits cohabitent très bien etc. Juste il n'est pas possible de dire à windows via les mecanisme msi qu'une bibliothèque 64 bits remplace une autre bibliothèque 32 bits lors de l'upgrade en 64 bits du dernier logiciel qui utilisait la bibliothèque 64bits.
vois pas bien ce que tu veux faire avec la liste des modifs effectues par Adobe au moment de l'installation
Au hasard un package MSI propre au lieu d'un pilotage en simulation frappe de touche de l'installation de leur package (qui est toujours mieux que de créer des packages par différence avant/après installation - d'accord)
Note que tu peux soit utiliser Process Monitor pour voir tous les acces a la base (et au disque), soit aller directement regarder dans le msi pour voir ce qui est fait
Ce n'est pas un package msi, connaissant adobe même si s'en était un il serait protégé et pour finir le monitoring des accès base de registre va m'apprendre qu'ils sont allés mettre la valeur 0x4500AEFF00 dans la clef {AE86423968-32-2566FFB7} ce qui peut presque palier à l'absence de doc, mais pas complètement.