>>> 1) provide Windows headers, to keep those DWORDs etc. defined >> >> Yes, but so does MSVC. > > MSVC as in Microsoft Visual C++? It only provides a C/C++ runtime. The > headers come > from the Platform SDK. In any case, here Winelib provides them, > probably slightly altered > so they'd built better on gcc.
Visual C++ ships with headers and a compiler. Anyway, there's no advantage to winelib as a build environment compared to MSVC or the Platform SDK, assuming you are able to use one of those, except for the ability to port to architectures other than x86, x86_64, and arm. >>> 2) implement Windows APIs in terms of Linux as much as possible -- to keep >>> those >>> CreateFileWs going, to avoid changing every single 'Sleep' to 'sleep' >>> "just because". >> >> Winelib doesn't do that. It uses the same implementation of the >> Windows API that is in Wine. > > Sleep and CreateFileW are Windows APIs. I want them implemented > for my C code to link to. Internally, they call into libc or Linux syscalls. > How is Winelib not what I want? Wine's CreateFileW does path mapping to simulate a Windows filesystem, regardless of whether you're using winelib. It's not a thin wrapper around Linux API's; it's exactly the same wrapper you get if you run a normal Windows program. Because it's the same API implementation, it doesn't offer any advantage over running the same code compiled with Microsoft's C/C++ compiler (which according to rumor is faster and has a better optimizer), while there is a significant disadvantage in the form of the work it takes to make that code build correctly.
