C和Windows API之间有什么关系？

Question

我在SO上查看了一些其他问题，并且不清楚c是否构建在WINAPI之上，之下或旁边。例如，有人可以用纯c写一些能够打开窗口的东西，还是需要使用windows api？

我注意到打开文件（fopen）的c（库？）版本与windows API版本（CreateFile）之间存在相似之处，这让我想知道是否只是另一个的包装器。有谁知道吗？

如果Windows正在运行;是一个程序员被迫使用windows api编程来运行它或者程序员根本不使用windows api并直接访问硬件（即Windows操作系统是否保护对硬件的访问）？

Windows CE的不同版本的Windows之间更便携。我发现的文档（现在已经改变了）曾经说过CreateFile只能回到windows ce的2.0版本（这里：http://msdn.microsoft.com/en-us/library/ms959950.aspx - 请注意最底部链接上的注释，其中显示支持的版本信息已更改）。那么应该用于windows ce版本1的是什么？换句话说，使用c函数编程或者标记为WINAPI的函数更可能适用于所有版本的Windows CE吗？

我在一本关于编程windows ce的书中读到了以下内容，这让我很困惑，因此在理解以下内容时可以更好地理解上述所有问题：

  

Windows CE支持在Windows NT和Windows 98上找到的大多数相同的文件I / O函数。支持相同的Win32 API调用，例如CreateFile，ReadFile，WriteFile和CloseFile。但是，Windows CE程序员必须意识到一些差异。首先，Windows CE不支持标准C文件I / O函数，如fopen，fread和fprintf。同样，不支持旧的Win16标准，_lread，_lwrite和_llseek。这不是一个很大的问题，因为所有这些函数都可以通过用少量代码包装Windows CE文件函数来轻松实现。

我对包装的理解是你必须有一些东西可以包装，考虑到win16和c库不可用它是否说明包装CreateFile函数来制作你自己的c-like版本的fopen？ （我所知道的唯一另一件事就是装配，如果这是他建议包装的东西，就不会以这种随意的方式写出来。）

鉴于上述情况，c语言（语法，数据结构，流控制），c函数库（例如fopen）和windows api（例如CreateFile）之间的依赖关系是什么？

Answer 1

在Windows之前很久就存在了。 Windows API是一堆用C语言编写的库。根据Microsoft已记录或通过API提供的内容，可能会也可能无法自行复制其功能。在某种程度上，fopen()和CreateFile()可能会调用相同或类似的操作系统服务，但不一定是另一个是严格的包装器。绕过Windows API直接访问硬件可能很困难，但只要有足够的时间和编程工作，任何事情都是可能的。

Answer 2

C对GUI没有任何了解，而且对操作系统一点也不了解。你在C中用图形表达的任何东西都是通过使用库来实现的，其中win32 api就是一个例子。

Answer 3

Windows API以C编程语言实现。 C标准库（例如fopen）提供的功能是可移植的，因为它被不同的编译器编译成适合不同体系结构的汇编代码。 Windows API函数（如CreateFile）仅适用于运行Windows的计算机，因此不可移植。

Answer 4

理论上，可以编写直接与硬件对话的C语言。回到MS-DOS的时代（例如）我们中的很多人都经常这样做（因为MS-DOS根本没有提供我们需要的东西）。编辑：在一些小型嵌入式系统上，它仍然很常见，但在典型的桌面系统上，这种情况大多已经消失。

有两件事发生了变化。首先，Linux和Windows等现代系统很多更完整，因此直接处理硬件的需求要少得多。其次，大多数系统现在都以受保护模式运行，因此普通用户代码无法直接直接与硬件通信 - 它必须通过某种设备驱动程序。

是的，大多数C库使用底层操作系统（例如）在Windows上，fopen和fwrite最终会调用CreateFile和WriteFile，但是Linux最终会调用open和write。

Answer 5

  

我注意到打开文件（fopen）的c（库？）版本与windows API版本（CreateFile）之间的相似性

不足为奇。他们也做类似的事情。

  

[是]一个只是另一个的包装？有谁知道吗？

您无法找到，因为源代码是拥有并保留为商业机密。 哪个更“根本”并不重要。您可以从Windows程序中使用Windows API。您可以使用C程序中的C API。

请注意，这无关紧要。您可以使用C API或Windows API的混合。

  

如果Windows正在运行;有人被迫使用windows api来运行它上面的东西，还是可以完全绕过Windows并直接访问硬件？

“直接访问硬件”？那是什么意思？如果Windows正在运行，那么......好吧...... Windows正在运行。 Windows可以调解您对硬件的访问权限。

使用bootcamp或GRUB或其他一些引导加载程序绕过Windows并“直接访问硬件”。

  

如果他们可以，如果你不知道你在做什么，是否有可能损坏硬件？

这是什么意思？你是否想通过滥用他们的驱动程序来“破坏”某些旋转媒体（即磁盘）？无论您运行的是哪种操作系统，都可能损坏您的硬盘。特权帐户和哑软件可以在磁盘上写入错误数据。这算是“损害”吗？

  

哪个更便携？

这是什么意思？到另一台Windows电脑？到没有运行Windows的计算机？你在问什么？请澄清您的问题，以便通过“便携式”来定义您的意思。

  不同版本的Windows之间的

由于不同的Windows互不兼容，我通常建议只使用POSIX标准库并避免使用所有Windows API。

但是，某些Windows变体（例如Windows mobile for phone vs. Windows“Server”）基本上完全不兼容。任何软件都无需在两个操作系统上运行。便携性并不重要。为什么要尝试在服务器上运行手机应用程序？

---

修改

  

那么底部的c语言（最接近硬件），接下来是windows API，然后是Windows API顶部的C库？

这没有意义。你混淆了两件无关的事情。 “语言”和“图书馆”彼此没什么关系。

此外，API不是操作系统。因此，通过一直使用Windows“API”，你会让它变得更加困惑。

这是一种看待它的方法。

• Windows操作系统有几个API。有一些底层函数库不属于应用程序接口。他们是“内部的”。
• 它具有本机Windows API。可从C。
调用
• 它有一个POSIX API。可从C调用。在某些情况下，Posix API通常使用Windows API。

Answer 6

大多数操作系统（包括Windows）都是用C（和/或汇编程序）编写的。然后为每个操作系统修改库以执行基本操作。 （套接字，文件，内存等）。

WINAPI只是一堆库（用C和/或汇编程序编写），允许访问操作系统内的功能。

与Windows无关，在您更改问题后，我认为您要了解的是操作系统（Windows或其他）的引导。
The book Operating Systems Design and implementation讨论了Minix（Linux基于哪个版本）的实现。

Answer 7

WINAPI提供了C中的开发人员可以使用的接口，以便使用WINAPI功能。 C ++程序也可以使用它。

Answer 8

Windows等操作系统包含WINAPI库，可以访问某些操作系统功能，有时还可以与硬件联系，这些库是用C语言编写的。

Answer 9

Carl Norum指出C早在Windows之前存在，但不要忘记Windows API类型是从MS-DOS API开始的，这种API是从CP / M API开始的。 C仅在CP / M之前存在很短的时间。

许多答案似乎暗示Windows API是基于C构建的，但这似乎也值得怀疑。 __stdcall是PASCAL的同义词，PASCAL是Microsoft C编译器中的关键字，因为Windows API是基于Pascal构建的。 __cdecl是Visual Studio编译的C和C ++程序中函数调用的默认设置，但它不适用于对API的调用。

C和Windows API之间的关系是它们能够相互协作。

Answer 10

作为一个有趣的说明，您可以通过查看AutoIt http://www.autoitscript.com/autoit3/来真正掌握Windows API的“强大功能”。 AutoIt是一种很棒的小脚本语言，可以创建GUI，运行命令行应用程序，操作窗口和进程等。是的，它可以进行文件I / O和网络连接。