* Gunnar André Dalsnes hardon@online.no [2004-02-17 20:32:25 +0100]:
<snip>
The current situation where we port/borrow/fork code from wine is really bad. Much work is done twice. The ideal solution would be to work with the Wine project (where possible) instead of forking it into ros. Keeping shell32 in synch seem to work well thou, but most shared components are not synched.
Where are the problems ? Did you ever talk to them or do you fear being hit in the back ? ;-)
I'll subscribe to the wine list(s) and have a look at the code. Perhaps you could tell me, which parts are used by both projects.
<snip>
My dream is to move/merge most of ros umode stuff into Wine. This includes everything inside the ros\lib source tree. Differences between ros and wine would be put into libraries, create a ntoskrnl.dll and win32k.dll wrapper for wine etc.
Yes, this sounds ideal. There should be a core module (either ros kernel or wine in userland), which provides generic kernel interfaces, loads binaries, memory mangement, ... i.e. the ros-kernel could be configured to support .so-libraries or not (for windows-only environments they're not needed, but perhaps its useful someday), also the wine core could support several binary formats.
On top of this core the should sit several services, like device handling window manager, widget libraries, ... Each interface (from within the win-env seen as one dll) could be provided by several module - at least one pure-win32 implementation (i.e. widgets) and others which work as adapters to other stuff, especially in the wine-environment (i.e uses gtk for widget rendering).
An interesting setup where both projects share much stuff would be a console-wine: it could use a simple framebuffer or libsvga output device and widget rendering/window manager from the shared codebase. (whether the code comes from windows-dlls or .so's doesnt really matter at this point).
This would be "windows on console" - something very interesting for me.
cu