Salut,
 
Je viens du monde Linux ou j’ai pas mal de connaissances système et sécurité. Pour ce qui est Windows par contre, je suis nul et je voudrais m'y mettre.
 
Je connais le C, mais je voudrais savoir s’il existe pour Windows, quelque chose du genre « Programming from the ground up », qui est un excellent petit livre pour Linux qui est transversal et introduit les concepts en partant des bas-niveaux au plus haut niveau. Donc par exemple ca commencait avec un peu d’assembleur, puis les syscalls, puis la facon dont un compilateur marchait, puis les librairies, le tout saupoudré de la facon dont Linux fonctionne.
 
Je pourrais foncer tête baissée dans les API de Windows mais j’aimerais aussi connaitre l’environnement sous-jacent de cet OS et de ce qui y tourne, donc tous conseils sont bienvenus.  

Ce sujet a été déplacé de la catégorie Windows & Software vers la categorie Programmation par Wolfman

Qu'est ce que tu cherches à connaitre de l'API windows ? L'API est extrêment vaste et pas des plus digestes pour certaines parties. La partie graphique (comctl, OLE, GDI, ...) est assez bas niveau et a plutôt mal vieillit. C'est plus que probable que tu vas perdre ton temps à t'investir là dedans plutôt que d'utiliser des API de plus haut niveau.
 
Sinon, il y a la partie programmation système de windows, celle là par contre n'est pas si différente de Linux. Évidemment les noms des fonctions sont différentes, mais pour l'immense majorité des cas, il y a équivalent plus ou moins direct entre une fonction POSIX et l'API Win32 (par exemple l'API des sockets BSD est pratiquement identique). La seule exception qui me vienne à l'esprit est la fonction fork(). Windows est plutôt orienté thread que processus. Il est possible d'émuler fork() sous windows (via cygwin), mais on sent que le système n'a pas été prévu avec ça en tête.
 
Si tu connais bien l'API système Unix, tu pourras facilement t'en sortir avec une recherche web, du genre "equivalent to function xyz win32". Perso, c'est que j'avais fait lorsque je suis passé des systèmes Unix à Windows. L'exception étant la partie graphique (API C), elle est vraiment unique à ce système: c'est conçu pour être bas niveau et pas pour aider le programmeur.
 

Ca tombe bien, car la partie graphique ne m'interesse pas. Ce qui m'interesse c'est surtout la gestion des ressources et des objets qui dans le cas de Windows, car si les principes de base ont l'air de rester les meme il y a pas mal de details qui changent, ne serait-ce que la facon dont les permissions fonctionnent.

Salut, voici des liens pour se documenter sur la WinAPI (dans le lien, à la section X/): http://hackasm.5gb.co/Projects/Com [...] tml#WinAPI

Après si tu veux, tu as la possibilité de voir directement les noms des fonctions dans les dll ( http://www.nirsoft.net/utils/dll_export_viewer.html ), que tu rentres dans bing et choisis le lien sur msdn pour te renseigner sur ladite fonction

Merci.

Attention, les API Windows, même pour les opérations bas niveau ont énormément évolué au fil des versions pour en simplifier l'usage.
Par exemple il y a beaucoup de choses qui sont maintenant disponibles par des APIs managées, qui évitent de faire du PInvoke.

Ta réponse sur ce que tu souhaites apprendre n'était pas du tout claire. Tu risques de passer beaucoup de temps à apprendre des trucs de plus en plus obsolètes si tu ne tiens pas compte de ce type de chose.

Euh, j'ai un peu du mal à cerner ce que tu veux dire, qu'elle soit évoluée ou pas ça ne change rien, elles sont toutes localisées dans C:\Windows\System32\ principalement et évolue via Windows update (tu peux vérifier par regarder le nombre de fonctions ajoutée à chaque update via dll exporter), donc apprendre la WinAPI n'a rien d'obsolète, de plus tu le dis toi même, elle évolue sur elle même.

Parles-tu des API surcouches ? Comme la SDL et toute la clique ?
Elle complique et complexifie le protocole plus que la WinAPI le fait déjà et même si tu mets plus de temps à refaire des concepts que ce que la WinAPI n'a pas à offrir, avec elle, elles seront toujours plus adaptées (petits détails qui ont leur importance) pour ce que tu veux faire qu'avec une bibli générique.

Que tu le veuilles ou non, n'importes quel programme est dans l'obligation d'utiliser cette API low level, ce n'est rien que des fonctions offertes par les créateurs de MS pour que nous, toi, puissions faire des programmes sur leur OS, même ta lib de gcc est obligée de passer par la WinAPI quand elle doit être injectée dans un programme windows.

https://msdn.microsoft.com/en-us/library/2x8kf7zx.aspx est juste une manière d'interagir avec les fonctions de ces dll, sinon tu peux passer via le linker, que ça soit lib statique (.lib) ou lib dynamique (.dll), ça ne change rien.

Et finalement, la communauté msdn est plus que présente ( https://social.msdn.microsoft.com/Forums/en-US/home ), peut-être qu'en france on n'en a rien à faire, dû à ce qu'on apprend dans les écoles d'infos (95% Linux/gcc), mais à l'étranger ce n'est pas le cas.

> Que tu le veuilles ou non, n'importes quel programme est dans l'obligation d'utiliser cette API low level
 
Ce qu'il te dit, si j'ai bien compris, c'est que l'interface peut de nos jours être low level, et que l'implémentation peut en fait être du code .NET (qui s'exécute dans l'environnement de la machine virtuelle CLR) et non pas une exécution directe de code compilé stocké dans une dll.  
 
A+,

 
Je le sais déjà cela:
 
 
 
Ce que j'ai plutôt compris dans son message, c'est plus l'apologie envers ces lib surcouches telles que la SDL, c'est sûr que c'est bien par moment (enfin perso je n'ai plus d'intérêt), mais encore faut-il ne pas rentrer dans l'excès et ne jurer que par ce type de lib, même si c'est pour avoir un code "portable", pour cela que je les appelle des lib hippies (peace and love entre OS) x)
 
Autre petit problème:
 Pourquoi attendre des lustres que la lib générique se mette à jour alors qu'une nouvelle fonction a été intégrée dans la bibli standard de l'OS la veille ?
 
 
Du moins ces deux points de vue convergent dans les grandes lignes x)