PaulLenoir1 a écrit:

Cependant le résultat n'est pas du tout ce que je cherche (et ça fait un effet de clignotement super moche quand notre fenêtre se remet au premier plan), car notre fenêtre ne fait pas que se remettre au premier plan, mais elle s'active en même temps et "pompe" le focus sur elle

C'est le principe. Le focus n'a rien à voir avec le fait qu'une fenêtre soit au premier plan. C'est juste une conséquence de la prise de focus.

PaulLenoir1 a écrit:

donc impossible d'utiliser le clavier sur une autre fenêtre en même temps, ce qui n'est pas le cas avec le gestionnaire des tâches (et qui est super gênant !).

Ce que vous dites sur "reset le focus" ne doit pas avoir un résultat meilleur puisque le but est que la fenêtre soit au premier plan SANS avoir le focus, et SANS être active (comme le gestionnaire des tâches); mais c'est pas grave, si vous avez un bout de code expliquant comment "reset le focus" d'une fenêtre, ça m'intéresse...

Non, effectivement, ce sera du pareil au même. Mais quel genre de problématique rencontrez-vous pour avoir le besoin qu'une fenêtre soit au premier plan MAIS inactive ? Je serais curieuse de savoir. Achetez un second écran à la limite.

>Mais, bon, "jouer à qui a la plus grosse 'top_most'" c'est complètement stérile.

Je crois qu'on ne s'est pas bien compris: je ne cherche pas à un top_most "supérieur" à celui du gestionnaire des tâches, mais seulement à créer une fenêtre pour un petit utilitaire, qui pourrait rester en avant plan par rapport à une application plein écran, tout en lui laissant le focus.

>Mais quel genre de problématique rencontrez-vous pour avoir le besoin qu'une fenêtre soit au premier plan MAIS inactive?

Je veux pouvoir faire un utilitaire qui serait capable d'influer sur une application en plein écran (ex: un jeu video simple qu'on essaye d'automatiser en simulant l'appui de touches).

Il serait donc utile d'avoir cette fenêtre au premier plan (pour paramétrer l'utilitaire et avoir des résultats en direct sur ce qu'il fait), tout en laissant le focus à l'appli plein écran; quand j'ai dis désactivée, je me suis mal exprimé (ce n'était pas au sens de la fonction enable()), je voulais juste parler de la fenêtre ayant le focus.

-
Edité par PaulLenoir1 24 octobre 2018 à 20:21:46

PaulLenoir1 a écrit:

>Mais quel genre de problématique rencontrez-vous pour avoir le besoin qu'une fenêtre soit au premier plan MAIS inactive?

Je veux pouvoir faire un utilitaire qui serait capable d'influer sur une application en plein écran (ex: un jeu video simple qu'on essaye d'automatiser en simulant l'appui de touches).

Il serait donc utile d'avoir cette fenêtre au premier plan (pour paramétrer l'utilitaire et avoir des résultats en direct sur ce qu'il fait), tout en laissant le focus à l'appli plein écran; quand j'ai dis désactivée, je me suis mal exprimé (ce n'était pas au sens de la fonction enable()), je voulais juste parler de la fenêtre ayant le focus.

Je n'ai pas la prétention de connaître le domaine mais voici les premières réflexions qui me viennent :

• Dans ce cas, pas besoin de se battre avec la taskbar. Si il est en plein écran, il n'y a normalement pas de raison de faire appel à la taskbar lors de l’exécution du jeu.
  Je comprend cependant ce besoin de faire le travail "de A à Z".
  
  
• On vous l'a déjà proposé mais est-ce qu'un overlay, une interface intra-game serai pas plus adaptée pour ce genre de besoins ?
  
  
• Pas d'autres idées hormis celles-ci.
  
  

On commence à voir le loup sortir du bois, du botting, interdit dans quasi tous les jeux.

On va donc dire que c'est pour faire de l'entrainement d'IA, hein, histoire de pas tout de suite signaler le thread aux administrateurs pour activité illégale.

Bon, on revient donc à des choses des plus connues et votre approche n'est plus nébuleuse, elle est complètement SAUGRENUE.

Les jeux, dans la très très très grande majorité, sont sous DirectX ou OpenGL, et toutes ces tambouilles, à base de GDI, ne servent à rien dans ce contexte.

Au mieux, cela ralentie à mort le jeu car lui et l'OS doivent jongler avec des contextes graphiques incompatibles, au pire ça fait planté le jeu, voire l'OS.

Tout ça pour l'afficher sur le même écran que le jeu au lieu de le mettre sur un second moniteur (un farmer chinois tellement radin qu'il n'achète pas de second écran, LOL). Et quel est l'intérêt pour un bot d'afficher en permanence des trucs ? C'est, en principe, un programme que l'on cherche à rendre le plus autonome possible, donc sans la moindre IHM.

S'il s'agit d'afficher des informations "In Game", il faut utiliser des technique d'overlay, déjà citées par un de me VDD, qui utilisent des framework dédiés à ce genre de chose, qui n'a rien à voir avec du GDI.

Vous n'avez pas à avoir votre putain de fenêtre "sur" un jeu pour que votre application puisse interagir avec le jeu, bien au contraire.

>Il serait donc utile d'avoir cette fenêtre au premier plan ...

Non, il serait bien plus utile qu'il soit sur un deuxième moniteur.

>On commence à voir le loup sortir du bois, du botting, interdit dans quasi tous les jeux.

Cet exemple est pour faire comprendre ce que je veux faire; je n'ai pas de but précis (de toute façon je n'ai pas trop le temps de jouer aux jeux videos en ce moment, car la prépa ça prend du temps !); je veux juste, par ce projet de créer une fenêtre qui puisse rester devant les fenêtres "topmost", mieux comprendre la programmation api windows et spécialement la gestion des fenêtres.

Donc si vous prenez ça comme une manière de tricher face aux jeux vidéos, vous vous trompez. Ma passion, c'est l'informatique, et non les jeux vidéos ! Par contre, un projet qui me tente vraiment (vous allez me dire que je rêve, je sais !) ça serait plutôt de me programmer mon propre explorateur de fichiers, mais pour cela il faut d'abord que je maitrise la gestion des fenêtres.

> une interface intra-game serai pas plus adaptée pour ce genre de besoins.

En fait, comme je le disais, je cherche plus à me confronter face à ce problème de fenêtre (quite à ne pas y arriver) et progresser ainsi dans la programmation avec l'api (depuis que j'ai lancé ce sujet, j'ai été éclairé sur pas mal de points), plutôt que de faire une interface intra-game et donc de contourner le problème de manière totalement différente (mon but final étant de comprendre comment marche le système de fenêtres et non de faire du botting comme dit Bacelar).

Merci tout de même de vos conseils !

PaulLenoir1 a écrit:

Par contre, un projet qui me tente vraiment (vous allez me dire que je rêve, je sais !) ça serait plutôt de me programmer mon propre explorateur de fichiers, mais pour cela il faut d'abord que je maitrise la gestion des fenêtres.

N'aie crainte ! L'explorateur de fichiers reste toujours à sa place, derrière la barre des tâches (qui est en réalité le menu démarrer au passage) !

PaulLenoir1 a écrit:

> une interface intra-game serai pas plus adaptée pour ce genre de besoins.

plutôt que de faire une interface intra-game et donc de contourner le problème de manière totalement différente

Pourtant, avant de se lancer dans un projet, on défini d'abord le(s) besoin(s) en détails pour savoir si ça vaut le coup. Puis on définit les outils et technologies les plus adaptées pour faire le boulot.
Faire un exercice "général" je comprend mais... C'est pas motivant, pas drôle, on retiendra bien moins qu'en s'amusant à créer quelque chose de concret.  En plus, on pourra pas le mettre sur le CV !

PaulLenoir1 a écrit:

mon but final étant de comprendre comment marche le système de fenêtres et non de faire du botting comme dit Bacelar.

Je dois t'avouer que je me suis également retenue. On passe d'un projet tellement vague à un truc super précis... Forcément, la première chose qui vient à l'esprit c'est "CGU CGU CGU CGU CGU" !

-
Edité par LilyKianii 25 octobre 2018 à 17:13:27

>Pourtant, avant de se lancer dans un projet, on défini d'abord le(s) besoin(s) en détails pour savoir si ça vaut le coup. Puis on définit les outils et technologies les plus adaptées pour faire le boulot.

En fait mon but n'est pas un projet en particulier, mais plutôt la maitrise d'un outil particulier; c'est pourquoi j'attache plus d'importance à l'outil utilisé (ici la mise en premier plan d'une fenêtre), qu'à la finalité du programme que je fais. En fait je n'ai pas spécialement d'idée de projet envisageable avec le temps que j'ai, donc de temps en temps je me donne un objectif, qui peux paraitre absurde, certes, mais qui me fait progresser en c++ (en même temps je n'ai pas de cours de c++, donc il n'y a qu'en lisant des tutos, testant et posant des questions sur des forums que je peux apprendre...).

Après je ne dis pas qu'un de ces objectifs auquel j'aurais réussi à venir à bout ne me servira jamais (à part progresser en c++), car tous les tests que je fais, je les garde et les trie par thème, et je peux les réutiliser le jour où j'en ai besoin dans un projet concret !

-
Edité par PaulLenoir1 25 octobre 2018 à 18:00:32

Ok, t'es en prépa, donc tu n'es pas en train de maintenir du code, alors pourquoi tu te fais chier à apprendre une API bas niveau, non portable, conçue il y a plusieurs décennies, t'es maso ?

Pour connaitre comment sont implémentées actuellement des bibliothèques graphiques de plus haut niveau, ou pour les étendre avec des fonctionnalités non portables, ça peut être utile, mais dans votre cadre d'apprentissage, c'est vraiment mettre les mains dans le cambouis et sans gants.

A un moment donné, il faut commencer à admettre des choses sans les dépiauter, sinon, vous allez devoir résoudre des équations de la physique quantique dans un transistor, et vous ne saurez toujours pas programmer un simple "Hello World".

Vous en faites pas, à un moment donné, vous allez mettre les mains dans le cambouis bien profond, si vous en faites votre métier, que vous le vouliez ou non.

Un truc que vous devriez aussi apprendre si vous voulez devenir développeur, c'est que chaque environnement graphique dispose de ses "guidelines" qu'il faut respecter, autant que faire ce peu.

Windows dispose donc d'un mécanisme de "top_most", mais il ne donne pas de quoi faire une "top_most war" parce que, si vous respectez les "guidelines" du système, vous devez être en bonne intelligence avec les autres applications et ne pas chercher à avoir la plus "grosse".

M$ s'est arrogé le droit d'utiliser des fonctionnalités non publiques pour implémenter des choses pour rendre le système utilisable, tant mieux. Ils n'ont pas à respecter à la lettre leurs "guidelines", du moment que cela reste cohérent. Si toi, tu les respectes pas, bin tu fais l'avion et tu pleures à chaque mise à jour.

Ce qui a été fait pour le gestionnaire de tâche sous Win10 est une tambouille interne qui potentiellement ne fonctionne que sous Win10 et peut-être pour pas très longtemps, donc complètement inutile à ton "apprentissage".

>mais pour cela il faut d'abord que je maitrise la gestion des fenêtres.

Et il faut commencez par maitriser les "guidelines" d'une IHM sous Windows, où il n'y a que 2 grandes catégories de fenêtres (si on ne compte pas ces cochonnerie de fenêtres modales), les top_most et les autres. Les top_most doivent vivre en bonne intelligence, donc pas de fenêtre plus top_most que les autres.

>ça serait plutôt de me programmer mon propre explorateur de fichiers

Ce n'est pas un projet très complexe.

Mais attention, "explorer.exe" est bien plus qu'un explorateur de fichier, il affiche des choses qui n'ont rien à voir avec le système de fichier et il est l'équivalent du shell de la console système sous Unix (gestion des variables d'environnement, ancêtre de tous les processus de la session, etc...), de l'affichage de la barre des tâches, du bureau, etc...

Si vous avez des besoins plus précis, on peut toujours contrevenir aux "guidelines", mais c'est pas gratuit, et il faut assumer l'énorme coût au long cours. Mais, par exemple, avoir une fenêtre systématiquement au-dessus d'une fenêtre d'une autre application/fenêtre, c'est gérable.

EDIT : On est en informatique, cela évolue très vite. Tes exercices ne vont pas être "valide" très longtemps. Ils doivent avoir une portée assez générale et "formateur", mais une fois fait, c'est juste les schémas de penser qu'il faut retenir.

-
Edité par bacelar 26 octobre 2018 à 11:05:27

Merci beaucoup Bacelar pour ces explications,

en fait dans le cadre de la prépa, on ne fait que du python, et pas très poussé puisqu'on ne traite même pas la programmation orientée objet, c'est pourquoi j'ai voulu chercher plus loin dans l'informatique; comme j'avais toujours rêver de pouvoir créer un exécutable (je n'avais fait que de la programmation interprétée genre python, java,... , donc la création de programmes compilés attirait ma curiosité). J'ai donc chercher, et je me suis dit que j'allais commencé par des choses "de base" avant d'utiliser des bibliothèques dont on ne sait pas comment elles marchent; j'ai commencé par me tourner vers l'assembleur, mais j'ai vite été déçu car je n'arrivait qu'à des programmes console assez basiques, donc j'ai cherché un peu plus haut niveau, et je suis tombé sur le cours de matheo21 sur le c/c++. Arrivé à la programmation graphique j'ai galéré pendant longtemps pour installer QtCreator et tout le bazard car le cours n'était plus du tout à jour en ce qui concerne l'installation de Qt. J'ai tout de même fini par y arriver et je me suis lancé dans la programmation de jeux du style tétris, sauf que je n'arrivait pas exécuter certains programmes en dehors de QtCreator (même avec toutes les dlls nécessaires), et en même temps j'étais curieux de savoir ce qui se cachait derrière cette énorme bibliothèque, donc j'ai laissé tombé Qt (probablement à tort) , et c'est là que je me suis lancé dans l'Api windows... Sauf que je me suis bien rendu compte que derrière cette Api il y "plein de choses" cachées au public ce qui a excité encore plus ma curiosité (en particulier sur le comportement de certains programmes comme le gestionnaire des tâches). Voilà où j'en suis maintenant, et je ne sais pas trop dans quoi me lancer...

>Mais attention, "explorer.exe" est bien plus qu'un explorateur de fichier, il affiche des choses qui n'ont rien à voir avec le système de fichier...

En effet j'ai bien remarqué que quand on tue le processus explorer.exe (vous allez me dire qu'il ne faut jamais faire ça, je sais...) il n'y a plus ni bureau ni barre des tâches, mais par contre les programmes sont toujours utilisables en les lançant par le cmd, donc ça m'a donné envie de créer un programme simplifié équivalent à explorer.exe, mais je ne sais pas si derrière ce programme il y a des choses indispensables au système ou non ?

-
Edité par PaulLenoir1 26 octobre 2018 à 14:46:47

Parcours/Galères assez classique d'un passionné d'Informatique.

De mon temps, il y a près de 30 ans, c'était pas python, qui est déjà très bien, mais Pascal (pas objet) ou matlab (sans commentaire), il y a quand même beaucoup de progrès.

Mais de mon temps, le Motorola 680X0 tenait encore la dragée haute au Intel 8086, j'ai donc pas trop souffert de l'horrible assembleur Intel.

>python, et pas très poussé puisqu'on ne traite même pas la programmation orientée objet

Python est un langage objet, il serait donc plus simple et toujours formateur de faire de l'objet avec ce langage.

Il n'y a pas une POO, il y en a plusieurs. La POO avec SmalTalk, Python ou C++ ne sont pas les mêmes.

Il y a de grands principes communs, mais il y a pas mal de choses qui divergent.

Il y a de grands principes communs en POO, comme SOLID, mais la manière de faire est bien différente en fonction des langages.

Je veux vous faire remarquer que même un "exécutable" est très largement interprété (µCode dans les CPU, architecture CISK/RISK, etc...) et que ce n'est pas un binaire autonome : les Dll, l'OS cible, le format du binaire, etc... sont des choses qui rendent quasi tous les programmes dépendant, seul les bootloader ne sont fonction que du BIOS/EFI et du CPU cible.

Faites attention à ne pas faire d'amalgame et des raccourcis trop hâtifs, Python est interprété mais il est assez facile de générer du code C depuis du Python et donc de faire du Python "exécutable". JAVA n'est pas un langage interprété, c'est un langage qui est compilé pour une Machine Virtuel (JVM) sous forme de byte-code et il est actuellement très courant de se passer de la JVM et de "JITer" tout le byte code à l'avance => un exécutable "comme les autres". Comme JAVA n'est pas interprété, il ne dispose pas (nativement) d'un typage dynamique des langages interprétés, comme JavaScript par exemple.

>donc la création de programmes compilés attirait ma curiosité

Qu'est-ce qui vous y attire ? Si c'est "l'autonomie", vous vous bercez totalement d'illusion.

>j'allais commencé par des choses "de base" avant d'utiliser des bibliothèques

Il y a bibliothèque et bibliothèque. Une bibliothèque pour un ORM, des réseaux de neurones, de calcul matriciel, OpenCV, etc... , ok, il faut d'abord apprendre le langage ET les concepts manipulés avant de les utiliser mais il faut utiliser les bibliothèques qui simplifient le travail dès que possible (la STL, Boost, une librairie graphique comme Qt, etc...).

>dont on ne sait pas comment elles marchent;

La très grande majorité des cas ces bibliothèques utilitaires sont Open Source, donc, si, on c'est très bien comment ça marche.

Après, il faut rentrer dans leur code bille en tête, il faut déjà bien comprendre comment s'en servir avant. Cela peut être très formateur de voir ces implémentations.

>donc j'ai cherché un peu plus haut niveau, et je suis tombé sur le cours de matheo21 sur le c/c++.

Le C et le C++ sont de plus au "niveau" que l'assembleur, clairement.

Le C et le C++ sont des langages complètement diffèrent maintenant, comme le Latin et le Français sont des langages "naturels" différents.

Le Cours de matheo21 sur le "c/c++" est très pédagogique mais est très très mauvais et il est à éviter comme la peste, c'est une calamité. Regardes sur le forum pour avoir des sources d'apprentissage bien meilleurs et à jour.

>car le cours n'était plus du tout à jour en ce qui concerne l'installation de Qt

Si ce n'était que sur "l'installation de Qt".

>sauf que je n'arrivait pas exécuter certains programmes en dehors de QtCreator

On peut te donner un coup de main pour ça.

>j'étais curieux de savoir ce qui se cachait derrière cette énorme bibliothèque, donc j'ai laissé tombé Qt

Alors pourquoi ne pas étudier le code source de cette bibliothèque ?

>l'Api windows

Ça n'existe pas, c'est un gros abus de langage.

Ici, c'est plus l'API Win32 de Windows, qui est une API C, pour permettre une utilisation plus ou moins directe par un grand nombre de langage "classique".

C'est pas vraiment l'idéal pour apprendre la POO mais plus pour faire de la bidouille système. Faire de la programmation graphique avec Win32, c'est un peu comme faire de l'assembleur dans du C, c'est vraiment quand il n'y a plus d'espoir. Les bibliothèques graphies sont bien plus simples ET bien plus puissantes que Win32. Les primitives non documentées ne font pas partie de Win32 et rien ne vous empêche de vous en servir dans une application Qt, sauf le fait d'être raisonnable et de ne pas se prendre la tête à reverse-engineerer les machins de M$. Win32 n'est pas inaccessible dans un programme Qt, vous pouvez mélanger les 2 mais faut pas faire nimportnawak.

>derrière cette Api il y "plein de choses" cachées au public

C'est pas vraiment caché, c'est juste non documenté. Cela permet à Windows de pouvoir modifier ces trucs sans avoir de problème de compatibilité ascendante des programmes. Mais, avec le Patriot Act et Trimp, je ne vous conseille pas de faire ouvertement du reverse-engeneering sur un OS qui est massivement employé par la défense américaine.

> je ne sais pas trop dans quoi me lancer...

Mais c'est quoi votre objetif ? Programmer des trucs sympa => usage de bibliothèques, voire de moteurs ; ou faire du hacking/reverse-enginerring et donc plus vraiment du développement au sens strict ?

>vous allez me dire qu'il ne faut jamais faire ça, je sais...

Si, si c'est le hacking qui t'intéresse.

>il n'y a plus ni bureau ni barre des tâches

Car c'est lui qui est en charge de leur affichage et gestion, comme de tout le reste de la partie visuelle d'une session.

>mais par contre les programmes sont toujours utilisables en les lançant par le cmd

Normal, le cmd a juste perdu son programme parent, ça fait longtemps qu'il est sevré.

>donc ça m'a donné envie de créer un programme simplifié équivalent à explorer.exe

Là, vous n'imaginez pas ce qu'est tout ce bordel. Il gère toute une session utilisateur.

Quand il meurt, au bout d'un certain temps, le Kernel en relance un, histoire que la session utilisateur ait de nouveau une interface graphique.

>il y a des choses indispensables au système ou non ?

Non, c'est plutôt l'utilisateur qui en a besoin.

Vous n'imaginez pas le nombre de programme, de driver, de Services Windows de tout poil qui fonctionne avant même qu'un utilisateur ne se connecte. "explorer.exe" n'est lancé qu'à la fin du processus de connexion d'un utilisateur, pas avant.

L'OS, il s'en cogne pas mal d'explorer.exe.

>Mais c'est quoi votre objetif ? Programmer des trucs sympa => usage de bibliothèques, voire de moteurs ; ou faire du hacking/reverse-enginerring et donc plus vraiment du développement au sens strict ?

Pour le moment mon objectif est plutôt de comprendre l'outils sur lequel je travaille, à savoir windows, dans la mesure  du possible. Ensuite pourquoi pas développer une application...

>Les bibliothèques graphies sont bien plus simples ET bien plus puissantes que Win32.

J'ai donc dû mal comprendre les tutos que j'avais lus, car j'avais cru comprendre que les bibliothèques graphiques étaient justement basées sur l'API Win32, et qu'elle permettaient de simplifier la vie à l'utilisateur en lui masquant la difficulté de cette API; j'avais aussi compris qu'on était obligé de passer par cette API (ou par une bibliothèque qui elle-même passe par cette api) depuis que windows n'était plus en mode réel.

>Les primitives non documentées ne font pas partie de Win32...

Mais alors elles font partie de quoi ?

>L'OS, il s'en cogne pas mal d'explorer.exe.

Donc explorer.exe ne sert qu'à l'interface graphique et non au système d'exploitation lui-même; on peut donc (je ne dit pas que c'est faisable de manière simple) le remplacer par une autre interface sans problème ? Pourtant il semble que l'api win32 utilise ce processus, puisqu'elle propose d'afficher une icône dans la barre des tâches ou de ne pas le faire, ... ?

-
Edité par PaulLenoir1 26 octobre 2018 à 17:48:57

Bon, OK, vous faites partie de l'équipe des "bleu" dans les profiles psycho-bullshit, vous voulez tout démonter avant de vous servir d'un truc. Vous savez, ça se soigner très bien de nos jours.

Bon, si vous voulez comprendre comment fonction Windows ACTUELLEMENT ( oui, ça bouge assez souvent, bien plus que l'API Win32, d'où l'intérêt d'utiliser l'API et pas des bidouilles), c'est pas vraiment en développant (pu qu'en développant) que vous allez maitriser la chose.

Comprendre comment fonctionne Windows en interne et comment se servir des API de Windows (Win32, COM, DirectX, etc...), c'est 2 choses complètement différentes. Savoir comment cela se passe à l'intérieur de Windows peut avoir un intérêt pour faire de l'optimisation ou de la programmation système très poussée. Mais il faut déjà très bien maitriser les API avant tout, car elles changent beaucoup moins souvent et permettent aussi de comprendre les choix d'implémentation dans l'OS.

Si vous voulez vraiment savoir comment fonctionne Windows en interne, il faut prendre des bouquins dédiés à cela et très récents, pas un sombre cours obsolète qui raconte beaucoup de bêtise ou des tuto Youtube.

Un bouquin de référence dans le domaine "Windows Internals":

https://docs.microsoft.com/en-us/sysinternals/learn/windows-internals

Je n'ai pas lu de versions récentes mais c'était du tout bon et c'est mise à jour régulièrement (le second tome de la 7ème édition n'est pas encore sortie). Je ne vous conseille pas de l'acheter à l'aveugle, essayez dans trouver un exemplaire pour voir s'il n'est pas trop complexe pour vous, ce n'est pas un livre d'initiation, c'est une "Somme".

Si des personnes ont d'autres sources, n'hésitez pas.

Vous pouvez très bien être un très bon programmeur "généraliste" sans rien savoir de comment Windows est fait à l'intérieur, bien au contraire. Un programmeur doit faire des programmes assez souples et simples pour passer sans encombre d'un OS à un autre ou d'une version d'un OS à une autre.

>est plutôt de comprendre l'outils sur lequel je travaille

L'outil sur lequel vous travaillez est plutôt une machine de Turing, selon une architecture conçue, à la base, par Van Neumann, avec un CPU gravé par Intel ou AMD, sur lequel tourne un programme "Windows" qui n'est pas le seul à faire ce genre de boulot.

Généralement, quand on développe, on essaye d'être le plus portable possible entre les OS. Windows n'est plus aussi hégémonique qu'à mes débuts. On programme aussi pour OSX, iOS, Linux, Les Unix, et plein d'autres OS qui ne sont pas forcément, et même très rarement, conçus comme Windows.

>Ensuite pourquoi pas développer une application...

Mais quel est votre objectif à moyen terme ? Administrateur , Hacker, développeur système, expert sécurité, etc...

>les bibliothèques graphiques étaient justement basées sur l'API Win32

Sous Windows oui, mais la très grand majorité de ses bibliothèques sont portées sur des OS autres que Windows. Elles n'utilisent Win32 que sous Windows et elles sont assez bien conçues pour faire leur travail sur plein d'OS différent, qui n'ont pas Win32.

La partie que vous utilisez de Win32, le GDI, n'est pas la seule à faire du graphisme, DirectX le fait aussi, et bon nombre de fonction du GDI utilise en interne DirectX. Certaines de des bibliothèques graphiques n'utilisent pas le GDI mais directement DirectX ou d'autres bibliothèques graphiques de bas niveau, comme OpenGL qui n'utilise pas le GDI mais directement des drivers dane le Kernel.

>et qu'elle permettaient de simplifier la vie à l'utilisateur en lui masquant la difficulté de cette API;

Oui, tout à fait, cela simplifie le travail mais ces bibliothèques offrent aussi des fonctionnalités bien supérieures à celles du GDI. Elles ne font pas qu'un Design Pattern Façade (simplification d'une interface de programmation) du GDI, elles offrent des fonctions qui demanderaient des centaines ou des milliers de lignes en GDI "de base".

>j'avais aussi compris qu'on était obligé de passer par cette API

Non, elles ne sont pas "obligées", mais beaucoup le faut car c'est simple à faire (plus que DirectX par exemple).

>depuis que windows n'était plus en mode réel.

Houlà, on n'est reparti en 1990 avec Windows 3.x. Gars, c'était même pas un système d'exploitation. Il fallait lancer DOS avant et ce n'était qu'un simple environnement d'exécution coopératif (un programme qui déconne et toute la machine part en sucette).

Il y a eu bien des évolutions depuis, et beaucoup.

Win32 n'était qu'un sous-système parmi d'autres, comme le sous-système compatible OS/2 d'IBM ou le sous-système POSIX pour le vendre aux militaires.

Je suis même pas sûr que le sous-système POSIX n'existe plus.

Et même les interruptions DOS ont perdurées un bon moment, et faire le con avec le BIOS c'était facilement faisable sur les OS non NT (Win95, Win98, WinMe).

Donc, non, Windows ne se résume pas à Win32, très loin de là.

>Mais alors elles font partie de quoi ?

De rien de spéciale.

Win32, c'est juste une documentation qui liste une série de fonction C, des .h pour déclarer ces fonctions et des .lib pour appeler ces fonctions (elles contient rarement du code mais servent plus d'intermédiaire entre votre code et des dll qui implémentent de sous-système Win32, ou d'autres API comme la NTAPI, qui est l'interface "native" entre le Kernel et le mode User).

Si, malicieusement, vous ne donnez pas le nom d'une fonction dans la documentation, que vous ne la déclarer pas dans l'un des .h qui sont fournis avec votre SDK (WinSDK), mais dans un .h privé, chez M$. Vous obtenez quoi ?

Une fonction non documentée, que seul les personnes ayant accès au .h privé pourront facilement utilisées et directement utilisable car le .lib contient le point d'entrée de la fonction. Elle n'est pas "cachée", elle est juste pas documentée. Après, on peut aussi ne pas mettre le point d'entrée de la fonction dans le .lib fourni dans le SDK, c'est un peu "plus" caché, mais appeler une méthode exportées par une Dll même sans .h ni .lib, c'est pas super compliqué non plus.

"Techniquement", rien ne distingue une fonction de l'API et une fonction non documentée, juste "l'oublie" dans quelques fichiers.

>Donc explorer.exe ne sert qu'à l'interface graphique

Et à l'initialisation d'informations liées à la session utilisateur.

>et non au système d'exploitation lui-même;

Non, Windows distingue 2 niveaux d'exécution (User et Kernel), les fameux Ring3 et Ring0 des architectures Intel. la majorité de l'OS s'exécute en Ring0, dans des zones non accessibles par les programmes "Users".

>le remplacer par une autre interface sans problème ?

Sans aucun problème (si vous êtes admin):

https://superuser.com/questions/1016380/how-do-i-replace-the-system-shell-explorer-exe-with-another-process-in-windows

>Pourtant il semble que l'api win32 utilise ce processus,

Non, c'est l'inverse, explorer.exe utilise Win32, et bien d'autres fonctions non documentées pour faire son job.

>puisqu'elle propose d'afficher une icône dans la barre des tâches ou de ne pas le faire, ... ?

C'est le GDI/Kernel qui stocke et l'explorer.exe qui demande quoi afficher aux GDI via, très probablement des fonctions non documentée, ou dans une documentation dédiée à la création d'"Extention Shell" (C'est plus vraiment du Win32 mais plutôt du COM).

Ok, c'est plus compliqué que ce que je pensais ...

En fait je pensais que l'api win32 était la seule "passerelle" entre le mode user et le mode noyau (c'est pourquoi je pensais qu'on était obligé de passer par elle directement ou indirectement). Est-ce la NTAPI qui jouerait ce rôle de passerelle, ou y a-t-il plusieurs passerelles différentes en parallèle entre le mode user et le mode noyau ?

>Mais quel est votre objectif à moyen terme ? Administrateur , Hacker, développeur système, expert sécurité, etc...

Pour le moment je ne me suis pas encore construit d'objectif précis (il faut d'abord que j'ai un peu une vision d'ensemble dans tout cela pour faire un choix précis); je travaille l'informatique en tant que passion, donc pour le moment ça serait plutôt du hacking, dans ce sens donné sur wikipedia:

" Derrière le terme hacker « se cachent des utilisateurs à part, qui préfèrent fouiller dans les entrailles d’un ordinateur plutôt que simplement l’utiliser ». Les motivations principales du hacker sont « la passion, le jeu, le plaisir, l’échange et le partage » "

-
Edité par PaulLenoir1 26 octobre 2018 à 21:34:45

C'est assez normal, ces notions n'ont même pas de définition strictes.

Win32 n'est pas la seule passerelle mais elle est très largement majoritaire.

Mais elle n'a pas été conçue pour être la seule et unique.

NTAPI, c'est un peu la couche inférieure de l'architecture NT coté User. Mais elle n'a pas été conçue pour être publique, c'est plus un besoin interne pour implémenter les différents sous-systèmes (OS/2, POSIX, Win32, etc...).

Mais, comme elle n'est pas vraiment "officielle", rien ne les empêchent de supprimer NTAPI s'ils changent de technologie Kernel.

Après, pour implémenter des choses de manière très performantes, des trucs totalement spécifiques, comme pour juste Internet Explorer, ont été intégré à la table des appels système du Kernel Windows, court-circuitant complètement l'architecture "standard".

Donc, quand on commence à creuser, il y a toujours des cas particuliers, qui n'ont aucun intérêt pour le développeur d'application "standard" mais qui peut fortement intéresser un expert en sécurité.

Si tu peux mettre la main sur un exemplaire de "Windows Internals", je pense que ta vision du domaine sera "révolutionnée".

> Si tu peux mettre la main sur un exemplaire de "Windows Internals", je pense que ta vision du domaine sera "révolutionnée".

J'ai trouvé la version 6 première partie en pdf (sachant que la dernière version est la 7, mais je pense que la 6 pourra toujours m'être utile pour mieux comprendre le fonctionnement de windows)

> mais qui peut fortement intéresser un expert en sécurité.

J'ai cherché quelques pages web parlant de cela, et je suis tombé sur le hooking qui a l'air d'être très utilisé en cyber-sécurité, mais qui m'a l'air assez compliqué à mettre en place tant que je n'ai pas de fondement plus solide sur le fonctionnement de windows...

Merci beaucoup du temps passé !

Le hooking, c'est autre chose.

C'est une fonctionnalité purement user (si on prend le terme au sens strict) et non Kernel) qui permet d'avoir des fonctionnalités très particulières, de monitoring "global" de la session utilisateur et de ses actions.

On peut détourner ces fonctionnalités pour implémenter des pièges ou tenter des intrusions.

Mais ces fonctionnalités sont de plus en plus remplacer par de nouvelles bien plus sûres au niveau sécurité.

La 6ème édition de "Windows Internals" date de Win7 je crois. Cela toujours formateur, même s'il n'est pas 100% à jours. Il doit déjà adresser beaucoup de vos interrogations de "hacker".