Main sources of Wine complexity

[Vincent Povirk]

You may want to look into libwapi, which is a small library bundled in
the Mono source code that provides implementations of some Windows API
functions, which are simple but lacking features/compatibility.
Synchronization objects are local to the process, and there are no
drive letters, for example (though some optional path translation is
available, I believe). Between that and individual functions of Wine,
you may be able to cover most of what you need.

Windows applications can be very picky about behavior of the API, so
such an approach can't work for us, and it gets especially complicated
when you need graphics, windowing, or COM marshaling.

On Mon, Jun 10, 2013 at 7:34 AM, Ivan <ivdivd0 at gmail.com> wrote:
> (short summary: why is emulation of Windows environment so difficult).
>
> First of all, my apologies if this is an off-topic question for this list
> but I hope it will be useful for others in the similar situation.
>
> I need to port fairly large WinAPI-heavy application to Linux. After some
> googling it becomes clear that there's nothing except for Wine/Winelib which
> is *huge*. However for at least most basic WinAPI functions it looks fairly
> easy to just re-implement it via Boost/STL/libc/Linux syscalls. Why there's
> nothing small like this already? Why only Wine with like 3 millions LoC and
> run-time dependencies?
>
> Is the approach described above make some sense for at least most common
> functionality (threading, IPC, file operations) w/o things like UI, graphics
> and registry. For instance, we need to either re-implement around 200 WinAPI
> functions (mostly events, mutexes, semaphore, sockets, file and folder
> operations) or to rewrite the entire thing from scratch. Using Winelib
> directly is not an option due to the nature of the app. Any help/advices are
> greatly appreciated.
>
> Thank you.
>
>
>