Hey,
I apologize for the flood of "newbie" questions coming from me lately :-) At the very least, I'll be giving Winelib a decent challenge, and perhaps we could improve it a bit...
Now, I've seen that Wine re-implements MSVCRT. However, this is a drop-in MSVCRT.DLL replacement, and it's incompatible with the rest of the GNU toolchain; for example, the GNU libstdc++ barfs on trying to include its own <wchar.h> and ending up including the msvcrt/wchar.h instead.
I'm looking for something more humble -- a library for easy porting, implementing those functions not implemented by glibc itself -- e.g. _wfopen, _wgetenv. In fact, many MSVCRT functions can be made available by simply #define-ing them to their glibc counterparts. (Of course, this should be done carefully.)
The main goal of this library should be source-level compatibility.
Does such a thing exist?
P.S. I know "real men" port their code to "real glibc", but I believe in taking small steps for bringing Linux into our codebase, thus decreasing friction with the rest of the developers.
I have to wonder if you're using winelib in a way that's not appropriate.
Winelib is not a useful intermediate step in porting an existing application to Linux, as most of the work involved in porting to winelib will not help you with a native Linux port. At some point you have to make a clean break from Windows, and winelib doesn't change that. It just provides a way to delay that painful step, while doing little to reduce the pain when it comes.
Nor is there typically any advantage to running existing Windows code with winelib compared to running a Windows exe or dll in Wine. While it's true that winelib can be used to port Windows code to a new CPU architecture not targeted by MSVC, there's not much demand for this.
Most people who think they want to use winelib want to do one of those things and don't realize that winelib doesn't solve any of their problems. Almost no one has a real use case for building existing Windows code with winelib. Given that, improving winelib's Windows source compatibility doesn't make it much more useful, and it probably isn't worth anyone's time.
Winelib works best to support a limited amount of new code (a single .dll.so or .exe.so) that acts as a bridge between Linux and Windows code.
On Tue, Jul 31, 2012 at 10:42 PM, Vincent Povirk madewokherd@gmail.com wrote:
Winelib is not a useful intermediate step in porting an existing application to Linux, as most of the work involved in porting to winelib will not help you with a native Linux port. At some point you have to make a clean break from Windows, and winelib doesn't change that. It just provides a way to delay that painful step, while doing little to reduce the pain when it comes.
Why not use Winelib as an abstraction layer? Keep in mind my users are enterprise and they do not mind the perceived "unsexy-ness" of a non-native port. I'm not going to present them with fugly non-native GUI anyway. I have a big bulk of "headless" code coming from Windows CE, that was ported to Windows without much difficulty, and now its heading to Linux as well.
Winelib is there to: 1) provide Windows headers, to keep those DWORDs etc. defined 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".
The code will keep running on Windows too. Why can't Winelib keep serving as a rudimentary abstraction layer, as funny as that might sound?
Our use of Windows is pretty basic. I don't believe we use a single function whose signature you don't already know by heart. (Except, maybe, for CryptoAPI, but I don't rule out re-implementing that chunk.) The code is full of MSC-isms and MSVCRT-isms but it's nothing too bad.
So, then, why not?
Winelib is there to:
- provide Windows headers, to keep those DWORDs etc. defined
Yes, but so does MSVC.
- 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.
Perhaps the io-layer aka libwapi library in Mono is closer to what you describe, but that is very limited and only intended for internal use in Mono.
On Tue, Jul 31, 2012 at 11:15 PM, Vincent Povirk madewokherd@gmail.com wrote:
Winelib is there to:
- 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.
- 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?
Perhaps the io-layer aka libwapi library in Mono is closer to what you describe, but that is very limited and only intended for internal use in Mono.
Interesting. I'll check it out to see what they've been up to.
- 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.
- 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.
On Wed, Aug 1, 2012 at 12:34 AM, Vincent Povirk madewokherd@gmail.com wrote:
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.
Oooh. Now I understand what you mean: build with MSVC as usual, run in WINE on Linux. Thanks for the patience :-)
If there's some code I'd must write natively to bind the Windows app to the Linux system (e.g. interacting with some low-level Linux stuff), can I build that library as a DLL with wineg++ / winelib and have the WINE-invoked app use that?
If there's some code I'd must write natively to bind the Windows app to the Linux system (e.g. interacting with some low-level Linux stuff), can I build that library as a DLL with wineg++ / winelib and have the WINE-invoked app use that?
Yes. This is what I meant by a bridge between Linux and Windows code.
The easiest way to do this is with LoadLibrary and GetProcAddress, but linking to a winelib dll is also possible.
-
Ilya Konstantinov -
Vincent Povirk