October 2004 - Wine-devel - list.winehq.org

msdn: d3drs_wrap[0-7] ???
by Ann and Jason Edmeades 21 Oct '04

21 Oct '04

As I understand it, there is texture states (D3DTSS_ADDRESSU/V/W) which map to the GL_WRAP_* states, and there is no direct mapping for the d3drs_* versions. I am not sure I understand the differences, but you would need to understand it before implementing it. BTW Any help on the d3d8/9 interfaces is very welcome - there's not enough people working on it (Nor the ddraw stuff either, come to that). I'm working on moving all the code from d3d8 into wined3d and calling from both d3d8/d3d9. It will probably take another month or so, but if patches could be held until it is complete I would appreciate it - I'm afraid of dropping or missing something as I go! Regards, Jason

2 1

msdn: d3drs_wrap[0-7] ???
by Devils Cry 21 Oct '04

21 Oct '04

Hi folks! Dunno why, but this list regrets my subscriptionrequests. Anyway, lets see if this gets through... Im currently working a bit on the d3d8 dll (i know there are currently heavy changes made, just creating some new interfaces) and am now focusing on the d3drs_wrap[0-7] function. I have some problems understanding what it should do, from msdn: [quote] D3DRS_WRAP0 [ie, its the same for wrap0 to 7] Texture-wrapping behavior for multiple sets of texture coordinates. Valid values for this render state can be any combination of the D3DWRAPCOORD_0 (or D3DWRAP_U), D3DWRAPCOORD_1 (or D3DWRAP_V), D3DWRAPCOORD_2 (or D3DWRAP_W), and D3DWRAPCOORD_3 flags. These cause the system to wrap in the direction of the first, second, third, and fourth dimensions, sometimes referred to as the s, t, r, and q directions, for a given texture. The default value for this render state is 0 (wrapping disabled in all directions). [/quote] My current thoughts are to enable the GL_TEXTURE_WRAP_S, T and R functions by the value passed to it (ie for 2 enable the S and T wrappers), but i guess this isnt exactly what it should do. Any thoughts, ideas, guesses? BTW, i havent found anything matching the D3DWRAPCOORD_3 flag (should be the 4th dimension). Is there something i can use for this? Thx in advance Nikolas

2 1

msdn: d3drs_wrap[0-7] ???
by Devils Cry 21 Oct '04

21 Oct '04

Hi folks! Im currently working a bit on the d3d8 dll (i know there are currently heavy changes made, just creating some new interfaces) and am now focusing on the d3drs_wrap[0-7] function. I have some problems understanding what it should do, from msdn: [quote] D3DRS_WRAP0 [ie, its the same for wrap0 to 7] Texture-wrapping behavior for multiple sets of texture coordinates. Valid values for this render state can be any combination of the D3DWRAPCOORD_0 (or D3DWRAP_U), D3DWRAPCOORD_1 (or D3DWRAP_V), D3DWRAPCOORD_2 (or D3DWRAP_W), and D3DWRAPCOORD_3 flags. These cause the system to wrap in the direction of the first, second, third, and fourth dimensions, sometimes referred to as the s, t, r, and q directions, for a given texture. The default value for this render state is 0 (wrapping disabled in all directions). [/quote] My current thoughts are to enable the GL_TEXTURE_WRAP_S, T and R functions by the value passed to it (ie for 2 enable the S and T wrappers), but i guess this isnt what it should do. Any thoughts, ideas, guesses? BTW, i havent found anything matching the D3DWRAPCOORD_3 flag (should be the 4th dimension). Is there something i can use for this? Thx in advance Nikolas

1 0

Re: shell32: shlfileop; Add resource for renaming files on collision (patch 2)
by Tobias Burnus 21 Oct '04

21 Oct '04

Hello, Rolf Kalbermatter wrote: > + IDS_COPY_X_OF_TEXT "Kopie%svon %s" > + IDS_COPY_X_OF_TEXT "Copy%sof %s" I may miss something, but I think there is are space missing around the first '%s'. Tobias

1 0

RE: Treeview +/-
by Ge van Geldorp 21 Oct '04

21 Oct '04

> From: Jon Griffiths > > Hi, > > Fixing my own FIXME. > > Cheers, > Jon > > +wine/dlls/comctl32/treeview.c > Draw +/- correctly for large icon sizes (patch applied here: http://www.winehq.org/hypermail/wine-cvs/2004/10/0115.html) I can see that this would be an improvement for large icon sizes, but I don't think it's good for small icon sizes. See attached screenshot of regedit. Maybe the height/width at which to switch to the Rectangle drawing algorithm needs a bit of tuning? Ge van Geldorp.

1 0

scroll bars not shown
by Nicolai Kuntze 21 Oct '04

21 Oct '04

Hi, in the application given in Bug 2302 are in some menus the scroll bars missing. I think the programm gets wrong dimensions from the size of the window. I do not have enough experience to track the bug by myself. Can someone please have a look on it? I have tried with the latest CVS checkout and comctrl32 as an native library. Yours, Nicolai ---- Diese Nachricht wurde auf Viren und andere gefaehrliche Inhalte sowie Spam untersucht.

1 0

Wine on OpenBSD
by Sascha Hanse 21 Oct '04

21 Oct '04

Hi people, I just tried to install the recent Wine-tarball (20041019) on my OpenBSD 3.6. First I had to remove kthread.c:275: the RFTHREAD flag. Then the 'make depend && make' worked properly but the make install first fails with: /usr/bin/install -c serialui.dll.so /usr/local/lib/wine/serialui.dll.so cd `dirname setupapi/__install__` && make install gcc -g -O2 -o install install.c install.c:23: windef.h: No such file or directory install.c:24: winbase.h: No such file or directory install.c:25: winreg.h: No such file or directory install.c:26: winternl.h: No such file or directory install.c:27: winerror.h: No such file or directory install.c:28: wingdi.h: No such file or directory install.c:29: winuser.h: No such file or directory install.c:30: winnls.h: No such file or directory install.c:31: setupapi.h: No such file or directory install.c:33: wine/unicode.h: No such file or directory install.c:34: wine/debug.h: No such file or directory *** Error code 1 Stop in /home/sensei/wine-20041019/dlls/setupapi. *** Error code 1 Stop in /home/sensei/wine-20041019/dlls (line 416 of Makefile). *** Error code 1 Stop in /home/sensei/wine-20041019 (line 301 of Makefile). After that I copied all needed headerfiles into dlls/setupapi/ and finally I got these errors: [SNIP] /tmp//ccU25700.o(.text+0x18d1): In function `InstallHinfSectionW': /home/sensei/wine-20041019/dlls/setupapi/install.c:927: undefined reference to `SetupOpenInfFileW'/tmp//ccU25700.o(.text+0x18e1):/home/sensei/wine-200 41019/dlls/setupapi/install.c:930: undefined reference to `SetupInitDefaultQueueCallback'/tmp//ccU25700.o(.text+0x18f0):/home/sen sei/wine-20041019/dlls/setupapi/install.c:931: undefined reference to `SetupDefaultQueueCallbackW'/tmp//ccU25700.o(.text+0x1912):/home/sensei /wine-20041019/dlls/setupapi/install.c:934: undefined reference to `SetupTermDefaultQueueCallback'/tmp//ccU25700.o(.text+0x1918):/home/sen sei/wine-20041019/dlls/setupapi/install.c:935: undefined reference to `SetupCloseInfFile'/tmp//ccU25700.o(.text+0x193e): In function `InstallHinfSectionA':/home/sensei/wine-20041019/dlls/setupapi/install. c:950: undefined reference to `RtlCreateUnicodeStringFromAsciiz'/tmp//ccU25700.o(.text+0x195f):/home/ sensei/wine-20041019/dlls/setupapi/install.c:953: undefined reference to `RtlFreeUnicodeString'/tmp//ccU25700.o(.rodata+0x80): In function `get_field_string':/home/sensei/wine-20041019/dlls/setupapi/install.c:9 8: undefined reference to `__wine_dbch_setupapi' collect2: ld returned 1 exit status*** Error code 1 Stop in /home/sensei/wine-20041019/dlls/setupapi. *** Error code 1 Stop in /home/sensei/wine-20041019/dlls/setupapi. *** Error code 1 Stop in /home/sensei/wine-20041019/dlls (line 416 of Makefile). *** Error code 1 Stop in /home/sensei/wine-20041019 (line 301 of Makefile). Please CC me because I'm not subscribed to the list. -Sascha -- Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin. --John von Neumann (1951)

2 1

Re: Tiny optimizations of bit testing operations
by Rein Klazes 21 Oct '04

21 Oct '04

On Wed, 20 Oct 2004 19:48:05 +0900, you wrote: > Hello, > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Tiny optimizations of bit testing operations. Testing with gcc 3.3.5: > - BOOL min_or_max_box = (wndPtr->dwStyle & WS_MAXIMIZEBOX) || > - (wndPtr->dwStyle & WS_MINIMIZEBOX); > + BOOL min_or_max_box = wndPtr->dwStyle & (WS_MAXIMIZEBOX | WS_MINIMIZEBOX); At moderate optimization levels (-O1) gcc compiles this to identical code. > - if((wndPtr->dwExStyle & WS_EX_LEFTSCROLLBAR) != 0) > + if (wndPtr->dwExStyle & WS_EX_LEFTSCROLLBAR) At any optimization level, gcc compiles this to identical code. > if ((wndPtr->dwStyle & WS_VSCROLL) && > - ((((wndPtr->dwExStyle & WS_EX_LEFTSCROLLBAR) != 0) && (ptClient.x <= rcClient.left + GetSystemMetrics(SM_CXVSCROLL))) || > - (((wndPtr->dwExStyle & WS_EX_LEFTSCROLLBAR) == 0) && (ptClient.x >= rcClient.right - GetSystemMetrics(SM_CXVSCROLL))))) > + (((wndPtr->dwExStyle & WS_EX_LEFTSCROLLBAR) && (ptClient.x <= rcClient.left + GetSystemMetrics(SM_CXVSCROLL))) || > + (!(wndPtr->dwExStyle & WS_EX_LEFTSCROLLBAR) && (ptClient.x >= rcClient.right - GetSystemMetrics(SM_CXVSCROLL))))) Not different then the previous example. >From the C point of view these bit logics are identical. The compiler finds that out easy. Rein. -- Rein Klazes rklazes(a)xs4all.nl

4 4

IE6: Help Engine Sputtering, Main Engine Doesn't Start, Segmentation Fault
by Dan McGhee 21 Oct '04

21 Oct '04

At the outset I must apologize for the length of this post. This situation is intricately convoluted and, currently, I cannot interpret the information that I have collected. Right now I can only relay information that I think is relevant. I would be more than happy to generate more info, but I will need some specific direction for commands and so forth. Right now I have reached the limit of my current troubleshooting skills. My overall goal is to get Edit Studio 4, a video editing application, running in wine. It depends on the IE6 Help Engine. There are other situations with this app and that's why I don't depend on an older version of wine to run it. Right now, if I can't get IE6 to run its help engine, I can't get my app to work. Here goes on my problems with IE6. Conventions: 1013 implies wine compiled from the cvs update on October 13 and a .wine, created from that update aug implies wine version compiled from the cvs update on October 13 and a .wine from a wine version, compiled from my repository, before the 20040824 16:00:16 CDT commit Symptoms: 1. with wine from 1013 and .wine from 1013, IE6 exits with no window--this started sometime after the September snapshot 2. with wine from 1013, any version of wine that I compile, and .wine from aug, IE6 runs and Help works 3. with wine from September snapshot and .wine from 1013, IE6 creates a segmentation fault My original symptom was that I couldn't get IE6 Help to work after the September snapshot. I did a regression and identified the commit of 20040824 16:00:16 CDT as causing the problem. The commit edits this patch: http://cvs.winehq.org/patch.py?id=13475 Among other things this patch changes wine/dlls/Makefile.in wine/configure.ac wine/configure it also changes itss.dll. However, my symptoms still persist whether I use a native or builtin version of itss. I include this information because I don't know if the symptoms are separate problems or are related. I am not able to pin point the cause of Symptom 1 because I do not yet know how to update my repository to do a regression. I must wait for the archive after the October snapshot. I have reasoned, since I can get IE6 to work completely using a ~/.wine created before that August commit, that the problem lies somewhere in the "fake windows" directory. There are differences in the registry, win.ini and system.ini files, but I do not know how to diagnose them. The following excerpt, from one of the logs I created, shows that there is a completely different sequence, between the working and non-working situations, when shell32 loads for the first time: trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shell32.dll" : builtin -trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\\shell32.dll" : builtin -trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shell32.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\ole32.dll" : native trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\BROWSEUI.dll" : native err:shell:ReadCabinetState Initializing shell cabinet settings trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\browselc.dll" : native -trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\RPCRT4.DLL" : native +trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\shdoclc.dll" : native +err:rebar:REBAR_WindowProc unknown msg 200b wp=00000000 lp=71180f00 +trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\uxtheme.dll" : builtin +trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\RPCRT4.dll" : native +trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\lz32.dll" : builtin +trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\version.dll" : builtin +trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\urlmon.dll" : native trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\MSOSS.dll" : native trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\CRYPT32.dll" : native trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\OLEAUT32.dll" : native trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\WININET.dll" : native I stopped the excerpt here because this is the point at which the non-working situation exits. I have generated a log from +relay "grepped" for shell32 but do not know how to interpret it to see if I can glean any more information. This log and all the others are contained in the tarball that I have attached. It creates a directory called "wine-trouble" and contains all the information that I have generated. The README contains specifics of what I have done. As I was composing the README for inclusion here, I realized that I had not done two things. I forgot to copy shell and shell32 to my fake windows directory so that all of my tests were conducted with builtin shell and shell32. Additionally, I have not run wine compiled before the August commit with a fake windows created on October 13. I will do both of these and see if I get differenet results. I'm really interested in resolving this and would rather that I had been able to supply better information. However, my knowlege of winedbg, windows and cvs does not currently allow me to proceed further. If anyone wants me to do more, I would appreciate being pointed in the right direction, but I will need some specifics. I have found no documentation on any of the wine mailing lists or other forums to indicate that anyone else is having this problem. It could be something that I am doing. This is why I haven't yet submitted a bug report. If a bug report would be more appropriate, I will do that. Thanks, Dan

1 1

Re: [wineD3D] HW Vertex Buffer
by Raphael 21 Oct '04

21 Oct '04

Hi again, A better patch than previous Changelog: - beta implementation of HW Vertex Buffer support (using ARB_vertex_buffer_object): locking/unlocking, creation, destruction - some wined3d headers/interface extension Todo - Bind/Unbind on rendering (use exported APIs, see IWineD3DDevice_BindVertexBuffer/IWineD3DDevice_UnbindVertexBuffer) Regards, Raphael

1 0