Win32 与 .Net [关闭]答案

【问题标题】：Win32 vs .Net [closed]Win32 与 .Net [关闭]
【发布时间】：2009-07-14 19:42:56
【问题描述】：

.NET 比 Win32 好还是相反？这将是两者的优点\缺点，在什么情况下一个会比另一个更好。微软是否发布了 .Net 作为 Win32 的替代品？

我不是在问需要维护的项目数量，而是关于正在开发的新项目，哪个更好。您是否认为 .Net 缺少来自 win32 的重要内容（不使用 dllImport ）？而你认为Win32会被.Net取代吗

我问这个是因为我和我的一个朋友发生了争执，正如我们都同意的那样，两者都必须深入研究我的朋友认为.Net 是不完整的，我说它几乎可以管理任何任务与驱动无关。 .Net 哪里失败了？

【问题讨论】：

尝试回答以下问题：“德语是比法语更好的语言，还是相反？两者的优缺点是什么？在什么情况下，一种比另一种更好？对于"如果不深入了解这些问题的背景，您能否明智地回答任何个问题？
好吧，虽然我尊重你的平行，但我没有问语言与语言的问题。虽然我可能会在我的问题中说哪个更好，但我试图从“哪个是最好的”转向“在你看来，在什么情况下哪个是最好的”，我希望这更具建设性。答案非常好，谢谢你，我正在等待更多，如果有人可以从“低级”的知识中输入，我会很高兴。不要试图向任何方向倾斜，只是从其他人的经验中收集一些关于什么需要什么的见解。
我很遗憾 COM（又名 ActiveX 或 OLE）在此处的问题、答案或 cmets 中均未提及。目前，.Net 提供了一种新颖的编程方式，并且有朝一日可能会嵌入到新一代操作系统中（听说过 SingularityOS 吗？），但现在这就是未来的音乐。我们今天使用的 .Net 框架本质上仍然基于 Win32，对于需要考虑平台、性能和可战斗性问题的当代开发人员来说，与 COM 相比更好。
.NET = 更便携（Linux 上的单声道等），更简单。 Win32 = 更高的性能，更多的代码要编写。我相信 .NET 是建立在 Win32 之上的，不是吗？
在 Windows 上是这样。您甚至可以通过挖掘控件的受保护成员来访问窗口句柄等。不是很推荐，但都在那里。

标签： .net c++ windows winapi

【解决方案1】：

这些都是我的POV。您的里程可能会有所不同。

.NET 的优势：

跨平台功能（通过 Mono 和 .Net Core）
良好的框架类选择通常意味着更少的代码。
组件的轻松集成，无论组件是用什么语言编写的。（您喜欢 F# 或 IronPython，太好了！用最合适的语言编写程序集。）

.NET 的缺点：

.NET 对不同的人意味着不同的东西。（例如，WPF 在哪里出现？）
有时 DLLImport 和/或 PInvoke 是获得所需功能的唯一方法，这意味着您失去了跨平台功能。

WIN32的优势：

如果您知道自己在做什么，就可以构建具有最少依赖性的出色应用程序。
比基于 .NET 的解决方案更适合“低级”操作。

WIN32的缺点：

如果您不知道自己在做什么，那么您可以轻松地以更致命的应用程序或系统方式在自己的脚下开枪。
您经常需要编写可以使用 .NET “免费”获得的代码。

两者都有自己的位置，并且可能会继续存在，直到真正的替代操作系统（Midori？某种形式的基于网络的操作系统？）上线并获得广泛接受。

【讨论】：

【解决方案2】：

.Net（或 WinForms 部分，无论如何）位于 Win32 之上。或者，换一种说法，Win32 用于构建 .Net 表单组件。因此，从这个意义上说，您可以将 .Net 视为一组预构建的 win32 小部件。您还可以将 .Net 视为 MFC 的逻辑继承者。

.Net 还可以在必要时直接调用 Win32 API，为您提供垃圾收集、BCL 中非常好的类库，以及 C# 和 VB.Net 中的 C/C++ 的许多不错的语言特性.

获得所有这些东西你失去的是一定程度的独立性。 .Net 是一个附加框架，默认情况下并非所有版本的 Windows 都附带，因此您在部署时需要担心额外的依赖关系。在使用任何高级垃圾收集语言时，您还需要考虑性能方面的考虑，其中看似简单的代码在幕后可能比您预期的要多得多。对于某些 winforms 组件尤其如此。

【讨论】：

那么 CLR 源代码是否真的调用了 Win32 函数（诸如 CreateWindow 之类的东西）？
@loop123123 是的，就是这样。

【解决方案3】：

您似乎已经知道简短的答案，但为了清楚起见，我将在此重申：

Win32：强大而完整。 Windows 平台上任何记录在案的行为都可以通过 Win32 进行组合，但随着权力而来的是责任和困难。创建丰富的 Win32 体验有相当多的微妙之处和困难。

.Net：功能强大，但属于 Win32 的子集。 .Net 为绝大多数业务线应用程序提供了绰绰有余的功能，但丰富的 UI 和特定的、专门的情况在其中根本不存在，因为无论出于何种原因，BCL 都不相信它会感觉支持它。我遇到的最常见示例是较新版本的 Windows 中的 UI 功能，尽管 PInvoke 在其他领域也很有用。 .Net 是一个更容易掌握和工作的模型，但是（根据我的经验）.net 的微妙之处比 Win32 更不可能让我一头雾水。

如果您包含 dllimport 和 PInvoke，那么我猜想 .Net 是一个合理的替代方案，能够在 90% 以上的任务中表现出色，而 WPF 为托管世界带来了完全不同级别的丰富 UI。

【讨论】：

【解决方案4】：

这不是一个公平的比较，两者之间没有更好的比较，这完全取决于您要完成的工作。对于大多数开发任务，.Net 非常复杂，甚至可能比 Win32 具有更好的性能。另一方面，.Net 甚至可以在窗口外运行，看看 Mono。现在，对于开发驱动程序和低级别的东西，最好使用 Win32。

【讨论】：

【解决方案5】：

.Net 不会取代 Win32。 Win32 是操作系统级别的接口，您可以将 .Net 视为位于 Win32 之上的小型子操作系统环境或虚拟机。 .Net 提供硬件架构中立性（无论您的客户端是在 Pentium IV、Core 2 Duo、Itanium、32 位、64 位还是其他任何设备上运行都无关紧要。）.Net 提供了一个可以理解这些环境的优化安装程序，所以如果指令说“移动一百万字节”，它将使用平台上可用的“最优化”移动指令。

.Net 使开发人员的一些事情变得更容易：内置的垃圾收集可以防止一个非常常见的错误，即忘记释放内存。 Visual Studio IDE 集成提供了可以说是任何语言中最好的开发环境。原型屏幕和代码当然很快。（当然，Visual Studio 也为编写 Win32 API 的 C/C++ 编码器提供了许多相同的优势。）

但是 .Net 以性能为代价实现了这些目标。代码必须在最终用户的机器上“即时”编译（JITted）才能运行。 .Net 框架需要 5-15 兆字节的 RAM，只是为了加载足够的代码来执行“Hello World”。 .Net 框架在速度低于 400MHz 或 RAM 小于 512 MB 的机器上表现不佳（您可以在更小、更慢的机器上运行它，但它的性能必须在逐个应用程序的基础上进行评估.)

【讨论】：

【解决方案6】：

.NET 在您的问题中暗示C# 或C++/CLI？ .NET 和 C++/CLI 是不自然的。另一方面，使用C# 和.NET 比使用Win32 更舒服。

【讨论】：

【解决方案7】：

对于硬件访问 WIN API 是最好的选择。它更快，因为它直接与低级设备对话，但没有免费午餐；你的代码会更复杂，它不会原谅糟糕的编码。

【讨论】：

您是否有来自自己经验的参考资料或轶事来支持您的陈述？提供您未记录的意见没有帮助。
请给出更详细的答案，例如比较表左右。