C和Windows API之间有什么关系？
我在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函数来制作你自己的类似fopen的版本？ （我所知道的唯一另一件事是assembly，如果这是他建议包装的话，就不会以这种随意的方式写出来。）
鉴于上述情况，c语言（语法，数据结构，流控制），c函数库（例如fopen）和windows api（例如CreateFile）之间的依赖关系是什么？
C早在Windows之前就存在了。 Windows API是一堆用C语言编写的库。根据Microsoft已记录或通过API提供的内容，可能会也可能无法自行复制其function。 在某种程度上， fopen()和CreateFile()每个都调用相同或类似的操作系统服务，但是对于另一个，它不太可能是一个严格的包装器。 绕过Windows API直接访问硬件可能很困难，但只要有足够的时间和编程工作，任何事情都是可能的。
C对GUI没有任何了解，对操作系统也很少。 你在C中以图形方式做的任何事情都是通过使用库来实现的，其中win32 api就是一个例子。
Windows API以C编程语言实现。 C标准库（例如fopen）提供的function是可移植的，因为它被不同的编译器编译成适合不同体系结构的汇编代码。 Windows API函数（如CreateFile）仅适用于运行Windows的计算机，因此不可移植。
从理论上讲，可以编写直接与硬件对话的C语言。 回到MS-DOS的时代（例如）我们中的很多人都经常这样做（因为MS-DOS根本没有提供我们需要的东西）。 编辑：在一些小型嵌入式系统上，它仍然很常见，但在典型的桌面系统上，这种情况大多已经消失。
有两件事发生了变化。 首先，Linux和Windows等现代系统要完整得多 ，因此直接处理硬件的需求要少得多。 其次，大多数系统现在都以受保护模式运行，因此普通用户代码无法直接与硬件通信 – 它必须通过某种设备驱动程序。
是的，大多数C库使用底层操作系统（例如）在Windows上， fopen和fwrite最终将调用CreateFile和WriteFile ，但在Linux上，它们最终会调用open和write 。
我注意到打开文件（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。
大多数操作系统，包括Windows都是用C（和/或汇编程序）编写的。 然后为每个操作系统修改库以执行基本操作。 （套接字，文件，内存等）。
WINAPI只是一堆库（用C和/或汇编程序编写），允许访问操作系统内的function。
在您更改问题之后，它与Windows无关，我认为您要了解的是操作系统（Windows或其他）的引导。
操作系统设计和实现一书讨论了Minix（Linux基于哪个版本）的实现。
WINAPI提供了C中的开发人员可以使用的接口，以便使用WINAPIfunction。 C ++程序也可以使用它。
Windows等操作系统包含WINAPI库，可以访问某些操作系统function，有时还可以与硬件联系，这些库是用C语言编写的。
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之间的关系是它们能够相互协作。
有趣的是，通过查看AutoIt http://www.autoitscript.com/autoit3/ ，您可以真正掌握Windows API的“强大function”。 AutoIt是一种很棒的小脚本语言，可以创建GUI，运行命令行应用程序，操作窗口和进程等。是的，它可以进行文件I / O和网络连接。