August 2006 - Wine-Devel - list.winehq.org

Re: widl [2/6]: Handle more pointer types in write_type
by Robert Shearman Aug. 29, 2006

Aug. 29, 2006

Dan Hipschman wrote: >So write_type can handle more than just full pointers. > Hi Dan, I see from a couple of patches back that you intend to move the representation of pointers out of the var_t type. How do you intend to represent "char **" for example? type: FC_RP, ref: { type: FC_RP, ref: { type: FC_CHAR } } or: type: FC_CHAR, ptr_level: 2 It seems to me you're going down the first route (and there's nothing wrong with that as far as I can see). I'm just interested to know which approach you are taking. -- Rob Shearman

2 1

Re: widl [3/6]: Represent typedefs with easier to use structures
by Robert Shearman Aug. 29, 2006

Aug. 29, 2006

Dan Hipschman wrote: >diff --git a/tools/widl/header.c b/tools/widl/header.c >index 3a4cea9..5de43c0 100644 >--- a/tools/widl/header.c >+++ b/tools/widl/header.c >@@ -203,13 +203,14 @@ void write_type(FILE *h, type_t *t, cons > { > int c; > >+ if (t->is_const) fprintf(h, "const "); >+ > if (n) fprintf(h, "%s", n); >+ else if (t->kind == TKIND_ALIAS) fprintf(h, "%s", t->name); > > I'm not really sure we should be depending on a typelib thing for a fundamental concept such as this. In fact, I think the kind field of the type_t structure could probably be removed and generated as needed in the typelib generation code. >@@ -902,6 +885,7 @@ static type_t *make_int(int sign) > > void init_types(void) > { >+ decl_builtin("void", 0); > decl_builtin("byte", RPC_FC_BYTE); > decl_builtin("wchar_t", RPC_FC_WCHAR); > decl_builtin("int", RPC_FC_LONG); /* win32 */ > > This would seem as though it would make widl incorrectly accept "int func(void a);" as a valid statement. I think you need to try to fix this case. >@@ -1147,6 +1131,7 @@ static type_t *make_type(unsigned char t > t->type = type; > t->ref = ref; > t->attrs = NULL; >+ t->orig = NULL; > t->funcs = NULL; > t->fields = NULL; > t->ifaces = NULL; >@@ -1175,8 +1160,15 @@ static typeref_t *uniq_tref(typeref_t *r > typeref_t *t = ref; > type_t *tp; > if (t->uniq) return t; >- tp = make_type(0, t->ref); >- tp->name = t->name; >+ >+ if (t->name) >+ { >+ tp = duptype(t->ref, 0); >+ tp->name = t->name; >+ } >+ else >+ tp = duptype(t->ref, 1); >+ > t->name = NULL; > t->ref = tp; > t->uniq = 1; >@@ -1311,11 +1303,27 @@ static unsigned char get_pointer_type( t > return RPC_FC_FP; > } > >-static type_t *reg_types(type_t *type, var_t *names, int t) >+static type_t *reg_typedefs(type_t *type, var_t *names, attr_t *attrs) > { > type_t *ptr = type; > int ptrc = 0; > >+ /* We must generate names for tagless enum, struct or union. >+ Typedef-ing a tagless enum, struct or union means we want the typedef >+ to be included in a library whether it has other attributes or not, >+ hence the public attribute. */ >+ if ((type->kind == TKIND_ENUM || type->kind == TKIND_RECORD >+ || type->kind == TKIND_UNION) && ! type->name && ! parse_only) >+ { >+ if (! is_attr(attrs, ATTR_PUBLIC)) >+ { >+ attr_t *new_attrs = make_attr(ATTR_PUBLIC); >+ LINK(new_attrs, attrs); >+ attrs = new_attrs; >+ } > > I'm not sure it is necessary to include this change with the rest of the patch. I'm also not sure what you are trying to accomplish here (as we always add the type to a typelib, no matter whether the type has the public attribute). >+ type->name = gen_name(); >+ } >+ > while (names) { > var_t *next = NEXT_LINK(names); > if (names->name) { >@@ -1323,8 +1331,7 @@ static type_t *reg_types(type_t *type, v > int cptr = names->ptr_level; > if (cptr > ptrc) { > while (cptr > ptrc) { >- int t = get_pointer_type( cur ); >- cur = ptr = make_type(t, cur); >+ cur = ptr = make_type(RPC_FC_RP, cur); > ptrc++; > } > } else { > > Thanks and keep up the good work! -- Rob Shearman

3 2

Re: widl: Remove use of type_t "ref" field for base types
by Robert Shearman Aug. 29, 2006

Aug. 29, 2006

Dan Hipschman wrote: >diff --git a/tools/widl/widltypes.h b/tools/widl/widltypes.h >index d39def3..cf0f246 100644 >--- a/tools/widl/widltypes.h >+++ b/tools/widl/widltypes.h >@@ -207,6 +207,7 @@ struct _type_t { > func_t *funcs; /* interfaces and modules */ > var_t *fields; /* interfaces, structures and enumerations */ > ifref_t *ifaces; /* coclasses */ >+ type_t *orig; /* dup'd types */ > int ignore, is_const, sign; > int defined, written, user_types_registered; > int typelib_idx; > You add a new field to type_t, yet no code uses it. Will it have some future purpose? -- Rob Shearman

2 1

Re: [wintrust] Add some documentation
by James Hawkins Aug. 29, 2006

Aug. 29, 2006

On 8/29/06, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > Hi, > > I thought I'd start with some documentation. The tests are already > there so what's missing is the implementation :-). > > > /*********************************************************************** > * WintrustAddActionID (WINTRUST.@) > + * > + * Add a Trust provider. Or actually the functions it performs. > + * Can you rewrite this sentence? It's not grammatically correct, and I don't understand what you're saying. -- James Hawkins

2 2

Keyboard freeze - Max Payne
by Jeremy Newman Aug. 29, 2006

Aug. 29, 2006

Just going through my list of issues I'd like resolved, and discovered this bug/regression. In Max Payne 1 / Max Payne 2 it seems the game freezes up for a few seconds when you hold down any key in the game. For example using 'W' to move forward, hold it down you take like 1 step and it freezes up. Letting go and waiting a few seconds gets the game back to normal. As you can imagine, this makes it unplayable. Before I go and enter this as a bug, I was wondering if anyone knows about this and/or has a fix.

2 4

Re: X11Drv: import glx context code
by Alexandre Julliard Aug. 29, 2006

Aug. 29, 2006

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > +@ cdecl WGL_CreateContext(long) X11DRV_WGL_CreateContext > +@ cdecl WGL_DeleteContext(long) X11DRV_WGL_DeleteContext > +@ cdecl WGL_GetCurrentContext() X11DRV_WGL_GetCurrentContext > +@ cdecl WGL_GetCurrentDC() X11DRV_WGL_GetCurrentDC > +@ cdecl WGL_GetCurrentReadDCARB() X11DRV_WGL_GetCurrentReadDCARB > +@ cdecl WGL_glGetIntegerv(long ptr) X11DRV_WGL_glGetIntegerv You should export the functions under their official name, like we do for the GDI functions, so something like: @ cdecl wglCreateContext(long) X11DRV_wglCreateContext etc. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [TRY 2] Add support for tooltips for system tray icons
by Alexandre Julliard Aug. 29, 2006

Aug. 29, 2006

James Liggett <jrliggett(a)cox.net> writes: > TRY 2: Integrate suggestions from Oleg Krylov and fix a tooltip rectangle bug. > > ChangeLog: > Add support for tooltips for system tray icons. It would be nicer to only initialize comctl32 once the first icon is added to avoid doing too much work at explorer startup, since the parent process is blocked in the meantime. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: widl [1/6]: Generate names for tagless structs, unions and enums
by Alexandre Julliard Aug. 29, 2006

Aug. 29, 2006

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > +static char *gen_name(void) > +{ > + static const char format[] = "__WIDL_%s_generated_name_%08lX"; > + static unsigned long n = 0; > + > + size_t size = sizeof format - 7 + strlen(input_base) + 8; > + char *name = xmalloc(size); > + > + sprintf(name, format, input_base, n++); > + return name; > +} You can't simply copy the file name, there's no guarantee it's a valid C identifier. You should use something like make_c_identifier in winebuild. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: opengl32: Enable per-app override for HKLM\Software\Wine\OpenGL: HKLM\Software\Wine\AppDefaults\app.exe\OpenGL.
by Paul Vriens Aug. 29, 2006

Aug. 29, 2006

On Mon, 2006-08-28 at 22:26 -0500, Ken Thomases wrote: > + > + /* @@ Wine registry key: HKLM\Software\Wine\OpenGL */ > + if ( RegOpenKeyA( HKEY_LOCAL_MACHINE, "Software\\Wine\\OpenGL", > &hkey) ) hkey = 0; > + > + len = GetModuleFileNameA( 0, buffer, MAX_PATH ); > + if (len && len < MAX_PATH) > + { > + HKEY tmpkey; > + /* @@ Wine registry key: HKLM\Software\Wine\AppDefaults\app.exe > \OpenGL */ > + if (!RegOpenKeyA( HKEY_LOCAL_MACHINE, "Software\\Wine\ > \AppDefaults", &tmpkey )) Hi, I thought this stuff was supposed to be moved to HKCU instead of HKLM? Cheers, Paul.

2 1

Re: X11Drv: import glx context code
by fenix＠club-internet.fr Aug. 29, 2006

Aug. 29, 2006

----Message d'origine---- >Date: Tue, 29 Aug 2006 01:39:49 +0200 >De: "Roderick Colenbrander" <thunderbird2k(a)gmx.net> >A: wine-patches(a)winehq.org >Sujet: X11Drv: import glx context code > >Hi, > seems you forget to change winex11dvr.spec file no ? :) Good Job anyway Regards, Raphael

2 1

Re: oleaut32 2/3: Updates variant:VarAnd to pass all failures exposed from conformance test
by Dan Kegel Aug. 28, 2006

Aug. 28, 2006

Did you attach the right patch? Seems like this is the same as #1. On 8/28/06, Benjamin Arai <me(a)benjaminarai.com> wrote: > Hi, > > ChangeLog: > - Removes all todo_wine's in VarAnd conformance test > - Fixes VarAnd to pass all tests in Windows XP SP2 and Wine > > --- > dlls/oleaut32/tests/vartest.c | 78 ---------- > dlls/oleaut32/variant.c | 327 +++++++++++++++++++++++++++++++++-------- > 2 files changed, 269 insertions(+), 136 deletions(-) > > Copyright: Google > License: LGPL > -- > Benjamin Arai > http://www.benjaminarai.com > > > > > > > -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

What purpose does wineinstall still serve?
by Scott Ritchie Aug. 28, 2006

Aug. 28, 2006

A while back, we talked about deleting Wine install. What exactly does it do these days, and why do we still have it? Thanks, Scott Ritchie

4 5

Re: missing link??
by Andreas Mohr Aug. 28, 2006

Aug. 28, 2006

Hi, On Sun, Aug 27, 2006 at 05:00:45PM +0200, Sabine Rode wrote: > Hallo, my tough guys, > it seems to be an miising link?? > I am newbie at ubuntu 6.06 instaöllled with the amd64 kernel > whenn i add my /etc/apt/sources.list with the both links > > deb http://wine.budgetdedicated.com/apt dapper main > and > > deb-src http://wine.budgetdedicated.com/apt dapper main > > i gwet both 404 errors. > > what is wrong? > your link or my issue? > > best regards > > sabine > germany 64bit support by Wine has been troublesome at least relatively recently (Wine, being used to run 32bit apps, additionally needs 32bit system libraries installed on the system and needs to be run in a chroot). Due to this possibly WineHQ simply doesn't offer Wine packages for a 64bit system - yet fails to do this properly :-P Please see also http://wiki.winehq.org/WineOn64bit or Google searches to find more info about current 64bit support status. (sorry, I'm not up-to-date any more on all matters of current Wine development due to working on other projects now). What's the exact status of 64bit support, anyone? [CC'd wd] Andreas Mohr

2 1

Yukon and Wine
by Tom Wickline Aug. 28, 2006

Aug. 28, 2006

Hello, Has anyone here taken a look at Yukon? It's a tool to capture games to a video. Yukon Home: http://www.neopsis.com/projects/yukon/ Example of AoE : http://dbservice.com/ftpdir/tom/Naxxramas-AoE.mp4 -Tom

1 0

Re: advpack:reg.c: Cast-qual warning fix
by Alexandre Julliard Aug. 28, 2006

Aug. 28, 2006

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > --- a/dlls/advpack/reg.c 2006-06-14 12:55:31.000000000 +0100 > +++ b/dlls/advpack/reg.c 2006-08-28 17:00:18.000000000 +0100 > @@ -255,11 +255,14 @@ > /* FIXME: read AdvOptions val for dwFlags */ > ZeroMemory(&cabinfo, sizeof(CABINFOW)); > cabinfo.pszInf = tmp_ini_path; > - cabinfo.pszSection = (LPWSTR)pszSection; > + cabinfo.pszSection = HeapAlloc(GetProcessHeap(), 0, (lstrlenW(pszSection) + 1) * sizeof(WCHAR)); > + lstrcpyW(cabinfo.pszSection, pszSection); > cabinfo.dwFlags = 0; I don't think we want to duplicate strings just because of the warning. If the string really needs to be writable sure, but if it's just because of MS broken prototypes it's not worth the extra cost. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: Patch to riched20 (resubmission)
by Huw Davies Aug. 28, 2006

Aug. 28, 2006

On Sun, Aug 27, 2006 at 05:35:54PM -0700, Mark Lu wrote: > If the rtf control is a child window AND it doesn't display its own context > menu, > then the WM_CONTEXTMENU message should be passed to the parent window in > the rtf > control's DefWindowProc. Here is what MSDN says on the subject: > > "If a window does not display a shortcut menu it should pass this message > to the DefWindowProc function. If a window is a child window, > DefWindowProc > sends the message to the parent. Otherwise, DefWindowProc displays a > default > shortcut menu if the specified position is in the window's caption." You mention the DefWindowProc behaviour here... > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -2318,7 +2319,11 @@ LRESULT WINAPI RichEditANSIWndProc(HWND > ME_SelectWord(editor); > break; > case WM_CONTEXTMENU: > - ME_ShowContextMenu(editor, (short)LOWORD(lParam), > (short)HIWORD(lParam)); > + if (!ME_ShowContextMenu(editor, (short)LOWORD(lParam), > (short)HIWORD(lParam))) > + { > + if (GetWindowLongW( hWnd, GWL_STYLE ) & WS_CHILD) > + SendMessageW( GetParent(hWnd), msg, wParam, lParam ); > + } > break; > case WM_PAINT: > if (editor->bRedraw) ...yet here you send the message to the parent yourself. Why can't you replace this with a 'goto do_default;' and let DefWindowProc do this for you? Huw.

2 1

Re: shlwapi: Fix writing an empty DataBlock list in SHWriteDataBlockList() (2nd resend)
by Alexandre Julliard Aug. 28, 2006

Aug. 28, 2006

Thomas Weidenmueller <wine-patches(a)reactsoft.com> writes: > --- dlls/shlwapi/clist.c 23 May 2006 12:48:43 -0000 1.12 > +++ dlls/shlwapi/clist.c 24 May 2006 17:23:15 -0000 > @@ -29,6 +29,8 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(shell); > > +#include "pshpack1.h" > + > /* DataBlock list element (ordinals 17-22) */ > typedef struct tagSHLWAPI_CLIST That doesn't look right. Why do you need to change the packing? -- Alexandre Julliard julliard(a)winehq.org

1 0

Patch not applied.
by Renu Rajput Aug. 28, 2006

Aug. 28, 2006

Hi I've tried submitting a patch to wine-patches 3 times(as per feedback from Wine group), but it has not been applied yet. Please tell me what I am doing wrong. Thanks Renu Here's the patch: diff -urN OldDir/dlls/comdlg32/filedlg.c NewDir/dlls/comdlg32/filedlg.c --- OldDir/dlls/comdlg32/filedlg.c 2006-08-10 18:45:12.000000000 +0530 +++ NewDir/dlls/comdlg32/filedlg.c 2006-08-11 16:09:32.000000000 +0530 @@ -2011,7 +2011,10 @@ IPersistFolder2_Release(ppf2); if( ! COMDLG32_PIDL_ILIsEqual(pidlCurrent, fodInfos-> ShellInfos.pidlAbsCurrent)) { - IShellBrowser_BrowseObject(fodInfos->Shell.FOIShellBrowser, pidlCurrent, SBSP_ABSOLUTE); + if (SUCCEEDED(IShellBrowser_BrowseObject(fodInfos->Shell.FOIShellBrowser, pidlCurrent, SBSP_ABSOLUTE))) + { + SendCustomDlgNotificationMessage(hwnd, CDN_FOLDERCHANGE); + } } else if( nOpenAction == ONOPEN_SEARCH ) {

2 1

Re : [DDRAW] Only detach surfaces when releasing a non-texture surface attached to a complex root.
by Elie Morisse Aug. 28, 2006

Aug. 28, 2006

Le 27.08.2006 19:23:53, Elie Morisse a écrit : > Refcounting fix, Wine devs tell me if I'm wrong as from now on I get something like this w/ The Nomad Soul : > > fixme:d3d:IWineD3DDeviceImpl_Release (0x1248028) Device released with resources still bound, acceptable but unexpected > fixme:d3d:dumpResources Leftover resource 0x217f988 with type 1,WINED3DRTYPE_SURFACE > fixme:d3d:dumpResources Leftover resource 0x1abca8 with type 1,WINED3DRTYPE_SURFACE > > Other games I tried aren't affected though, so this one may just be buggy.. > Good part is this prevents memory faults in The Nomad Soul at exit and when switching resolution. > > Please use this one instead, it fixes a regression in Moto Racer 2 ( detach surfaces of complex attached surfaces when releasing the root ).

1 0

Re: [DDRAW] Only detach surfaces when releasing a non-texture surface attached to a complex root.
by Stefan Dösinger Aug. 28, 2006

Aug. 28, 2006

Am Sonntag 27 August 2006 17:23 schrieb Elie Morisse: > Refcounting fix, Wine devs tell me if I'm wrong as from now on I get > something like this w/ The Nomad Soul : > > fixme:d3d:IWineD3DDeviceImpl_Release (0x1248028) Device released with > resources still bound, acceptable but unexpected fixme:d3d:dumpResources > Leftover resource 0x217f988 with type 1,WINED3DRTYPE_SURFACE > fixme:d3d:dumpResources Leftover resource 0x1abca8 with type > 1,WINED3DRTYPE_SURFACE > > Other games I tried aren't affected though, so this one may just be buggy.. > Good part is this prevents memory faults in The Nomad Soul at exit and when > switching resolution. Just asking, does this game hit the This->first_attached != This case? This shouldn't happen, I suspect that the refcounting issue is somewhere else. Also the This->first_complex == This check should always return true in theory. Can you send me a +ddraw,+d3d7 trace of the game, with and without your patch?

2 1

Building Wine with the lsb sdk
by Dan Kegel Aug. 28, 2006

Aug. 28, 2006

I've been a longtime fan of the idea behind the LSB, i.e. build once, run everywhere. (If you're an anti-fan of the LSB, please kindly skip this message.) So tonight I downloaded the current LSB SDK from http://www.freestandards.org/en/Download and gave it a shot. Here's the script I came up with: #!/bin/sh set -ex PATH=/opt/lsb/bin:$PATH CC=lsbcc CXX=lsbc++ export CC export CXX # Must define RTLD_DEFAULT because of http://bugs.linuxbase.org/show_bug.cgi?id=375 # Must define MAP_FILE because it's not in Unix's SUS3 # Must disable linux/videodev.h as it's not supported by the LSB, # and won't compile with lsbcc LSBCC_SHAREDLIBS=wine export LSBCC_SHAREDLIBS ac_cv_header_linux_videodev_h=no \ ./configure --prefix=/usr/local/wine-lsb make depend LDFLAGS=-ldl make LDFLAGS=-ldl CFLAGS="-g -O2 \"-DRTLD_DEFAULT=((void *)0)\" -DMAP_FILE=0" This worked past a number of problems, but the build breaks with the error /opt/lsb/include/unistd.h:342: error: syntax error before 'Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library' while building dlls/comctl32/tests/imagelist.c The fix is not obvious. I'll try giving it another look sometime this week. - Dan

1 1

DIB Engine
by satyr_22901＠yahoo.com Aug. 27, 2006

Aug. 27, 2006

Hi, I've recently tried to play Heroes of Might and Magic IV under Wine, which has very poor performance and this message it printed out many, many times after the game is started: fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy After doing some digging it appears the problem is the current DIB engine or lack thereof (the DIBEngine page on the Wine wiki and the bugzilla bug it links to are very useful). From what I can tell this has been a known shortcoming in Wine for at least 4.5 - 5 years, with a few partial patches created three or four years ago. Is (or has) there any recent (less than a year old) work being done on creating a more efficient DIB engine for Wine? If not, has anyone looked into using a library like EVAS or Cairo as a foundation for implementing it? Before anyone asks, yes I'm a newbie in terms of hacking on Wine or working with device independent bitmaps under Windows, and yes I am volunteering to help work on an improved DIB engine. :) Thanks, Brian P.S. I've run other games such as Diablo II and Total Annihilation (including more recently being able to use TA: Mutation) under Wine and they work beautifully. Keep up the good work! Jen: Wings? I don't have wings! Kira: Of course not. You're a boy. - from "The Dark Crystal" __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

9 10

Re: [DDRAW] Only detach surfaces when releasing a non-texture surface attached to a complex root.
by Stefan Dösinger Aug. 27, 2006

Aug. 27, 2006

Am Sonntag 27 August 2006 17:23 schrieb Elie Morisse: > Refcounting fix, Wine devs tell me if I'm wrong as from now on I get > something like this w/ The Nomad Soul : > > fixme:d3d:IWineD3DDeviceImpl_Release (0x1248028) Device released with > resources still bound, acceptable but unexpected fixme:d3d:dumpResources > Leftover resource 0x217f988 with type 1,WINED3DRTYPE_SURFACE > fixme:d3d:dumpResources Leftover resource 0x1abca8 with type > 1,WINED3DRTYPE_SURFACE > > Other games I tried aren't affected though, so this one may just be buggy.. > Good part is this prevents memory faults in The Nomad Soul at exit and when > switching resolution. Not so sure about this yet, the patch seems to contain a lot of indention changes, it is a bit hard to read. Can you check this with the moto racer 2 demo? It is a bit nasty in terms of refcounting

1 0

Test showing GetShortPathNameW problem preventing msi from installing .NET 1.1
by Robert Reif Aug. 27, 2006

Aug. 27, 2006

This test shows the problem that msi is having installing .Net 1.1. Could someone familiar with this code have a look at it please? diff -p -u -r1.36 path.c --- dlls/kernel/tests/path.c 14 Jun 2006 11:54:23 -0000 1.36 +++ dlls/kernel/tests/path.c 26 Aug 2006 15:53:13 -0000 @@ -929,6 +929,16 @@ static void test_GetTempPath(void) SetEnvironmentVariableA("TMP", save_TMP); } +static void test_GetShortPathNameW(void) +{ + WCHAR nameW[] = { 'c',':','\\','w','i','n','d','o','w','s','\\','M','i','c','r','o','s','o','f','t','.','N','E','T','\\','F','r','a','m','e','w','o','r','k','\\','v','1','.','1','.','4','3','2','2','\\','1','0','3','3','\\','v','b','c','7','u','i','.','d','l','l',0 }; + DWORD size; + + size = GetShortPathNameW( nameW, NULL, 0 ); + + ok(size > 0, "GetShortPathNameW() failed\n"); +} + START_TEST(path) { CHAR origdir[MAX_PATH],curdir[MAX_PATH], curDrive, otherDrive; @@ -939,4 +949,5 @@ START_TEST(path) test_PathNameA(curdir, curDrive, otherDrive); test_CleanupPathA(origdir,curdir); test_GetTempPath(); + test_GetShortPathNameW(); }

3 3

Re: WineD3D: Sample from the correct source when using older pixel shaders
by Ivan Gyurdiev Aug. 27, 2006

Aug. 27, 2006

Stefan Dösinger wrote: > Pre 2.0 pixel shaders do not contain a tag for the texture type to sample > from. Wine had 2D textures hardcoded, this patch checks the bound texture > type to decide from which texture to sample from. For >= 2.0 shaders the > shader tag is still used. > Why can't this be done in a much cleaner way where the sampler is initialized (2nd pass, baseshader, get_registers_used)? Then you don't have to copy and paste the same thing in many places - there's 10 texture instructions or something like that for pixel shaders alone. Also, maybe the stateblock should be passed as an argument to all functions that use its states. I don't like walking up the tree to find what you need (this->wineD3Ddevice) - it's a hidden dependency on device state, which isn't even all the time - that's why you had to move the point where the shader is compiled [ this needs better documentation ]. Similarly, I think the code would be cleaner if projected sampling vs regular was retrieved from the stateblock, and stored somewhere else, at the point when the sampler is initialized.

3 5