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 #244 For 15 Oct 2004

By Brian Vincent

Table Of Contents


This is the 244th issue of the Wine Weekly News publication. Its main goal is to pretend summer isn't over. 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 157 posts in 560K.

There were 60 different contributors. 34 posted more than once. 28 posted last week too.

The top posters of the week were:

1. News: To Do List Update

9 Oct 2004 - 15 Oct 2004 (1 post) Archive Link: "News"

Topics: News

People: News

When we last looked at the Wine To Do List it was back in May. Things have progressed nicely since then. At the time we had green beating red, 24 to 15 with yellow coming in at 30. Since then quite a few items have been completed and even more are in progress. Here's where we currently stand on the 71 items:

That puts the completed list above the rest for the first time.

2. Wineconf 2005: Help!

8 Oct 2004 (4 posts) Archive Link: "Wineconf 2005"

Topics: Project Management

People: Jeremy WhiteCodeWeaversHuw Davies

Discussion at last year's Wineconf showed interest in making it a yearly event. The problem is finding someone to help organize it and the fact we even pulled it off last January is directly due to CodeWeavers offering to host it in balmy, breezy Minnesota. With so many developers living in Europe it's time we try to move the event to the other side of the pond. Jeremy White started the ball rolling:

It's that time again, time to plan for another Wineconf.

There has been some back room chatter about Wineconf this year, but no definitive plans.

A small cabal of people (myself included) think that we should hold it in Southern Germany around February/March.

Marcus and Michael have each expressed that they might be able to get a facility to hold it in, but those efforts have so far not yielded anything definitive (I think we're tied up in big company red tape).

Also, Huw Davies has offered to help host Wineconf in Oxford; that essentially translates into an offer by CodeWeavers to host Wineconf in mid March in Oxford.

However, I want to throw this open to discussion and see if others have great ideas or if someone outside our secret cabal wants to step up and make this happen in Southern Germany.

Based on our experience last year, I feel pretty strongly that we need the following:

  1. An inexpensive, yet easy to reach location. Connection to nice places to visit before/after is a plus, but should be a substantially secondary consideration IMO.
  2. Two rooms that can each hold about 30-40 people, ideally with white boards, power, and high speed internet.
  3. Access to food and hotels, preferably all within walking distance of each other. Since Europe is civilized, we should be able to walk from our Hotel to the conference, to a variety of food sources, and then, of course, to the pub.

Candidly, I don't know that this is all that complicated. We'll likely be bringing enough people in that we should be able to negotiate a pretty nice deal with a hotel. (We promise them xxx heads in beds, they give us conference facilities for a weekend).

If someone wanted to help host Wineconf, and was willing to facilitate a conversation between myself and a hotel that was well situated, CodeWeavers would be happy to sponsor the conference (i.e. financially reassure the Hotel).

Thoughts? Comments?

Some ideas were tossed around, but nothing concrete. Anyone out there able to help? Feel free to reply on wine-devel to Jeremy's original post, or you can mail him directly. (Click on the link above for his address.)

3. Direct3D 9 Work

20 Sep 2004 - 12 Oct 2004 (15 posts) Archive Link: "dx9-1"

Topics: DirectX

People: Jason Edmeades

We discussed Jason Edmeades plans to work on Direct3D 9 a few weeks ago (see WWN issue #240). The concensus seemed to be created a shared library between Direct3D 8 and Direct3D 9 code given how similar they are. The other alternative is to copy all the D3D8 code and then add in the D39D changes. However, this scheme creates maintenance headaches in the long run since bugfixes need to be applied to both. Jason began creating the new library a few weeks ago but not a lot discussion has come up on wine-devel. Jason has provided some nice comments with each patch, so I thought it might be worth putting them all together to show the direction this is headed.

Patch #1:

First dx9 related patch - Its mostly a 'feeler' patch to ensure the direction I am going is not rejected, and as discussed I plan to move the code into the wined3d library from d3d8, and use it for d3d9.

Note this is going to be a long process as my time is very limited. However, I will try very hard not to break d3d8 as I do the move. If I regress anything, let me know by email directly asap.


Patch #2:

Make d3d8 know about the wined3d device and use it for the first function. Also move another stub into the common library

(d3d9 completion status : 0.000001%)

Patch #3:

Move some of the screen mode related functions into wined3d and add untested support for the new d3d9 options of providing the format to some of the calls.

Patch #4:

Copy across the first of the functions used to make traces more readable, creating utils.c to store them in. Eventually the ones in d3d8 will be removed but for now just duplicate the code

BTW Before anyone asks, dont hold your breath for any working d3d9 support - This may take months!

Patch #5:

This change is larger because I have duplicated the code from dx8 and d3dcore_gl.h into wine-d3d and wined3d_gl.h so both old and new code can call and use it for the short term, one of the subsequent patches should clean up the old versions once no one needs them.


Patch #6:

Move the Check* type functions into wined3d and copy from d3d9, and flag they are mostly stubs

Patch #7:

Move the GetDeviceCaps into the wined3d library and call from d3d9.

(Note the d3d9 specifics are stubbed out, and in fact some of the 'common' caps are different between 8 and 9, but I can deal with that later).

Patch #8:

Well I've almost completed the simple interface, and the logical progression is onto the hardest!!

I have also only called the new code from d3d9 for now as its a complete skeleton to be built on.


Patch #9:

Copy and tidy up the code from dx8 create device into wined3d. Call from wined3d and d3d8, but short term only use the code for real from d3d9

Patch #10:

Fully support (as far as was previously - they havent changed in dx9) VertexBuffer and Resource classes and use when called from d3d9 (not d3d8 yet - later!). This also reduces the header includes in all the d3d9 interface, as they will be included from the private header when needed and it will be easier to remove them when they are no longer needed post-changes.

FYI I am working on the 'minimum' changes to get a tutorial program which writes a triangle to the screen to work.... Not there yet!


4. COM Inheritance

11 Oct 2004 - 12 Oct 2004 (4 posts) Archive Link: "COM inheritence"

Topics: RPC / COM / OLE

People: Jason EdmeadesRobert ShearmanRob Shearman

With the D3D9 changes, Jason ran into some issues sharing code and explained:

If you havent noticed, I'm trying to port the d3d8 code into wined3d and make it common for use from d3d9, and this is all COM objects. I have come across something which in theory would enable me to tidy my code simply, but I cant see how to make it work in C.

Now I have a class, for example FRED who implements some common functions, and all the code for it would be in fred.c. I also have a subclass, defined called JIM, which needs to have entrypoints as per fred, plus some more, and its code resides in jim.c. Still with me...?

Now previously, inside jim, I have duplicated all the common functions, but I want to avoid this and just call the one definition. My plan was to change the Vtbl to look like:

I was also ensuring the variable definitions in the IJimImpl structure map precisely over the IFredImpl structure, before any unique variables are defined (I think this is a necessity for emulating subclassing in C?).

Now, obviously if the common funcs need changing I can copy in the code, and change the vtbl to have a local override but at the moment I dont need to (they are mostly stubs even in the d3d8 code today).

However, doing this fails to compile - It wont allow me to have a vtbl in jim.c which includes pointers to functions which are in fred.c, even if I have extern prototypes defined. Basically this is because array initialization requires constant values.

However, this would seem something which is so common - ie inheritence is used all over the place. How do people handle this? I've looked through a few places in the code and cant see how this can be done. I could 'pretend' by initializing the Vtbl as I create the com object and do some LoadLibrary type dynamic addressing but I really want link time resolution not load time resolution.

One solution would be to put the common routines in a header file, and #include it, but code in headers or #including modules is uaually frowned upon! I cant see any sensible way of doing this and I'd rather not do lots of code duplication if avoidable as this common class is used in about 7 other classes!

Rob Shearman suggested, " Have a look at dlls/quartz/pin.h I have emulated C++ style inheritance by creating a structure that is included at the start of every derived implementation and then constructing the vtable at compile time and linking to the base functions. If you wanted to do the same for d3d{8,9} and wined3d you would have to add each common function to the spec file."

Jason wasn't sure that was the same solution as the problem he was trying to solve:

I like the solutions of putting the structures in - thats a neat way of ensuring consistency...

However, I think the vtbl issue is different - Dont you get away with constructing the vtbl because all subclasses are in the same C part, or have I missed something?

BTW I dont want to call cross shared library for inheritance, but I do want to call cross 'C' part in the same library, so hopefully shouldnt need to use the spec file.

Any thoughts? If not, I'll go for forwarding functions - painful, but not the end of the world.

Rob answered the first question and then confirmed Jason's original idea:

They are all part of the same interface, yes.

Forwarding functions seem to be the only maintanable way of doing this.

5. WinMM Timer Events

9 Oct 2004 - 11 Oct 2004 (6 posts) Archive Link: "RFC re winmm/time.c"

Topics: Multimedia

People: Jeremy WhiteEric PouechVitaliy Margolen

Hell may not be freezing over, but the temperature dropped a little this past week: some patches from Jeremy White, CodeWeaver's CEO, made it into Wine. This isn't the first time it's happened, though as Jeremy likes to point out, his patches usually find their way to Alexandre's patch dumpster based on comment style alone. One in question generated some discussion on wine-devel when Jeremy asked:

I ran into a problem with PowerPoint and winmm timer events, that has led me to radically alter this file. (ed. note: winmm/time.c)

However, I'd appreciate a gut check from anyone more experienced with it than I.

The fundamental problem is that Powerpoint does a timeBeginPeriod(1), trying to set timer resolution to 1 ms; we steadfastly discard that, and continue generating time updates and events on a roughly 10 ms interval, this can, in rare situations, lead to some awkward delays.

Some investigation with a test program shows that most Windows systems start with a default resolution of 1 ms. This test program is attached; the 'average' reported at the top is the default resolution. Further, Windows seem to steadfastly ignore any timeBeginPeriod(x) where x > the current period. I surveyed about 6 systems; a mix on Win98/Win2k and Win XP. All but one rogue Win 2K system had a 1 ms timer interval (the rogue system had a 10 ms interval; why, I do not know). The MSDN pages suggest (but don't state clearly) that this is the expected behavior.

This behavior essentially means that on most Windows systems the timer resolution of winmm is 1ms and can not be changed.

So, question #1: anyone object if I fix the timer resolution at 1 ms?

Next, if I make this change, it makes the code in time.c, which is fairly awkward imho, even less efficient. We'll basically be scanning a loop every ms for no particularly good reason.

I couldn't stomach this, so I rewrote it. Question #2: anyone object to my change? I have tested it with my attached test program, and I appear to have gotten it right, but...

Thoughts? Comments? Flames? Suggestions I go back to my day job?

Eric Pouech gave a little background on what Jeremy found and gave a review:

mm timers have been created to give better resolution than the old ticker from DOS (55ms, 18.2 ticks per second). But this requires specific hardware to do so, hence the various results you get. I would assume that on recent boxes you get 1ms as lowest resolution.

the current code had been written (hmmm) with the assumption that GetTickCount() could have a resolution of 55ms, hence you couldn't rely on it and had to do the job yourself for a better resolution.

Wine provides 1ms resolution in GetTickCount, ReactOs does also (through a quicly browsing of the code) (and the number of cases where winmm will be run on Windows), so the basic proposition sounds fine.

From an implementation point of view, there's something wrong with it. The time returned from TIME_MMSysTimeCallback (time to wait for next timer to elapse) only takes into account the timers which existed when the function is entered, not the ones which could have been created or deleted while processing the callbacks.

Another point, with your proposal, we could use the fact that the global time no longer needs to be maintained, hence the worker thread can be destroyed when no more timers exist.

Vitaliy Margolen mentioned there might be a problem with this approach based on his own personal experience:

I'm using mmTimer on Win95 in one of my programs to create more precise Sleep function. I'm using one shot timers for this. So having an extra overhead will hurt the performance. I'm already have interthread suspending/resuming with thread handle duplication.

As I recall all my systems I was using at a time had a default resolution of 10ms.

MSDN says that each timeBeginPeriod should be matched with timeEndPeriod. When I stopped the program in the middle of debugging it, I had a resolution of 1ms thereafter. It seems that native using the same resolution for the whole system.

Thus far Alexandre hasn't committed the patch.

6. Wine Libraries on Windows

14 Oct 2004 (4 posts) Archive Link: "Stupid thing to try ..."

Topics: Testing

People: Lars SegerlundSteven EdwardsThorsten KaniReactOS

There's no reason why some of Wine's higher-level libraries won't work on Windows. At least, in theory that's possible. Lars Segerlund inquired about that this week:

I was thinking of a silly thing to try, namely replacing windows dll's with wines, does anybody have any thoughts about it ?

I just thought about it as a debugging trick I wanted to try, but I don't know enough to evaluate if it's even worth trying.

So what about it, is it worth giving a shot ?

Steven Edwards cautioned against doing that directly since apparently it's a great way to cripple a working system:

It wont work well. I have done it before. The best thing to do is the change your dlls search order and use a copy of the Wine dlls built for Mingw and test them under Windows that way. Certain key processes such as winlogon are tied to ole32 and friends.

Thorsten Kani offered more advice:

I am currently using the ReactOS tree to debug comctl32.dll under Windows. For this to work, you will also need the Mingw package and a recent gcc/binutil package. (also available from there).

Also make sure to disable Windows File Protection. I am using a patched SFC.DLL + a tool called 'Wfpadmin' for the job.

Steven then followed up with a way to test specific applications using an undocumented trick on Windows, " Under Windows you can just compile the dll using mingw and then drop the dll in to the program direct that you want to test. Lets say you have a app name foo.exe you can copy the wine comctl32.dll to that directory that contains foo.exe and the make a copy of foo.exe and name the copy foo.exe.local When you create a *.exe.local file it exposes a hidden hack in Windows that forces it to search the local directory first for dlls no matter what the registry setting is. Note this only works for comctl32, shell32, shlwapi, ole32 and a few others. Dlls from Wine like user32, gdi32, ntdll, kernel32 and friends cannot be loaded on Windows."

The neat thing about this approach is it lets you mix and match native DLL's on Windows to figure out potential problems.







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.