Re: wine 0.9.9 vs. Ned For Speed V -- already better
On 3/5/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Am Sonntag, 5. März 2006 20:36 schrieb Samium Gromoff: > > manages to allow NFS to initialize the video mode, apparently. > You can try my directdraw patches: http://stud4.tuwien.ac.at/~e0526822/ > But wait before downloading, I have some updates I'll upload within the next > hours. > > Is a demo of that game available? Need for Speed V is: Porsche Unleashed The Demo: nfspudemo.zip : http://ftp.gameaholic.com/pub/demos/?N=D http://miningco.gameaholic.com/idgames.d/gamedemos/?offset=14 http://www.sports-gaming.com/downloads/demos/nfspudemo.shtml http://www.gamepro.com/computer/pc/1713/info.shtml http://www.fileshack.com/file.x?fid=701 http://www.gamershell.com/download_4366.shtml http://files.gameaholic.com/idgames.d/gamedemos/ http://www.ausgamers.com/files/demos.php http://www.3dgamers.com/ Tom > > Stefan > > > > > > >
Re: Feedback request on wininet patch
Victor Pelt wrote:
-FIXME("Option INTERNET_OPTION_RECEIVE_TIMEOUT: STUB\n");
+ {
It would be nice if you could use indentation consistent with the rest
of the file, and avoid tabs.
+ unsigned long conns=*(unsigned long*)lpBuffer;
What's 'conns' for?
+ /* have HINTERNET hInternet , handle where to set the options */
+ int result = setsockopt(INET_getSocketHelper(lpwhh),
INET_getProtocolHelper(lpwhh), SO_RCVTIMEO, lpBuffer, (int)sizeof(lpBuffer));
+
+ if (result == 0) {
+ ret = TRUE;
+} else {
+ /* Translate the result in the right error to return */
+ ret = FALSE;
+}
+ }
How about "ret = (result == 0);"?
@@ -2455,6 +2504,9 @@ BOOL WINAPI InternetSetOptionW(HINTERNET
case INTERNET_OPTION_CONNECT_RETRIES:
FIXME("Option INTERNET_OPTION_CONNECT_RETRIES: STUB\n");
break;
+case INTERNET_OPTION_CONTEXT_VALUE:
+ FIXME("Option INTERNET_OPTION_CONTEXT_VALUE; STUB\n");
+ break;
default:
FIXME("Option %ld STUB\n",dwOption);
INTERNET_SetLastError(ERROR_INVALID_PARAMETER);
This chunk should be in a separate patch, since it's unrelated.
+/* Helper functions to get unix backend stuff based in windows handles
(LPWININETHANDLEHEADER s) */
+int INET_getSocketHelper(LPWININETHANDLEHEADER);
+int INET_getProtocolHelper(LPWININETHANDLEHEADER);
Why not just make these static, and get rid of these declarations?
Mike
Re: [Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI
Uwe Bonnes wrote: "H" == H Verbeet <[EMAIL PROTECTED]> writes: ... >> Appended patch lets me circumvent that problem. H> I'm not sure if GL_STENCIL_BACK_FAIL and GL_STENCIL_BACK_FAIL_ATI are H> interchangeable, but more importantly it makes the same kind of H> assumptions about what's going to be defined. I said "circumvent" not "solve"... This patch http://www.winehq.org/pipermail/wine-patches/2006-March/024775.html should solve the problem with missing defines.
Re: DirectDraw -> WineD3D patch
Hi, I've updated the patch to fix a few issues and take the merged header patches into account. It can still be found at http://stud4.tuwien.ac.at/~e0526822/ Thanks for all your feedback so far, Stefan pgpLnwKMXVJjH.pgp Description: PGP signature
Re: [PATCH] [WineDbg test harness]: various updates
Eric Pouech wrote: - now supports all tests with or without 'in ' information - extended startup tests please, discard this patch A+ -- Eric Pouech
about Wingdings/Symbol
I wish to make a initial font file for Wingdings and Symbol fonts. Do anyone some font designing already? I plan to draw some common usable symbols for first. -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!
Re: configure: add --with-fontfir (try3) with patch!
On Monday 06 March 2006 00:43, Alexandre Julliard wrote: > Vitaly Lipatov <[EMAIL PROTECTED]> writes: > > On Sunday 05 March 2006 23:22, Alexandre Julliard wrote: > >> Could you please explain what you are trying to do? I > >> don't think we want to hardcode more paths, I've just been > >> getting rid of them. > > > > I told about > > fontdir = $(datadir)/fonts/wine > > line in fonts/Makefile.in. It is _hardcoded_ path. I try to > > get rid of this and get possibility to set path to fontdir > > with configure options. > > It's not less hardcoded if it's in configure... You still I planned place _default_ path to configure. With --with-fontdir option we can set it to any other place. If we have this path hardcoded in fonts/Makefile.in we can't use it from other places of WINE tree. > haven't explained what you are trying to do, and why you can't > put fonts in datadir. I don't like WINE fonts in %_datadir/fonts/wine, I it crossed with ALT Linux font policy and so on. I have a small patch to check the font dir after C: \\WINDOWS\\FONTS for bitmap/ttf fonts. It patch needs in @FONTDIR@ substitution in Makefile. Sorry if I can't express my thoughts in English clearly. -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!
Re: configure: add --with-fontfir (try3) with patch!
Vitaly Lipatov <[EMAIL PROTECTED]> writes: > On Sunday 05 March 2006 23:22, Alexandre Julliard wrote: >> Could you please explain what you are trying to do? I don't >> think we want to hardcode more paths, I've just been getting >> rid of them. > I told about > fontdir = $(datadir)/fonts/wine > line in fonts/Makefile.in. It is _hardcoded_ path. I try to get > rid of this and get possibility to set path to fontdir with > configure options. It's not less hardcoded if it's in configure... You still haven't explained what you are trying to do, and why you can't put fonts in datadir. -- Alexandre Julliard [EMAIL PROTECTED]
Re: World of Warcraft 0.10 Public Test Realm (PTR)
Tomas Carnecky wrote:
> so.. I know where the problem is.. WoW loads its own Survey.dll which
> requires ddraw.dll, ddraw initializes itself and during that it creates
> a drawable and a context and calls glXMakeCurrent(). After some tests
> WoW unloads ddraw.dll but someone (ddraw, wine or WoW) fails to activate
> the old drawable and context, eg. call glXMakeCurrent() with the real
> window and rendering context.
>
> a trace with +x11drv,+x11settings,+ddraw,+loaddll is in the attachment..
>
> in a full trace with +opengl,+ddraw,+loaddll I can see that there is no
> wglMakeCurrent call after the ddraw dll is unloaded
>
for those who can't wait to login into the PTR, here is a little patch
that disables opengl support in ddraw, so ddraw won't call
glXMakeCurrent(). It's a really ugly solution, but at least now we can
try to login into the PTR.
The better solution would be to save the old drawable and context and
reactivate it after ddraw initilizes opengl. Or whatever the ddraw
author comes up with :-)
tom
diff --git a/dlls/ddraw/main.c b/dlls/ddraw/main.c
index d9abebe..8212c38 100644
--- a/dlls/ddraw/main.c
+++ b/dlls/ddraw/main.c
@@ -91,6 +91,8 @@ static BOOL DDRAW_bind_to_opengl( void )
{
const char *glname = SONAME_LIBGL;
+return FALSE;
+
gl_handle = wine_dlopen(glname, RTLD_NOW, NULL, 0);
if (!gl_handle) {
WARN("Wine cannot find the OpenGL graphics library (%s).\n",glname);
Re: [Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI
On 05/03/06, Uwe Bonnes <[EMAIL PROTECTED]> wrote: > I said "circumvent" not "solve"... Fair enough, but just removing the lines would probably work as well. :-)
Re: Question about copyright lines
On Saturday 04 March 2006 12:32, Segin wrote: > >For protection in countries which are signatories to the UCC but NOT > >the Berne Convention (I don't know of any offhand), the year and name ... > Ok, but you still need to put the copyright year/holder's name in a > certain order, as your last paragraph said. Just not nessessrary for > most countries. Since accession to the Berne Convention is a requirement for membership of the WTO, parties (not signatories, which is a different thing with little practical meaning) to the UCC who are not parties to the Berne Convention are such a small set now that it is probably not worth worrying about. These days the copyright notice has more value as: a means of giving credit; a means of letting others know who they need to ask if they wish to do something outside the license; and a method to assist distant future users of materials in identifying when a work enters the public domain. -- Troy Rollo - [EMAIL PROTECTED]
Re: World of Warcraft 0.10 Public Test Realm (PTR)
so.. I know where the problem is.. WoW loads its own Survey.dll which requires ddraw.dll, ddraw initializes itself and during that it creates a drawable and a context and calls glXMakeCurrent(). After some tests WoW unloads ddraw.dll but someone (ddraw, wine or WoW) fails to activate the old drawable and context, eg. call glXMakeCurrent() with the real window and rendering context. a trace with +x11drv,+x11settings,+ddraw,+loaddll is in the attachment.. in a full trace with +opengl,+ddraw,+loaddll I can see that there is no wglMakeCurrent call after the ddraw dll is unloaded tom trace:loaddll:load_builtin_dll Loaded module L"kernel32.dll" : builtin trace:loaddll:load_native_dll Loaded module L"Z:\\games\\World.of.Warcraft\\WoWTest\\WoW.exe" : native trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\msvcrt.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\advapi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\gdi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\user32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\comctl32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\iphlpapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\rpcrt4.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ole32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\shlwapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\shell32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ws2_32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\wsock32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\opengl32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\imm32.dll" : builtin trace:loaddll:load_native_dll Loaded module L"Z:\\games\\World.of.Warcraft\\WoWTest\\DivxDecoder.dll" : native trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winmm.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\msacm32.dll" : builtin trace:loaddll:load_native_dll Loaded module L"Z:\\games\\World.of.Warcraft\\WoWTest\\fmod.dll" : native trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\mpr.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\wininet.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winex11.drv" : builtin trace:x11settings:X11DRV_Settings_SetHandlers Resolution settings now handled by: NoRes trace:x11settings:X11DRV_Settings_SetHandlers Initialized new display modes array trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 0: 1280x1024x32 @0 Hz (NoRes) trace:x11drv:X11DRV_XF86DGA2_Init trace:x11drv:X11DRV_SetupXIM X display of IM = 0x7c0630e0 trace:x11drv:X11DRV_SetupXIM Using C locale of Input Method trace:x11drv:X11DRV_SetupXIM ximStyles->count_styles = 2 trace:x11drv:X11DRV_SetupXIM ximStyles[0] = XIMPreeditNone trace:x11drv:X11DRV_SetupXIM ximStyles[1] = XIMPreeditNothing trace:x11drv:X11DRV_SetupXIM Setting Style: ximStyleRoot = STYLE_ROOT trace:x11drv:X11DRV_SetupXIM No callback style avalable trace:x11drv:X11DRV_CreateBitmap (0x1a4) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1a8) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a8, buffer=0x7fd2b944, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a4, buffer=0x7fd2b9c4, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x1ac) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1b0) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1b0, buffer=0x7fd2bc14, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1ac, buffer=0x7fd2bc94, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x1c0) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1c4) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c4, buffer=0x7fd2c344, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c0, buffer=0x7fd2c364, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x1c8) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1cc) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1cc, buffer=0x7fd2c68c, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c8, buffer=0x7fd2c6ac, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x1d0) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1d4) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d4, buffer=0x7fd2c9d4, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d0, buffer=0x7fd2c9f4, count=0x300) trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\uxtheme.dll" : builtin trace:x11drv:X11DRV_CreateBitmap (0x210) 512x16 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x248) 1024x32 1 bpp trace:x1
Re: [Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI
> "H" == H Verbeet <[EMAIL PROTECTED]> writes: ... >> Appended patch lets me circumvent that problem. H> I'm not sure if GL_STENCIL_BACK_FAIL and GL_STENCIL_BACK_FAIL_ATI are H> interchangeable, but more importantly it makes the same kind of H> assumptions about what's going to be defined. I said "circumvent" not "solve"... -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented
Am Sonntag, 5. März 2006 19:15 schrieb Michael Jung: > On Sunday 05 March 2006 18:27, Rainer Dorsch wrote: > > Do you have any free easy to install app in mind which might show the > > same issue? > > Unfortunately, no. All the apps I've tested with seem to work fine. It > might be a problem with the unix filesystem shell namespace extension. > Could you try to browse the old drive letter based shell namespace (under > 'My Computer' or 'Arbeitsplatz' on a german system) and figure if the > problem persists there, too? Not sure if I understood that correctly. I do everything within the notes file select box: I went to 'Arbeitsplatz' in the Shell and then 'C'. MyDocuments was shown as a file, not a folder. I.e. the problem persists. Thanks, Rainer -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 Icq: 32550367
Re: configure: add --with-fontfir (try3) with patch!
On Sunday 05 March 2006 23:22, Alexandre Julliard wrote: > Could you please explain what you are trying to do? I don't > think we want to hardcode more paths, I've just been getting > rid of them. I told about fontdir = $(datadir)/fonts/wine line in fonts/Makefile.in. It is _hardcoded_ path. I try to get rid of this and get possibility to set path to fontdir with configure options. -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!
Re: configure: add --with-fontfir (try3) with patch!
Vitaly Lipatov <[EMAIL PROTECTED]> writes: >> Can't you achieve the same thing with the standard configure >> options? What are you trying to do with the fonts? > I wish remove direct path to font dir from fonts/Makefile.am and > make in configurable via configure option. > I can't place fonts in datadir/wine/fonts now. > > P.S. > I have plans to use @FONTDIR@ in other Makefiles. Could you please explain what you are trying to do? I don't think we want to hardcode more paths, I've just been getting rid of them. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine 0.9.9 vs. Ned For Speed V -- already better
Am Sonntag, 5. März 2006 20:36 schrieb Samium Gromoff: > manages to allow NFS to initialize the video mode, apparently. You can try my directdraw patches: http://stud4.tuwien.ac.at/~e0526822/ But wait before downloading, I have some updates I'll upload within the next hours. Is a demo of that game available? Stefan pgpXh2l2WZMUU.pgp Description: PGP signature
Re: World of Warcraft 0.10 Public Test Realm (PTR)
Tomas Carnecky wrote: > At a certain point the screen just turns black, it's always at the same > point, and when looking through the +x11drv trace I can see these > messages at that point: > > trace:x11drv:X11DRV_DCICommand (20,(12,2079885668,543712117),(nil)) > trace:x11drv:X11DRV_DCICommand (20,(13,1792,543712117),0x7bf88d40) > trace:x11drv:X11DRV_DCICommand (20,(11,1792,543712117),0x7bf88d60) > trace:x11drv:X11DRV_DCICommand (20,(10,1792,543712117),0x7bf88ea8) > > also, these messages don't appear in version 1.9.4 (which is the 'live' > version). So I suspect that Blizzard added something related to this > function to the 0.10 version which breaks something. > > When the screen turns black, its just the screen, everything else works, > keyboard for sure, I can press 'Esc' to get out of the game, not sure > about the mouse though.. > It seems that Blizzard added DDraw HAL.. right after these CDICommand calls I see: trace:x11settings:X11DRV_Settings_CreateDriver Setting up display settings for DDRAW (NoRes) trace:x11drv:X11DRV_DDHAL_SwitchMode (0,(nil),(nil)) which changes the display setting, but I disabled xvidmode and xrandr so this really shouldn't do anything. also, it seems like WoW draws to a completely different buffer after that because I see two different pictures changing, like the application would call SwapBuffers() on two buffer that are not updated.. like WoW would set up a new drawable but not switch to it.. tom
wine 0.9.9 vs. Ned For Speed V -- already better
Here goes the log for running NFS5: PU, in win 0.9.9, the first version which manages to allow NFS to initialize the video mode, apparently. The wine debug output is attached. fixme:ras:RasEnumConnectionsA (0x7cb11980,0x7fbef9e0,0x7fbef9e4),stub! fixme:ras:RasEnumConnectionsA RAS support is not implemented! Configure program to use LAN connection/winsock instead! fixme:ddraw:DirectDrawEnumerateExA no non-display devices supported. fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fd7b268)->(0x20024,0408) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdaa9a8)->(0x20024,0419) err:ddraw:choose_mode requested color depth (24) not available, try reconfiguring X server fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 16 err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LINEPATTERN (000a) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_MONOENABLE (000b) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ROP2 (000c) value : 000d ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_PLANEMASK (000d) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LASTPIXEL (0010) value : 0001 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ZVISIBLE (001e) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EDGEANTIALIAS (0028) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_RANGEFOGENABLE (0030) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EXTENTS (008a) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_VERTEXBLEND (0097) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LINEPATTERN (000a) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_MONOENABLE (000b) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ROP2 (000c) value : 000d ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_PLANEMASK (000d) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LASTPIXEL (0010) value : 0001 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ZVISIBLE (001e) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EDGEANTIALIAS (0028) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_RANGEFOGENABLE (0030) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EXTENTS (008a) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_VERTEXBLEND (0097) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EXTENTS (008a) value : ! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:GL_IDirect3DDeviceImpl_7_3T_SetTextureStageState Unhandled stage type is : D3DTSS_COLOROP => D3DTOP_SUBTRACT fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:GL_IDirect3DDeviceImpl_7_3T_SetTextureStageState Unhandled stage type is : D3DTSS_COLOROP => D3DTOP_SUBTRACT fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_ValidateDevice (0x7fdabba0/0x7fdabba0)->(0x7baae7d4): semi-stub! fixme:ddraw:Main_IDirect3DDeviceImpl_7_3T_Val
Re: WRT: winetest-latest is outdated
Hi Detlef, On Friday 03 Mar 2006 22:49, Detlef Riekenberg wrote: > Hi. > > The latest Winetest-Binaries are outdated > ( http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/?N=D ). Yup. I'm trying to migrate from the old computer (an old RH-7.3 box much like Frankenstein's monster) to a more manageable machine (running Debian etch). Cross-building isn't working on the new machine yet and is currently broken on the old one. > Winetest (ELF) compiled again recently > ( http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php ), > but the crossbuilds are still missing. That's true: the two builds are independent. The wine tests had a different problem, for which I've a work-around now. > Is there anything that we can do for help? Yes. The autoconf-generated script seems to be getting confused when cross-compiling. When cross-compiling, I do something similar to the following: 1. get the source-code and move to directory wine-cross-source 2. In directory wine-cross-elf, do: ../wine-cross-source/configure && make depend && make tools 3. In directory wine-cross-pe, do: ../wine-cross-source/configure --host=i686-mingw32msvc \ --with-wine-tools=../wine-cross-elf After that, it does a "make depend" and a bunch of other stuff to get winetest.exe, the DLLs and other EXEs. Step 3 is failing. It looks as if the configure script becomes confused between cross-building and native environments, in particular with OpenGL libraries. Although the code is cross-compiling, it seems to pick up the native GL libraries and header files. Then, when the cross-compiler fails (to link some glx symbol, iirc), the configure script dies. When it fails, the configure script gives a hint that the file /usr/X11R6/lib/libGL.a should be removed. Doing this certainly fixes the cross-compilation and the ELF compilation still works as it links against the .so version. However, removing the xlibmesa-gl-dev package isn't feasible as its need by many other -dev packages and would break OpenGL compilation. This looks like a bug in configure.ac, as why should a native static library break cross-compilation. Any clues? Cheers, Paul. config.log is available from: http://www.astro.gla.ac.uk/users/paulm/config.log The last few lines from running configure are: ... checking for GL/gl.h... yes checking for GL/glx.h... yes checking for GL/glext.h... yes checking for up-to-date OpenGL version... yes checking for glXCreateContext in -lGL... no configure: error: /usr/X11R6/lib/libGL.a is present on your system. This prevents linking to OpenGL. Delete the file and restart configure. pgp5W5OUbkKT7.pgp Description: PGP signature
Feedback request on wininet patch
Hey
I implemented one of the missing options in InternetSetOption. Any
feedback about the way i implemented it would be appreciated. If it is
alright i will implement the other missing options too
regards
Victor Pelt
diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c
index f52103d..d1ec52a 100644
--- a/dlls/wininet/internet.c
+++ b/dlls/wininet/internet.c
@@ -2361,6 +2361,44 @@ BOOL WINAPI InternetQueryOptionA(HINTERN
return INET_QueryOptionHelper(FALSE, hInternet, dwOption, lpBuffer, lpdwBufferLength);
}
+/* Helper function to get the unix socket from a LPWININETHEADER */
+int INET_getSocketHelper(LPWININETHANDLEHEADER lpwhh) {
+ int nSocket = -1;
+
+ switch (lpwhh->htype) {
+ case WH_HFILE:
+nSocket = ((LPWININETFILE)lpwhh)->nDataSocket;
+break;
+ case WH_HHTTPSESSION:
+ case WH_HHTTPREQ:
+nSocket = (&((LPWININETHTTPREQW)lpwhh)->netConnection)->socketFD;
+break;
+ default:
+ERR("Handle type isn't supported(%u)\n",lpwhh->htype);
+break;
+ }
+
+ return nSocket;
+}
+
+/* Helper function to get the unix proticolflag from a LPWININETHEADER */
+int INET_getProtocolHelper(LPWININETHANDLEHEADER lpwhh){
+ int protocol = SOL_SOCKET;
+
+ switch (lpwhh->htype){
+ case WH_HHTTPSESSION:
+ case WH_HFILE:
+ case WH_HHTTPREQ:
+/* FIXME hardcode tcp protocol, maybe we should do something smarter here */
+protocol = 6;
+break;
+ default:
+ERR("Handle type isn't supported(%u)\n",lpwhh->htype);
+break;
+ }
+ return protocol;
+}
+
/***
* InternetSetOptionW (WININET.@)
@@ -2447,7 +2485,18 @@ BOOL WINAPI InternetSetOptionW(HINTERNET
TRACE("Option INTERNET_OPTION_DISABLE_PASSPORT_AUTH: harmless stub, since not enabled\n");
break;
case INTERNET_OPTION_RECEIVE_TIMEOUT:
-FIXME("Option INTERNET_OPTION_RECEIVE_TIMEOUT: STUB\n");
+ {
+ unsigned long conns=*(unsigned long*)lpBuffer;
+ /* have HINTERNET hInternet , handle where to set the options */
+ int result = setsockopt(INET_getSocketHelper(lpwhh), INET_getProtocolHelper(lpwhh), SO_RCVTIMEO, lpBuffer, (int)sizeof(lpBuffer));
+
+ if (result == 0) {
+ ret = TRUE;
+} else {
+ /* Translate the result in the right error to return */
+ ret = FALSE;
+}
+ }
break;
case INTERNET_OPTION_SEND_TIMEOUT:
FIXME("Option INTERNET_OPTION_SEND_TIMEOUT: STUB\n");
@@ -2455,6 +2504,9 @@ BOOL WINAPI InternetSetOptionW(HINTERNET
case INTERNET_OPTION_CONNECT_RETRIES:
FIXME("Option INTERNET_OPTION_CONNECT_RETRIES: STUB\n");
break;
+case INTERNET_OPTION_CONTEXT_VALUE:
+ FIXME("Option INTERNET_OPTION_CONTEXT_VALUE; STUB\n");
+ break;
default:
FIXME("Option %ld STUB\n",dwOption);
INTERNET_SetLastError(ERROR_INVALID_PARAMETER);
diff --git a/dlls/wininet/internet.h b/dlls/wininet/internet.h
index 6df7e31..37cac89 100644
--- a/dlls/wininet/internet.h
+++ b/dlls/wininet/internet.h
@@ -494,4 +494,9 @@ typedef struct
const char* name;
} wininet_flag_info;
+/* Helper functions to get unix backend stuff based in windows handles (LPWININETHANDLEHEADER s) */
+int INET_getSocketHelper(LPWININETHANDLEHEADER);
+int INET_getProtocolHelper(LPWININETHANDLEHEADER);
+
#endif /* _WINE_INTERNET_H_ */
+
Re: configure: add --with-fontfir (try3) with patch!
On Sunday 05 March 2006 20:43, Alexandre Julliard wrote: > Vitaly Lipatov <[EMAIL PROTECTED]> writes: > > On Tuesday 21 February 2006 20:10, Vitaly Lipatov wrote: > >> I made some fixes to correct work. > >> > >> Changelog > >> add --with-fontdir parameter to configure for set WINE > >> fonts placement. ... > Can't you achieve the same thing with the standard configure > options? What are you trying to do with the fonts? I wish remove direct path to font dir from fonts/Makefile.am and make in configurable via configure option. I can't place fonts in datadir/wine/fonts now. P.S. I have plans to use @FONTDIR@ in other Makefiles. -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!
Re: fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented
On Sunday 05 March 2006 18:27, Rainer Dorsch wrote: > Do you have any free easy to install app in mind which might show the same > issue? Unfortunately, no. All the apps I've tested with seem to work fine. It might be a problem with the unix filesystem shell namespace extension. Could you try to browse the old drive letter based shell namespace (under 'My Computer' or 'Arbeitsplatz' on a german system) and figure if the problem persists there, too? Bye, -- Michael Jung [EMAIL PROTECTED]
Re: configure: add --with-fontfir (try3) with patch!
Vitaly Lipatov <[EMAIL PROTECTED]> writes: > On Tuesday 21 February 2006 20:10, Vitaly Lipatov wrote: >> I made some fixes to correct work. >> >> Changelog >> add --with-fontdir parameter to configure for set WINE fonts >> placement. > Sorry, what is broken with my patch? > http://www.winehq.org/pipermail/wine-patches/2006-February/024535.html Can't you achieve the same thing with the standard configure options? What are you trying to do with the fonts? -- Alexandre Julliard [EMAIL PROTECTED]
Re: fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented
Hello Michael, thanks for the prompt reply. I have one other (also commercial) program (a map viewer which came with a map CDROM) running on wine but it shows a completely different file select box. I could recompile wine if you have a patch which generates more debug output and send the debug output (though I am the next 3 days away from my computer). These are the two specific setting which I do for wine: - I need to set win98 (winecfg) to get the file select box working at all - I need to set WINEDLLOVERRIDES="usp10=n" Do you have any free easy to install app in mind which might show the same issue? Thanks, Rainer Am Sonntag, 5. März 2006 18:14 schrieben Sie: > Hello Rainer, > > On Sunday 05 March 2006 17:48, Rainer Dorsch wrote: > > wine-0.9.9 still does not display folders correctly in a file select box > > (Lotus Notes in this case). Folders and files are displayed with the file > > symbol. It seems to be only a display issue, clicking on folders still > > opens them. > > I would like to take a look at this, but I don't have a Notes license. Do > you observe this behaviour with any other program available for free or > with a demo version availabe? > > Bye, -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 Icq: 32550367
Re: fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented
Hello Rainer, On Sunday 05 March 2006 17:48, Rainer Dorsch wrote: > wine-0.9.9 still does not display folders correctly in a file select box > (Lotus Notes in this case). Folders and files are displayed with the file > symbol. It seems to be only a display issue, clicking on folders still > opens them. I would like to take a look at this, but I don't have a Notes license. Do you observe this behaviour with any other program available for free or with a demo version availabe? Bye, -- Michael Jung [EMAIL PROTECTED]
Re: configure: add --with-fontfir (try3) with patch!
On Tuesday 21 February 2006 20:10, Vitaly Lipatov wrote: > I made some fixes to correct work. > > Changelog > add --with-fontdir parameter to configure for set WINE fonts > placement. Sorry, what is broken with my patch? http://www.winehq.org/pipermail/wine-patches/2006-February/024535.html -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!
Re: KERNEL32: Improve descriptions
On Sun, Mar 05, 2006 at 07:39:04PM +0300, Vitaly Lipatov wrote: > On Sunday 05 March 2006 14:13, Alexandre Julliard wrote: > > Vitaly Lipatov <[EMAIL PROTECTED]> writes: > > > -UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, > > > UINT unique, LPWSTR buffer ) +UINT WINAPI GetTempFileNameW( > > > LPCWSTR lpPathName, LPCWSTR lpPrefixString, UINT uUnique, > > > LPWSTR lpTempFileName ) > > > > *Please* don't change nice readable parameter names into the > > horrible Hungarian line noise format. > Sorry, I thought we need to fix parameter names according to > MSDN :( > Have we some policy about it? Will I change Hungarian notation to > readable names when possible? Just don't change the name. The *types* should be the same as MSDN, the *names* do not need to. Ciao, Marcus
fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented
Hello, wine-0.9.9 still does not display folders correctly in a file select box (Lotus Notes in this case). Folders and files are displayed with the file symbol. It seems to be only a display issue, clicking on folders still opens them. A screenshot is here http://www.winehq.org/pipermail/wine-devel/attachments/20060223/9f1675d7/fileselect.png shows an example for rd at silverboxy:~/test$ ls -l insgesamt 4 drwxr-xr-x 2 rd rd 4096 2006-02-23 17:08 dir -rw-r--r-- 1 rd rd0 2006-02-23 17:08 file rd at silverboxy:~/test$ The console shows this log fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30190, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:commdlg:GetFileName95 Flags 0x0090 not yet implemented fixme:imm:ImmReleaseContext (0x30190, 0x4997af70): stub fixme:process:GetProcessWorkingSetSize (0x,0x4075d768,0x4075d76c): stub fixme:process:SetProcessWorkingSetSize (0x,33554432,33554432): stub - harmless when opening a file select box. Causes this one fixme:commdlg:GetFileName95 Flags 0x0090 not yet implemented this wine glitch? Thanks, Rainer -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 Icq: 32550367
Re: KERNEL32: Improve descriptions
On Sunday 05 March 2006 14:13, Alexandre Julliard wrote: > Vitaly Lipatov <[EMAIL PROTECTED]> writes: > > -UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, > > UINT unique, LPWSTR buffer ) +UINT WINAPI GetTempFileNameW( > > LPCWSTR lpPathName, LPCWSTR lpPrefixString, UINT uUnique, > > LPWSTR lpTempFileName ) > > *Please* don't change nice readable parameter names into the > horrible Hungarian line noise format. Sorry, I thought we need to fix parameter names according to MSDN :( Have we some policy about it? Will I change Hungarian notation to readable names when possible? -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!
Re: [Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI
On 05/03/06, Uwe Bonnes <[EMAIL PROTECTED]> wrote: > Hallo, > > compiling a recent CVS checkout, I go a failure with GL_STENCIL_BACK_FAIL > etc undefined. Same problem for me. http://www.winehq.org/pipermail/wine-devel/2006-March/045297.html > It seems that a patch from Vitaly regarding wined3d_gl.h from > yesterday evening as notor only partial applied. Well, no, the patch is just like that. It assumes GL_STENCIL_BACK_FAIL, GL_STENCIL_BACK_PASS_DEPTH_FAIL and GL_STENCIL_BACK_PASS_DEPTH_PASS are defined, which is not guaranteed. > Appended patch lets me circumvent that problem. I'm not sure if GL_STENCIL_BACK_FAIL and GL_STENCIL_BACK_FAIL_ATI are interchangeable, but more importantly it makes the same kind of assumptions about what's going to be defined.
GL_STENCIL-related build failures in dlls/wined3d/device.c
The recent changes to dlls/wined3d/device.c cause the following build
failures for me on FreeBSD 5.4, though I assume this is in fact not
related to FreeBSD but to xorg 6.8.2 or libglut 6.4.1 on this system.
device.c: In function `IWineD3DDeviceImpl_SetRenderState':
device.c:3776: error: `GL_STENCIL_BACK_FAIL' undeclared (first use in this
function)
device.c:3776: error: (Each undeclared identifier is reported only once
device.c:3776: error: for each function it appears in.)
device.c:3777: error: `GL_STENCIL_BACK_PASS_DEPTH_FAIL' undeclared (first use
in this function)
device.c:3778: error: `GL_STENCIL_BACK_PASS_DEPTH_PASS' undeclared (first use
in this function)
gmake[2]: *** [device.o] Error 1
gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/wined3d'
gmake[1]: *** [wined3d] Error 2
The most straightforward patch would be the one below, but it leaves
three "variable may be used uninitialized" warnings in the first of the
two affected spots.
Gerald
Index: device.c
===
RCS file: /home/wine/wine/dlls/wined3d/device.c,v
retrieving revision 1.145
diff -u -3 -p -r1.145 device.c
--- device.c4 Mar 2006 17:10:57 - 1.145
+++ device.c5 Mar 2006 08:35:52 -
@@ -3226,9 +3226,15 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetRen
GLint action = StencilOp(Value);
+#ifdef GL_STENCIL_FAIL
glGetIntegerv(GL_STENCIL_FAIL, &stencilFail);
+#endif
+#ifdef GL_STENCIL_PASS_DEPTH_FAIL
glGetIntegerv(GL_STENCIL_PASS_DEPTH_FAIL, &depthFail);
+#endif
+#ifdef GL_STENCIL_PASS_DEPTH_PASS
glGetIntegerv(GL_STENCIL_PASS_DEPTH_PASS, &stencilPass);
+#endif
if(WINED3DRS_STENCILFAIL == State) {
stencilFail = action;
@@ -3773,9 +3779,15 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetRen
GLint action = StencilOp(Value);
+#ifdef GL_STENCIL_BACK_FAIL
glGetIntegerv(GL_STENCIL_BACK_FAIL, &stencilFail);
+#endif
+#ifdef GL_STENCIL_BACK_PASS_DEPTH_FAIL
glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL, &depthFail);
+#endif
+#ifdef GL_STENCIL_BACK_PASS_DEPTH_PASS
glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS, &stencilPass);
+#endif
if(WINED3DRS_CCW_STENCILFAIL == State) {
stencilFail = action;
Re: DirectDraw -> WineD3D patch
> That's indeed the reason. Simple fix is to set the rendertarget usage also > for ddraw offscreen surfaces.Not sure if there are any possible sideeffects > of this, but until now i haven't seen any. That looks a bit more complex. I changed the way ddraw and WineD3D interact some time ago, but I didn't update the palette code for that change. I think I have to re-write the palette setting code, it's pretty crappy ATM. pgpCdkK9X4UvB.pgp Description: PGP signature
[Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI
Hallo,
compiling a recent CVS checkout, I go a failure with GL_STENCIL_BACK_FAIL
etc undefined. It seems that a patch from Vitaly regarding wined3d_gl.h from
yesterday evening as notor only partial applied.
Appended patch lets me circumvent that problem.
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Index: wine/dlls/wined3d/device.c
===
RCS file: /home/wine/wine/dlls/wined3d/device.c,v
retrieving revision 1.145
diff -u -r1.145 device.c
--- wine/dlls/wined3d/device.c 4 Mar 2006 17:10:57 - 1.145
+++ wine/dlls/wined3d/device.c 5 Mar 2006 14:47:13 -
@@ -3773,9 +3773,9 @@
GLint action = StencilOp(Value);
-glGetIntegerv(GL_STENCIL_BACK_FAIL, &stencilFail);
-glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL, &depthFail);
-glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS, &stencilPass);
+glGetIntegerv(GL_STENCIL_BACK_FAIL_ATI, &stencilFail);
+glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL_ATI, &depthFail);
+glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS_ATI, &stencilPass);
if(WINED3DRS_CCW_STENCILFAIL == State) {
stencilFail = action;
World of Warcraft 0.10 Public Test Realm (PTR)
At a certain point the screen just turns black, it's always at the same point, and when looking through the +x11drv trace I can see these messages at that point: trace:x11drv:X11DRV_DCICommand (20,(12,2079885668,543712117),(nil)) trace:x11drv:X11DRV_DCICommand (20,(13,1792,543712117),0x7bf88d40) trace:x11drv:X11DRV_DCICommand (20,(11,1792,543712117),0x7bf88d60) trace:x11drv:X11DRV_DCICommand (20,(10,1792,543712117),0x7bf88ea8) also, these messages don't appear in version 1.9.4 (which is the 'live' version). So I suspect that Blizzard added something related to this function to the 0.10 version which breaks something. When the screen turns black, its just the screen, everything else works, keyboard for sure, I can press 'Esc' to get out of the game, not sure about the mouse though.. Does anyone have an idea how to fix this? tom
Re: shell32: Unicode'ify ISFHelper interface
Hey Vitaliy, thanks for the comments. I've sent an updated version. On Saturday 04 March 2006 20:26, Vitaliy Margolen wrote: > Here > > +++ b/dlls/shell32/shfldr_fs.c > > +if (uLen < lstrlenW (wszNewFolder) + 4) > and here > > +++ b/dlls/shell32/shfldr_unixfs.c > > +if (uLen < sizeof(wszNewFolder)/sizeof(WCHAR)+3) > Why 4 in one place and 3 in the other? That's because the sizeof expression counts the terminating zero, while strlen does'nt. Bye, -- Michael Jung [EMAIL PROTECTED]
WineFile improvements
Hello! I am now preparing patch, which should add unimplemented functionality. While preparing the patch, I've got a couple of questions: 1. There is a menu item "Associations". Should I implement it as a control panel applet? Anyway, it's pretty clear, it shouldn't be an integral part of winefile, as it isn't winefile specific. 2. Should Find File be a stand-alone application? 3.What library should pack/unpack use? Should it use zip/unzip utilities or some dll? Thanks for answering any of these questions Yours Truely, Evgeny F
Re: KERNEL32: Improve descriptions
Vitaly Lipatov <[EMAIL PROTECTED]> writes: > -UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, UINT unique, > LPWSTR buffer ) > +UINT WINAPI GetTempFileNameW( LPCWSTR lpPathName, LPCWSTR lpPrefixString, > UINT uUnique, LPWSTR lpTempFileName ) *Please* don't change nice readable parameter names into the horrible Hungarian line noise format. -- Alexandre Julliard [EMAIL PROTECTED]
Re: DirectDraw -> WineD3D patch and Wine-0.9.9
Hi, > No, it isn't. AFAIK this patch modifies DirectDraw and Direct3D 7 Correct. I started sending 2 header patches, and they were merged. I'll steadily send small WineD3D patches until WineD3D is ready for the ddraw merge, then I'll provide a last patch for testing. If it works fine and AJ likes it, it can be merged. Don't know if it will be in Wine 1.0, depends on the time and how many regressions occur. There's a high number of ddraw / d3d7 apps which work, so regressions are likely. Stefan pgpHpvIMjBa3V.pgp Description: PGP signature
Re: [d3d8] regression between 0.9.8 and 0.9.9 in Age of Mythology
> Yes I noticed that the new code was always 1c4 as well, but hadn't > gone back to see what the old code was doing. But 1c4 definitely > seems wrong since the vertex coordinates are all messed up and invalid > according to MSDN. For example z is supposed to be [0,1] but I get > large values, and rhw is also supposed to be between [0,1/MaxVertexW] > but I was getting negative values. I'll look into the FVF code more. I think that those 'wrong' values appear in the cases where 0x1c4 shouldn't be used. The fvf is set by the SetFVF call which is called from d3d8's SetVertexShader. (the comment in drawprim.c saying that the fvf needs to be set in the stateblock from d3d's SetVertexShader can be ignored I think as it appears that's already done by this call) The FVF received by SetFVF is the vertex shader itself. I think something goes wrong with selecting the vertex shader but I haven't looked at this yet. Roderick -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
Re: Wine 0.9.9 and instalation of AutoCAD 2000
Vitaliy Margolen wrote: Please submit bug reports to http://bugs.winehq.org/ instead of sending e-mails here. Bug report aside, he is a developer and he wants to fix this. What he's asking is if any one remember an issue concerning: "map_image Section .rsrc"
