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

Re: [lostwages] Remove winetools from download page

by Michael Jung

Hi Vitaliy, On Thursday 22 December 2005 18:32, Vitaliy Margolen wrote: > Also had an interesting case last night: person had problems with > winetools. When I asked the version, he said it's 3.0.9. So, there is your > problem. Some one packaged winetools and made this version number. This seems to be the version we are distributing via our debian apt-repository. Have a look at http://wine.sourceforge.net/apt/binary/ > As far as winetools go. I see a really bad patterns there. > 1. There is no clean way to install them for a local user to test. > Winetools are invasive and change too many things and go into to many > places. This is not the way to package software. > 2. It can't use wine from the source tree (again for testing). > 3. It's using redundant scripts to like findwine. For what purpose? > 4. Those scripts override environment variables that wine and wine parts, > depend on. Why? > 5. It adds some extra needless overrides to the registry, like > DLLOVERRIDES="*=native, builtin". Is there a reason for this? That > _is exactly_ what we, developers, trying to avoid. > 6. "Version"="win98" - that is wrong. Wine's default _is_ win2k. You should bring your concerns to Joachim von Thadden's or Sven Paschukat's attention. If they fix them, we can keep the link to winetools. If they prefer not to fix them, we can explain to them why we think this is a problem for wine's development progress and thus give a rational for removing the link. Merry Christmas (or if you prefer, Happy Holidays ;) -- Michael Jung mjung(a)iss.tu-darmstadt.de

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by Vitaliy Margolen

Wednesday, December 21, 2005, 8:12:43 PM, Tom Wickline wrote: > Winetools helps people run programs that they might not be able to and > it helps them do that now. And that's what 99.9% of end users care > about, can I run what I want to now? If the answer is no 99.8% of them > will leave while .1% might stick around and wait on a fix. Could you please show me some one, or ask them speak up on #winehq. So for I have yet to talk to anyone there who had used winetools and had IE6 working (that's the main goal of this isn't it?). Ok it looks like there is 1 person who did use winetools and they worked. So, Tom, could you please specify the place where I can redirect all the people who having problems _with winetools_? To wine-users I presume? As it looks to me that's the place where all the advertisement going on about using winetools. Also had an interesting case last night: person had problems with winetools. When I asked the version, he said it's 3.0.9. So, there is your problem. Some one packaged winetools and made this version number. As far as winetools go. I see a really bad patterns there. 1. There is no clean way to install them for a local user to test. Winetools are invasive and change too many things and go into to many places. This is not the way to package software. 2. It can't use wine from the source tree (again for testing). 3. It's using redundant scripts to like findwine. For what purpose? 4. Those scripts override environment variables that wine and wine parts, depend on. Why? 5. It adds some extra needless overrides to the registry, like DLLOVERRIDES="*=native, builtin". Is there a reason for this? That _is exactly_ what we, developers, trying to avoid. 6. "Version"="win98" - that is wrong. Wine's default _is_ win2k. Please, we do not need this "quality" "software" linked to from the main download page. We can have a link to it in user section of wiki. But NOT the main download page! These "tools" defeat the purpose of what we, developers, are trying to archive. > Happy Holiday's

Dec. 22, 2005

Re: Bug 3885

by Oliver Stieber

--- Aric Cyr <Aric.Cyr(a)gmail.com> wrote: > Tom Spear <speeddymon <at> gmail.com> writes: > > > > > Aric Cyr wrote: > > >>>I took a look at the D3D_OK hack, and I believe the problem to be > > >>>CheckDeviceFormat in wined3d/directx.c. This function should return an > > >>>error if > > >>>D3DFMT_D32 is checked for on cards which don't support 32bit depth. > > >>>Currently > > >>>it just returns OK for most formats though. This code is really just a > > >>>stub as > > >>>it stands, and needs to be converted to check if there are any visuals that > > >>>meet > > >>>the requested format's requirements, and if there is, return D3D_OK, > > >>>otherwise > > >>>D3D_NOTAVAILBLE. > > >>> > > >>>To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case > > >>>(you'll need to add it) in wined3d/directx.c in > > >>>IWineD3DImpl_CheckDeviceFormat() > > >>>and see if that fixes that issue or not. This would be just another hack > > >>>though, so a real patch would still be necessary as I decribed above. > > > > Well I took a stab at adding the case for D3DFMT_D32, to the bottom of > > the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed > > to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes > > the first one and then goes to do the second one, but crashes in a > > different spot, so it seems we also have some stack corrupion (as was > > mentioned in the bug).. So that hack works for now, I would suggest > > that since the rest of that code is stubbed out, we should probably go > > ahead and submit a patch so we can at least run the darn thing and then > > start debugging the stack corruption issue. > > Thanks for testing this out. You have proved my theory correct, so I'll see > about making a patch which will correct CheckDeviceFormat(). Basically that > whole function needs a re-write, so I'd rather do it that way than to put this > hack in there. Especially since, I assume, this problem is not present on > nVidia systems, only ATI. I'm part of the way through re-writing this function to use an inclusive list per usage instead of an exclusive list for all usages and should hopefully have the re-write finished by the end of the week along with CheckDeviceType and friends. Oliver. > > Regards, > Aric > > > > ___________________________________________________________ Does your mail provider give you FREE antivirus protection? Get Yahoo! Mail http://uk.mail.yahoo.com

Dec. 22, 2005

Re: SPARC assembly won't compile, problems with NT headers

by Eric Frias

Troy Rollo wrote: >winegcc from the current WineHQ produces assembly output for SPARC systems >that cannot be processed by the assembler. > > I've attached the patches we're using for winebuild on SPARC. This fixes both of the problems you're encountering. I'm not sure if the fix is the right one, but it works quite nicely :-) We use gcc/gas. Eric Index: import.c =================================================================== --- import.c (.../vendor/wine/current/tools/winebuild) (revision 31841) +++ import.c (.../trunk/wine/tools/winebuild) (revision 31841) @@ -314,7 +314,7 @@ if (odp->flags & FLAG_PRIVATE) continue; imp->exports[imp->nb_exports++] = odp; } - imp->exports = xrealloc( imp->exports, imp->nb_exports * sizeof(*imp->exports) ); + imp->exports = xrealloc( imp->exports, imp->nb_exports ? (imp->nb_exports * sizeof(*imp->exports)) : 1); if (imp->nb_exports) qsort( imp->exports, imp->nb_exports, sizeof(*imp->exports), func_cmp ); return 1; @@ -835,7 +835,10 @@ if (!nb_imm) return; fprintf( outfile, "\n/* immediate import thunks */\n\n" ); - fprintf( outfile, "\t.text\n" ); + if (target_cpu == CPU_SPARC) + fprintf( outfile, "\t.data\n" ); + else + fprintf( outfile, "\t.text\n" ); fprintf( outfile, "\t.align %d\n", get_alignment(8) ); fprintf( outfile, "%s:\n", asm_name(import_thunks)); @@ -959,7 +962,10 @@ if (!nb_delayed) return; fprintf( outfile, "\n/* delayed import thunks */\n\n" ); - fprintf( outfile, "\t.text\n" ); + if (target_cpu == CPU_SPARC) + fprintf( outfile, "\t.data\n" ); + else + fprintf( outfile, "\t.text\n" ); fprintf( outfile, "\t.align %d\n", get_alignment(8) ); fprintf( outfile, "%s:\n", asm_name(delayed_import_loaders)); fprintf( outfile, "\t%s\n", func_declaration("__wine_delay_load_asm") ); @@ -1147,7 +1153,10 @@ for (i = 0; i < ext_link_imports.count; i++) fprintf( outfile, "\t%s %s\n", get_asm_ptr_keyword(), asm_name(ext_link_imports.names[i]) ); - fprintf( outfile, "\n\t.text\n" ); + if (target_cpu == CPU_SPARC) + fprintf( outfile, "\t.data\n" ); + else + fprintf( outfile, "\t.text\n" ); fprintf( outfile, "\t.align %d\n", get_alignment(get_ptr_size()) ); fprintf( outfile, "%s:\n", asm_name("__wine_spec_external_link_thunks") ); @@ -1239,6 +1248,15 @@ output_delayed_imports( outfile, spec ); output_immediate_import_thunks( outfile ); output_delayed_import_thunks( outfile, spec ); + + if (target_cpu == CPU_SPARC) + { + /* DJANKOV Q&D */ + fprintf( outfile, "\n\t.data\n" ); + fprintf( outfile, "\t.align %d\n", get_alignment(4) ); + fprintf( outfile, "%s:\n", asm_name("_end") ); + fprintf( outfile, "\t.long 0\n" ); + } output_external_link_imports( outfile, spec ); if (nb_imports || ext_link_imports.count || has_stubs(spec)) output_get_pc_thunk( outfile ); }

Dec. 22, 2005

RE: _itow tests in ntdll/tests

by Thomas Mertes

Hello, I am the author of the _itow tests and the _itow function. As far as I can remember when I tested the _itow functions under WIN2000 and under XP (No SP or just SP1) it was allowed to call _itow with _itow(123, NULL, 10) and the result of this call was NULL. The wine _itow function implemented this functionality because of "bug by bug" compatibility (Some Applications might be based on this "Feature"). The Test was done to find regressions or changes in the M$ operating systems. In my opinion testing corner cases is important. What does "there is failure" mean. Does it crash or return something different from NULL. When it crashes under XP SP2 the function _itow should remain unchanged. When some other value (different from NULL) is returned it might be necessary to change _itow. By the way. The reason I stopped developing for Wine is: I now have my own project: Seed7 In the Seed7 programming language new statements and operators can be declared easily. Functions with type results and type parameters are more elegant than a template or generics concept. Look at wikipedia: http://en.wikipedia.org/wiki/Seed7 or at sourceforge: http://sourceforge.net/projects/seed7 Just download Seed7 and see the new concepts. Greetings Thomas Mertes -- GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro* Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl

Dec. 22, 2005

Re: Typo on download page for debian packages

by Stefan Munz

Am Donnerstag, 22. Dezember 2005 10:45 schrieb Andreas Mohr: > Hi, > > On Thu, Dec 22, 2005 at 09:20:47AM +0100, Stefan Munz wrote: > > Hi, > > > > I don't know who who is responsible for maintaining the website, but > > probably he will read wine-devel ;-) > > > > I found a little typo on the download site for the debian packages. The > > link to the repository works for me only without the space: > > > > deb http://wine.sourceforge.net/apt/ binary/ > > > > should be: > > > > deb http://wine.sourceforge.net/apt/binary/ > > This is not true, and further you could even see it from three locations > that it's not: this line, the screenshot below, and the second line even > further below (and from my own testing which confirmed that it's correct). > > Let me guess that you're not a Debian user, right? ;-) Since a few weeks a use kubuntu on my laptop, that's why I was looking on the debian download page. But I'm definitely a debian newbie ;-) My fault was to try the explore the repository with a web browser and take it as one url. Sorry for your inconvenience. cu, Stefan > > Andreas -- Dipl.-Inform. Stefan Munz. . . . . . . . . . stefan.munz(a)itomig.de ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de Sand 14 . . . . . . . . . . . . . . . . . . phone: +49 7071 29 704 93 D-72076 Tübingen . . . . . . . . . . . . . . mobil: +49 178 729 72 72

Dec. 22, 2005

Re: ATI Opengl regression (DRI?)

by Aric Cyr

On 12/22/05, Raphael <fenix(a)club-internet.fr> wrote: > On Friday 16 December 2005 02:26, Aric Cyr wrote: > > Raphael <fenix <at> club-internet.fr> writes: > > > On Thursday 15 December 2005 19:55, Jesse Allen wrote: > > > > > You really don't need to use glXQueryServerString() and > > glXQueryClientString(). It would be better, easier (not strcmp) and more > > correct to just use glXQueryVersion(). glXQueryVersion will automatically > > report the version common to both the client and server (so in this case > > 1.2). > > No, we cannot > - glXGetFBConfigs is implemented by glx client (normally when glx client > version > 1.2 but in many 1.2 implementations its provided by Xorg). > - glXQueryDrawable is only implemented by glx server (when glx server version > > 1.2) > - for others calls we check if client version > 1.2 else we use SGIX extension Sorry, I think I was asleep when I posted that. What I meant to say is that we don't need any of the glXQueryServerString or glXQueryClientString calls, since we can and should just use glXQueryExtensionsString. In fact, this is what the code does, but it also passes around the server and client strings to each of the query_functions, even though none of them use those parameters. I guess you put those in for future use, but I think they will never get used and just clutter things up. > > > i thought that DRI implemented GLX 1.3 specs but seems they use a too > > > older x code :( > > > http://cvs.sourceforge.net/viewcvs.py/dri/xc/xc/programs/Xserver/GL/glx/ > > > > Too old perhaps, but that what DRI (and hence ATI) are using. Both support > > most of the 1.3 features so there really isn't much of an issue. The > > problem is that we cannot assume 1.3 regardless of how old 1.2 is. The > > reason for the glx version is so that we can do the right thing in any > > case. > > Not really, many of GLX features are supported by glx clients. > And only old clients (ie X versions) reports 1.2 caps (and generaly they > support 1.3 extensions) > I have only problems with "1.2 glx servers" (who don't support drawable > queries), who is the DRI / ATI configuration :( By drawable queries do you glXDrawableAttribARB? There is zero documentation for that function, and the entire GLX_ARB_render_texture extension. It seems like the ARB dropped the whole idea. Last mention of it was in 2002, from what I could find. I don't think we can rely on this extension to implement wglSetPbuffersAttribARB(). Maybe framebuffer objects would be a better solution, which ATI and nVidia both support now. > > Also seems like we should be relying on glXGetProcAddress() but need to be > > using glXGetProcAddressARB() since nVidia apparently doesn't export the > > former. > > ??? where you see glXGetProcAddress use ? Ya I checked the code after I sent this. I just happened to be reading the thread that I mentioned and thought it would be good advice to throw into the mail. Regards, Aric -- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)

Dec. 22, 2005

Re: Typo on download page for debian packages

by Andreas Mohr

Hi, On Thu, Dec 22, 2005 at 09:20:47AM +0100, Stefan Munz wrote: > Hi, > > I don't know who who is responsible for maintaining the website, but probably > he will read wine-devel ;-) > > I found a little typo on the download site for the debian packages. The link > to the repository works for me only without the space: > > deb http://wine.sourceforge.net/apt/ binary/ > > should be: > > deb http://wine.sourceforge.net/apt/binary/ This is not true, and further you could even see it from three locations that it's not: this line, the screenshot below, and the second line even further below (and from my own testing which confirmed that it's correct). Let me guess that you're not a Debian user, right? ;-) Andreas

Dec. 22, 2005

Re: SPARC assembly won't compile, problems with NT headers

by Alexandre Julliard

Troy Rollo <wine(a)troy.rollo.name> writes: > 2. "can't resolve `_end' {*UND* section} - `.L__wine_spec_rva_base' {.data > section}" > > This problem is more sinister. It arises from the same limitation as the first > problem, but is not susceptible to being worked around. The offending code is > the code that attempts to generate the NT header of the executable - > specifically the SizeOfImage element. I can't see any way at this point to > provide for this calculation to be done until after the linker output is > generated. I suspect the solution to this problem is to just output a zero in > this location and have winegcc modify the executable image to insert the > correct values after the linker has created it. You can probably fix it by defining an _end symbol, like we do for MacOS. You certainly don't want to try modifying the binary after it has been built. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2005

Resent: [opengl] fix last wgl regression

by Raphael

Resent resync patch with little correction Regards, Raphael On Thursday 15 December 2005 23:59, Raphael wrote: > Hi, > > Thix patch should fix last wgl patch regression > anyway i don't understand why ATI drivers don't support older GLX 1.3 specs > (as 1.4 is already here). > > For glXGetFBConfigs i don't plan to support a compatibility code, > it should be too buggy (on pixel format selection) as was older opengl code > as we can't query visuals > > Changelog: > - fix wgl regression: test glx server version and extensions to use (and > not use glXQueryDrawable on older glx implementations) > > Regards, > Raphael

Dec. 22, 2005