Une erreur dans cette actualité ? Signalez-le nous !
Principalement les programmeurs système, les programmeurs de jeux, et les fournisseurs de composants qui proposent des "addons" sous forme de DLL Win32, seul format compatible avec tous les langage de programmation Windows, à condition d'utiliser la convention d'appel _stdcall au lieu de _cdecl.
Bien entendu pas question de MFC ni d'ATL et encore moins de DotNET  Quelques avantage qui résultent de l'utilisation directe de l'API Windows bas niveau : - Il n'y a aucune encapsulation, donc pas de Framework supplémentaire à télécharger. - Le code est très rapide et très compacte car tout est déjà dans la Flat API de Windows. - On peut contourner les bugs des langages "évolués". - On peut créer ses propres composants. etc. Pour ceux qui parlent anglais, voir ma profession de foi ici : http://www.jose.it-berater.org/smffo...p?topic=1129.0 et pour ceux qui veulent en apprendre plus sur la programmation bas niveau (en anglais), voir là : http://www.jose.it-berater.org/smffo...hp?board=151.0 ... hello Patrice,
Bien entendu pas question de MFC ni d'ATL et encore moins de DotNET
 Bonjour,
Si j'ai bien compris, la cinquième édition du livre de Charles Petzold SDK est 'culte'. Je me souviens avoir acheté un des tout premiers bouquin en américain sur les API. Un pavé dans les 1300 pages. Cordialement
Qu'entends-tu par là ?
Sous prétexte que le code "managé" est plus sûr que le code bas niveau qui lui est "unsafe", résultat les jeunes informaticiens ne savent plus programmer en utilisant directement le SDK, et il sont incapable d'écrire le moindre bout de code avec un simple éditeur ASCII et un compilateur en ligne de commande, et je ne parle même pas de la taille du code généré. Je programme de temps en temps en C#, mais ne l'utilise jamais en production, uniquement pour des démos. Car je ne supporte pas d'attendre 45 secondes avant de pouvoir afficher "Hello world" la première fois qu'il doit charger le Framework DotNET. En outre comme le code IL n'est pas du véritable code compilé, il est impossible de l'exécuter sans "run-time", dans ces conditions je préfère utiliser WinDev. Concernant MFC et ATL, ils ne fonctionnent pas sans le CRT Microsoft, alors bonjour la galère quand la bonne version n'est pas installée sur la machine des clients, ou alors il faut utiliser à chaque fois un installateur, donc pas question d'envoyer simplement un ZIP avec juste l'EXE. Et comme je n'utilise pas la POO je n'ai rien à faire de MFC (Microsoft Foundation Class). ...  Envoyé par Patrice Terrier
L'avantage de l'IL par rapport à Windev, c'est que le framework (au moins en version 2) est déployé nativement sur la plupart des versions de Windows. Concernant les API, pourquoi pas quand on a besoin de performances maximales, sinon le reste du temps, c'est une "bétise" de se passer des framework, ceux ci apportent des fonctionnalités testées et validées. Pourquoi réinventer la roue à chaque fois ? En allant à l’extrême, tu devrais te mettre à l'assembleur, cela semble bien correspondre à ta forme de pensée, mais ce n'est pas parce que tu penses d'une certaine manière que celle ci est la meilleure :/ La réciproque es tout autant valide. Juste pour mon information, quand tu codes et que tu as besoin d'afficher une fenêtre, tu codes toi même, à chaque fois, la boucle de gestion des messages ?
Le code Winev n'est pas plus compilé que l'IL et Windev à tout autant besoin d'un runtime.
Concernant les API, pourquoi pas quand on a besoin de performances maximales, sinon le reste du temps, c'est une "bétise" de se passer des framework, ceux ci apportent des fonctionnalités testées et validées. Pourquoi réinventer la roue à chaque fois ?
Je ne cherche pas non plus à réinventer la roue, puisque déjà tout existe dans l'API bas niveau 
En allant à l’extrême, tu devrais te mettre à l'assembleur, cela semble bien correspondre à ta forme de pensée, mais ce n'est pas parce que tu penses d'une certaine manière que celle ci est la meilleure.
Par contre quand je dois écrire des applications complètes, je fais appel à WinDev, c'est pour cela qu'il fait partie de ma boîte à outils. Concernant l'assembleur, pourquoi pas, lorsque c'est nécessaire... Voici un exemple de calcul matriciel utilisé dans la version 32-bit de GDImage.dll (écrit en PowerBASIC)
Juste pour mon information, quand tu codes et que tu as besoin d'afficher une fenêtre, tu codes toi même, à chaque fois, la boucle de gestion des messages ?
... hello,
je suis tout à fait d'accord avec DephiManiac concernant dotnet. Il est vrai que depuis windows 7 le framework dotnet est intégré à toutes les versions de windows. Sachant que c'est microsoft qui le produit autant dire que son intégration à windows est optimale. Patrice tu dis que tu attends 45 secondes pour que dotnet se lance la première fois, cela m'étonne fortement tu dois avoir un processeur un peu lent  . L'avantage a l'utiliser dans windev par rapport aux api c'est que les objets dotnets sont vus comme des classes avec leurs methodes et leurs propriétés. Beaucoup plus facile à interfacer qu'avec les apis. Bien sur tout n'est pas parfait et il y a des assemblages dotnet que l'on arrive pas à utiliser dans windev mais la plupart du temps cela fonctionne.Ami calmant, J.P Monsieur JP
L'avantage a l'utiliser dans windev par rapport aux api c'est que les objets dotnets sont vus comme des classes avec leurs methodes et leurs propriétés. Beaucoup plus facile à interfacer qu'avec les apis.
... Même chez Microsoft, il est arrivé qu'on utilise le SDK pour contourner la lenteur de .Net.
Il y avait un article de blog de l'équipe Visual Studio qui expliquait comment ils faisaient apparaître le splash screen de VS2010 et pourquoi (lenteur de chargement avec .Net). Microsoft se ré-intéresse au C++ depuis quelques temps, et au lieu de faire une API "tout .Net" comme certains le prédisaient, il ont fait WinRT... Personnellement, je pense que vous avez tous raison, seulement vous ne développez pas les mêmes choses. WinDev n'est pas dépendant de .Net, donc une "extension" à WinDev ne doit pas l'être non plus. Comprendre le fonctionnement interne d'une appli Windows me paraît utile, car WinDev se calque pas mal dessus. Un exemple simple : TimerSys() ne fait qu'un SetTimer(), qui génère un message WM_TIMER, donc un événement de l'IHM, et non un traitement parallèle comme peuvent le penser des débutants. J'ai moi aussi développé des extensions à mes applis WinDev sous forme de DLL natives et elles n'utilisent évidemment aucun framework à la noix (genre MFC), il faut que ça soit léger, rapide, fiable et sans dépendances. De toute façon, ce que je fais avec est plus facilement écrit en C++ qu'en un quelconque langage .Net. Monsieur Hibernatus34
Vous avez tout à fait raison. Microsoft est entrain (une nouvelle fois) de faire machine arrière, pour générer à nouveau du code qui ne nécessite pas un Framework monstrueux (DotNET) et qui soit capable de tourner sur des tablettes... ANDROID (sic), la concurrence a du bon, merci Google ! Retour à la case départ. PS : GDIPLUS et même DWM sont écrits en mode procédural et en code dit "unsafe" !!! Note : code "unsafe" = code qui manipule des pointeurs pour adresser directement les registres du CPU. C'est la seule chose que comprenne le code machine (assembleur), avec entre autre l'instruction JUMP qui n'est rien d'autre qu'un GOTO  ... |
Copyright © 2000-2019 - www.developpez.com
Partenaire : Hébergement Web
