madewokherd at gmail.com
Tue Jul 31 16:34:20 CDT 2012
>>> 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.
More information about the wine-devel