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?