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函数的指针一样.delete this ;在类方法中编写一种有趣的时刻).在最后一手(三手???)中,考虑一些使用遗留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/
小智 16
本机API是"真正的"操作系统API..NET库(除了极少数例外)只不过是一个奇特的包装器.所以,是的,我会说任何能够理解.NET复杂性的人都可以理解相对平凡的事情,比如在没有中间人的情况下与API交谈.
只是尝试从托管代码执行DLL注入.它无法完成.您将被迫为此编写本机代码,用于窗口调整,实际子类化以及其他十几项操作.
所以是的:你应该(必须)知道两者.
编辑:即使您打算使用P/Invoke.
小智 11
假设您正在构建针对Windows的应用程序:
假设您正在为"Web 2.0"世界构建应用程序,或者对*NIX和MacOS用户同样有用/有益:
是的,原因如下:
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仍将存在很多年.
这就是任何类似问题的答案."即使有更高级别的语言/ api Y,学习低级语言/ api X也是有意义的"
是
你可以启动你的Windows PC(或任何其他操作系统)并在SO中提出这个问题,因为微软的几个人写了加载你的操作系统的16位汇编代码.
您的浏览器有效,因为有人在C中编写了一个OS内核,可以满足您所有浏览器的请求.
它一直到脚本语言.
无论大小,总有市场和机会在任何抽象层次上写东西.你只需要喜欢它并适合正确的工作.
除非在同一级别上有更好的竞争,否则任何抽象级别的api /语言都是无关紧要的.
另一种看待它的方式:迈克尔·阿布拉什(Michael Abrash)的书中的一个很好的例子:AC程序员被赋予了编写清除屏幕功能的任务.由于C是比汇编更好(更高级别)的抽象,所以程序员只知道C并且知道它很好.他尽了最大努力 - 他将光标移动到屏幕上的每个位置并清除了那里的角色.他优化了循环并确保它尽可能快地运行.但是它仍然很慢......直到一些人进来并说有一些BIOS/VGA指令或可以立即清除屏幕的东西.
知道你在走什么总是有帮助的.
| 归档时间: |
|
| 查看次数: |
8371 次 |
| 最近记录: |