[mOved] Google chrome - Page 8

		if not Ignore then begin
 1601 			if ErrFunc = '__main' then
 1602 				ErrFunc := '_main';
 1603 			if ErrFunc = '__exit' then
 1604 				ErrFunc := '_exit';

_main et _exit sont renommés par un #define dans TIGCCLIB, ce hack fait en sorte que le nom mis par l'utilisateur est affiché.

La raison pour laquelle on renomme ces fonctions est simple: au tout début de TIGCC, ces noms ont été utilisés parce que c'étaient les fonctions attendues par le kernel. En _nostub, il y avait un code de démarrage minimal (juste jmp _main, en gros). Mais ensuite est venu le code de démarrage, et nous avons vite vu que ce code de démarrage est utile/nécessaire aussi pour les programmes kernel. Et du coup il faut que _main soit le début du code de démarrage pour que le kernel fasse la bonne chose. Mais comme tous les programmes existants utilisaient _main, nous ne pouvions pas changer le nom pour des raisons de compatibilité, donc problème... La solution a été de mettre un #define _main __main dans les headers de TIGCCLIB, le vrai _main pour le kernel se situe dans le code de démarrage, le _main utilisateur est renommé en __main par le #define et c'est le code de démarrage qui s'occupe d'appeler __main. Et pour simplifier le code de démarrage, _main est aussi renommé en __main en _nostub (alors que dans ce cas, ce ne serait pas strictement nécessaire).

c'est limpide

J'avais un peu manipulé les sendMessage et compagnie... pour les memes raisons, envoie d'un prog de ETP-Studio à VTI.
Par contre moi je voulais simuler le glisser-déplacer d'un fichier windows pour faire le "receive" de VTI, plutot que simuler l'appui de F10 et remplissage du formulaire (qu'on voit flicker d'ailleurs avec tigcc).

Kevin Kofler (./210) :

GoldenCrystal (./208) :
Tu veux faire quoi, remplir des formulaires avec des données incorrectes ? (tu peux pas...)

Si. La "communication" entre TIGCC IDE et VTI fonctionnait comment à ton avis?
1. Envoi de touches par SendMessage.
2. Manipulation du contenu de la ligne d'entrée du dialogue d'ouverture de fichiers avec un seul SendMessage.
Cf. http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/tigcc/ide/MainUnit.pas?revision=1.13&view=markup, lignes 4766 à 4781.
Et c'est bien à cause de ce genre de hacks que cette "communication" n'était pas maintenable.

Oui tu contrôles l'interface de VTI c magique... Mais comment tu contrôles le contenu d'une page web affiché par un navigateur avec ça ?
Il est vrai que j'avais oublié que WM_GETTEXT/WM_SETTEXT sont des hacks relativement gore qui te permettent de croiser la fontière entre processus, et dans le cas de IE et de Chrome (uniquement) ça peut te permettre de modifier la barre d'adresses. (Du coup ça me semble de conception assez naïve, enfin ça reste complètement débile comme "attaque")
Celà n'empêche que tout le reste ne change pas.
Règle n°1: WM_[G|S]ETTEXT, même si pour certains types de fenêtres uniquement est un hack, ça reste un message windows
Règle n°2: Rien ne t'oblige à implémenter ce messages Windows dans tes contrôles, tu peux même le supprimer sans problèmes (et c'est pour ça que tu ne pourras normalement jamais voler de mdp aussi naïvement)
Règle n°3: ça peut te sembler débile, mais les messages windows ne s'appliquent non seulement qu'aux fenêtres natives, mais à plus forte raison encore, qu'aux contrôles natifs. Tous les autres sont des "exceptions"

Passons au cas qui nous intéresse: hors chrome (qui a respecté les règles de windows), et internet explorer (enfin c'est normal il vont pas donner le mauvais exemple) les interfaces ne sont pas natives, règles 1,2 et 3...
Deuxièmement, l'affichage du contenu des navigateurs n'utilise pas de contrôles natifs, on viole du même coup la règle 3 pour tous.
(Pour safari la zone est une fenêtre native mais pas un contrôle natif mais c du détail)

Donc reprenons:

Voler les mdp ? (pas de bol c pas possible)

Ça aussi c'est possible, il y a même des outils spécialisés pour ça.

Archi faux ! Si ton application est codée correctement (pas avec les pieds), ce qui est au moins le cas avec IE, et je doute que celà ne le soit avec Firefox, tu ne pourras jamais voler les mots de passes d'une méthode aussi banale. Il faut obligatoirement hacker le process, car les contrôles mot de passes ne te fileront pas le mot de passe avec un simple GetWindowText...

Ou alors faire changer l'url dans la barre d'adresse (tu peux pas)

Si, ce n'est qu'un champ texte, cf. première réponse.

Mea culpa cf. première réponse, celà dit ça reste vrai pour la majorité des navigateurs (mais pas pour les plus utilisés)

ou scroller la page pour faire chier l'utilisateur ? -_-

Et ça aussi, c'est possible.

Evidemment puisque je n'ai pas écrit l'inverse -_-

Et on peut aussi manipuler ce qui est affiché sur la page, mais là ça ne passera probablement plus par SendMessage, il faut créer un contrôle qu'on affiche par dessus la page ou modifier le buffer graphique de la page.

Par contre là c'est du délire total, et complètement débile
D'une part si tu affiches un contrôle au dessus de la page, tu ne peux pas *modifier* la page, tu peux simplement en afficher une autre, et je vois pas ce que ça t'apporte.
D'autre part, comme je me tues à le dire, hacker un processus n'est pas si simple, superposer un contrôle à l'affichage d'un navigateur, pour que ça soit bien fait, tu n'as globalement que deux solutions: (et une troisième à base de timers que j'apellerai la méthode "clodo" car ça va bouffer le cpu inutilement et ça sera pas fluide pour autant)
Soit tu installes un hook global au niveau des messages de fenêtre, qui te permet de synchroniser en temps réel ton contrôle avec la zone d'affichage du navigateur.
Soit tu injectes du code dans le navigateur. Au niveau des fonctionnalités la seconde solution est bien plus flexible (enfin avis perso), et au niveau de la mise en place aussi bien qu'au niveau l'accès requis (sécurité) les deux sont d'un niveau équivalent...
Enfin dans tout ça SendMessage te servira à rien bien évidemment...

Bref:

Heu tu dois vraiment avoir la même connaissance de Windows qu'un concombre de mer pour dire ce genre de conneries...

-> À mon avis c'est toi qui ne sais pas de quoi tu parles.

Oui j'imagine que tu as déjà codé des milliers de "hacks" pour Windows, je dois simplement être un novice

Et ce genre de bidouilles est aussi possible sous X11.

Ben ça par contre je m'en fiche royalement. Mais bon permets moi quand même d'en douter, X11 ne gère globalement que les fenêtres, le clavier et la souris, ça me parait franchement limité quand même ^^
A moins bien sur que tu n'aie moyen comme sur Windows de hacker le process, et à ce moment là, de toucher au toolkit sous-jacent, mais ça semble toujours très loin du petit monde tranquille de SendMessage, et surtout c'est très crade.


Enfin bref tout ça pour dire... Non tu peux pas faire grand chose avec "SendMessage et consors"... Mais crois ce que tu veux si tu aimes à penser que l'API Windows est un gruyère que tu peux creuser absolument comme tu veux ^^

Même pas besoin de creuser, c'est un gruyère, il y a des trous partout.

Je comprends pas pourquoi vous vous embêtez avec Sendmessage alors que de toute façon si on peut exécuter un processus utilisateur on peut lire les mots de passe direct...

GoldenCrystal (./215) :

Et ce genre de bidouilles est aussi possible sous X11.

Ben ça par contre je m'en fiche royalement. Mais bon permets moi quand même d'en douter, X11 ne gère globalement que les fenêtres, le clavier et la souris, ça me parait franchement limité quand même ^^ A moins bien sur que tu n'aie moyen comme sur Windows de hacker le process, et à ce moment là, de toucher au toolkit sous-jacent, mais ça semble toujours très loin du petit monde tranquille de SendMessage, et surtout c'est très crade.

Bah tu peut faire grossomodo comme sous windows (la sécuritée en moins) cad envoyer des message "mouse/keyboard" a l'application..

Ha oui tu peut aussi envoyer des demande de "refresh" sur des zones de la fenetre ko<a href='javascript:;' onclick='getPost(event,114458,216)'>./217</a>

Kevin Kofler (./216) :
Même pas besoin de creuser, c'est un gruyère, il y a des trous partout.

Fail
En fait, le gruyère n'a pas de trous.

http://fr.news.yahoo.com/zdnet/20080912/ttc-google-a-integre-du-code-microsoft-d-79c9bc8.html
Kevin

Je sais, et c'est pour ça qu'il ne compile pas sous GNU/Linux, ils n'ont pas encore d'interface utilisateurs portable, que cette merde qui utilise une lib pourrie qui n'est disponible que sous Visual C++, même pas MinGW (parce que ça se base sur l'ATL qui est propriétaire et disponible seulement pour Visual C++). Bref, c'est un de ces projets pseudo-libres qui ne sont que des extensions pour des libs propriétaires qui ne fonctionnent qu'avec un seul compilateur et pour un seul système d'exploitation, tous les deux non-libres. Ils en ont d'autres comme ça, c'est du pur PR ("Vous voyez? Nous faisons aussi du libre!"), ces projets sont complètement inutilisables dans un cadre libre.

pke y'a du libre et du pseudo-libre?
pr moi, le pseudo-libre, ca serait plutot cette gpl de merde qui me contraint...

(et en plus, ça n'utilise même pas khtml ! )

Folco (./225) :
Mais au moins, c'est pas pourri avec du code de mac

Bah webkit, c'est tout de même essentiellement développé par Apple, hein

nEUrOO (./223) :
pke y'a du libre et du pseudo-libre?

Bah oui, s'il faut une lib, un OS et/ou un compilateur non-libres, ce n'est pas utilisable dans un contexte 100% libre, donc dire qu'on soutient le libre alors qu'on se contente de sortir sous une licence libre des extensions à une lib propriétaire nécessitant un compilateur propriétaire et gérant uniquement un OS propriétaire, c'est abusé. C'est un pur coup de pub de la part d'une entreprise qui ne veut pas comprendre le fonctionnement des logiciels libres (et non, je ne parle pas de Google là, hein...).

donc, tout ce qui est fait pour tourner uniquement sous windows ou mac disons, en utilisant ds tools kits specifiques et non portes, est non libre?

Kevin Kofler (./227) :

nEUrOO (./223) :
pke y'a du libre et du pseudo-libre?

Bah oui, s'il faut une lib, un OS et/ou un compilateur non-libres, ce n'est pas utilisable dans un contexte 100% libre, donc dire qu'on soutient le libre alors qu'on se contente de sortir sous une licence libre des extensions à une lib propriétaire nécessitant un compilateur propriétaire et gérant uniquement un OS propriétaire, c'est abusé. C'est un pur coup de pub de la part d'une entreprise qui ne veut pas comprendre le fonctionnement des logiciels libres (et non, je ne parle pas de Google là, hein...).

J'aurais pourtant juré que tu avais déjà écrit des programmes pour TI

Pollux (./229) :
J'aurais pourtant juré que tu avais déjà écrit des programmes pour TI

Mais les OS libres comme PedroM, c'est mal, un peu comme les libs partagées

nEUrOO (./228) :
donc, tout ce qui est fait pour tourner uniquement sous windows ou mac disons, en utilisant ds tools kits specifiques et non portes, est non libre?

Le code lui-même peut être libre, mais il n'est pas utilisable dans un contexte entièrement libre, donc le programme n'est pas vraiment libre en pratique.
http://www.gnu.org/philosophy/java-trap.html

Pollux (./229) :
J'aurais pourtant juré que tu avais déjà écrit des programmes pour TI

Bah, je n'ai jamais dit que tout ce que j'ai sorti était libre ni encore moins que c'était utilisable dans un contexte 100% libre.

Kevin Kofler (./231) :

Pollux (./229) :
J'aurais pourtant juré que tu avais déjà écrit des programmes pour TI

Bah, je n'ai jamais dit que tout ce que j'ai sorti était libre ni encore moins que c'était utilisable dans un contexte 100% libre.

Ben Google non plus n'a jamais dit que Chrome était utilisable dans un contexte 100% libre... Et puis j'imagine qu'une version Linux va sortir tôt ou tard, il vaut mieux que la beta windows sorte maintenant pour que les bugs soient corrigés et que la version Linux qui sortira soit stable et n'ait pas de grosse faille de sécurité, plutôt que d'attendre des mois avant de sortir une version multiplateforme qui serait buggée ^^

Kevin Kofler (./231) :

nEUrOO (./228) :
donc, tout ce qui est fait pour tourner uniquement sous windows ou mac disons, en utilisant ds tools kits specifiques et non portes, est non libre?

Le code lui-même peut être libre, mais il n'est pas utilisable dans un contexte entièrement libre, donc le programme n'est pas vraiment libre en pratique.
http://www.gnu.org/philosophy/java-trap.html

Pollux (./229) :
J'aurais pourtant juré que tu avais déjà écrit des programmes pour TI

Bah, je n'ai jamais dit que tout ce que j'ai sorti était libre ni encore moins que c'était utilisable dans un contexte 100% libre.

5 fois en un post... j'aimerais bien savoir quelle est ta moyenne par post, vu que tu ne parles presque que de ça
Sur plus de 25000 posts, ça doit faire beaucoup de libre

oh, "à vue de nez" et en se limitant aux posts de 2008, ça ne fait que 8% qui parlent de libre ^^ (disons ça m'étonne moins que les 12% de posts qui contiennent "fedora" par exemple )

juste pour être clair, "à vu de nez" = des stats réelles?

Pollux (./232) :
Ben Google non plus n'a jamais dit que Chrome était utilisable dans un contexte 100% libre...

Sauf que ce n'est pas de Google que je me plains (enfin, pas primairement, mais je leur reproche quand-même d'avoir utilisé WTL au lieu de Qt!), mais de l'entreprise qui nous sort des "projets libres" comme WTL qui ont tous en commun de nécessiter le compilateur et le système d'exploitation propriétaires de cette même entreprise. (Il y a aussi un outil pour la création d'installeurs qui est lui aussi inexploitable avec d'autres OS et/ou compilateurs.)

Tu as raison, il ne faut aucun logiciel libre sous Windows... Franchement, quelle idée pourrie de sortir KDE pour Windows Vraiment le truc qui ne sert à rien

Il n'a pas du tout dit ça.
Et il faut quand même avouer que le code de WTL n'a aucune chance d'être ré-utilisé quelque part d'autre => le rendre open source ne sert à rien à part donner une bonne image (sauf si en fait ce n'est qu'une première étape, et qu'ils comptent rendre open source windows )

Kevin Kofler (./237) :
(enfin, pas primairement, mais je leur reproche quand-même d'avoir utilisé WTL au lieu de Qt!)

Développer N backends monoplateforme ça peut permettre d'être bien mieux intégré à chaque système que de dépendre d'une API multiplateforme ^^ (c'est probablement pour ça que Mozilla utilise son propre toolkit)