• news •

• the team •

• the project •

• faq •

• join •

• files •

• X •

• screen shots •

• contact •

• Wine •

WineLib:

Why work on WineLib first? Here's some recent Q&A with Patrik Stridvall (our contact with the Wine team who has helped us greatly in the project) on the topic of WineLib that explains:

Q: Are they [the roadblocks to success] exactly the same as the roadblocks to [the] windows binary/program execution?

A: No, they are considerable fewer. The technically hard ones mostly disappears...

Q: Would we have better luck at the WineLib at this point?

A: Yes, much better.

Q: Does the address space reversal issue pose problems with the WineLib?

A: No, not unless the application violates the Windows API, and assumes things that it isn't allowed to assume. However, very few application has any reason to do that, and those, since source code is required to exist for WineLib to work, can be easily fixed.

Q: [Therefore] the primary concern at this point is getting WineLib ported. [since] This could have immediate positive results in the form of ports. Executing Windows programs can come second.

A: I agree.

Q: As I understand it, to compile winelib programs, we build and install wine normally (which also installs the winelib and necessary headers), then try to compile the programs in programs/. Is this correct, and would this be a good place to start with winelib?

A: Yes, the applications in programs/ uses WineLib.

However, since BeOS doesn't have mmap and sendmsg/recvmsg, the communication with the Wine Server will need to be fixed before even WineLib will work.

Probably not that difficult, but it will take some time doing it, and don't look at me. I will give help with advise, if somebody does it, though.

Thanks for the input, as always, Patrik. We probably couldn't have gotten nearly as far as we have without your help!