Version imprimable
Bonsoir à tous,
Je ne cherche pas à lancer un débat sans fin ou à déchainer les foules :ccool:
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.
Merci de ta réponse. :ccool:
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....Citation:
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 Win32Citation:
3-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
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
Je pense qu'il voulait dire surcouche mais "pas que" de l'API.
Salut,
Oui très certainementCitation:
Envoyé par sloshy
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 :D
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'eauCitation:
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
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().
ils sont :cfou:
On disait la même chose des inventeurs de l'operating system. :zoubi:
Ben non, c'est tout-à-fait normal:Citation:
Envoyé par minnesota
- 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.
Oui, des génies aussi. :mrgreen:Citation:
Envoyé par bacelar
@Medinoc
Merci, j'avais fait abstraction de POSIX dans mon constat, heureusement que tu es là :mrgreen:
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...)