Re: dlls/rstrtmgr: add stubs for RmGetList and RmRegisterResources
On 09/09/2010 07:41 AM, Austin English wrote: +@ stdcall RmGetList(long ptr ptr ptr) Hi Austin, This function has 5 parameters. -- Cheers, Paul.
Re: [2/7] urlmon/tests: Removed no longer needed todo_wine's
On 09/09/2010 02:46 AM, Thomas Mullaly wrote:
These todo's should have been removed as I implemented each of the
IUriBuilder_{Get/Set}* functions, but, I forgot about them.
Hi Thomas,
todo_wine's that succeed are marked as failures so that means these are
not fixed on (at least) AJ's box as otherwise previous patches would
have been rejected.
Judging by the test.winehq.org results there are only todo_wine's and no
failures on Wine.
--
Cheers,
Paul.
Keeping people from trying iTunes in Wine?
Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine. Should we let them bash their heads against the wall like that? Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.)
Re: Keeping people from trying iTunes in Wine?
You could also add Office 2010 to the list. :) Tom On Thu, Sep 9, 2010 at 3:59 PM, Dan Kegel d...@kegel.com wrote: Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine. Should we let them bash their heads against the wall like that? Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.) -- Wine is not a conclusion but a process...
Re: winedbg: Only add ContextFlags which are defined
André Hentschel n...@dawncrow.de wrote: CONTROL and INTEGER are standard defines, but ia64 and ARM don't define CONTEXT_FLOATING_POINT ia64 does define CONTEXT_FLOATING_POINT, ARM probably should also do. -- Dmitry.
Re: d3dx9_36: Implement D3DXCreateMesh and initial ID3DXMesh methods. (try 2)
On 9 September 2010 02:40, Misha Koshelev misha...@gmail.com wrote:
+while (count MAX_FVF_DECL_SIZE (count == 0 ||
declaration[count-1].Stream != 0xFF))
+{
+count++;
+}
+if (count 1)
+{
+vertex_size = declaration[count-2].Offset +
d3dx_decltype_size[declaration[count-2].Type];
+}
You may want to consider using D3DXGetDeclVertexSize() there.
Re: winedbg: Only add ContextFlags which are defined
Am 09.09.2010 11:07, schrieb Dmitry Timoshkov: André Hentschel n...@dawncrow.de wrote: CONTROL and INTEGER are standard defines, but ia64 and ARM don't define CONTEXT_FLOATING_POINT ia64 does define CONTEXT_FLOATING_POINT, ARM probably should also do. A standard ARM CPU doesn't has a FPU, so i guess that don't make sense. I didn't find that define for ia64, so maybe i have missed something, sry. -- Best Regards, André Hentschel
Re: winedbg: Only add ContextFlags which are defined
André Hentschel n...@dawncrow.de wrote: CONTROL and INTEGER are standard defines, but ia64 and ARM don't define CONTEXT_FLOATING_POINT ia64 does define CONTEXT_FLOATING_POINT, ARM probably should also do. A standard ARM CPU doesn't has a FPU, so i guess that don't make sense. Probably, but Wine is using float internally, and doesn't make any effort to avoid that. Defining CONTEXT_FLOATING_POINT to 0 on ARM is another solution. -- Dmitry.
Re: Keeping people from trying iTunes in Wine?
On 09/09/2010 12:59 AM, Dan Kegel wrote: Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine. Should we let them bash their heads against the wall like that? Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.) This would be relatively simple to implement, and would even be doable with a shell script outside of Wine. Just md5sum the .exe, compare it with a blacklist, pop the warning if so, and if not pass it to the normal Wine process. Thanks, Scott Ritchie
Re: msxml3/tests: add lastChild tests
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5160 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:6040: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:6040: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:6040: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154
Re: [2/7] urlmon/tests: Removed no longer needed todo_wine's
Hi Paul, On Thu, Sep 9, 2010 at 2:19 AM, Paul Vriens paul.vriens.w...@gmail.comwrote: todo_wine's that succeed are marked as failures so that means these are not fixed on (at least) AJ's box as otherwise previous patches would have been rejected. The reason they didn't show up as test succeeded failures on wine is because they weren't getting executed on wine. This is because IUriBuilder_GetIUri wasn't implemented which means it would skip those tests on wine. I implemented GetIUri in patch 5/7 of this set which would have caused a lot of test succeeded failures until the todo's were removed. So I decided (since removing the todo's just by themselves resulted in a lot of changes) to keep this patch separate from the 5/7 patch. Of course, if it's preferred, I can always merge the changes into patch 5/7 and resubmit this set. -- Thomas Mullaly thomas.mull...@gmail.com
Re: Keeping people from trying iTunes in Wine?
On Thu, 9 Sep 2010 00:59:32 -0700 Dan Kegel d...@kegel.com wrote: Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine. Should we let them bash their heads against the wall like that? Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.) Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds? I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive. -- Rosanne DiMesio dime...@earthlink.net
Re: Keeping people from trying iTunes in Wine?
On Thu, Sep 9, 2010 at 1:46 PM, Scott Ritchie sc...@open-vote.org wrote: This would be relatively simple to implement, and would even be doable with a shell script outside of Wine. Just md5sum the .exe, compare it with a blacklist, pop the warning if so, and if not pass it to the normal Wine process. Wouldn't it be better to read the manifest/version information from the exe (and maybe the installer too)? I think there are too many versions of the exe to make md5 sums practical. Also, maybe it should be a warning with an option to ignore it :) Octavian
Re: Keeping people from trying iTunes in Wine?
Rosanne DiMesio dime...@earthlink.net wrote: Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds? No, I just want to give them fair warning they're about to pound sand. The dialog would have a 'Never show this dialog again' checkbox, and buttons for 'Give Up' and 'Full Speed Ahead, Damn The Torpedoes'. I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive. You would then check the checkbox and click 'Geronimo'. - Dan
Re: Keeping people from trying iTunes in Wine?
Scott wrote: This would be relatively simple to implement, and would even be doable with a shell script outside of Wine. Just md5sum the .exe, compare it with a blacklist, pop the warning if so, and if not pass it to the normal Wine process. You'd probably want to sha1sum only the first megabyte or so, since getting the checksum of a gigabyte executable would really slow things down. And you might want to do it only for files that are doubleclicked on, i.e. in the desktop integration, rather than messing with the real wine. - Dan
Re: Keeping people from trying iTunes in Wine?
On 9 September 2010 15:53, Dan Kegel d...@kegel.com wrote: Scott wrote: This would be relatively simple to implement, and would even be doable with a shell script outside of Wine. Just md5sum the .exe, compare it with a blacklist, pop the warning if so, and if not pass it to the normal Wine process. You'd probably want to sha1sum only the first megabyte or so, since getting the checksum of a gigabyte executable would really slow things down. And you might want to do it only for files that are doubleclicked on, i.e. in the desktop integration, rather than messing with the real wine. - Dan I brought up a long time ago the idea of having something like this that checked the current rating in the appdb. So exe files are associated with the appdb entry and double-clicking would say something like: This Windows application is rated as Bronze and may not run correctly or something. Luke.
Re: Keeping people from trying iTunes in Wine?
On Thu, Sep 9, 2010 at 8:06 AM, Luke Benstead kaz...@gmail.com wrote: I brought up a long time ago the idea of having something like this that checked the current rating in the appdb. So exe files are associated with the appdb entry and double-clicking would say something like: This Windows application is rated as Bronze and may not run correctly or something. Yeah... well, it's hard to do this right, so it might only be worth doing it for the apps that cause the most grumbling about Wine on the web. - Dan
Re: Keeping people from trying iTunes in Wine?
On Thu, Sep 9, 2010 at 8:34 AM, Rosanne DiMesio dime...@earthlink.net wrote: On Thu, 9 Sep 2010 00:59:32 -0700 Dan Kegel d...@kegel.com wrote: Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine. Should we let them bash their heads against the wall like that? Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.) Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds? I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive. Agreed. Wine doesn't make efforts to babysit users for most other things, I don't see why this should be any different. Also consider that if such a workaround were to go into wine, that code may long outlive the 'affected apps', and the list would quickly grow out of date. I suppose if a packager wanted to do something like this for their distro I wouldn't complain too much, unless users started asking about it in #winehq/the forums. But this _should not_ go into vanilla wine. -- -Austin
Re: Console issues in recent git
Eric, When running a program with r in winedbg, I get: fixme:winedbg:dbg_run_debuggee Re-running current program with \r as args is broken Does this have anything to do with the EOL conversion issues? J. Leclanche On Wed, Sep 8, 2010 at 9:32 PM, Reece Dunn mscl...@googlemail.com wrote: On 8 September 2010 21:04, Eric Pouech eric.pou...@orange.fr wrote: does the attached patch help with some of the concerns ? I/ it should allow typing in the console (for all GUI programs) and still see output get buffer when the programs exits II/ reduce the number of cases where the console is in raw mode after wine exits Not all the cases are supposed to be fixed. For example, this is one example of what still doesn't work but in this case, the first program is killed at the same time as winedbg exits, which shouldn't the case) what shall remain not fixed is the case where: - pgm A is started from shell command line - pgm A spawns child B - B is a CUI and tries to interact with the console by reading the input - A dies I still sometimes see it when exiting winedbg after it has been launched upon a fault in a running program... but, something goes wrong here as quitting winedbg (B) shouldn't kill the program beeing debugged (A) what's not yet fixed : - regression in EOF management This fixes the issue with StarCraft 2. Thanks for looking into this, - Reece
Re: Keeping people from trying iTunes in Wine?
On Thu, Sep 9, 2010 at 5:47 PM, Austin English austinengl...@gmail.com wrote: On Thu, Sep 9, 2010 at 8:34 AM, Rosanne DiMesio dime...@earthlink.net wrote: On Thu, 9 Sep 2010 00:59:32 -0700 Dan Kegel d...@kegel.com wrote: Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine. Should we let them bash their heads against the wall like that? Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.) Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds? I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive. Agreed. Wine doesn't make efforts to babysit users for most other things, I don't see why this should be any different. Also consider that if such a workaround were to go into wine, that code may long outlive the 'affected apps', and the list would quickly grow out of date. I suppose if a packager wanted to do something like this for their distro I wouldn't complain too much, unless users started asking about it in #winehq/the forums. But this _should not_ go into vanilla wine. -- -Austin The dialog could suggest upgrading Wine, that would prevent the affected app list from getting out of date. Damjan
Re: user32: Update Italian translation
On 09/09/2010 04:09 PM, Luca Bennati wrote: Hi Luca, You need to add the UTF-8 pragma: Warning: string Sì seems to be UTF-8 but codepage 1252 is in use. Warning: string Più finestre... seems to be UTF-8 but codepage 1252 is in use. -- Cheers, Paul.
dogfood report: Safari runs youtube, firefox doesn't
So I wanted to quickly try youtube in wine to verify sound was working. I think I used to use Firefox for this, so I did sh winetricks firefox flash and fired it up... but it hung. (And it even hung my desktop once; had to use CTL ALT F1, kill firefox, and ALT F7 to recover. It must have hung while holding an X grab, that mysterious problem described in http://bugs.winehq.org/show_bug.cgi?id=23439#c7 ) Sad face. Happily, sh winetricks safari got me a working browser that can do youtube just fine.
Re: dogfood report: Safari runs youtube, firefox doesn't
On 9 September 2010 19:29, Dan Kegel d...@kegel.com wrote: So I wanted to quickly try youtube in wine to verify sound was working. I think I used to use Firefox for this, so I did sh winetricks firefox flash and fired it up... but it hung. (And it even hung my desktop once; had to use CTL ALT F1, kill firefox, and ALT F7 to recover. It must have hung while holding an X grab, that mysterious problem described in http://bugs.winehq.org/show_bug.cgi?id=23439#c7 ) Sad face. Happily, sh winetricks safari got me a working browser that can do youtube just fine. What version of Firefox? Is it a version with out-of-process plugin support? - Reece
Re: dogfood report: Safari runs youtube, firefox doesn't
Dan Kegel dank at kegel.com writes: So I wanted to quickly try youtube in wine to verify sound was working. I think I used to use Firefox for this, so I did sh winetricks firefox flash This is a regression, this used to work a couple of months/ 1 year (?) ago, but it hangs. If someone with a fast computer is bored, plz carry out regression test. (My computer is really getting too slow for this as wine's amount of codelines is growing and growing)
Re: fusion:asmname Improve parse_display_name
Alexandre Goujon ale.gou...@gmail.com writes: @@ -522,8 +522,18 @@ static HRESULT parse_display_name(IAssemblyNameImpl *name, LPCWSTR szAssemblyNam if (!str) return E_OUTOFMEMORY; -ptr = strstrW(str, separator); -if (ptr) *ptr = '\0'; +ptr = strchrW(str, ','); + +if(ptr *ptr != ' ') +*ptr = '\0'; It's unlikely that you would get a space here... -- Alexandre Julliard julli...@winehq.org
Re: msxml3: Implement property SelectionNamespaces for XPath
Adam Martinson amartin...@codeweavers.com writes: +extern inline const struct list* nsList_from_xmlDocPtr(xmlDocPtr doc); Declaring an extern function inline doesn't make much sense. Also it would be more generally useful if it didn't return a const pointer. -- Alexandre Julliard julli...@winehq.org
Re: Console issues in recent git
Le 09/09/2010 18:13, Jerome Leclanche a écrit : Eric, When running a program with r in winedbg, I get: fixme:winedbg:dbg_run_debuggee Re-running current program with \r as args is broken Does this have anything to do with the EOL conversion issues? no, it has been broken for years (if you really used 'r' or 'r foo bar' as command in winedbg) A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Keeping people from trying iTunes in Wine?
On Thu, Sep 9, 2010 at 6:12 PM, Damjan Jovanovic damjan@gmail.com wrote: On Thu, Sep 9, 2010 at 5:47 PM, Austin English austinengl...@gmail.com wrote: On Thu, Sep 9, 2010 at 8:34 AM, Rosanne DiMesio dime...@earthlink.net wrote: On Thu, 9 Sep 2010 00:59:32 -0700 Dan Kegel d...@kegel.com wrote: Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine. Should we let them bash their heads against the wall like that? Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.) Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds? I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive. Agreed. Wine doesn't make efforts to babysit users for most other things, I don't see why this should be any different. Also consider that if such a workaround were to go into wine, that code may long outlive the 'affected apps', and the list would quickly grow out of date. I suppose if a packager wanted to do something like this for their distro I wouldn't complain too much, unless users started asking about it in #winehq/the forums. But this _should not_ go into vanilla wine. -- -Austin The dialog could suggest upgrading Wine, that would prevent the affected app list from getting out of date. Damjan If we would want any application database stuff, perhaps appdb would be the place to store information like this. There should come some way to extract this information to an XML file or whatever format periodically. It could be packaged with a wine build or optionally downloaded when you run Wine or so. Roderick
Re: Keeping people from trying iTunes in Wine?
Perhaps making a hash based on app name and version in the appdb, and then have wine reading the hash from the app to check against the appdb. If anyone uses Fedora, their ABRT tool generates hashes for different bugs and then searches their bugzilla before submitting the crash dump, to find if a report is already generated. If the report is already in bugz, then it appends to that bug.We could do something similar, but check against the appdb, and notify the user.. Maybe there could be a separate builtin app (like notepad and explorer) to read the appdb and check ratings, and allow access to the appdb without having to fire up the web browser? Thanks Tom On Thu, Sep 9, 2010 at 2:15 PM, Roderick Colenbrander thunderbir...@gmail.com wrote: On Thu, Sep 9, 2010 at 6:12 PM, Damjan Jovanovic damjan@gmail.com wrote: On Thu, Sep 9, 2010 at 5:47 PM, Austin English austinengl...@gmail.com wrote: On Thu, Sep 9, 2010 at 8:34 AM, Rosanne DiMesio dime...@earthlink.net wrote: On Thu, 9 Sep 2010 00:59:32 -0700 Dan Kegel d...@kegel.com wrote: Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine. Should we let them bash their heads against the wall like that? Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.) Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds? I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive. Agreed. Wine doesn't make efforts to babysit users for most other things, I don't see why this should be any different. Also consider that if such a workaround were to go into wine, that code may long outlive the 'affected apps', and the list would quickly grow out of date. I suppose if a packager wanted to do something like this for their distro I wouldn't complain too much, unless users started asking about it in #winehq/the forums. But this _should not_ go into vanilla wine. -- -Austin The dialog could suggest upgrading Wine, that would prevent the affected app list from getting out of date. Damjan If we would want any application database stuff, perhaps appdb would be the place to store information like this. There should come some way to extract this information to an XML file or whatever format periodically. It could be packaged with a wine build or optionally downloaded when you run Wine or so. Roderick
Re: winedbg: Only add ContextFlags which are defined
Am 09.09.2010 12:34, schrieb Dmitry Timoshkov: André Hentschel n...@dawncrow.de wrote: CONTROL and INTEGER are standard defines, but ia64 and ARM don't define CONTEXT_FLOATING_POINT ia64 does define CONTEXT_FLOATING_POINT, ARM probably should also do. A standard ARM CPU doesn't has a FPU, so i guess that don't make sense. Probably, but Wine is using float internally, and doesn't make any effort to avoid that. Defining CONTEXT_FLOATING_POINT to 0 on ARM is another solution. Just found the function get_server_context_flags in ntdll where the same as in my patch is done... -- Best Regards, André Hentschel
Re: dogfood report: Safari runs youtube, firefox doesn't
On Thu, Sep 9, 2010 at 11:39 AM, Reece Dunn mscl...@googlemail.com wrote: sh winetricks firefox flash and fired it up... but it hung. (And it even hung my desktop once; had to use CTL ALT F1, kill firefox, and ALT F7 to recover. It must have hung while holding an X grab, that mysterious problem described in http://bugs.winehq.org/show_bug.cgi?id=23439#c7 ) Sad face. What version of Firefox? winetricks uses firefox 3.6.6 at the moment. Is it a version with out-of-process plugin support? Yes, that started in 3.6.4. - Dan
