wine-devel January 2006

wine-devel@winehq.org

161 participants
302 discussions

Re: Small CVS-Update-Script
by Christian Lachner 12 Feb '06

12 Feb '06

I know that there is something like my script out there but i did (again) spend some time on rewriting my own one since i like it better ;). This one is compeltely different from my first one - it works the same, but does some checks before doing anything , the code is written nicer and cleaner and the output is also very nice now :D. Have fun with this piece of code! On 10/2/05, Andreas Schneider <andreas.schneider(a)linux-gamers.net> wrote: > Hi gladiac, > > take a look at > > http://winecvs.linux-gamers.net/ > > Cheers, > > -- andreas > > Gladiac Spark wrote: > > This is nothing special but may be useful for some people out there > > having problems updating their cvs-trees or being lazy writing some > > commands in their console. Copy the 'getwinecvs' to /usr/src or wherever > > you want (don't forget to edit the SRC=Variable if you're doing so) and > > chmod it to give you x-rights. (e.g.: 'chmod 750 getwinecvs' without quotes) > > > > By running it, it will search for an existing wine-tree... if there is > > one, it will be cleaned and then updated; if not, the complete tree will > > be downloaded. > > When using -c as parameter for getwinecvs, it will automatically begin > > to compile after getting all the updates and then install. > > To see what it exactly does, have a look at the source. > > > > Even if it is called General CVS-Updater by gladiac it has been written > > FOR wine. I hope it is helpful for others. I know it's not very nerdy > > but.... who cares ;). > > > > > > ------------------------------------------------------------------------ > > > > > > -- > http://www.linux-gamers.net - your online gaming resource > >

3 9

StretchDIBits function problem.
by Cyril Margorin 10 Feb '06

10 Feb '06

Hello, I've discovered, that using of GetDIBits after StretchDIBits doesn't return correct data. More then - all pixels that it returns are black. In attachment the test function. Changelog: Cyril Margorin <comargo(a)gmail.com> add test of StretchDIBits()/GetDIBits() bunch to gdi/test/bitmap.c -- Cyril Margorin

4 4

Regression problems in app - help with debugging?
by Dr J A Gow 09 Feb '06

09 Feb '06

Hello All, I have some regression problems relating to Wine in a commercial ECAD app 'Easy-PC' version 9.0, available from http://www.numberone.com The application was quite usable on Crossover Office 4.2, with just some minor dialog corruption. Alpha versions of Wine available at the same time (can not exactly remember which ones) could also run it successfully. However, under the latest Wine 0.9.6, Wine CVS and CXO 5.0.1 it does not work. Note that it does not crash, it errors out cleanly with a dialog box message. I have been debugging the problems in this app for some time now. It is a critical app for me as I use it in a production environment, but I do not want to pay Microsoft for the privilege of exposing my machine to malware. I am thus prepared to help debug Wine to get this application running. However, my Windows programming experience is limited to device drivers, not apps (although fluent C/C++ systems programming on other platforms), I have hit a brick wall, possibly due to my limited knowledge of how the Windows API works and I will need some help with this. If anyone would like to help me debug this app (hope springs eternal!), a demo version of the app is available free of charge from the web site address above, and this version exhibits the same problems as the full version. Background ------------- The system: Dual physical processor (not dual core) Opteron running SuSE 10.0 x86_64 SMP. Wine: Latest 0.9.6 release, up to CVS grabbed a week or so ago. The application installs OK and when run, puts up a GUI as expected. However, when you try to create a new PCB or schematic, an error dialog box is displayed indicating that the app can not read the technology file Default.stf (schematic) or Default.ptf (pcb). This is _not_ a permissions problem, all files are actually present and the same install will work under CXO 4.2. I generated and analyzed several hundred MB of logfiles over many days, added extra debug statements to the Wine code and analyzed the application's operation. The problem actually appears to have two causes, and this is what I have come up with so far. Problem 1 ----------- Application calls StgOpenStorage with a grfMode flag of 0x10020 (STGM_TRANSACTED | STGM_SHARE_DENY_WRITE). Immediately afterwards it calls StorageBaseImpl_OpenStream with a grfMode of 0x12 (STGM_SHARE_EXCLUSIVE | STGM_READWRITE). This second call fails with an access denied error code, after which the logs show an easily traced error handling sequence leading to display of the error dialog mentioned above: 0009:Call ole32.StgOpenStorage(59693db0 L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.ptf",00000000,00010020,00000000,00000000,5821f850) ret=1022e7f0 ... ... trace:storage:StgOpenStorage <-- 00000000, IStorage 0x5b3465f8 0009:Ret ole32.StgOpenStorage() retval=00000000 ret=1022e7f0 ... ... trace:storage:StorageBaseImpl_OpenStream (0x5b3465f8, L"\0005FileType", (nil), 12, 0, 0x5821f848) fixme:storage:StorageBaseImpl_OpenStream STORAGE ACCESS DENIED - parent 0, this 2 Note that the last fixme is one I added to find out exactly what was going on here. Now, logic would dictate that the grfMode of the OpenStream method call is indeed incompatible with that of its parent storage object. However, I would have thought that the application coders would most likely have hard-coded the grfMode flags in the application. If so, it would seem that the app is buggy, yet this application works on Windows! Either the app is buggy and the Win32 OLE32 implementation behaves differently, or I am missing something here. Ok, so with no obvious solution to this problem, I decided to bypass it. I modified the storage32.c implementation in the following way to bypass the grfMode check: parent_grfMode = STGM_ACCESS_MODE( This->ancestorStorage->base.openFlags ); *if* ( STGM_ACCESS_MODE( grfMode ) > STGM_ACCESS_MODE( parent_grfMode ) ) { FIXME("StorageBase_OpenStream called with grfMode mismatch - parent %d, this %d\n", parent_grfMode,STGM_ACCESS_MODE(grfMode)); ///res = STG_E_ACCESSDENIED;/ ///goto end;/ } Obviously not a viable fix, but a hack to get it working. After implementing this, the OpenStream call succeeded, as did subsequent stream access. However, the app _still_ errored out in exactly the same manner and at the same time. After more log searching, this led to the discovery of the second problem. Problem 2 ----------- During its loading and setup, the application repeatedly calls StgOpenStorage on the .stf/.ptf files in question, calls OpenStream, reads from the stream, and then finally closes the storage. I placed tell-tales in useful locations in the file open/close handlers in the wineserver, and could clearly see the files being opened and subsequently closed. This open/read/close occurs correctly and in sequence up to a certain point. At this point in the execution, the app calls StgOpenStorage on the technology file, with the following call. It is opened correctly, with grfMode of STGM_TRANSACTED | STGM_SHARED_DENY_WRITE | STGM_READWRITE: 0009:Call ole32.StgOpenStorage(5821f754 L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.ptf",00000000,00010022,00000000,00000000,5821f7f4) ret=7c17eabc trace:storage:StgOpenStorage (L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.ptf", (nil), 10022, (nil), 0, 0x5821f7f4) ... ... ... trace:storage:StorageBaseImpl_AddRef (0x5b3465f8) AddRef to 1 trace:storage:StgOpenStorage <-- 00000000, IStorage 0x5b3465f8 0009:Ret ole32.StgOpenStorage() retval=00000000 ret=7c17eabc Almost immediately, the app opens three streams in this object and starts to access them, all successfully. There follows a whole slew of logging statements, all of which appear sensible However, what is strange about this access is that soon we seem to be frantically increasing the storage object's reference pointer. This sequence appears frequently in the code, closely spaced but interspersed with what seems quite logical and successful calls to seek functions and memory allocation functions: 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000030) ret=584e498b 0009:Ret ntdll.RtlAllocateHeap() retval=55926480 ret=584e498b trace:storage:StorageBaseImpl_AddRef (0x5b3465f8) AddRef to 9 trace:storage:StorageImpl_ReadProperty storage name: L"\0005SummaryInformation" 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000008) ret=584e7ab3 0009:Ret ntdll.RtlAllocateHeap() retval=5594d108 ret=584e7ab3 The storage object's reference pointer is so incremented up to 19: 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000030) ret=584e498b 0009:Ret ntdll.RtlAllocateHeap() retval=559250f8 ret=584e498b trace:storage:StorageBaseImpl_AddRef (0x5b3465f8) AddRef to 19 trace:storage:StorageImpl_ReadProperty storage name: L"\0005SummaryInformation" 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000008) ret=584e7ab3 0009:Ret ntdll.RtlAllocateHeap() retval=55925130 ret=584e7ab3 Finally, the code executes a trace:storage:StgStreamImpl_Destroy (0x5b34b7e0) trace:storage:StorageBaseImpl_Release (0x5b3465f8) ReleaseRef to 18 There follows a lot more log file, mostly concerned with set up and so on. What I am highligting here is that between this point, and the point of actual failure which I am going to describe shortly, there appears to be no attempt to close the Default.ptf file, unlike the attempts further up the logs closer to program start. I am wondering about this: is the reference counter being incorrectly incremented here, preventing the 'Release' function from destroying the storage object and thus closing the file? I am not sufficiently familiar with the COM storage object stuff in Windows to know what _should_ happen here. Anyway. I will now describe the point of failure. Further down the log, there are several more successful opens/closes of the technology file, with the correct mode flags. Then, finally, the app tries to re-open the technology file with a grfMode of STGM_TRANSACTED | STGM_SHARE_DENY_WRITE. This call fails with a sharing violation (remember it had been left open from the previous call) 0009:Call ole32.StgOpenStorage(5971bec8 L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.stf",00000000,00010020,00000000,00000000,5821e69c) ret=1022e7f0 .... .... 0009:Ret kernel32.CreateFileW() retval=ffffffff ret=584edc8b trace:storage:StgOpenStorage <-- 80030020, IStorage (nil) There then follows the same error handling sequence leading to display of the dialog. I then thought about a simple test. I overrode the sharing mode detection in fd.c/check_sharing() in the wineserver (again, not a real solution). Note there are some minor differences in the code - I used a return code so I could easily check it: /// if ((access & FILE_UNIX_READ_ACCESS) && !(existing_sharing & FILE_SHARE_READ))/ /// rc=0;/ /// if ((access & FILE_UNIX_WRITE_ACCESS) && !(existing_sharing & FILE_SHARE_WRITE))/ /// rc=0;/ /// if ((existing_access & FILE_UNIX_READ_ACCESS) && !(sharing & FILE_SHARE_READ)) rc=0;/ /// if ((existing_access & FILE_UNIX_WRITE_ACCESS) && !(sharing & FILE_SHARE_WRITE)) rc=0;/ *if* (fd->closed->unlink[0] && !(existing_sharing & FILE_SHARE_DELETE)) rc=0; *if* (unlink && !(sharing & FILE_SHARE_DELETE)) rc=0; *if*(rc==0) { fprintf(stderr,"FILEDESC - sharing mode invalid\n"); rc=1; } *return* rc; and the application worked! Not only worked, but worked perfectly! The minor dialog corruption of previous versions had completely gone! I would like to thank the hard working people who have been working to correct problems in Wine, and in doing so had fixed this minor dialog problem. The only issue of note then is that the top-right hand buttons of a maximized MDI child window do not appear until you resize the frame. This is a minor issue though, and not of importance here. However, what I did does not represent a real solution - I just hacked around the problem, which itself seems subtle in nature. I looked closely at the Microsoft documentation and the logic in check_sharing(), even writing a program in Windows to check that at the CreateFile level that the sharing logic in Wine is correct. It seems to be. I am now stumped, I would really like to get this app working properly under Wine, without bad hacks. I would appreciate any guidance from those more experienced with the user-land Windows API. If you got this far, many thanks for taking the time to read this long message. I have provided only small excerpts from logs, but I can provide other parts of the files on request if necessary. John.

2 3

dx9 and shaders
by Coleman Kane 09 Feb '06

09 Feb '06

Hi, What is the status on Shader support for DX9 in the latest WINE cvs, and the future projections of support in this area? I am working on a transition project, and am curious how far off support for this is in the WINE project, and perhaps where work needs to be done. Are there any people organizing this effort here? -- Coleman Kane

8 15

gethostbyname call with 0 length arg
by Phil Goss 08 Feb '06

08 Feb '06

Hi, Is it a bug in the WINE gethostbyname (WS_gethostbyname) implementation, where if the arg name is of string length 0, then it returns unsuccessful. I have experience this issue with a Windows program (Onkyo Nettune) where the hostname passed to gethostbyname is of length 0. (This seems to be a bug in the program itself). However, the program works okay in native Windows. There seems to be a check in the gethostbyname for a NULL arg name ... if(!name) ... But no check for ... if(!strlen(name)) .... I have tested the strlen check and it seems to work and satisfies the Windows program. Does the above make sense, as I am not a programmer? Not sure if this s bug in wine even though it implementation should be matching Windows native. Thanks, Phil -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

4 9

*** No rule to make target `../../dlls/d3d9/tests/d3d9_test.exe.so',
by Rainer Dorsch 07 Feb '06

07 Feb '06

Hello, I compiled the last few wine releases. 0.9.6 gives me a compile error: make[2]: Entering directory `/home/rd/SW.nobackup/wine-0.9.6/programs/winetest' make[2]: *** No rule to make target `../../dlls/d3d9/tests/d3d9_test.exe.so', needed by `d3d9_test.exe.so'. Stop. Any hints are welcome. Thanks, Rainer

5 9

Win32HandleToDosFileHandle / DosFileHandleToWin32Handle
by Derek Fawcus 05 Feb '06

05 Feb '06

I'm looking to do some changes to the wine vdm - or more accurately to the winedos dll to make the handling for some DOS applications more useful. This is mainly driven from a desire to run DOS apps without a wineconsole, so using the unix stdin/stdout/stderr as the DOS file handles. i.e. ala the BSD doscmd program; mind it also has similar issues (plus I'd have to port it :) There are a few things I'll have to alter wrt to the existing console handling (within winedos), but the main part will be using the JFT within the PSP/PDB and creating SFTs. i.e. in effect fleshing out dlls/kernel/file.c:dos_handles to be a pseudo-SFT. I think I've figured out more or less where I need to hack^h^h^h^hcode. Looking at what's done at the moment, I see the above two functions being used. Now really, what I'd like to have available is Win32HandleToDosSFT and DosSFTToWin32Handle; so I'll have to create something along those lines. So a few questions : a) Is the behaviour of the above two functions correct? i.e. should they be DosFileHandle <-> Win32Handle conversion routines? Or is this just an artifact of how the DOS file handles are currently implemented? b) Do any real apps (that anyone knows of) depend upon calling them? I do see that they are used in a number of places for the existing 16 bit routines. If the behaviour is correct, then I guess I'll have to adjust them so that they involve a lookup of the current PSP/PDB and hence indirect through the JFT. Does anyone know if there is already a defined set of functions for SFT handling at the NT abstraction level? I'd have expected that the NT vdm would have used it if such was available. DF

2 5

linux/capi.h: present but cannot be compiled
by Joshua Crawford 03 Feb '06

03 Feb '06

(I'm not on the devel list, so please Cc: replies either to me or the users list.) After recently upgrading my distro (from Slackware 10.1 to Slackware 10.2 with Freerock GNOME), configure (current CVS) now reports configure: WARNING: linux/capi.h: present but cannot be compiled configure: WARNING: linux/capi.h: check for missing prerequisite headers? configure: WARNING: linux/capi.h: see the Autoconf documentation configure: WARNING: linux/capi.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/capi.h: proceeding with the preprocessor's result configure: WARNING: linux/capi.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## It seems linux/capi.h requires linux/compiler.h (for __user). I tried simply putting linux/compiler.h above linux/capi.h in the AC_CHECK_HEADERS list, but that did't work, so I'll have to leave the fix to someone who actually knows something about autoconf. This is the relevant section from config.log: configure:7159: checking linux/capi.h usability configure:7171: gcc -c -g -O2 conftest.c >&5 In file included from conftest.c:76: /usr/include/linux/capi.h:80: error: variable or field `__user' declared void /usr/include/linux/capi.h:80: error: syntax error before '*' token /usr/include/linux/capi.h:115: error: syntax error before "capi_manufacturer_cmd" /usr/include/linux/capi.h:117: error: syntax error before '}' token configure:7177: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "0.9.6" | #define PACKAGE_STRING "Wine 0.9.6" | #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" | #ifdef __cplusplus | extern "C" void std::exit (int) throw (); using std::exit; | #endif | #define YYTEXT_POINTER 1 | #define HAVE_GETHOSTBYNAME 1 | #define HAVE_CONNECT 1 | #define HAVE_INET_ATON 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_ALSA_ASOUNDLIB_H 1 | #define HAVE_ARPA_INET_H 1 | #define HAVE_ARPA_NAMESER_H 1 | #define HAVE_ASM_TYPES_H 1 | #define HAVE_CUPS_CUPS_H 1 | #define HAVE_CURSES_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_ELF_H 1 | #define HAVE_FLOAT_H 1 | #define HAVE_GETOPT_H 1 | #define HAVE_GIF_LIB_H 1 | #define HAVE_JPEGLIB_H 1 | #define HAVE_LBER_H 1 | #define HAVE_LCMS_H 1 | #define HAVE_LDAP_H 1 | #define HAVE_LINK_H 1 | /* end confdefs.h. */ | #include <stdio.h> | #if HAVE_SYS_TYPES_H | # include <sys/types.h> | #endif | #if HAVE_SYS_STAT_H | # include <sys/stat.h> | #endif | #if STDC_HEADERS | # include <stdlib.h> | # include <stddef.h> | #else | # if HAVE_STDLIB_H | # include <stdlib.h> | # endif | #endif | #if HAVE_STRING_H | # if !STDC_HEADERS && HAVE_MEMORY_H | # include <memory.h> | # endif | # include <string.h> | #endif | #if HAVE_STRINGS_H | # include <strings.h> | #endif | #if HAVE_INTTYPES_H | # include <inttypes.h> | #else | # if HAVE_STDINT_H | # include <stdint.h> | # endif | #endif | #if HAVE_UNISTD_H | # include <unistd.h> | #endif | #include <linux/capi.h> configure:7199: result: no configure:7203: checking linux/capi.h presence configure:7213: gcc -E conftest.c configure:7219: $? = 0 configure:7239: result: yes configure:7252: WARNING: linux/capi.h: present but cannot be compiled configure:7254: WARNING: linux/capi.h: check for missing prerequisite headers? configure:7256: WARNING: linux/capi.h: see the Autoconf documentation configure:7258: WARNING: linux/capi.h: section "Present But Cannot Be Compiled" configure:7260: WARNING: linux/capi.h: proceeding with the preprocessor's result configure:7262: WARNING: linux/capi.h: in the future, the compiler will take precedence configure:7274: checking for linux/capi.h configure:7281: result: yes -- Joshua 'bruce' Crawford ... http://www.geocities.com/mortarn The early bird may get the worm, but the second mouse gets the cheese.

2 2

Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL? [FIXED]
by Tony Lambregts 01 Feb '06

01 Feb '06

I dont normally top post ;^) but this time it makes sense to. This (replied to) email is not archived in the Piper Mail archive correctly although it looks fine here. In the pipermail archive there is only a pgp signature. This is not the first time I have seen this, it seems that Piper Mail grabs the pgp signature and does not archive the patch which makes the archive less usefull. If you ask me this is what I would call a bug in pipermail. http://www.winehq.org/pipermail/wine-patches/2006-January/023490.html Between this bug and the lack of dates in the archive I really getting to despise pipermail. So... I went looking at the alternative and thought of GMANE and it turns out that this patch is not archived there at all. In fact the last patch by Jonathan Ernst that was archived by GMANE is 2005-12-19 16:28:02 GMT and I know that there are more after that date. http://search.gmane.org/?query=&email=Jonathan+Ernst&group=gmane.comp.emula… So now I'm really starting to get upset because we have no reliable archive and that just sucks. Has anyone got any ideas on how to fix this. -- Tony Lambregts Jonathan Ernst wrote: > Le dimanche 15 janvier 2006 à 07:40 -0800, Dan Kegel a écrit : > >>On 1/15/06, Ge van Geldorp <gvg(a)reactos.org> wrote: >> >>>>The Mozilla ActiveX control download feature is cool and all, >>>>but until we repackage the sucker to include MSVCP60.DLL to fix >>>>http://bugs.winehq.org/show_bug.cgi?id=4064 ... >>>>I could have sworn I saw somebody post a note saying they had >>>>done said repackaging, but I can't find it now... >>> >>>http://www.winehq.org/pipermail/wine-patches/2005-December/022795.html >>>Instructions on how to repackage can be found at >>>svn://svn.reactos.org/trunk/tools/MozillaControl/ >> >>Thanks! I've updated bug 4064. Now can somebody >>update winehq.org's copy of the control so we can close that bug? >>- Dan >> >>-- >>Wine for Windows ISVs: http://kegel.com/wine/isv >> >> >> > > > Le lundi 16 janvier 2006 à 14:30 +0100, Filip Navara a écrit : > >>Jonathan Ernst wrote: >> >> >>>// Exact size of the file: >>>$iFileSize = 4771240; >>> >> >>Shouldn't you change the file size too? >> >>- Filip >> > > > Sure, thanks for spotting it ;-) > > Changelog: > - use repackaged Mozilla ActiveX control from ReactOS > > > > > ------------------------------------------------------------------------ > > Index: mozactivex.php > =================================================================== > RCS file: /home/wine/tools/mozactivex.php,v > retrieving revision 1.1 > diff -u -p -r1.1 mozactivex.php > --- mozactivex.php 19 Oct 2005 16:17:09 -0000 1.1 > +++ mozactivex.php 16 Jan 2006 14:02:33 -0000 > @@ -14,31 +14,27 @@ > > > // Name of the file > -$sFileName = "MozillaControl1712.exe"; > +$sFileName = "MozillaControl1712-ReactOS.exe"; > > // Exact size of the file: > -$iFileSize = 4771240; > +$iFileSize = 4735160; > > // List of locations > -$aList = array("http://www.iol.ie/~locka/mozilla/", > - "http://osdn.dl.sourceforge.net/sourceforge/wine/", > - "http://nchc.dl.sourceforge.net/sourceforge/wine/", > - "http://easynews.dl.sourceforge.net/sourceforge/wine/", > - "http://mesh.dl.sourceforge.net/sourceforge/wine/", > - "http://puzzle.dl.sourceforge.net/sourceforge/wine/", > - "http://citkit.dl.sourceforge.net/sourceforge/wine/", > - "http://umn.dl.sourceforge.net/sourceforge/wine/", > - "http://cogent.dl.sourceforge.net/sourceforge/wine/", > - "http://jaist.dl.sourceforge.net/sourceforge/wine/", > - "http://surfnet.dl.sourceforge.net/sourceforge/wine/", > - "http://peterhost.dl.sourceforge.net/sourceforge/wine/", > - "http://ufpr.dl.sourceforge.net/sourceforge/wine/", > - "http://optusnet.dl.sourceforge.net/sourceforge/wine/", > - "http://keihanna.dl.sourceforge.net/sourceforge/wine/", > - "http://heanet.dl.sourceforge.net/sourceforge/wine/", > - "http://switch.dl.sourceforge.net/sourceforge/wine/", > - "http://internap.dl.sourceforge.net/sourceforge/wine/", > - "http://ovh.dl.sourceforge.net/sourceforge/wine/" > +$aList = array("http://switch.dl.sourceforge.net/sourceforge/reactos/", > + "http://surfnet.dl.sourceforge.net/sourceforge/reactos/", > + "http://citkit.dl.sourceforge.net/sourceforge/reactos/", > + "http://keihanna.dl.sourceforge.net/sourceforge/reactos/", > + "http://heanet.dl.sourceforge.net/sourceforge/reactos/", > + "http://easynews.dl.sourceforge.net/sourceforge/reactos/", > + "http://ovh.dl.sourceforge.net/sourceforge/reactos/", > + "http://jaist.dl.sourceforge.net/sourceforge/reactos/", > + "http://puzzle.dl.sourceforge.net/sourceforge/reactos/", > + "http://nchc.dl.sourceforge.net/sourceforge/reactos/", > + "http://switch.dl.sourceforge.net/sourceforge/reactos/", > + "http://kent.dl.sourceforge.net/sourceforge/reactos/", > + "http://optusnet.dl.sourceforge.net/sourceforge/reactos/", > + "http://mesh.dl.sourceforge.net/sourceforge/reactos/", > + "http://internap.dl.sourceforge.net/sourceforge/reactos/" > ); > > > > > ------------------------------------------------------------------------ > >

5 10

Re: wined3d: Fixed render states
by H. Verbeet 01 Feb '06

01 Feb '06

On 31/01/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > wined3d: Fixed up render states POINTSCALEENABLE, POINTSPRITENABLE, > EDGEANTIALIAS, MULTISAMPLEANTIALIAS You probably want to split the patch up in smaller pieces. > + if(This->stateBlock->renderState[D3DRS_POINTSCALEENABLE]) { > + att[0] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_A]) / > + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); > + att[1] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_B]) / > + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); > + att[2] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_C]) / > + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); > + } You're not supposed to use D3DRS_ stuff in wined3d, rather use the respective WINED3DRS_ defines, as the original code did. > + if(GL_SUPPORT(ARB_POINT_PARAMETERS)) { Same problem as with your patch for d3d8, wined3d doesn't currently check for ARB_POINT_PARAMETERS support (in IWineD3DImpl_FillGLCaps). > - /* Doesn't work with GL_POINT_SMOOTH on on my ATI 9600, but then ATI drivers are buggered! */ > - glDisable(GL_POINT_SMOOTH); Did you verify that this isn't required anymore? Otherwise that's a potential regression. > + checkGLcall("glEnable(Gl_LINE_SMOOTH)"); > + checkGLcall("glDisable(Gl_LINE_SMOOTH)"); That should probably say Gl_LINE_SMOOTH, but it's not really critical.

4 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2006