Main sources of Wine complexity
(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.
On Mon, Jun 10, 2013 at 2:34 PM, Ivan <ivdivd0(a)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.
* no direct API conversion is always possible, eg. there is no WaitForMultipleObjects() equivalent in pthreads, which means the entire synchronization API has to be reimplemented. * Windows and *nix file systems differ and so does behavior of file APIs (eg. case sensitivity, attributes such as hidden files, etc.) * complex interdependencies and interactions between APIs exist (eg. sockets can be made into handles which can then use various synchronization APIs, and socket I/O notifications can get delivered into the UI message loop...). * the Windows API has a ~28 year history and is enormous. * the Windows API doesn't follow a standard, it is a de-facto standard with questionable documentation and only Wine's regression tests to determine exact behavior. * Wine is very small compared to Windows itself. * Windows has lots of dependencies too, they're just less direct/obvious (eg. USER/GDI in the kernel, as opposed to Wine using X11 libs) Can't you just use a small subset of Winelib that covers everything you need: * delete all the DLLs that aren't used by your app * fiddle with ./configure options to disable dependencies you don't need There is also Cedega and other Wine spin-offs, but I think there's even less hope there. Damjan
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(a)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.
participants (3)
-
Damjan Jovanovic -
Ivan -
Vincent Povirk