January 2005 - Wine-Devel - list.winehq.org

Re: Minor wine-devel DCOM corrections
by Dan Kegel Jan. 11, 2005

Jan. 11, 2005

Rob Shearman wrote: > We have a number of marshaling tests in our test framework at the moment > (in wine/dlls/ole32/tests/marshal.c). It is hard to do anything > cross-process (or cross-machine!) because of the way the test framework > is done. Mike did suggest using environment variables to hack around > those limitations, but so far that hasn't turned into any code from > either of us. Hey, that's not a bad idea. You could set an environment variable, then rerun the same program with the same arguments, and your test could sense the environment variable and run the 2nd process's test role. Is there a generic win32 way to run yourself again with the same arguments? If not, it'd probably only take a little tweaking of include/wine/test.h to set one up... - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

Re: Correction to COINIT_MULTITHREADED test
by Paul Vriens Jan. 11, 2005

Jan. 11, 2005

On Mon, 2005-01-10 at 21:20, Bill Medland wrote: > Bill Medland (billmedland(a)mercuryspeed.com) > Correct testing for multithreaded > (as spotted by Paul Vriens; fix suggested by Robert Shearman) > Hi Bill, it wasn't the check that was way over my head. The thing is, that with this code change we walk a new path in COM_CreateApartment. I don't know what the result is but in CoInitializeEx we do: 545 if (!(apt = COM_CurrentInfo()->apt)) 546 { 547 apt = COM_CreateApartment(dwCoInit); 548 if (!apt) return E_OUTOFMEMORY; 549 } and apparently that leaves us with a E_OUTOFMEMORY all the time. Which means that we will not come to the part: 559 COM_CurrentInfo()->inits++; and that leads to errors as: trace:ole:CoInitializeEx ((nil), 4) trace:ole:COM_CreateApartment thread 0xd is entering the multithreaded apartment trace:ole:CoInitializeEx ((nil), 2) err:ole:CoInitializeEx Attempt to change threading model of this apartment from 0x0 to 0x2 which also shows that the check is wrong. When CoInitializeEx is called with COINIT_DISABLE_OLE1DDE it shouldn't go in. What MSDN also says is: Any combination of values from the COINIT enumeration can be used, except that the COINIT_APARTMENTTHREADED and COINIT_MULTITHREADED flags cannot both be set. So should that be accounted for as well? Cheers, Paul.

1 0

comctl32.dll and commctrl.dll
by Dripple Jan. 11, 2005

Jan. 11, 2005

Hi all, I'm a newbie in wine using and wine developpement. I just need information about comctl32.dll and commctrl.dll. I'm trying to have this app (http://appdb.winehq.org/appview.php?appId=1485&versionId=2451) working. In fact, it works. But only using native comctl32.dll, which requires native commctrl.dll. Can anybody explain me what's missing in buitlin comctl32.dll and/or commctrl.dll ? Is it planned to fix commctrl.dll, to avoid piracy ? Thanks. Dripple

5 7

Re: advpack: add two missing stubs
by Robert Reif Jan. 11, 2005

Jan. 11, 2005

Rob Shearman wrote: > > I think you forgot to include the tests. > > Rob > Past my bed time. diff -u -N wine.cvs/dlls/advpack/tests/advpack.c wine/dlls/advpack/tests/advpack.c --- wine.cvs/dlls/advpack/tests/advpack.c 1969-12-31 19:00:00.000000000 -0500 +++ wine/dlls/advpack/tests/advpack.c 2005-01-10 22:54:50.000000000 -0500 @@ -0,0 +1,66 @@ +/* + * Unit tests for advpack.dll + * + * Copyright (c) 2005 Robert Reif + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#define NONAMELESSSTRUCT +#define NONAMELESSUNION +#include <windows.h> + +#include "wine/test.h" +#include "advpub.h" + +static void version_test() +{ + HRESULT hr; + DWORD major, minor; + + major = minor = 0; + hr = GetVersionFromFile("kernel32.dll", &major, &minor, FALSE); + ok (hr == S_OK, "GetVersionFromFileEx(kernel32.dll) failed, returned " + "0x%08lx\n", hr); + + trace("kernel32.dll Language ID: 0x%08lx, Codepage ID: 0x%08lx\n", + major, minor); + + major = minor = 0; + hr = GetVersionFromFile("kernel32.dll", &major, &minor, TRUE); + ok (hr == S_OK, "GetVersionFromFileEx(kernel32.dll) failed, returned " + "0x%08lx\n", hr); + + trace("kernel32.dll version: %d.%d.%d.%d\n", HIWORD(major), LOWORD(major), + HIWORD(minor), LOWORD(minor)); +} + +static void admin_test() +{ + BOOL res; + DWORD reserved; + + res = IsNTAdmin(0, &reserved); + ok (res == TRUE || res == FALSE, "IsNTAdmin returned: 0x%08x\n", res); + + trace("IsNTAdmin = %s\n", res == TRUE ? "TRUE" : res == FALSE ? "FALSE" : + "???"); +} + +START_TEST(advpack) +{ + version_test(); + admin_test(); +} diff -u -N wine.cvs/dlls/advpack/tests/.cvsignore wine/dlls/advpack/tests/.cvsignore --- wine.cvs/dlls/advpack/tests/.cvsignore 1969-12-31 19:00:00.000000000 -0500 +++ wine/dlls/advpack/tests/.cvsignore 2005-01-10 21:17:35.000000000 -0500 @@ -0,0 +1,3 @@ +Makefile +advpack.ok +testlist.c diff -u -N wine.cvs/dlls/advpack/tests/Makefile.in wine/dlls/advpack/tests/Makefile.in --- wine.cvs/dlls/advpack/tests/Makefile.in 1969-12-31 19:00:00.000000000 -0500 +++ wine/dlls/advpack/tests/Makefile.in 2005-01-10 21:07:22.000000000 -0500 @@ -0,0 +1,13 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +TESTDLL = advpack.dll +IMPORTS = advpack user32 kernel32 version + +CTESTS = \ + advpack.c + +(a)MAKE_TEST_RULES@ + +### Dependencies:

1 0

Re: [LOSTWAGES] Add regedit janitorial project
by Michael Stefaniuc Jan. 10, 2005

Jan. 10, 2005

Mike McCormack wrote: > > ChangeLog: > * Add regedit janitorial project > > ------------------------------------------------------------------------ > > > Janitorial Projects > > Any self respecting project has a Janitorial project (e.g. Kernel > Janitor's List <http://janitor.kernelnewbies.org>), and it's high time > that we have one too. What is there to clean up? Well, lots of things! :) > > > Regedit fixes > > Regedit lacks a few features. We need to improve regedit to: > > * Allow display and editting of binary (REG_BINARY) values. > * Allow display and editting of multi-string (REG_SZ_MULTI) values. > * Import registry files regerated by Windows 2000 regedit Are you sure this is a janitorial project? It sounds to me more like a normal development work and not janitorial. It would better fit into "tasks" or the "todo" lists. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

4 4

Fwd: Foobar2000 audio player Regression
by Nick Hornback Jan. 10, 2005

Jan. 10, 2005

I originally posted this to the -users list, but I was contacted by Robbert Xerox, who had the exact same issue, and thus far nobody has replyed in the users list, so maybe it will get more attention here. > Foobar2000 worked virtually perfectly in the 20041019 > release (aside from some comctrl32 repainting issues > -- which native comctrl32.dll fixed), but in 20041201 > it is completely unuseable. Two major problems: > 1) The toolbars are completely gone. They are sort-of > displayed when they get activity via mouse-press or > whatever, but they do not repaint correctly at all. > See this screenshot for details: > http://img20.exs.cx/my.php?loc=img20&image=w1ifoobar.gif > 2) It takes 100% cpu. In the 20041021 release, it > hovered around 5% cpu (on my athlon 64 3200+), which > was excellent because that beat most native linux > audio players. > The console log is as follows (no errors or warnings): > fixme:hook:NotifyWinEvent (32780,0x10026,-4,1)-stub! > fixme:hook:NotifyWinEvent (32780,0x10026,-4,1)-stub! > fixme:hook:NotifyWinEvent (32780,0x10026,-4,2)-stub! > fixme:hook:NotifyWinEvent (32772,0x1002a,-4,0)-stub! > fixme:hook:NotifyWinEvent (32772,0x1002c,-4,0)-stub! > fixme:win:SetWindowTextA cannot set text "" of other > process window (nil) > Does anyone know what is going on here? I have since found out that if you use a the builtin comctrl32.dll, none of the window repaints at all. In previous wine releases, using the builtin comctrl32.dll would just create minor glitches (ex. the status bar wouldn't update). __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

4 6

RtlQueryRegistryValues implementation, probably not prefect but makes safedisc happy
by Ivan Leo Puoti Jan. 10, 2005

Jan. 10, 2005

I've attempted to implement RtlQueryRegistryValues() This code is probably buggy, as I haven't tested it much, but it makes safedisc happy. If it's OK I'll send a patch to add it to ntdll, ntoskrnl will then forward calls. comments/corrections/thoughts welcome. Ivan.

1 0

Warnings left when compiling on GNU/Linux
by Gerald Pfeifer Jan. 10, 2005

Jan. 10, 2005

When compiling on SUSE LINUX 9.2 using GCC 3.3.5 the following are the only warnings I'm getting for current Wine CVS: metafile.c:395: warning: `test_mf_PatternBrush' defined but not used rtlstr.c:552: warning: `test_RtlUpcaseUnicodeChar' defined but not used rtlstr.c:578: warning: `test_RtlUpcaseUnicodeString' defined but not used rtlstr.c:629: warning: `test_RtlDowncaseUnicodeString' defined but not used hlp2sgml.c:219: warning: `%x' yields only last 2 digits of year in some locales On FreeBSD 4.10 using GCC 3.3.4 I am also seeing the following one: fd.c:572: warning: right shift count >= width of type fd.c:574: warning: right shift count >= width of type Any chance we could get rid of these? :-) Gerald

5 5

ole32 : wrong check in compobj.c
by Paul Vriens Jan. 10, 2005

Jan. 10, 2005

Hi, while looking through the code I saw: if (model & COINIT_MULTITHREADED) this will never work as COINIT_MULTITHREADED = 0. The attached patch fixes the 3 occurrences of a check against COINIT_*. This patch however makes the COM_CreateApartment in compobj.c: 545 if (!(apt = COM_CurrentInfo()->apt)) 546 { 547 apt = COM_CreateApartment(dwCoInit); 548 if (!apt) return E_OUTOFMEMORY; 549 } return E_OUTOFMEMORY, always (?). And that makes sure that we have a mismatch between CoInitialize and CoUninitialize. So there's definitely something else wrong as well. Any idea ? Cheers, Paul.

3 4

Re: Minor wine-devel DCOM corrections
by Mike Hearn Jan. 10, 2005

Jan. 10, 2005

On Mon, 10 Jan 2005 10:56:30 -0800, Bill Medland wrote: > Bill Medland (billmedland(a)mercuryspeed.com) > Minor typo correction and term expansion changes Bill, if that document was helpful I'll write some more docs for you.

3 3

Use Interlocked* functions
by Joris Huizer Jan. 10, 2005

Jan. 10, 2005

To see how far we are, I tried grepping to get This->refs stuff grep -r -n -e 'TRACE(.*This->ref)' * grep -r -n "++(This->ref)" * grep -r -n -- "--(This->ref)" * I hope there are a lot of false positives there :-/ regards, Joris

5 7

Re: ntdll / kernel32 : #52 (take #2)
by Alexandre Julliard Jan. 10, 2005

Jan. 10, 2005

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > +/****************************************************************** > + * NtAddAtom (NTDLL.@) > + */ > +NTSTATUS WINAPI NtAddAtom( const WCHAR* name, ULONG name_len, ATOM* atom ) > +{ > + return RtlAddAtomToAtomTable( get_global_table(), name, atom ); > +} You can't do that, if the name is a counted string you cannot ignore the length and assume it is null-terminated. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Give a more informative error when a DLL fails to initialize
by Mike Hearn Jan. 10, 2005

Jan. 10, 2005

Hi Alexandre, This patch was missed, does it no longer apply? Also is it OK to just put the changelog as the first line of the email like that? thanks -mike On Wed, 22 Dec 2004 18:19:47 +0000, Mike Hearn wrote: > Give a more informative error when a DLL fails to initialize > --- dlls/ntdll/loader.c (revision 3) > +++ dlls/ntdll/loader.c (local) > @@ -893,9 +893,14 @@ static NTSTATUS process_attach( WINE_MOD > WINE_MODREF *prev = current_modref; > current_modref = wm; > if (MODULE_InitDLL( wm, DLL_PROCESS_ATTACH, lpReserved )) > + { > wm->ldr.Flags |= LDR_PROCESS_ATTACHED; > + } > else > + { > + ERR("Initialization of %s failed\n", debugstr_w(wm->ldr.BaseDllName.Buffer)); > status = STATUS_DLL_INIT_FAILED; > + } > current_modref = prev; > }

3 4

Re: WININET: implement InternetTime{From,To}SystemTime{A,W} (#2)
by Dmitry Timoshkov Jan. 10, 2005

Jan. 10, 2005

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > Changelog: > Implement and test InternetTime{From,To}SystemTime{A,W}. If you could also make the attached tests pass (applied over your tests) that would be great. The tests show that strings should be parsed a bit smarter and comparisons should be case insensitive. -- Dmitry.

1 0

Re: Janitorial : Use Compiler Warnings ( -Wmissing-declarations ) ( #1 )
by Alexandre Julliard Jan. 10, 2005

Jan. 10, 2005

Rémi Assailly <remi.assailly(a)free.fr> writes: > --- include/wine/library.h 2005-01-07 19:41:26.000000000 +0100 > +++ include/wine/library.h 2005-01-07 19:49:41.389057824 +0100 > @@ -42,6 +42,7 @@ > extern void *wine_dlopen( const char *filename, int flag, char *error, int errorsize ); > extern void *wine_dlsym( void *handle, const char *symbol, char *error, int errorsize ); > extern int wine_dlclose( void *handle, char *error, int errorsize ); > +extern void __wine_dll_register( const IMAGE_NT_HEADERS *header, const char *filename ); Functions starting with '__wine' are internal only and must not be declared in the public headers if it can be avoided. -- Alexandre Julliard julliard(a)winehq.org

2 2

Switching to winecfg
by Crestez Leonard Jan. 10, 2005

Jan. 10, 2005

As winecfg gets better and better I think it's time to consider making it actually change the config file. I made a patch for it, but it's a work in progress, and not ready for general use. I don't expect you to commit it, so I sent it here for discussion. I don't think that this needs a complex migration process, all we need to do is save the wine config registry to $WINEPREFIX/config. If people want their config file back, wine can skip saving the configuration if it wasn't modified. This will allow comments to persist in the config file. Anyway, regedit is better than editing a config file. In writing this patch I came across some strange stuff in server/registry.c. What's the point of all the save level stuff? current_level is only set once to 1, on initialization, and save_level depends on whether registry branches should be saved only when modified (can anyone think of a reason to disable that feature?). Can't the KEY_DIRTY bit be used instead of this level stuff? Also update_level seems to be dead code, not called from anywhere. Please tell me what you think about the patch. -- Crestez Leonard <cleonard(a)go.ro>

2 1

Re: WININET: implement InternetTime{From,To}SystemTime{A,W} (#2)
by Alexandre Julliard Jan. 10, 2005

Jan. 10, 2005

Hans Leidekker <hans(a)it.vu.nl> writes: > +/*********************************************************************** > + * InternetTimeFromSystemTimeW (WININET.@) > + * > + * NOTES > + * This is not an illegal W->A crosscall since internet dates are ASCII strings. It would still be much cleaner to have the A function call the W one. -- Alexandre Julliard julliard(a)winehq.org

1 0

typelib2.c problems
by Gerald Pfeifer Jan. 10, 2005

Jan. 10, 2005

The following change to dlls/oleaut32/typelib2.c revision 1.32 date: 2005/01/09 17:32:17; author: julliard; state: Exp; lines: +14 -14 Paul Vriens <Paul.Vriens(a)xs4all.nl> - use Interlocked* functions in AddRef and Release. - store the result of the Interlocked functions and use only this. causes the following warnings on SUSE LINUX 9.2 and FreeBSD: typelib2.c:3012: warning: passing arg 1 of `InterlockedIncrement' from incompatible pointer type typelib2.c:3027: warning: passing arg 1 of `InterlockedDecrement' from incompatible pointer type Would you mind fixing this? Gerald

1 0

dcom95.exe removed from sf.net
by Jeremy Newman Jan. 10, 2005

Jan. 10, 2005

Somebody removed dcom95.exe from sf.net. Was there a reason for that? We really need to keep that file mirrored. It's an essential file for many programs to run under wine. I've re-added the file as a hidden file for the moment. It won't show up in the download list, but we can still link to it.

8 18

Re: German language files
by Mike McCormack Jan. 10, 2005

Jan. 10, 2005

Thanks for the translations, however please read: http://www.winehq.org/site/sending_patches You should send patches, not zip files. Diff against the current WineHQ CVS, not ReactOS. Diff new files against /dev/null. eg. diff /dev/null dlls/shell32/shell32_De.rc Your changes are unlikely to be accepted as they are. There's only one person processing WineHQ patches. If you keep the submissions uniform it reduces his workload. Mike Klemens Friedl wrote:> > Please add the files to the wine directory. Thanks! > > > Klemens Friedl <frik85>

1 0

Re: USER32: result of ScrollBar functions review (4th try)
by Alexandre Julliard Jan. 9, 2005

Jan. 9, 2005

Vitaly Lipatov <lav(a)etersoft.ru> writes: > @@ -1728,12 +1821,15 @@ > SCROLLINFO info; > > TRACE("hwnd=%p nBar=%d min=%d max=%d, bRedraw=%d\n", hwnd, nBar, minVal, maxVal, bRedraw); > - > + > info.cbSize = sizeof(info); > info.fMask = SIF_RANGE; > info.nMin = minVal; > info.nMax = maxVal; > SetScrollInfo( hwnd, nBar, &info, bRedraw ); > + if (nBar == SB_CTL) > + FIXME("needs to send SMB_SETRANGE when SB_CTL\n"); > + //return SendMessageW(hwnd, SBM_SETRANGE, (WPARAM)0, (LPARAM)0); > return TRUE; There's no reason to add a FIXME, calling SetScrollInfo is perfectly fine and it's what Windows does too, we even have a test for it. Also please send separate changes as separate patches, especially when you are renaming functions which causes a lot of changes all over and makes it hard to see what else is changing. -- Alexandre Julliard julliard(a)winehq.org

2 2

Wine(server) priority inversion on CK kernel mailing list
by Andreas Mohr Jan. 9, 2005

Jan. 9, 2005

Hi, I'm following CK kernel development, and the mailing list had the following posting: ---------- Message: 19 Date: Fri, 07 Jan 2005 23:16:14 +1100 From: Con Kolivas <kernel(a)kolivas.org> Subject: Re: [ck] wine is bloody slow with 2.6.10-ck2 To: Michal ?erav?k <michalz(a)olomouc.com> Cc: CK Kernel <ck(a)vds.kolivas.org> Message-ID: <41DE7D8E.8090102(a)kolivas.org> Content-Type: text/plain; charset="iso-8859-2" Michal ?erav?k wrote: > Hi, > > I have been running photoshop under wine > with 2.6.8.1-ck9 and 2.6.9 and it was good. > Is there any workaround for 2.6.10-ckx and wine > to get normal speed? > It's the same with prelink and without. Nice your wineserver +19. If that's not enough, just run wine at +19. Wineserver gets into a silly priority inversion scenario with the main wine threads. Cheers, Con ---------- Note that Con indicated several times that Wine is a very "special" piece of software, it has wildly differing gaming behaviour (threading behaviour) than native Linux games. For those of you who don't know what priority inversion is (I'll try to explain it, but I'm sure my explanation sucks ;): one (high priority) thread is waiting on a lock, and in order to keep this high priority, another thread owning that lock gets more CPU to get that lock released. Problem is that that thread should have a lower priority, but since the high priority thread always has to wait on the lock, the low priority thread effectively has a much higher priority. These could just be the usual known slow wineserver communication effects at work here, but I wanted to make sure you know about these issues on the CK list. Andreas Mohr

3 3

Re: [winegcc] Include .so files when calling winebuild
by Alexandre Julliard Jan. 9, 2005

Jan. 9, 2005

Peter Berg Larsen <pebl(a)math.ku.dk> writes: > Changelog: > Currently when compiling a program, winegcc calls winebuild > to solve .def references. But winegcc drops .so files, > so any new .def symbols in a .so causes a unresolved symbol at > link time. This patch adds .so files to the files to winebuild. I'm not sure I follow you, if your .so files have been built correctly they shouldn't contain undefined references to Windows APIs. Could you please show an example of the situation that causes a problem? -- Alexandre Julliard julliard(a)winehq.org

2 1

another build problem on current cvs
by Joris Huizer Jan. 9, 2005

Jan. 9, 2005

Hello, For the past week or so, building from cvs on a debian/stable system w/ alsa installed (using a custom kernel Linux debian 2.4.18.041216) breaks on alsa-specific code in wine; I attached the log; note that I did a `cvs update -dPA` and `make distclean` so this can't be any problem with the source I have Any ideas? Maybe you can point me to a place where I can read how to fix this properly (I never worked on alsa-specific code before...) or something like that regards, Joris

4 7

Directx 9
by Ann and Jason Edmeades Jan. 8, 2005

Jan. 8, 2005

Hiya, FYI I've spent the last couple of months putting together a directx 8 level support into wined3d and calling it from d3d9 such that I can also change d3d8 easily to use the new code. This is mostly complete other than the texture support and the shader support plus moving some functions / stubs into the common code. If you have any directx 8/9 questions feel free to email me directly, put questions on wine-devel or perhaps even the wined3d (very, very quiet - http://www.bbrox.org/mailman/listinfo/wine-d3d) mailing list (Lionel's). You really are welcome, and I'll try to answer any questions I can. I wouldn't spent too much time trying to move existing functionality between d3d8 to wined3d unless you really want to as I am trying to get this move completed asap. I really don't want to discourage any d3d assistance, its just I know where I am and what I have left to do. I have generally been doing a patch and getting it committed both due to lack to time, but also to avoid potential rework of multiple patches. I really hope to get most of the non-shader support done quite quickly once the 20 patch goes in (Christmas and FarCry got in the way, and I had some teething problems with the render target support which delayed it!). Next will be the texture support and that should be quick as it is relatively trivial to move across. >As soon as I'm happy with how wine's and directX work >I can stop duplicating what you've done and start >moving onto a more co-operative development... Sounds good - one thing wine has suffered from is a lack of people doing the directx support! Note that Raphael (copied on this note) has some outstanding patches he has put off while I do the move to support hardware vertex buffers so the drawstridedslow case is driven less frequently, but that's the only outstanding work I know about. > or moving DirectX8 over to using WineD3d. I have a version locally where I have changed d3d8 up to about patch 13. I can send it to you if it helps - Unfortunately I think the swap to wined3d will have to be one big patch, I don't think there is a way to move d3d8 over slowly, as you have to move the state block code in one go, the resource8 subclasses in one go etc... >I've merged all the creation surface code into a >single createSurface function that is called with >different parameters/flags to create a backbuffer, >PlainOffscreenSurface or rendertarget etc... Sounds fine - The problem I had with the latest patch was purely being able to add the support for getfrontbuffer etc which needed to return d3d8 or d3d9 objects, but the initial crates being done in the wined3d layer. A single callback sounds useful, as I know I'll have to do something similar for stencildepth surfaces (nothing else is created purely from the wined3d layer, so I don't think others need the same). FWIW I do the same, ie find demos on the web with source code, and then try to get them working. That's how most of the d3d8 support came about as it's a lot easier making a demo work than finding why there's a small amount of corruption for a particular game. I wouldn't claim to be a directx nor opengl expert - its all been a learning experience as I go! Maybe we should collect some useful test program links! If there's any d3d8/9 programmers out there, there's definitely a fun project to do to produce test programs for wine. They cant be automated (I think!) but it would be useful to be able to visually see the effect differences of all the render states, the texture states, prove the shader support works in both hw and sw vertex and pixel code etc etc. Jason

1 0