• welcome •

• about •

• the team •

• the project •

• join •

• news •

• files •

• contact •

• Wine •

Wine has been successfully compiled on BeOS!

After some hard work by the team (and special thanks to Patrik Stridvall of the Wine project), we are at the next step in the BeWine project: get BeWine to RUN!

Here is the current state of problems, possible resolutions, and needs of the project; submitted by Patrik Stridvall (edited for clarity by the webmaster):

Primary issues with BeWine

1 [Emulator Only] LDT modification support.

This is critical and can't be worked around. However all i386 OS:es
that I know of have support for this, even SCO 4.2. It is not AFAIK very difficult to implement in the kernel core, so if BeOS really does not support it, we might be able to persuade Be to fix it in some future release or as a patch to a current release.

It might be possible to write a kernel driver that does this; well it is possible to modify them, but the kernel core might have some objections if we just do that. Need I say crash?

2 [Emulator Only] Prevervation of FS/GS registers during context switch and system and library calls.

This is probably a non-issue but it is critical so we need to keep it
in mind. System and library call non-preservation can be worked around
at a runtime cost, but it will take some time to implement.
Non-preservation during context switch is not possible to work around
AFAICS.

3 [Emulator Only] Differences in address space layout between
Windows and BeOS.

In short BeOS kernel space is 0x00000000-0x7fffffff and user space 0x80000000 - 0xffffffff. In Window it is the opposite, well not quite but it wouldn't change the problem very much if it was.

This is critical mainly because of lack of relocation records in many Windows applications.

However this might be fixed if we load the non-relocatable parts offset by 0x80000000 and do runtime relocation when a segmentation fault occurs (when user space tries to access kernel space).

We might even speed this up by doing runtime patching of the code and data. This is a little dangerous since active pointers might be compared with passive ones, but it might be possible under certain circumstances.

3 BeOS lacks sendmsg/recvmsg

Required to pass file descriptors between processes (teams).

This is an entirely internal problem in Wine, no application will care one way or the other, but it doesn't make it a less serious problems.

Fixing it is not that hard, I think, even if it will require writing quite a lot of code. What worries me most is that it must fit in Wine in a way that developers for Wine on Unices that support it will not have to worry about it.

4 BeOS lacks a general purpose select.

This is also an entirely internal problem in Wine, and it is or will only be used once in Wine, in the select loop in the Wine server.

Somebody mentioned that XBeos has the same problem and that they have solved it, so it might not be that hard. I have not looked very much at it.

5 BeOS lacks mmap

This can largely be worked around since BeOS seems to have other
mechanisms for doing similar things. There may be applications
that will not work but I think they will be few. Internally in Wine it is solvable AFAICS.

6 Signal context handling:

We must have the content of CPU registers when the signal occured.

This is solved, I believe, but not yet implemented. Primary remaining issue: Is it safe to assume that the segment registers when the signal occured is the same as the segment registers in the signal handler? I would be suprised if they weren't but that doesn't make it 100% certain.

7 BeOS socket descriptors are not file descriptors

This is connected to No. 4 but in this case I am refering to the implementation of Windows Sockets (Winsock).

This is not a problem with Winsock 1.x, which most applications use, since in Winsock 1.x socket descriptors are not file descriptors either.

But it is a problem with Winsock 2.0; fortunately this might be fixed using the new (in Winsock 2.0) concept service provider, so I don't worry very much about it, it will be some work, but not a fundamental problem, AFAICS.