Gavriel State explained the current state of this patch (Karl Lessard had written it, but it had not yet been reviewed enough to be sent to wine-patches).

Zygo Blaxell, even though he was busy moving house, took the time to send the patch in its current state to wine-devel, with the following warning: Disclaimer: I scraped this patch together in the last ~45 minutes or so. The following code appears to run 'sol.exe' without segfaulting. This is the _only_ thing I'm willing to say about it. This is the first time in a couple of weeks that this code has actually worked at all for me, so I don't know yet if it's still chock full o' bugs.

Alexander added the next day: Cool. After some minor changes i actually got a fairly large speedup. Went from maybe 10 seconds per frame to about 1 second per frame. I'll do some further optimization, profiling and clean-up tomorrow.

Alexander Larsson then posted to wine-devel the result of his first shot at the patch, asking Corel if they wanted to clean it up and/or to submit to wine-patches.

Gavriel State answered that Alexander could do it if he had the time, Corel poeple were more concentrating on porting issues right now, and it'd be better (and quicker) if Alexander took care of the clean-up. The patch has not yet made its way to wine-patches.

Ulrich Weigand reminded that:

one of the requirements of the elfdll import/export handling is that is should transparently work between elfdll and PE modules, so that within the whole executable, DLLs can be arbitrarily replaced by PE or elfdll versions, and all imports/export still work.

This means that not only the non-exported symbols should not be available for ELF linking, but rather *no* symbols at all should use ELF linking, because the side being linked to might be PE.

So, Bertho's current experimental dllglue works like this: link everything belonging to one elfdll into an object, use the symbol table of the object together with the .spec files defining the exports of the various DLLs to create a PE header containing both an exports and an imports table, link the PE header into the object (thereby resolving all symbols originally imported by the elfdll to IAT stubs) and finally localize all ELF symbols (except one symbol pointing to the PE header itself).

Thus, you get a .so file which the Wine loader loads using dlopen(), retrieves the PE header using dlsym(), and performs the usual PE import/export resolving.

Ulrich nevertheless pointed to some areas that could be enhanced:

• On the export side, it might be possible to avoid the necessity for an specific .spec file if the symbols intended to be exported could be marked in the source using a technique similar to the ones you mentioned.
• On the import side, we could avoid the necessity for assembly glue code stubs if the compiler could be told that calls to an imported function should be coded as *indirect* calls, with the imported symbol actually pointing to a *pointer* to the function. This is exactly what the 'declspec(dllimport)' of MS compilers does.

Alexander said that Mozilla and Cygnus were willing to add the needed support for "Export side" in egcs, but this wouldn't be present in egcs 2.95.

On the "Import side", Alexander suggested to directly tweak with the GOT (Global Offset Table) [editor's note: the GOT is used to relocate symbols from an .so library on loading].

Both Ulrich and Bertho's Stultiens agreed this was not a very good solution because it was non portable (because use of assembly language and too much knowledge of .so internals were required) and it couldn't solve some elfdll specific issues (like importing two functions of same name from two different DLLs).

Gérard Patel answered point by point:

• 1/ Yes it's hosed. The Wine code here is a bit difficult to understand, though. I am not sure than fixing it will not lead to worse problems. If I had all the time in the world I would like to rewrite it. I guess that the motivation to fix it is gone now than people can use the so-called 'native' (read : BillG) controls. I think (but I am not sure at all) that somewhere someone hinted to want to write a 32 bit version of these openfile controls, so maybe this will be fixed. Corel will need it anyway, so all hope is not lost.
• 2&3/ It's a recent problem. I intend to attack some scrollbar problems real soon now. Wether I will win or the scrollbar will win is an open question. I will probably try your code while I'm at it. In a week or two.
• 4/ I have no intention to look at this problem soon, sorry.

Dennis then applied Gérard's patches and replied: My scrollbar problem that has been there for a long time has gone away with wine-990704.

But, he also noticed (after diving into the code) that there is still a lot of (graphical) problems with the scrollbars in win9x mode. So I started to fix some small problems. And since I have some free weeks now in the sommer I could spend some time fixing the scrollbars for real. and asked wether someone else was also looking at those issues.

Gérard answered he was focusing on some other areas, but reminded a few guidelines:

• scrollbars are used everywhere, breaking something with them should be real easy. I don't know how much code there is in Wine, but it could be near one million of lines...Enough to make it difficult to find where is the change that broke something.
• if you want to pass just a few weeks on wine development and then pass to other things, please forget it. Problems could surface after you are gone and then who will be left to fix things you could have broken ??? Do changes only if you offer support :-)

Dennis agreed on the guidelines and went on, with Gérard, on a more in depth discussion of the current state of the graphical behavior of scrollbars (and fixme:s in the code).

Ulrich Weigand gave a full answer regarding DLL loading, load order and al.

Well, the problem is that you can *not* simply say 'native DLLs are better' or 'built-in DLLs are better'. There are basically two aspects to be considered that tend to contradict each other:

• On the one hand, native DLLs of course guarantee 100% compatibility for those routines they implement. Examples: If you use native USER, the visual appearance of window borders, dialog controls etc. is more-or-less perfect, if you use built-in USER, it doesn't really look quite like Windows 95 ... Same holds for the common controls (COMMCTRL) or the common dialogs (COMMDLG). The native SHELL contains e.g. the routines used by installers to create desktop shortcuts; since the file format of a shortcut file is not documented, Wine doesn't correctly implement these routines yet, hence some installers might fail when using built-in SHELL.
• On the other hand, a native DLL might try to access features of the rest of the system which are not quite correctly implemented in Wine (e.g. because they are undocumented). In this case, the native DLL might work much worse than the built-in one, or even not all. Examples: The native MPR requires shared PE sections to work, which is not yet supported by Wine, hence it doesn't run. The native GDI requires a Windows display driver to be present, which isn't the case under Wine. The native KERNEL doesn't work at all because it directly accesses the Win95 core which isn't there under Wine.
• A probably minor point: In a few cases, the Wine built-in DLLs implement *more* features than the original Windows DLLs; these features will not work when using the native DLLs, of course. The one prime example of this is the integration of Wine with X provided by built-in USER; if you use native USER, you can only run Wine in -desktop mode, and using the clipboard or drag-and-drop between Wine windows and X windows will not work.

So, unfortunately, there is no rule-of-thumb which load-order to use; you'll have to have a certain knowledge of what the DLL in question does, which other DLLs/features it requires etc. to make a case-by-case decision. For most users, it will probably be best to simply stay with the load-order settings laid out the the default wine.ini file. This default setting is determined as follows: for all DLLs where there is a proper Wine implementation at all (i.e. not just stubs), or where the native DLL is known *not* to work, use built-in first. All others, use native.

If you do want to experiment with variations of the load-order settings, there are two fixed rules that must be complied with:

• Always use the same setting for DLL pairs (i.e. the 16-bit and 32-bit DLL that form a tightly integrated whole). You can use both native COMMDLG and COMDLG32 or both built-in, but don't try to mix it. The same holds for the other DLLs listed in the [DllPairs] section.
• If DLL A calls routines of DLL B, and you use the native version of DLL B, you *must* also use the native version of DLL A. [This will no longer be required once the elf-dll mechanism works.] Normally, this is only a concern when using native USER.

Some candidates where it might be worth-while to try deviating from the standard setting (built-in) and use the native version would be:

• SHELL/SHELL32
• COMMCTRL/COMCTL32
• COMMDLG/COMDLG32

The native versions of these seem to work quite well nowadays, and they tend to bring noticeable improvements over the built-in ones. But, of course, YMMV ;-)

If you are especially daring, you might also try to use native USER/USER32 (if you do this, you *must* also use the native versions of the DLLs mentioned above). You'll have to live with the drawbacks (only -desktop mode, etc), but in some cases it does have advantages: e.g. some InstallShield apps run better with native USER, and if you are very lucky, you might even get Explorer to run a little ...

Lots of people were very happy with this description and requested it to be added to the documentation directory.

Alexander Larsson rejected it because Making it compile is good, but making it work would be better ;-) I'm not going to apply patches that simply remove everything that doesn't compile. This is especially important since few people have access to these other platforms, so if you don't do the job nobody else will.

So, Alexandre added a #error in the CONTEXT struct definition: to clearly mark that there is something here that you must think about when porting. I could have put in a dummy struct instead, it would have compiled just fine, and it would only have been fixed after someone spent hours trying to figure out why some obscure API function doesn't work right. I think a clear compile-time error is preferable.

Patrik asked why there wasn't any alike #error in the library part to bark at compile time when __i386__ was not defined.

Alexandre agreed and ended the thread with all the places that need a portable CONTEXT (mostly the exception stuff) will eventually have a #error added.

Marcus Meissner provided some improvement on the patch and asked wether BeOS was supporting mmap().

Howard answered there is talk about it for R5, not sure if it will happen.

Howard also explained that his previous attempts at porting show that Be was missing some important calls (like mmap, socketpair, select() on file descriptors, send/recvmsg). He now wants to tackle the porting issue on a step by step approach, and may be requiring some feedback from Be, which stated they'd tend to be more and more Posix compliant.

Ulrich and Howard then discussed the different points. mmap() could be implemented by reading all the file into memory (which would result in bad performances with MapViewOfFile on large files). mmap() is also now used as an improvement for passing data back and forth to the server (instead of sending them through the pipe); Ulrich asked wether a shared memory feature exists on Be? Howard said yes: Areas.

Ulrich reminded that the current server implementation requires you need to be able to pass *file descriptors* over the pipe. This means that the server opens a file, passes the descriptor to the client, and the client then uses the descriptor to access the file. Of course, you cannot simply pass the numerical value of the descriptor, because the client is another process. Thus, we use a special feature of sockets that allows to pass open file descriptors ('access rights'). This is the reason for using sendmsg() instead of sendto() in the first place!

Ulrich pinpointed the known troubleshooter while porting to other Unices: thread support, address spaces,

Howard asked about using Be native synchronization methods. Ulrich listed all the objects Win32 sync methods were able to wait on:

• signalled synchronization objects (semaphores, events, mutexes)
• process or thread termination
• I/O activity (files, pipes, sockets, mailslots)
• Console I/O
• file-change notifications

From a Unix stand point, WaitForMultipleObjects has to wait on:

• "real file" descriptors
• pipes
• connection to the X server
• in a (near future) on network connections

Regarding the LDT (Local Descriptor Table), Ulrich said: That's the Intel processor data structure used to define segments. Linux normally uses only one single data segment and a single code segment, both spanning the complete address space from 0 to 4 GB. All segment registers are usually set up by the OS on process startup with these values and never changed by the program. Thus, the illusion of a non-segmented address space is created, although the Intel processor actually *always* uses a segmented address space ;-)

Wine, however, needs to define additional segments for its own use. This is obvious when executing 16-bit code, but is even necessary when executing Win32 processes (e.g. the TEB selector must be loaded into the %fs register).

As accessing the LDT directly is protected, we need to use special system calls to do so (modify_ldt() on Linux, i386_set_ldt() on *BSD, and sysi86(SI86DSCR, ...) on Solaris/x86). So, the question is:

• Does BeOS provide an analogous syscall at all?
• Are the LDT settings shared for all threads in one address space (if they aren't, Wine won't work. This is broken on Linux 2.0.*)
• Does the BeOS environment survive if segments are actually used? This means:
  • Can the libraries cope if they are called with segment registers %fs,%gs set up different than usual (e.g. the Solaris/x86 thread libraries crashed when the application modified the %gs segment register ...)
  • What happens when executing code in a 16-bit segment and/or with the stack in a 16-bit segment at the time an interrupt/signal/... needs to be processed by the OS?
  • Are the values of the segment registers preserved over process switches?