我在linux中有一个应用程序,该应用程序已成功编译。我想在Windows中运行相同的程序。
但是编译会产生以下与头文件有关的错误。
我怎样才能解决这个问题?
Windows API在结构上和风格上与任何Unix风格提供的系统调用和库例程的组合都非常不同。
Windows使用与任何* nix系统完全不同的模型来处理终端I / O。结果,确实没有直接等同于termios.h标题及其朋友的信息。
termios.h
您想在MSDN上阅读有关Windows Communications资源的信息。
一些需要了解的更多信息包括:
BuildCommDCB()
SetCommState()
通常,您会发现需要直接使用Windows API进行更多处理,因为stdio在执行设备I / O时会增加混乱。
stdio
没有直接等效于Unix select(2)系统调用的方法。
在Windows中,许多内核对象可以处于有信号或无信号状态,并且用信号通知对象的行为可用于释放称为的线程WaitForMultipleObjects()。HANDLE当数据可用时,会发信号通知一些而非全部对象。具体来说,我知道HANDLEWinSock的s具有此功能,但我不了解Comm API。我知道HANDLEs不能打开文件。
WaitForMultipleObjects()
HANDLE
如果您需要等待正在处理窗口消息的线程中的事件,那么您可能应该使用MsgWaitForMultipleObjects()它,因为它可以在线程被阻塞的同时正确地传递消息。
MsgWaitForMultipleObjects()
在MSDN文章使用同步中阅读有关Windows同步原语的信息。
但是,Windows内置了几种异步I / O,它们可以select()通过更改设计来替代需求。两者都将需要大量使用不能与C stdio库结合使用的功能。
select()
MSDN上有几篇有关I / O技术的文章,以及许多示例:
CreateFile()
请注意,有关Windows工作方式的许多信息分散在API函数和结构的概述文章和参考资料的备注部分中。这可能给人的印象是,初读时完全没有记载任何东西。
另一种方法是使用Cygwin进行移植。它在Windows API上提供了大部分POSIX层。但是,最终您将获得依赖于Cygwin DLL(即GPL)的应用程序,除非您从他们那里购买了商业使用许可。使用Cygwin来获得对没有Unix经验的Windows用户也能很好运行的应用程序可能会很棘手,因为关于这两个系统的设置和使用方式的许多其他假设都不同。
select()在混合了不同的打开文件描述符的情况下,Cygwin进行了大量繁重的工作来构建可在Windows上运行的实现。用户指南中对此工作进行了描述。
请注意,只有在Cygwin环境中完成针对Cygwin的构建时,才进行记录和支持。仅仅将Cygwin的bin放在Windows PATH上并从命令提示符下工作通常是不够的。您确实需要启动Cygwin的bash构建并从那里进行编译,以便所有内容都使用相同的Cygwin样式的安装点和模拟的Unix文件结构。
将Cygwin头文件与第三方工具头文件混合在一起是确保疯狂的必经之路。
编辑: 我重新安排了一下,并添加了一些材料以回应评论。