Windows <Sys/File.H> Equivalent

Windows sys/file.h equivalent

When writing WIN32API apps you usually #include <windows.h> - that includes most of the Windows API in your application. If you need to cut down on some of those includes, #define WIN32_LEAN_AND_MEAN will wipe out some of the more obscure things from the Windows libraries.

What functions are you trying to convert? It'll probably be a case of using a different function on WIN32; it is very different to Linux/Unix/POSIX.

Example: the ReadFile() function is roughly equivalent to read() in terms of general idea, but the calling signatures are very different. ReadFile()'s MSDN entry says:

Header: WinBase.h (include Windows.h)

What is the Windows equivalent to the capabilities defined in sys/select.h and termios.h

The Windows API is structurally and stylistically very different from the blend of system calls and library routines provided by any flavor of Unix.

termio.h

Windows does terminal I/O with a very different model from any *nix system. As a result, there really is no direct equivalent to the termios.h header and its friends.

You want to read at MSDN about the Windows Communications Resources.

Some things to learn more about include:

• The DCB structure
• The COMMTIMEOUTS structure
• BuildCommDCB()
• SetCommState()
• ... and many more ...

In general, you will find that you need to deal a lot more with the Windows API directly because stdio will add to the confusion when doing device I/O.

select.h

There isn't a direct equivalent to the Unix select(2) system call.

In Windows, many kernel objects can be in either a signaled or non-signaled state, and the act of signalling the object can be used to release a thread that called WaitForMultipleObjects(). Some but not all HANDLE objects are signaled when data is available. Specifically, I know that HANDLEs from WinSock have that capability, but I don't know about the Comm API. I know that HANDLEs to an open file do not.

If you need to wait for an event in a thread that is processing window messages, then you should probably use MsgWaitForMultipleObjects() instead, since it will properly deliver messages while the thread is otherwise blocked.

Read about the Windows synchronization primitives at the MSDN article Using Synchronization.

However, there are several kinds of asynchronous I/O built into Windows that can replace the need for select() by a change of design. Both will require extensive use of features that cannot be used in combination with the C stdio library.

MSDN has several articles on I/O techniques, as well as numerous examples:

• I/O Concepts
• Synchronous and Asynchronous I/O
• Synchronization and Overlapped Input and Output
• CreateFile() (especially the Remarks section)

Note that much of the information on how Windows works is scattered among the overview articles and the remarks sections of the reference material for the API functions and structures. This can give the impression that nothing is completely documented on a first reading.

Porting with Cygwin

Another approach is to use Cygwin to do the port. It provides most of a POSIX layer over the Windows API. However, you will end up with an application that is dependent on the Cygwin DLL which is GPL unless you purchase a commercial use license from them. It can be tricky to use Cygwin to get an application that works well for a Windows user with no Unix experience also, since so many other assumptions about the way the two systems are setup and used differ.

Cygwin has done a fair amount of heavy lifting to build an implementation of select() that works on Windows given a mix of different open file descriptors. This effort is described in the User's Guide.

Do be aware that building against Cygwin is only documented and supported if done from within the Cygwin environment. It usually is not sufficient to just put Cygwin's bin on the Windows PATH and work from a command prompt. You really need to launch Cygwin's build of bash and compile from there so that everything is using the same Cygwin-style mount points and simulated Unix file structure.

Mixing Cygwin header files with third-party tool header files is a sure path to madness.

Edit: I've rearranged a bit, and added some material in response to comments.

Windows Equivalent for sys/mman.h

You should look at the mman-win32 library. But as @Mgetz pointed out, a more simple way is to look at the VirtualAllocEx functions and try to adapt your code.

Why include direct.h or sys/stat.h conditionally based on _WIN32 or __linux__?

There is no portable way in C to manipulate file system directories. You need some library that provides wrapper interfaces to manipulate directories. (Using system call, OS interrupts routines etc)

direct.h is a header file for the C programming language for windows. It contains declaration of functions and required macros, struct etc used to manipulate file system directories. In Linux like system, you can use sys/stat.h for the same.

Now if your code may be compiled for either of the OS, you can keep the common (portable) code without any guards and keep windows-specific or linux-specific code in conditional compilation block.

If you don't include those files conditionally, you may get direct.h not found or similar error in Linux and any similar error for windows.

__linux__ is pre-defined by the compiler targeting the code for Linux.

This msdn document says:

_WIN32: Defined for applications for Win32 and Win64. Always defined.

Error using include sys/resource.h with Windows 10 C++

sys/resource.h is a POSIX header file, that's why your system is not able to find it anywhere on windows.

If you still want to use it then you can either either use a virtual machine or install cygwin on your system.

Using sys/socket.h functions on windows

You have two options:

1. Use Cygwin (Unix emulation library).
2. Port to Winsock (Windows standard library).

Cygwin: lets you compile your Unix sources mostly untouched, but ties you to the Cygwin emulation library. This have two implications: general performance -no only network- will probably be less than optimal; and the target environment must have (at run time) the Cygwin DLL installed.

Winsock: this requires you to replace sys/socket.h (BSD sockets library, UNIX standard for the TCP/IP stack) with winsock2.h, and rewrite some parts of the code - not much, but some.

Some related questions with valuable info:

Differences between winsock and BSD socket implementations

Some Issues About Cygwin[Linux in Windows] (socket,thread,other programming and shell issues)

Examples for Winsock?

---

Related Topics