"Complimentary" msvcrt?

[Ilya Konstantinov]

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
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?