La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Logiciels => Discussion démarrée par: BadMax le 27 janvier 2015 à 21:07:47
-
On peut pas debug au niveau des appels aux DLL?
Non les applis Microsoft embarquent parfois leurs propres DLL. C'est visible avec Office, avec IE probablement aussi.
Il y a des années un copain avait écrit un petit programme pour visualiser les API utilisées en utilisant le pointeur dans l'application. Avec une appli normale genre le bloc note, le Wordpad ou la calculatrice, on voyait les appels aux DLLs standards.
Avec Office et IE à l'époque (y'a +10 ans ;) ), le programme ne retrouvait pas les DLL appelées. C'est là où on a compris que pour Office les DLL étaient embarquées. Pourquoi ? Simplement pour que Office soit utilisable sur Win98 / Millenium / NT4.0 / 2000...
Je ne m'intéresse plus à Windows depuis longtemps mais je mettrai ma main à couper que c'est toujours valable.
-
Qu'est-ce que tu appelles "ses propres DLL"?
-
C'est quoi ce procès bidon de reprocher à office d'avoir des dll ? Pourquoi pas se plaindre qu'il y a des .so sous linux aussi ????
Et si c'est possible de tracer les appels dans les dll systèmes avec visual, suffit de configurer les serveurs de symboles, et visual va récupérer les infos qui vont bien tout seul comme un grand
Pour les dll spécifiques au prog, on peut pas, mais bon que le code de office soit dans l'exe ou la dll c'est quoi la différence ?
-
Qu'est-ce que tu appelles "ses propres DLL"?
Exemple: les icones de texte, de police, etc. T'as une API standard dans Windows pour cela. Ben dans Office, il utilise sa propre bibliothèque :)
-
C'est quoi ce procès bidon de reprocher à office d'avoir des dll ?
Hein?
-
Hein?
Bah :
Il y a des années un copain avait écrit un petit programme pour visualiser les API utilisées en utilisant le pointeur dans l'application. Avec une appli normale genre le bloc note, le Wordpad ou la calculatrice, on voyait les appels aux DLLs standards.
Avec Office et IE à l'époque (y'a +10 ans ;) ), le programme ne retrouvait pas les DLL appelées. C'est là où on a compris que pour Office les DLL étaient embarquées.
-
Ha je commence à capter où il veut en venir : MS s'était fait engueuler une époque car ils utilisaient des API non publiques de Windows dans Office, et du coup le procès anti-trust avait obligé MS à documenter ces API
Et au final y avait rien eu de fracassant, et depuis ils le font plus a priori :D
-
J'en sais rien, j'ai plus l'outil en question :D
Serait étonné qu'Office 2010 n'embarque pas des DLL juste pour gérer l'interface graphique par exemple : sous XP, Vista et 7, il a le meme Look'n Field.
-
Oui mais ça il a le droit :D
-
Oui mais du coup est-ce que la DLL est une copie d'une DLL système standard de 7 ou est-ce une DLL développé spécifiquement ? Il y a 10 ans, les équipes Office faisaient tout elles-meme. Mais dans les deux cas, qui s'occupe du patch ? :)
-
Maintenant MS le fait plus trop, mais à l'époque oui ça arrivait que IE ou Office mette à jour certains composants de Windows comme les librairies Shell.
Ce qui pause aucun problème à partir du moment :
- où l'API est documentée
- le composant est dispo aux autres développeurs
(personne va se plaindre d'un nouveau directx par exemple !)
Là où ça avait râlé à l'époque, c'est que certains bouts étaient cachés/pas documentés, et que ça faisait de la concurrence déloyale du coup
-
C'est de pratique courant pour beaucoup d'applications Windows d'avoir ses propres DLL...c'est d'ailleurs fait pour ca les DLL...
C'est un moyen pratique de découper l’exécutable en plusieurs morceaux ce qui peut faciler la mise a jour ou la consommation mémoire a l’exécution. On peut aussi 'lié statiquement une dll' dans le binaire final (le .exe).
Je ne vois pas ou est le probleme la, tout le monde fait ca depuis que Windows existe.
Un simple utilitaire comme : http://www.dependencywalker.com/ permet de voir quelles DLL une application utilise.
-
(http://toastytech.com/guis/nt351word.png)
C'est vrai qu'Office 97 faisait pas mal en backportant les common control ...