Wine Traffic #185 For 29 Aug 2003

AclereX® Enterprise Migrationware allows corporations to run existing Windows applications on their Linux desktop - transparent and seamlessly.

For unique applications developed in-house or not supported out-of-the-box, AclereX® can be customized to specifically meet your individual corporate needs.

Well, it's been a while since the last update, so I thought it'd be worthwhile to write about where we're up to. Looking at the TODO list on WineHQ, it seems the remaining work falls into two areas:

• A bit of documentation stuff (rather worryingly "fix the docs build system" says a patch was submitted last *year*, but is still labelled as work in progress!).
• Configuration, ie winecfg and an auto setup wizard thingy. John K Hohm has been making great progress lately with making DLLs self register, but unfortunately nobody has really stepped up to work on winecfg. We may or may not get the patches from Mark it seems :|

There are a few other things, like DLL separation, and completing the work to make DLLs self register.

I have a whole load of time with not much to do during September, so I might sit down and try and get some patches off for winecfg, seeing as merging in Oves OLE code is going to be slow work at my current rate of patch committing :(

Is there anything else we might need? I'm tempted to say that having InstallShield work is a priority, as it seems to have broken quite a bit lately.

On the TODO list it says that some window management hacks exist but more debugging work is needed - does anybody know the status of that? A lot of InstallShield installers at the moment fail due to that X11 ConfigureWindow error - how hard is this to fix?

Having a wine.inf to set up a new installation, does anybody have details on that? Is this just a case of eating our own dogfood, or is it really a must have for 0.9?

So, Mark has sent me his work, unfortunately not as a patch against CVS so I'll have to do some merging in. It implements the GUI (but not backend) for drive editing.

I'm looking over the code now, and have a few questions about how to proceed. The primary issue is that we can't have the same setting pulled both from the config file and the registry, can we? So, as winecfg gradually gets more functional, parts of the config file will stop being referenced in favour of reg entries set via winecfg, but not all parts of winecfg will actually do anything. So:

1. How do we stop users being confused because they updated and now their config file doesn't seem to work anymore?
2. How do we stop users being confused because they started winecfg but the changes they make don't always take effect?

Possibilities include:

• Warnings on startup if a part of the config file exists. IE if we move version settings into the registry, output err: lines if those keys are in the config file to get the user to remove them.
• Disabling any controls that don't do anything in the winecfg program, so the user can't edit them.

winecfg should not care at all about the config file. It should get to the values through registry calls, as we do all over Wine ATM. This calls will be routed to the values from the config file for now, but we'll switch them to go to the real registry when we're ready.

For writing, we should also use the registry functions. I'm not sure what would happen now if you're trying to write config values through the registry, they may get saved in the registry. Which is just cool, it just means that winecfg will not be really function until the big switch, but that should be in the near future :)

Yes, that would be very nice indeed. Such a test shell should be something like the JUnit stuff (http://www.junit.org). Here are few things that I'd want in such an app:

• it should be a single executable (.exe preferably) containing all unit tests
• when started, it should go through these steps:
  • display a dialog explaining what it is and what it would do. The dialog would have OK/Cancel buttons
  • if OKed to proceed, the program should extract the tests, run them, and collect results, inspect the system. While doing these, it should inform the user what is going on ("Extracting tests...". "Running test X", etc.) The failed tests should be listed below.
  • when done, it should present the user with 3 buttons:
    • View Report
    • Send Report
    • Cancel
  • on "Send Report", the report should be emailed to a special mailing list, from where it's later picked up by some scripts and analysed.
  • We should be able to disable the UI via a command line switch, to allow for automatic execution.

I have been trying to port Wine, WineX, or ReWind to OpenBSD 3.4-beta for the past week. I've made the most progress with ReWind, so that is what this post will focus on.

Where I'm stumbling right now, I believe, is in the dll loader:

odin_at_sleipnir:p6[~/.wine/c]$ wine windows/Sol.exe
err:module:BUILTIN32_LoadLibraryExA loaded .so but dll ntdll.dll still not found - library environment problem or version conflict, check your setup.
err:module:PE_fixup_imports Module (file) ntdll.dll (which is needed by wine) not found

Now, it _is_ actually loading libntdll.so, I can see this with ktrace:

181 wine    NAMI    "/usr/local/lib/libntdll.so"
181 wine    RET     open 3
181 wine    CALL    read(0x3,0xcfbefdbc,0x1000)
181 wine    GIO     fd 3 read 4088 bytes
      "\^?ELF\^A\^A\^A\0\0\0\0\0\0 ......

I see that message is in relay32/builtin32.c, printed if MODULE_FindModule returns nothing.

In MODULE_FindModule in this loop:

for ( wm = MODULE_modref_list; wm; wm = wm->next )
{
  .....
}

I added a printf("MOD: %s\n", wm->modname); which prints out "MOD: wine" four times before the error message above.

I'm curious how MODULE_modref_list is seeded. That's where I think I'll find a clue to my problem. Could anyone give me some pointers?

I'm quite sure I've found my problem and it lies with OpenBSD's ld.so, not with anything I've done compiling Wine. Quite simply, the .init and .fini sections don't appear to be executed when a shared library is loaded with dlopen.

I've posted on tech--at--openbsd.org about it and received a few private replies confirming that observation and saying Wine isn't the only software that misbehaves because of this, so I think I'm on the right track.

Of course, that may not be the only issue (it certainly wasn't the first) so we'll see if I get bit by anything else once I get my ld.so working the way I need it to.

After investigating the DirectX NT dlls as part of an investigation to see if they would work on ReactOS, I discovered something.

The core DX dlls (like ddraw.dll, dsound.dll, dinput.dll and others) dont seem to make kernel-mode or driver/hardware calls directly. Most of it appears to be done via other places (such as winmm.dll, some special thunks in gdl32.dll and others) If my theory is correct (remember though, its just a theory), it may be possible to not only use the directx userland dlls (like ddraw.dll & friends) with ReactOS but it may be possible (if one were to implement the lower-level stubs) in a meaningfull way) to use said dlls with WINE.

If it is possible to use native versions of some of the high-level bits, that could really help get more games going... One of the main things that would be needed is a proper implementation of the GdiEntryxxx functions and the DdEntryxxx functions in gdi32.dll, they are the "thunks" that allow DirectDraw and Direct3D to talk to kernel mode. DirectSound & DirectMusic appear to go through winmm.dll to talk to the sound hardware.

Well, if you look at TransGaming DDraw code in Wine, you will see that they mimic the way DirectX is doing this (ie by somehow using an Escape in the GDI which returns a structure filled with function pointers and private datas).

Now this is a debate we had in the current WineHQ D3D development team : should we base our DirectX implementation on how Windows does the separation between the DLL and the drivers or just implement the DLL and do our own driver interface.

After some debate, we choose the second one :

• to not be tied down to some MS APIs at both sides (ie at DLL entry points and at DLL exit points).
• DLL entry points are 1) documented pretty well in MSDN and 2) easily testable by doing some simple Win32 programs. Compared to the MSDN, the DDK I read was a lot more difficult to read (and I have no idea if it's even 'legal' to implement something using the DDK without MS' aproval as it's not really a published API).
• finally, as the ultimate goal of Wine is to reimplement Wine and as no applications should use these low-level calls directly, the current solution used in Wine works fine :-)

Anyway, if people from ReactOS want to use our DirectX calls with Windows drivers, the way we choose is not the way to go...

Oh well, they added some DDK docs in the MSDN (which were not really there last time I looked)...

But it's as we feared : they explicitely tells us that this interface may change on each DirectX revision (which is normal as the driver interface need to change to accomodate more advanced graphic options). So we may have to rewrite 'old' DirectX code each time a new revision of the DDK comes out.

Anyway, the current code is current not written at all with a DLL / Driver separation in mind (there are some plans about it, but nothing has been done yet from what I know). And you should speak to Raphael about this, he's the one motivated to do this (I am not, as getting more games to run is more fun than to rewrite everything :-) ).

And more people to code would be welcome of course. And I think if you really want us to go the DDK way, you would need to at least do part of the work yourself :-)

Warning Microsoft DirectDraw and Microsoft Direct3D use several kernel-mode routines to communicate with the operating system and the display driver. These entry points are subject to change with each operating system revision. Applications are advised to use the DirectDraw/Direct3Dapplication programming interfaces (APIs). The DirectDraw/Direct3DAPIs insulate the application from such operating system changes, and hide many other difficulties involved in interacting directly with display drivers. For more information, see Windows DDK.

The Wine lists are currently getting about 1000 Sobig.F viruses per day, some of them supposedly from Alexandre ;)

I have temporarily changed the maximum message size on wine-patches to 40KB. So any emails with valid forged "From" headers will be caught for moderation. Since all the other lists were already set at 40KB by default, no viruses were able to make it through.

We've been through this discussion before too. Wine is not a VM, and the isolation between Win32 and Unix code is the result of application's ignorance, rather than a deliberate design decision. As such, it is highly NOT recommended for cases where hostile code of unknown qualities is tested.

For all you know, sobig may be checking whether it is runnning on wine, and then issuing the correct interrupts (static linking dlopen) and infecting your Unix system.