wine-devel November 2007

wine-devel@winehq.org

117 participants
275 discussions

Asking Valve for Steam Survey Results
by Scott Ritchie 24 Nov '07

24 Nov '07

Valve regularly runs surveys of steam users, where they profile many different things about the hardware. They're nice enough to publish the results: http://www.steampowered.com/status/survey.html Some of these provide a way to detect Wine users. Everyone using the "Wine waveout" audio driver, for instance, must be a Wine user. Unfortunately, valve lumps all of these into "other" on the survey results page. Worries about sampling bias aside (maybe Wine users are less likely to do the steam survey), if we had the raw data from Valve we could determine the actual percentage of Steam users playing through Wine. Looking at the data we do have, we may be able to make a good guess from examining the video card driver name field. Excluding NVidia, ATI, and Intel leaves just over 4% of respondents using an "other" video driver like the Wine one. If even only a quarter of these "others" are using Wine, that still gives us 1% of the entire 10 million+ Steam user base, translating into hundreds of thousands of users. Does anyone know whom we can contact at Valve for more specific results? Thanks, Scott Ritchie

5 6

AppDB and Bugzilla don't currently work...
by Lionel_Debroux 24 Nov '07

24 Nov '07

Hi, Both AppDB and Bugzilla currently complain about too many connections to the server: (AppDB) Warning: mysql_connect() [function.mysql-connect]: Too many connections in /home/winehq/opt/appdb/include/query.php on line 82 Warning: mysql_select_db(): supplied argument is not a valid MySQL-Link resource in /home/winehq/opt/appdb/include/query.php on line 83 Warning: mysql_real_escape_string() [function.mysql-real-escape-string]: Too many connections in /home/winehq/opt/appdb/include/query.php on line 116 Warning: mysql_real_escape_string() [function.mysql-real-escape-string]: A link to the server could not be established in /home/winehq/opt/appdb/include/query.php on line 116 Warning: mysql_connect() [function.mysql-connect]: Too many connections in /home/winehq/opt/appdb/include/query.php on line 14 Database error, please try again soon. (Bugzilla) Software error: Can't connect to the database. Error: Too many connections Is your database installed and up and running? Do you have the correct username and password selected in localconfig? For help, please send mail to the webmaster (bugs-admin(a)winehq.org), giving this error message and the time and date of the error. Regards, Lionel Debroux.

2 1

xlviewer install cmdline passed from CreateProcessA to msiexec looks wrong
by Darragh Bailey 24 Nov '07

24 Nov '07

OK, long time lurker, only recently decided to try my hand at coding for wine. Picked a bug 9628 and decided to have a bash. Bug occured because a patch to the msiexec command line parsing was reverted due to regressions in the xlviewer installer and other apps. I don't know about the other apps, I can't find a corresponding bug and only gleaned this bit of info from the changelog and in the cvs mailing list that tracks commits. http://www.winehq.org/pipermail/wine-cvs/2007-March/031339.html After some digging I found that problem was that with current git the command line being sent to msiexec when installing "RPG Maker" was missing the msiexec executable. So the msiexec command line parsing would result in "/i" as being the first element of the arguments array to be processed. The main loop, expected that msiexec should always be argv[0], and so will always start from the second element. Then comparing of what used to happen when msiexec used the call to CommandLineToArgvW suggested that use of CommandLineToArgvW was more correct given the main loop design. If the program name is absent as the first argument, msiexec would just get back an empty string as the first element and the arguments to msiexec would start at the second element. Since this appears more correct, I looked at the behaviour of xlviewer (free download from microsoft) installer, to see what the differences were. I had to add some extra traces to the start of the main function in msiexec to get an idea of what was going on. Basically they would just dump out the contents of argv, one per line, so that I could see what it was getting as the command line. Added the following to the top of the main function: for( i=0; i<argc; i++) { WINE_TRACE("bug 9628: argv[%d] = \"%s\"\n", i, argv[i]); } using the newly build wine tree, and just pointing wine at the exe. The command line msiexec would get on installing xlviewer was trace:msiexec:main bug 9628: argv[0] = "c:\windows\system32\msiexec.exe" trace:msiexec:main bug 9628: argv[1] = "/I" trace:msiexec:main bug 9628: argv[2] = "C:\windows\temp\IXP001.TMP\XLVIEW.MSI" trace:msiexec:main bug 9628: argv[3] = "CDCACHE=2" trace:msiexec:main bug 9628: argv[4] = "LAUNCHEDFROMSETUP=1" trace:msiexec:main bug 9628: argv[5] = "SETUPEXEPATH=C:\windows\temp\IXP001.TMP" SETUPEXENAME=SETUP.EXE /lpiwaeo C:\windows\temp\Microsoft" trace:msiexec:main bug 9628: argv[6] = "Office" trace:msiexec:main bug 9628: argv[7] = "Excel" trace:msiexec:main bug 9628: argv[8] = "Viewer" trace:msiexec:main bug 9628: argv[9] = "2003" trace:msiexec:main bug 9628: argv[10] = "Setup(0004)_Task(0001).txt CDCACHE=0 DWSETUPLOGFILE=C:\windows\temp\Microsoft" trace:msiexec:main bug 9628: argv[11] = "Office" trace:msiexec:main bug 9628: argv[12] = "Excel" trace:msiexec:main bug 9628: argv[13] = "Viewer" trace:msiexec:main bug 9628: argv[14] = "2003" trace:msiexec:main bug 9628: argv[15] = "Setup(0004).txt DWMSILOGFILE=C:\windows\temp\Microsoft" trace:msiexec:main bug 9628: argv[16] = "Office" trace:msiexec:main bug 9628: argv[17] = "Excel" trace:msiexec:main bug 9628: argv[18] = "Viewer" trace:msiexec:main bug 9628: argv[19] = "2003" trace:msiexec:main bug 9628: argv[20] = "Setup(0004)_Task(0001).txt" Now this looks wrong to me. It looks like there is a bug in how the command line is being passed to msiexec. The existing code that parses this command line, is in fact working around this bug. Adding +process to the WINEDEBUG variable I got to see what CreateProcessA was calling msiexec with[1]: L"\"c:\\windows\\system32\\msiexec.exe\" /I C:\\windows\\temp\\IXP008.TMP\\XLVIEW.MSI CDCACHE=\"2\" LAUNCHEDFROMSETUP=\"1\" SETUPEXEPATH=\"C:\\windows\\temp\\IXP008.TMP\\\" SETUPEXENAME=\"SETUP.EXE\" /lpiwaeo \"C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014)_Task(0001).txt\" CDCACHE=\"0\" DWSETUPLOGFILE=\"C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014).txt\" DWMSILOGFILE=\"C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014)_Task(0001).txt\"" 1. I also have to increase the debug str length in debug.c otherwise the end of the string would get dropped. Now when I run msiexec with the following command line msiexec /I C:\\windows\\temp\\IXP008.TMP\\XLVIEW.MSI CDCACHE="2" LAUNCHEDFROMSETUP="1" SETUPEXEPATH="C:\\windows\\temp\\IXP008.TMP\\" SETUPEXENAME="SETUP.EXE" /lpiwaeo "C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014)_Task(0001).txt" CDCACHE="0" DWSETUPLOGFILE="C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014).txt" DWMSILOGFILE="C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014)_Task(0001).txt" I see the following appear in the traces from msiexec: trace:msiexec:main bug 9628: argv[0] = "programs/msiexec/msiexec.exe.so" trace:msiexec:main bug 9628: argv[1] = "/I" trace:msiexec:main bug 9628: argv[2] = "C:\windows\temp\IXP002.TMP\XLVIEW.MSI" trace:msiexec:main bug 9628: argv[3] = "CDCACHE=2" trace:msiexec:main bug 9628: argv[4] = "LAUNCHEDFROMSETUP=1" trace:msiexec:main bug 9628: argv[5] = "SETUPEXEPATH=C:\windows\temp\IXP002.TMP\" trace:msiexec:main bug 9628: argv[6] = "SETUPEXENAME=SETUP.EXE" trace:msiexec:main bug 9628: argv[7] = "/lpiwaeo" trace:msiexec:main bug 9628: argv[8] = "C:\windows\temp\Microsoft Office Excel Viewer 2003 Setup(0003)_Task(0001).txt" trace:msiexec:main bug 9628: argv[9] = "CDCACHE=0" trace:msiexec:main bug 9628: argv[10] = "DWSETUPLOGFILE=C:\windows\temp\Microsoft Office Excel Viewer 2003 Setup(0003).txt" trace:msiexec:main bug 9628: argv[11] = "DWMSILOGFILE=C:\windows\temp\Microsoft Office Excel Viewer 2003 Setup(0003)_Task(0001).txt" Which seems bang on with what msiexec should be getting as its commandline arguments. In fact the only way I could pass in the command line to msiexec and get the same output near the top was with the following: msiexec /I C:\\windows\\temp\\IXP002.TMP\\XLVIEW.MSI CDCACHE="2" LAUNCHEDFROMSETUP="1" SETUPEXEPATH="C:\\windows\\temp\\IXP002.TMP\" SETUPEXENAME="SETUP.EXE" /lpiwaeo "C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup\(0003\)_Task\(0001\).txt" CDCACHE="0" DWSETUPLOGFILE="C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup\(0003\).txt" DWMSILOGFILE="C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup\(0003\)_Task\(0001\).txt"" Notice the difference between the following: SETUPEXEPATH="C:\\windows\\temp\\IXP008.TMP\\" = correct command line SETUPEXEPATH="C:\\windows\\temp\\IXP002.TMP\" = broken It seems to me that current command line parsing in msiexec is a hack to work around a bug somewhere between CreateProcessA and where the executable actually gets run, when you have a directory path ending in a slash and also enclosed by quotes. It appears that one of the double slashes at the end gets substituted before its time. So basically, I'm wondering if I'm actually on the right track here. Is this a bug in the behaviour of how the command line is sent to the new process? I've yet to log a bug since I'm still trying to understand what exactly is happening and if this is in fact a bug. At the moment I trying to work out how to get more information on what's happening to the commandline in the create_process function, so I've yet to work out why the command line is altered by the time it reaches the msiexec program. Any suggestions are welcome. :) -- Darragh "Nothing is foolproof to a sufficiently talented fool."

1 0

Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 4]
by Roderick Colenbrander 23 Nov '07

23 Nov '07

> This is an updated version of my previous patch for the same purpose. > > The proposed code now uses the WINE_D3DX_CAPABLE macros instead of DRI > module names for guessing the exact card model which is to be returned. > The patch also no longer includes manual addition of an entry to the > ChangeLog. Thanks to Roderick Colenbrander and Stefan Dösinger for the > suggestions. I have tested and confirmed that this patch fixes the bug > #7267 (http://bugs.winehq.org/show_bug.cgi?id=7267 ) to the same extent > as the previous version of the patch did. I think the code should be like this (in pseudo code) this way also other cards will at least be classified: case VENDOR_MESA: if(D3D9_CAPABLE(gl_info) if(strstr(gl_info->gl_renderer, "R300")) card = radeon_9500; else card = generic_nv_card; if(D3D8_CAPABLE(...) if(strstr(gl_info->gl_renderer, "R200")) card = ... Roderick -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

2 3

re: Start: Convert start to Unicode. [try7]
by Dan Kegel 23 Nov '07

23 Nov '07

Anatoly, thank you for working to fix "start" to work better for Unicode, I should have done that originally. But you seem to be having trouble getting the patch in, so here's what little advice I can give: If there is any difference between versions of your patch, you should describe it in the patch description. If there isn't, you should call it a resend, rather than a new try. - Dan

2 1

Driver-supported DirectX
by Remco 23 Nov '07

23 Nov '07

I don't know the first thing about driver- and DirectX-programming, so please forgive (and point out) any mistakes. As a reader of this list I'm wondering; there are quite a few problems that come from the fact that DirectX isn't 1:1 translatable to OpenGL. How about talking to some guys from the GPU-driver department about creating a driver-interface that gives you the right hooks. I guess Parallels and Transgaming would also be interested in such a development. I can imagine that the Nouveau-devs and Xorg-radeon-devs would be more than happy to listen. This goes beyond the scope of the Wine project I think. But since Wine has the higher level part of DirectX documented and implemented on top of OpenGL, wouldn't this be the place to start an independent library? Codeweavers has a lot of knowledge about Windows, DirectX and Linux. Only Microsoft itself would be a better choice, but I don't think they really care that much about Linux. ;) This would mean that DirectX would be as native to Linux and OSX (and friends) as it would be for Windows. It would be an actual reliable platform that could be used by game developers. It would de-Windows-ize DirectX. Maybe NVIDIA, ATI and Intel would also be interested. They could sell their expensive next-gen cards to those 5% that don't run Windows if games would actually be released for non-Windows OSes. Or are there really compelling technical reasons to wrap around OpenGL? I can think of the Compiz-issue. Similarly, Microsoft stated that they have to wrap OpenGL around DirectX on Windows, to be able to use both OpenGL and DirectX at the same time (for Aero). But I suspect that this implementation just developed naturally because messing with the drivers would be unthinkable way back when. Remco ____________________________________________________________________________________ Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs

5 6

Re: Start: Convert start to Unicode. [try5]
by Anatoly Lyutin 23 Nov '07

23 Nov '07

Alexandre Julliard wrote: > No, what you need is one function for errors that can happen in normal > usage (file not found, invalid option etc.) that is Unicode and > localized, and one function for internal errors (LoadString failures > etc.) that simply uses WINE_ERR with an English message. > > I send new version according your requirements to patches-lists. Have I made all correctly? -- Best regards Anatoly Lyutin.

1 0

Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 3]
by Roderick Colenbrander 23 Nov '07

23 Nov '07

> Presently, if an ATI card uses open-source DRI drivers from the Mesa > project ( http://dri.freedesktop.org/wiki/ATI ), Wine will report it to > Windows applications as being some generic nVIDIA model, based on D3D > capabilities of the card. > > This patch adds detection of the used ATI video card, based on Mesa DRI > module name, which is returned by drivers in GL Renderer string. In my > opinion, returning even an approximate ATI card model should be better, > than the present condition, disguising the ATI card as some equally > generic model from nVIDIA. Also, the patch adds detection of VENDOR_MESA > >from GL Renderer string, as Mesa DRI drivers may have various things as > GL Vendor, but the GL Renderer name always contains the string "Mesa". > This patch resolves the bug #7267, "Lineage 2 complains about outdated > NVIDIA drivers using ATI card with Mesa drivers" - > http://bugs.winehq.org/show_bug.cgi?id=7267 . The idea behind the whole code is that we detect a 'compatible' card based on the OpenGL capabilites. That stuff is done using the D3DX_CAPABLE() macros. The extension I check directly correspond to D3D functionality. In the end the result is further refind by checking the opengl renderer string. The reason why it is all done this way is because we need to detect the card based on OpenGL / GLX information and they don't export the pci id (which is good) but bad for D3D. Retrieving the real card name and so on from /proc or whatever isn't guaranteed to get good results and it also doesn't scale with remote X and if the system uses multiple videocards. It is very tricky. I would really ask you to use the D3DX_CAPABLE() macros as not using them can result in bad problems. E.g. a game assuming a certain d3d functionality is there while it isn't backed by any GL extension. The reason we default to Nvidia cards is that they are very generic and have quite solid drivers, so from an application point of view that is nice. Second games don't really need the exact GPU but they just use the info to get an impression of the features / performance. You can debate whether reporting Nvidia or ATI on totally different drivers matters (I would say no). So at least use the D3DX_CAPABLE macros as those are correct. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

2 2

Re: [msvcrt] short tty reads don't imply EOF
by Alexandre Julliard 23 Nov '07

23 Nov '07

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > Changelog: > * For ttys, short reads don't mean we're at the end of the file. That's not limited to ttys, other file types can have short reads too. -- Alexandre Julliard julliard(a)winehq.org

2 1

Ansi to Unicode
by luis.busquets＠ilidium.com 22 Nov '07

22 Nov '07

Is there any standard function in WINE to transform an Ansi string into a Unicode string? And the opposite?

3 2

← Newer
1
...
6
7
8
9
10
11
12
...
28
Older →

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 November 2007