future at shiny.co.il
Tue Jul 31 14:59:30 CDT 2012
On Tue, Jul 31, 2012 at 10:42 PM, Vincent Povirk <madewokherd at 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
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
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'
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
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
but it's nothing too bad.
So, then, why not?
More information about the wine-devel