学习低级WinAPI编程还有意义吗?

Cam*_*pka 52 windows winapi

拥有所有C#管理的幸福,回到Petzold的编程Windows并尝试使用纯WinAPI生成代码是否有意义?

可以从中学到什么?是不是太过时了有用?

OJ.*_*OJ. 61

这个问题接近于宗教:)但无论如何我会给出我的想法.

我确实看到了学习Win32 API的价值.大多数(如果不是全部)GUI库(托管或非托管)都会导致对Win32 API的调用.即使是最彻底的库也不能覆盖100%的API,因此总是存在需要通过直接API调用或P /调用来插入的空白.API调用周围的一些包装器名称与底层API调用具有相似的名称,但这些名称并不完全是自我记录的.因此,理解底层API及其中使用的术语将有助于理解包装器API及其实际操作.

此外,如果您了解框架使用的基础API的性质,那么您将在给定方案中应该使用哪些库功能做出更好的选择.

干杯!


pae*_*bal 22

在学习Win32 API之前,我保持标准的C/C++多年,而且直言不讳,"学习Win32 API"部分并不是我生命中最好的技术经验.

一方面Win32 API非常酷.它就像是C标准API的扩展(fopen当你可以拥有它时需要CreateFile.但我猜UNIX/Linux/WhateverOS具有相同的Gizmo功能.无论如何,在Unix/Linux中,他们拥有"Everything is a file".在Windows中,他们有"一切都是......窗口"(不开玩笑!看CreateWindow!).

另一方面,这是一个遗留API.你将处理原始C和原始C疯狂.

  • 就像告诉一个人的结构自己的大小来传递void *指向某个Win32函数的指针一样.
  • 消息传递也可能非常令人困惑:将C++对象与Win32窗口混合会导致鸡或蛋问题的非常有趣的例子(当你delete this ;在类方法中编写一种有趣的时刻).
  • 当你更熟悉对象继承时,必须继承WinProc是头分裂而不是最优.
  • 当然,有一种乐趣是" 为什么在这个水力压裂的世界里他们用这种方式做了这件事? "当你用头撞击你的键盘太多并且用额头上刻有钥匙回家的时候,只是因为某人认为编写API以更改"窗口"的颜色更合乎逻辑,而不是通过更改其中一个属性,而是通过询问它的父窗口.
  • 等等

在最后一手(三手???)中,考虑一些使用遗留API的人自己使用遗留代码样式.你听到" const是为了傻瓜 "或" 我不使用名称空间,因为它们会降低运行时速度 " 的那一刻,或者甚至更好的" 嘿,谁需要C++?我用我自己的面向对象的C代码! "(不开玩笑......在专业的环境中,结果很可见......),你会感觉到这种恐惧只会在断头台面前受到谴责.

所以...总而言之,这是一次有趣的体验.

编辑

重新阅读这篇文章后,我发现它可能被视为过度消极.它不是.

知道如何在幕后工作是有趣的(也是令人沮丧的).你会明白,尽管存在巨大的(不可能的?)约束,但Win32 API团队确实做了很多工作,以确保从"olde Win16程序"到"最后的Win64 over-the-top应用程序"的所有内容都可以一起工作,在过去,现在和将来.

问题是:你真的想要吗?

因为在其他更高级别和/或面向对象的API中花费数周时间来完成可以完成(并且做得更好)的事情可能会非常缺乏动力(实际体验:Win API为3周,3个为4小时)其他语言和/或图书馆).

无论如何,你会发现Raymond Chen的博客非常有趣,因为他的内部人员对Win API及其多年来的演变有所了解:

https://blogs.msdn.microsoft.com/oldnewthing/

  • @jle:是的,但是通过Python使用Win32 API就像通过Java或C#使用Win32 API:有人已经为你编写了包装器.此外,我希望你不用Win32编写GUI,因为即使使用python,这也很痛苦.最后,但并非最不重要的是,问题没有提到Python(或任何脚本语言),也没有提到"python"标签,所以...... (5认同)

Ed.*_*Ed. 16

绝对.当没有人知道低级别时,谁会更新并编写高级语言?此外,当您了解低级别的东西时,您可以使用更高级别的语言编写更高效的代码,并且还可以更有效地进行调试.


小智 16

本机API是"真正的"操作系统API..NET库(除了极少数例外)只不过是一个奇特的包装器.所以,是的,我会说任何能够理解.NET复杂性的人都可以理解相对平凡的事情,比如在没有中间人的情况下与API交谈.

只是尝试从托管代码执行DLL注入.它无法完成.您将被迫为此编写本机代码,用于窗口调整,实际子类化以及其他十几项操作.

所以是的:你应该(必须)知道两者.

编辑:即使您打算使用P/Invoke.


小智 11

假设您正在构建针对Windows的应用程序:

  • 它可以确保了解系统的较低级别 - 它们如何工作,代码如何与它们交互(即使只是间接地),以及哪里有更高级别抽象中没有的其他选项
  • 有时,您的代码可能无法满足您的要求,效率,高性能或精确
  • 然而,在越来越多的情况下,像我们这样的人(他们从未学过"非托管编码")将能够在不"学习"Win32的情况下完成我们正在尝试的编程.
  • 此外,有很多网站提供工作样本,代码片段甚至是功能齐全的源代码,您可以"利用"(借用,抄袭 - 但检查您是否遵守任何重用许可或版权!)来填写在任何未由.NET框架类库(或您可以下载或许可的库)处理的空白中.
  • 如果您可以在Win32中完成所需的功能而不会搞乱,并且您在开发格式良好,可读的托管代码方面做得很好,那么我认为掌握.NET将是一个比传播自己更好的选择超过两个非常不同的环境.
  • 如果您经常需要利用那些没有获得良好的Framework类库覆盖率的Windows功能,那么请务必学习所需的技能.
  • 我个人花了太多时间来担心编码的"其他领域"我应该理解为制作"好的节目",但是有很多的masochists认为每个人的需求和欲望就像他们自己的.苦难喜欢公司.:)

假设您正在为"Web 2.0"世界构建应用程序,或者对*NIX和MacOS用户同样有用/有益:

  • 坚持使用尽可能多的跨平台环境的语言和编译器.
  • Visual Studio中的纯.NET明显优于Win32,但是针对MONO库(可能使用Sharp Develop IDE)进行开发可能是一种更好的方法.
  • 你也可以花时间学习Java,这些技能可以很好地转移到C#编程(理论上,Java代码可以在任何具有匹配JRE的平台上运行).我听说它更像是"一次编写,到处调试",但这可能和C#一样真实(甚至更多).


Joe*_*csy 9

打个比方:如果你以生活(编程)为基础制造汽车,那么了解发动机是如何工作的(Win32)是非常恰当的.


Ste*_*Cox 8

简单的回答,是的.


Jay*_*Jay 7

是的,原因如下:

1).net包装Win32代码..net通常是一个优秀的代码编写系统,但是对底层Win32层有一定的了解(oops,WinAPI,现在也有64位代码),可以增强你对真实情况的了解.

2)在这种经济形势下,当你找工作时,最好比其他人有一些优势.一些WinAPI体验可能会为您提供此功能.

3)某些系统方面尚未通过.net框架提供,如果您想访问这些功能,则需要使用p/invoke(请参阅http://www.pinvoke.net以获得一些帮助).拥有至少一小部分WinAPI经验将使您的p/invoke开发工作更加高效.

4)(已添加)现在Win8已经存在了一段时间,它仍然建立在WinAPI之上.iOS,Android,OS/X和Linux都在那里,但WinAPI仍将存在很多年.


Sen*_*hil 7

这就是任何类似问题的答案."即使有更高级别的语言/ api Y,学习低级语言/ api X也是有意义的"

你可以启动你的Windows PC(或任何其他操作系统)并在SO中提出这个问题,因为微软的几个人写了加载你的操作系统的16位汇编代码.

您的浏览器有效,因为有人在C中编写了一个OS内核,可以满足您所有浏览器的请求.

它一直到脚本语言.

无论大小,总有市场和机会在任何抽象层次上写东西.你只需要喜欢它并适合正确的工作.

除非在同一级别上有更好的竞争,否则任何抽象级别的api /语言都是无关紧要的.

另一种看待它的方式:迈克尔·阿布拉什(Michael Abrash)的书中的一个很好的例子:AC程序员被赋予了编写清除屏幕功能的任务.由于C是比汇编更好(更高级别)的抽象,所以程序员只知道C并且知道它很好.他尽了最大努力 - 他将光标移动到屏幕上的每个位置并清除了那里的角色.他优化了循环并确保它尽可能快地运行.但是它仍然很慢......直到一些人进来并说有一些BIOS/VGA指令或可以立即清除屏幕的东西.

知道你在走什么总是有帮助的.