Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #185 For 29 Aug 2003

By Brian Vincent

Table Of Contents


This is the 185th release of the weekly Wine Weekly News publication. Its main goal is to spend the day recovering from last night's concert. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at

Mailing List Stats For This Week

We looked at 313 posts in 864K.

There were 74 different contributors. 44 posted more than once. 33 posted last week too.

The top posters of the week were:

1. News: AclereX

23 Aug 2003 - 29 Aug 2003 (1 post) Archive Link: "News"

Topics: News

People: TransgamingMike HearnNewsTransGaming

Mike Hearn gave a pointer to a LinuxPlanet story about a new offering from TransGaming: AclereX. I hesitated to put this in the news section because as Mike pointed out it seems like they haven't officially announced this yet. It does seem fair game though since it's being announced in the trade press and there's a public web site. From the datasheet on their web site:

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.

You might notice some threads that started Thursday and Friday aren't covered here. I'll get to them next week. The end of this week has been crazy and I haven't had enough time to devote to covering those.

2. Wine 0.9 Progress

25 Aug 2003 - 28 Aug 2003 (19 posts) Archive Link: "Wine 0.9 progress"

Topics: Project Management

People: Mike HearnDimitrie PaunJakob ErikssonSteven EdwardsMark

Mike Hearn started this thread:

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:

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?

Dimi replied and mentioned that the documentation item was not a big deal. In fact, he had some patches ready to resubmit for that item. Wine's configuration was another issue. He agreed that work need to be done as soon as possible getting winecfg working. Mark Westcott had mentioned he had some patches floating around for winecfg and Dimi wondered what the status of those were. Mike went out in search of them and then raised more questions (ed note: this is two emails combined together):

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:

Dimi thought the current warning that winecfg was incomplete would suffice. As far as cutting over to the new system:

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 :)

Jakob Eriksson brought up another idea, " Well, if development after 0.9 is going to focus on correctness while getting to 1.0, lots of conformance testing is a must. I really was looking forward to write a testing application that runs all the tests, but I can't figure out why make crosstest is not working."

Steven Edwards mentioned a simple solution that seemed to work, " Can you rename mingws libmsvcrt.a or libntdll.a and see if that fixes it? On Windows with Mingw+MSYS I have to rename libmsvcrt.a to build the tests. "

Concerning a testing application, Dimi gave some pointers:

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

From there discussion delved into where and how to send the results of tests.

3. Porting ReWind To OpenBSD

23 Aug 2003 - 24 Aug 2003 (5 posts) Archive Link: "Porting to OpenBSD 3.4-beta"

Topics: Ports

People: Dan BrosemerOve Kaaven

OpenBSD doesn't get mentioned a lot on the Wine lists. Perhaps that's because most folks use it for bulletproof networking equipment rather than desktops. There is somewhat active development with FreeBSD and the port to that platform is known to work. This week Dan Brosemer took a stab at OpenBSD and ran into problems:

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:

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

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

In MODULE_FindModule in this loop:

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?

Ove K@#229;ven gave a pointer to how it's called, " ntdll.spec.c (generated by winebuild) contains a global constructor to automatically call __wine_spec_ntdll_init as soon as the .so is loaded, this init routine calls __wine_dll_register which eventually adds the DLL to that list. Perhaps you need to adapt the ".section .init" thing in there. "

Dan investigated and reported:

I'm quite sure I've found my problem and it lies with OpenBSD's, 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 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 working the way I need it to.

4. Why Native DirectX Doesn't Work

22 Aug 2003 - 23 Aug 2003 (7 posts) Archive Link: "interesting stuff I have been finding out about DirectX"

Topics: DirectX

People: Jonathon WilsonLionel UlmerMicrosoftReactOSTransGaming

Jonathon Wilson looked into whether Wine could use native DirectX DLL's and was surprised by what he found:

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.

Lionel Ulmer rained on his parade:

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 :

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

Concerning the DLL entry points, Jonathon found some other MSDN docs that looked useful, " See this: That explains some stuff about the DdEntry and GdiEntry stuff... "

Lionel still didn't think it would be worth pursuing:

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 :-)

Specifically, Microsoft places this warning at the top of their page:

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.

5. Devel Lists and Viruses

22 Aug 2003 (15 posts) Archive Link: "Viruses in the wine-devel archive ??"

Topics: Project Management

People: Duane ClarkP. ChristeasShachar ShemeshSylvain PetreolleJeremy NewmanMarcus Meissner

Wine-devel was hit pretty hard with viruses last week. Duane Clark described the precautions taken:

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.

Several messages in the archives were found to be infected and removed. Jeremy Newman wanted to know if the offending party should be unsubsribed from the list as well. Duane didn't think so, " Please don't remove anyone from the lists. The "From" is always forged, so you should ignore it. "

Of course the obvious question was asked (by P. Christeas), " Does SoBig.F run under wine? If yes, how bad can it get? "

Marcus Meissner tried running it and reported that it crashed. Sylvain Petreolle wondered how long it would take for virus writers to begin complaining their code didn't work under Wine. Shachar Shemesh warned against using Wine as a sandbox for testing such things:

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.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.