Bonsoir à tous,
Je ne cherche pas à lancer un débat sans fin ou à déchainer les foules
Est-il encore utile d'apprendre l'API Win32 ?
Plusieurs personnes m'ont dit que c'était inutile car bientôt obsolète, j'aimerais votre avis.
Merci d'avance.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
API Windows utile
Bonsoir à tous,
Je ne cherche pas à lancer un débat sans fin ou à déchainer les foules
Est-il encore utile d'apprendre l'API Win32 ?
Plusieurs personnes m'ont dit que c'était inutile car bientôt obsolète, j'aimerais votre avis.
Merci d'avance.
Inutile et obsolète certainement pas. Elle ne sera réellement obsolète que lorsque la totalité du parc Windows sera passer en 64 bits (pour l'API Win32x86, restera l'API Win32x64).
l'API Win32 est la base, le cœur du système Windows et les framework et autres machines virtuelles ne sont que des sur-couches rajoutées entre le code du programmeur et l'API.
ALors si tu ne destine qu'à faire du code sur du framework, managé, sur machine virtuelle, ou que sais-je, sans jamais utiliser directement les fonctions de l'API, alors oui tu peux ne pas l'apprendre.
Par contre si tu veux faire du code dit natif en C notamment, ou des drivers par exemple, l'API est nécessaire.
--- Sevyc64 ---
Parce que le partage est notre force, la connaissance sera notre victoire
Merci de ta réponse.
J'avais peur de me lancer dedans (c'est pas facile à vrai dire l'API Win32) sans savoir si dans le futur ça m'aurait servi ou non..
en aucun cas c'est obsolète....Envoyé par poneyrose
1-VC++ est toujours commercialisé et Microsoft développe toujours les MFC
2-les API Windows sont utiles pour certains SDK comme Direct X par exemple voire Open GL
3-même pour .NET c'est utile étant donné que Microsoft n'a pas totalement réussi à intégrer les API dans .NET
Surtout que .Net utilise lui-même en interne les API Win323-même pour .NET c'est utile étant donné que Microsoft n'a pas totalement réussi à intégrer les API dans .NET
Comme je disais avant, .Net n'est qu'une surcouche (pas totale, c'est vrai) de ces API
--- Sevyc64 ---
Parce que le partage est notre force, la connaissance sera notre victoire
pas totale? tu peux expliquer? avec sources et tout ça svp? je suis sceptique (et ça m'interresse).
l'api win32 est la base de l'OS, qu'on fasse un fopen en C ou un MaSuperFonctionDouvertureDeFichier en LeLangageDeLaMortQuiTue, au final on aura un appel à ntcreatefile non?
de plus j'ose esperer qu'on aura jamais de kernel dévellopé en C#, ni de driver.
bref, c'est utile tout dépend ce que tu veux faire plus tard
“La seule révolution possible, c'est d'essayer de s'améliorer soi-même, en espérant que les autres fassent la même démarche. Le monde ira mieux alors.”
Je pense qu'il voulait dire surcouche mais "pas que" de l'API.
Salut,
Oui très certainement
Le plus simple pour t'en convaincre c'est de faire un petit programme en C en mode console avec un simple main() et tu traces en assembleur
Mais je suppose que tu l'as déjà fait
Microsoft avait dans ses cartons ce genre de projet notamment un OS entièrement en code "managed" qui s'appelait Midori mais je crois qu'il est tombé à l'eaude plus j'ose esperer qu'on aura jamais de kernel dévellopé en C#, ni de driver.
bref, c'est utile tout dépend ce que tu veux faire plus tard
http://en.wikipedia.org/wiki/Midori_(operating_system)
Pour le coup de fopen():
À ma connaissance, fopen() appelle _open() qui appelle CreateFile() qui appelle NtCreateFile() qui appelle KiFastSystemCall(), et le kernel appelle ZwCreateFile().
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
ils sont
On disait la même chose des inventeurs de l'operating system.
Ben non, c'est tout-à-fait normal:ils sont
- Fonction du Kernel ZwCreateFile() : Indispensable, c'est la cause de tout.
- Séparation Kernel/User KiFastSystemCall() : La base d'un OS moderne.
- Fonction user NtCreateFile() : Normal, elle expose toutes les fonctionnalités d'ouverture de fichier que le kernel offre.
- Fonction API Windows CreateFile() : Celle-là est plus dure à justifier, pourquoi ne pas utiliser NtCreateFile() directement? Peut-être des histoires de legacy avec Win 3.11? Ou bien tout simplement pour se donner un peu de liberté quand à l'API native.
- Fonction POSIX-like _open() dans la libc : Microsoft se casse le cul pour que les POSIX-maniaques d'EPITA ne soient pas trop désorientés, alors autant ne pas cracher dessus!
- Fonction standard C fopen() dans la libc : Indispensable. Aurait pu appeler directement une fonction de plus bas niveau s'il n'y avait pas l'exigence de POSIX.
En fait, à part l'étape CreateFile(), tout coule de source ou est une concession à POSIX.
En comparaison, tu as les OS POSIX:
- Fonction du kernel (nom inconnu) : Indispensable, c'est la cause de tout. On remarquera qu'elle propose moins de fonctionnalités que ZwCreateFile(), en partie parce qu'une beaucoup sont déléguées vers d'autres fonctions comme ioctl(). Aussi, cette fonction utilise les droits rwxrwxrwx au lieu d'une ACL.
- Code assembleur pour appeler le kernel: Ici, le code est recopié au lieu d'être centralisé, c'est un choix.
- Fonction POSIX open() : Normal, elle expose toutes les fonctionnalités d'ouverture de fichier que le kernel offre. Et en bonus, elle est directement compatible posix!
- Fonction standard C fopen() dans la libc.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Oui, des génies aussi.On disait la même chose des inventeurs de l'operating system.
@Medinoc
Merci, j'avais fait abstraction de POSIX dans mon constat, heureusement que tu es là
CreateFile n'est pas NtCreateFile car la technologie NT, dont est issue les OS récent de M$, devait gérer de manière cloisonnée les API Windows et les API POSIX pour prétendre à équiper l'armée américaine.
Donc pas d'implémentation POSIX au dessus de Win16/32.
Ah oui, les "Windows Services for Unix", le "POSIX Subsystem", psxss.exe... Dommage qu'il faille payer un supplément pour les avoir.
(note: au passage, note le "POSIX-like" pour _open(), pour bien marquer la différence entre le _open() de la CRT et le vrai psxss...)
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager