World Wine News

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?

First dx9 related patch - It's 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.

Changelog

Make a wined3d interface, and generate a wined3d object in the d3d9 create method. Make the first (simple) call implementation into the new wined3d interface (d3d8 change will follow later), and ensure the wined3d8 object has access to the locks required for later on.

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

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.

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, don't hold your breath for any working d3d9 support - This may take months!

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.

Changelog

Move into wined3d and call from d3d9 the GetAdapterId function and copy all the gl declarations into the more global wined3d_gl header file

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

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

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 it's a complete skeleton to be built on.

Changelog

Add an IWineD3DDevice object type (empty for now), and create one when an IDirect3DDevice object is created.

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

Fully support (as far as was previously - they haven't changed in dx9) VertexBuffer and Resource classes and use them 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!

Changelog

• Add support (as far as was previously) for the VertexBuffer and Resource classes in wined3d and use when called from d3d9
• Reduce the header includes in all the d3d9 interface to one common set in the private header

If you haven't 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 can't 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:

IJimVtbl Jim_Vtbl = {
IJimImpl_QueryInterface,
IJimImpl_AddRef,
IJimImpl_Release,
IFredImpl_CommonFunc1,
IFredImpl_CommonFunc2,
:
IJimImpl_UniqueFunc1 etc
}

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 don't need to (they are mostly stubs even in the d3d8 code today).

However, doing this fails to compile - It won't 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 - i.e. inheritance is used all over the place. How do people handle this? I've looked through a few places in the code and can't 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 usually frowned upon! I can't 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!

I like the solutions of putting the structures in - that's a neat way of ensuring consistency...

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

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

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

They are all part of the same interface, yes.

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

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 seems 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 cannot 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?

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 quick 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.

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.

I was thinking of a silly thing to try, namely replacing windows dlls with wine's, 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 ?

It won't 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.

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.