[Debugging] LOAD_DLL_DEBUG_INFO

Bonjour,


"AMcD®" <arnold.mcdonald@free.fr> wrote in message
news:423eae06$0$22843$636a15ce@news.free.fr...

Ha ben mince alors.
Prononce le mot Delphi, ils viendront au moins t'insulter.

Arg, ne prononce pas le nom de ce langage dans un thread où il est question
de debugging !! :-)

Désolé, mais moi aussi je suis alergique - la dernière fois que je l'ai
utilisé c'est certe un peu vieux (la dernière version sous Win16), mais
c'était vraiment une horreur : un cauchemar !!!

Justement, pour reparler de ce thread, je suis par contre moins alergique à
VB, mais juste pour ce pour quoi il est fait :-) :-) Aller stop sur ces
polémiques !!!!!!


Olivier Huet

Olivier Huet wrote:

Aller stop sur ces polémiques !!!!!!

Stop sur ces polémiques ? Quelles polémiques ? Je n'ai fait qu'exprimer une
opinion en essayant de me justifier. Si tu me lis, ici ou ailleurs, tu
verras que je reconnaîs toujours mes erreurs, suis prêt à changer d'avis
quand que je me trompe, etc. Je ne suis pas bouché moi. Je n'ai pas
d'oeillères. Et si tu me lis, justement, tu verras aussi que même si je suis
quelqu'un avec un style particulier (sur les NGs !), toutefois, ça se passe
finalement toujours bien avec tout le monde. Enfin, avec des gens
intelligents. Ce n'est que de l'écrit et il est parfois possible d'être mal
compris, interprété. Surtout quand on ne pratique pas la langue de bois
comme c'est mon cas.

Mais je ne supporterai jamais qu'on vienne m'insulter gratuitement. Je ne
tolère pas qu'on vienne professer doctement en se payant ma tête. Qui plus
est quand cela vient de personnes d'un certain âges, reconnues, qui savent
très bien ce qu'elles font/écrivent. Le titre de MVP leur monte tellement à
la tête qu'ils se croient peut-être un peu seuls au monde...

Eh bien moi je ne fonctionne pas comme cela ! On m'a insulté, j'attends des
excuses. D'autant plus que j'attends toujours la preuve de certaines
flagorneries avancées lors de du thread dont tu parles.

Alors MONSIEUR Bellamy, cette version Delphi de mon exemple, j'attends
toujours ! Serait-ce qu'avoir tort et le reconnaître publiquement écornerait
votre aura ? Allons, allons, personne n'a autant d'importance, dégonflez un
peu l'ego, ça vous fera du bien.

PS : et au cas où tu en douterais, j'ai des dizaines d'exemples que tu ne
feras jamais en Delphi, n'ai aucun doute à ce sujet...

--
AMcD®

http://arnold.mcdonald.free.fr/

yarocco a écrit :

Olivier Huet wrote:

Arg, ne prononce pas le nom de ce langage dans un thread où il est
question
de debugging !! :-)

Désolé, mais moi aussi je suis alergique - la dernière fois que je l'ai
utilisé c'est certe un peu vieux (la dernière version sous Win16), mais
c'était vraiment une horreur : un cauchemar !!!
Olivier Huet

Bon, je viens ajouter ma couche :)

... sur quelqu'un qui déclare être "alergique", et qui se réfère à une
version Win16 pour qualifier Delphi d'horreur et de cauchemar. ;-)

J'ai appris a programmer (si on peut dire ca) avec Delphi et je trouve
vraiment qu'il est super meme si justement on fait des choses enormes
sans rien comprendre ce qui rend les questions des debutants vraiments
stupides dans le sens que quelqu'un qui voit les rouages mis en place ne
serait que pour creer la fenetre principale d'une appli pensera autrement.
Bref, apres quelques annees(j'ai commence avec D2, puis D5 juska la 7),
je le trouve pas mal du tout. Juste quelques gros defauts qui je pense
ne seront jamais corriges :
-Taille des exe

Le principal problème, c'est la taille d'un petit .exe déployé vers des
plateformes n'ayant pas déjà les .bpl. En fait, ça dépend du contexte,
des stratégies de déploiement.

-optimisation de la VCL et RTL

Voir quand même le projet Fastcode, justement sur
borland.public.delphi.language.basm

et quelques autres mais moins importants (que je n'ai pas en tete :)).
Sinon, niveau debug, je le trouve pas mauvais du tout justement, il y a
une fenetre CPU (registres + desassembleur) avec une correspondance
entre ASM et code delphi (ca sert quand on comprend pas trop l'ASM), des
"watches", bref ce que je demande a un debugger :)

OK, c'est génial. Et extrèmement pédagogique. Dans cette optique, un
énorme reproche, les versions gratuites sont privées de le fenêtre FPU
(donc 3DNow/MMX/SSE).
A signaler qu'une option permet d'uiliser TD32, gratuit et plus complet,
même si moins convivial que le debugger intégré.

Il est vrai que je ne l'emploi pas completement (toute la partie
internet par exemple) et donc je ne connais pas reellement ses limites,
cependant je trouve qu'il permet deja de faire au moins autant qu'en
C/C++ (excepte pour les drivers mais je m'y suis pas encore plonge non
plus...). Quand au BASM (ASM integre), je trouve ca pas mal du tout car
ca permet d'approcher l'assembleur plutot dooucement (on garde le code
"interace" en Delphi et on met du BASM pour les parties critiques ou
simplements les procedures). J'ai procede ainsi et je sais qu'etant
maintenant completement en ASM, ca m'a facilite la chose (experience
personnelle mais qui je pense peut se generaliser).

BASM est réellement intégré au langage, et surtout documenté (c'est
frugal, mais suffisant). En fait, les domaines d'intervention de
l'IDE/RAD (IHM et fonctions de haut niveau), du LHN Pascal Objet et de
BASM sont clairement identifiables.

Enfin, tout ca pour dire que Delphi est quand meme un outil et un
langage assez puissant qui n'a vraiment rien a voir avec VB et qui, je
pense, n'a pas grand chose a envier au C/C++ (et ses compilos).

OK. Maintenant, deux gros défauts: limité à Windows (et Linux avec la
CLS), mais x86 exclusivement. Et de gros doutes sur l'avenir (dans notre
optique bas niveau), rien de prévu en 64bit par exemple.

--
Pierre

Pierre Maurette wrote:

-Taille des exe

Le principal problème, c'est la taille d'un petit .exe déployé vers des
plateformes n'ayant pas déjà les .bpl. En fait, ça dépend du contexte,
des stratégies de déploiement.

Ben, c'est sur mais un exe avec une fenetre simple et 3 boutons ca prend
5Ko en ASM et 360Ko en Delphi !!!

-optimisation de la VCL et RTL

Voir quand même le projet Fastcode, justement sur
borland.public.delphi.language.basm

Je connais merci :) c'est justement la que j'ai vu la non optimisation
de la part de Borland .

et quelques autres mais moins importants (que je n'ai pas en tete :)).
Sinon, niveau debug, je le trouve pas mauvais du tout justement, il y
a une fenetre CPU (registres + desassembleur) avec une correspondance
entre ASM et code delphi (ca sert quand on comprend pas trop l'ASM),
des "watches", bref ce que je demande a un debugger :)

OK, c'est génial. Et extrèmement pédagogique. Dans cette optique, un
énorme reproche, les versions gratuites sont privées de le fenêtre FPU
(donc 3DNow/MMX/SSE).
A signaler qu'une option permet d'uiliser TD32, gratuit et plus complet,
même si moins convivial que le debugger intégré.

Y'a aussi OllyDgb qui est un programme a part mais extremement complet aussi

Enfin, tout ca pour dire que Delphi est quand meme un outil et un
langage assez puissant qui n'a vraiment rien a voir avec VB et qui, je
pense, n'a pas grand chose a envier au C/C++ (et ses compilos).

OK. Maintenant, deux gros défauts: limité à Windows (et Linux avec la
CLS), mais x86 exclusivement. Et de gros doutes sur l'avenir (dans notre
optique bas niveau), rien de prévu en 64bit par exemple.

Pour le portage en 64 bits, apparement c'est a l'etude (vu sur le forum
de fast project justement ;)
Linux, c'est la CLX pas CLS.... (erreur de frappe je suppose) et c'est
pas vraiment top...
Pour l'architecture processeur, c'est vrai que c'est un peu regretable
d'etre aussi limite mais bon, vu les problemes qu'ils ont pour passer au
64 bits, je me dis qu'il faut mieux rester sur le x86 :P

yarocco a écrit :

Pierre Maurette wrote:

-Taille des exe

Le principal problème, c'est la taille d'un petit .exe déployé vers
des plateformes n'ayant pas déjà les .bpl. En fait, ça dépend du
contexte, des stratégies de déploiement.

Ben, c'est sur mais un exe avec une fenetre simple et 3 boutons ca prend
5Ko en ASM et 360Ko en Delphi !!!

367 ko pour le projet vide, mais 17 ko en cochant "Consruire avec les
paquets d'exécution". OK, il faut bien déployer les paquets (des DLL).
C'est le même machin en C ou C++, comme en MASM32, du moins je le
suppose. Mais effectivement, je n'ai jamais eu l'idée de faire du 100%
API Windows avec Delphi

A signaler qu'une option permet d'uiliser TD32, gratuit et plus
complet, même si moins convivial que le debugger intégré.

Y'a aussi OllyDgb qui est un programme a part mais extremement complet
aussi

Bon programme, mais pas vraiment comparable (assembler != source)

Pour le portage en 64 bits, apparement c'est a l'etude (vu sur le forum
de fast project justement ;)

Alors, Fastproject, c'est Borland ? ;-)
Plus sérieusement, j'ai un peu peur que tout Borland soit "à l'étude"...

Linux, c'est la CLX pas CLS.... (erreur de frappe je suppose) et c'est
pas vraiment top...

C'est mort ...

Pour l'architecture processeur, c'est vrai que c'est un peu regretable
d'etre aussi limite mais bon, vu les problemes qu'ils ont pour passer au
64 bits, je me dis qu'il faut mieux rester sur le x86 :P

Wait and see ...

--
Pierre