So, you want to fix typos?
I see somebody's posting a few fix-typo-in-comments patches, e.g. http://www.winehq.org/pipermail/wine-patches/2007-December/048099.html http://www.winehq.org/pipermail/wine-patches/2007-December/048101.html That reminds me that I worked out some time ago how to find such typos efficiently. At the risk of encouraging lots of silly typo-fixing patches, I've documented the process here: http://kegel.com/wine/spellingpolice/ For instance, to find typos in comments in shell32, you can do: sudo apt-get install ispell wget http://kegel.com/wine/spellingpolice/stop.txt wget http://kegel.com/wine/spellingpolice/lspell-pl.txt -O lspell.pl perl lspell.pl stop.txt ~/wine-git/dlls/shell32/*.[ch] This outputs: /home/dank/wine-git/dlls/shell32/autocomplete.c: 1 dispays /home/dank/wine-git/dlls/shell32/brsfolder.c: 1 relativ /home/dank/wine-git/dlls/shell32/dataobject.c: 1 droping /home/dank/wine-git/dlls/shell32/iconcache.c: 1 resoure /home/dank/wine-git/dlls/shell32/pidl.c: 1 relativ /home/dank/wine-git/dlls/shell32/pidl.h: 1 desribes /home/dank/wine-git/dlls/shell32/shell.c: 1 incidently /home/dank/wine-git/dlls/shell32/shfldr_fs.c: 1 spezified /home/dank/wine-git/dlls/shell32/shfldr_unixfs.c: 4 appart relativ savely should'nt /home/dank/wine-git/dlls/shell32/shlexec.c: 1 foward /home/dank/wine-git/dlls/shell32/shlfileop.c: 2 ERRROR INVLID /home/dank/wine-git/dlls/shell32/shlfolder.c: 1 whitch /home/dank/wine-git/dlls/shell32/shlview.c: 2 buily provied /home/dank/wine-git/dlls/shell32/trash.c: 1 DESCRITION
Re: What happened to the videos from WineConf?
"H. Verbeet" <[EMAIL PROTECTED]> wrote: > > The videos have been processed and encoded, but we ran into problems > > getting them on youtube. I've found the right person to talk to > > about this, so hopefully they'll get the videos online in the next > > couple weeks. > > FWIW, personally I don't care much for youtube. Just having an .ogg we > can download somewhere would be enough for me. Maybe the full-res Theora videos can be published as torrents on a strictly legal tracker like legittorrents.info? Alternatively, WineHQ.org could host a tracker. This can be useful for bandwidth-reduction on all downloads from WineHQ.org. Remco Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
appdb new version submission form has awkward radio buttons
When submitting a new version, clicking the radio button next to "Request being a maintainer for this version, allowing you to edit it later" or "Monitor changes to this version, also after it has been accepted" can't be undone. There should be a way to get back to the state of no button clicked. Perhaps those should be checkboxes instead.
appdb license choices unclear
Has anybody else been confused by this? When submitting an app to the appdb, I'm often flummoxed by what to put in the license field. I'm usually looking for something that means "Closed source, free to download, but not redistributable" (like e.g. http://labs.adobe.com/misc/terms_of_use.html ) but the only choices are: Retail, Open Source, Freeware, Demo, Shareware. "Freeware" might be the closest of the bunch, but it implies GPL or at least the ability to redistribute binaries (i.e. the other meaning of the word Free). Is there a way to make this clearer? Maybe "nonredistributable freeware"? - Dan
Re: splitting out on_winver_change() and friends
On Dec 29, 2007 5:13 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > Yes. I want to do it right. Should I start working in that direction? I'd like to hear Alexandre's comments for my suggestions. The current application override system bothers me but maybe he has other ideas or I am missing something. The entire system seems to depend too much on the applications name which seems limited to me but maybe he has ideas for a more robust way of tracking dlloverrides and version settings when the application name conflicts. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: splitting out on_winver_change() and friends
On Sat, Dec 29, 2007 at 11:23:11AM -0500, Steven Edwards wrote: > On Dec 29, 2007 10:45 AM, Robert Millan <[EMAIL PROTECTED]> wrote: > > I'd like to avoid duplication if possible. > > Also as a follow-up again, you can also just hack Dan's winetricks > script for your needs as it does the winversion magic with the > registry I was talking about. I looked at this before, and the winversion magic in that script seems to be just a minor part of what winecfg does. > I think doing that would be a hack and > if you want to properly fix the problem (if I understand what you need > correctly) is to enhance the entire application default override > system like I described in the last email. Yes. I want to do it right. Should I start working in that direction? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.)
RtlpWaitForCriticalSection
I got a game (Need for speed III) that has been reported to work by others. On my computer, though, the game hangs at different places about 50% of the time. I compiled Wine 0.9.51 from source on a Slackware 12.0 dual core Athlon, and although I'm sure most people this days buy at least that kind of computer, maybe that was not true when the reports came out. What I'm thinking is that this is a race condition brought out because of the two cores. I think that because if I run inside gdb I catch a SIGTERM going to a thread that then exits. Another thread then prints the: err:ntdll:RtlpWaitForCriticalSection section ... wait timed out in thread ..., blocked by , retrying (60 sec) I see three ways to fix this problem: - When a thread dies, release the locks it has. Of course this wouldn't be compatible with windows, but perhaps a command line option could activate that code. In any case I could try something like that for this game in particular. I'm looking for some pointers on where should I start looking. - Looking into why the thread is getting a SIGTERM in the first place. Perhaps there is a way to delay the signal from being sent in a reasonable way? Who would be sending it? - Run the game in a single core (setting the affinity?) It just occur to me that I should be able to set the affinity on a bash shell and then start wine from there. I'll try that.
Re: splitting out on_winver_change() and friends
On Sat, Dec 29, 2007 at 08:51:26PM +0100, Roderick Colenbrander wrote: > > The system on windows doesn't use the md5sum (I think it has one) but it > looks for the product ID which is burried into most executables first. It > also checks for other things but in a hackier way. As there are a lot of > different versions of a program but which all need the same override. I think it's a bad idea to do that: - Product IDs may not necessarily be unique identifiers for every given program. Hashes are. - It's easier for users to submit information about their apps if they can use tools they're familiar with such as md5sum / sha1sum. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.)
Re: splitting out on_winver_change() and friends
On Sat, Dec 29, 2007 at 11:18:26AM -0500, Steven Edwards wrote: > > you would have something like > > HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\Version win98 > HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\filename > setup.exe > > HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\Version > win2000 > HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\filename > setup.exe Sounds good. It could also be a good idea to have some mechanism so that multiple hashes can point to the same description / setup. Think of the same versioning problem shared by a dozen of different localised versions of an app, etc. How about something like: HKCU\Software\Wine\AppDefaults\md5\b83fd2e8b34ba6b6f59e9f9cfbe129d9 foomatic_installer HKCU\Software\Wine\AppDefaults\md5\912672566150fd7663fba3a927f79fca foomatic_installer [ ... ] HKCU\Software\Wine\AppDefaults\foomatic_installer\Version win98 HKCU\Software\Wine\AppDefaults\foomatic_installer\filename setup.exe (as a bonus, this gives us a short description of what these hashes are referring to) -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.)
Re: icmp states I need to be running wine as root
* On Sun, 21 Oct 2007, Juan Lang wrote: > > > Isn't there another way to do this than with SOCK_RAW, or having to > > run wine as root? > > In answer to your second question: yes, modify the Linux kernel not > to have such restrictions. Well, there are already patches which modifies it in one way or another. I refer to "man 7 capabilities" or web resources [1]-[3]. Some of approaches may be abandoned already, but I see recent discussion [4] on this and by [5] I judge SELinux already can handle this task. Plus, I have found some recently updated tool called "Filesystem capabilities for linux" which also is not POSIX compatible (and so were old capabilities implementation for linux kernel): | With this patch, you will be able to grant selective privileges to | executables on a needed basis. This means for some executables, there is | no need anymore to run as root or as a suid root binary. | | For example, you may drop the SUID bit from ping and grant the | CAP_NET_RAW capability: | | # chmod u-s /bin/ping | # chcap cap_net_raw=ep /bin/ping If this is acceptable solution, then it probably would be nice for Wine to have separate binary for every needed capability. CAP_NET_RAW (for ICMP), CAP_SYS_RAWIO (for IO ports) and CAP_SYS_NICE (for threads priority) comes to mind. This plan is to don't force users to give the bunch of capabilities to the main Wine binary (or even several of them) at once (so the security risk should be increased in a minimal way). But well, that could be a minor nuance for such users. [1] http://www.securityfocus.com/infocus/1400 [2] http://lwn.net/Articles/79185/ [3] http://lwn.net/Articles/199004/ [4] http://lkml.org/lkml/2006/9/18/100 [5] http://lwn.net/Articles/79208/ [6] http://www.olafdietsche.de/linux/capability/
Re: COM/DCOM of WINE
On Sat, Dec 29, 2007 at 09:26:47PM +0200, Saulius Krasuckas wrote: > ... > > If something will not work for you please fill a bug report at > > http://bugs.winehq.org . In case if builtin DCOM support doesn't work as > > expected you can run "winetricks dcom98" to use native DCOM instead (you > > can download winetricks at http://kegel.com/wine/winetricks ). If this > > workaround helps you should mention this in your bug report as well. > > IANAL, but for being legal this way requires a user to have valid Windows > Licence (or so). One of at least Win98, AFAIK. AFAIK copyright only governs copying/distribution. You may need a license to redistribute MS-DCOM, but since it's Microsoft itself who distributes it in their website I don't think they have a basis to claim damages. (IANAL, either) -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.)
Re: splitting out on_winver_change() and friends
> On Dec 29, 2007 10:45 AM, Robert Millan <[EMAIL PROTECTED]> wrote: > > I was thinking in doing something like this already, but you still need > a > > way to set winver, so it boils down to either sharing code with winecfg > or > > duplicating it. > > > > I'd like to avoid duplication if possible. > > I am not sure where the global winver is set but I am sure its still > in the registry so you can change it with a registry key as Julliard > said. For just running per-application all you need to do is set it as > HKCU\Software\Wine\AppDefaults\foo.exe\Version which is a string > resource, again this can be done via a reg file that regedit can > import. Thats even less complicated then then inf route I suggested. > > Do you mean you have a situation like a broken application AND > installer that only works under win98 but the default version is > win2000? Maybe you only want that installer to run in win98 mode but > the rest of wine to run in win2000 mode? Wine used to have the -winver > option I think and CrossOver has this setting but I can't see anyway > to set the windows version on the command line for a buggy installer. > The solution (which I also think kind of sucks) would be to do > something like script > > wine regedit add-setup.exe-version.reg > wine setup.exe > wine regedit remove-setup.exe-version.reg > wine regedit add-foo.exe-version.reg > wine foo.exe > > Of course steps 3 and 4 could be combined in one registry file and 1 > and 3 would not even be needed if you could set the version on the > command line but we don't seem to support that anymore for quite a > long time. I think the solution to have multiple appdefaults with > programs having generic names like setup.exe and install.exe is to > enhance the support in wine and winecfg application/dlloverrides to > use md5sum/sha hashes. I don't know how julliard really feels about > this but this is similar to what was discussed with having a custom > Wine shim engine for application compatibly. If you were going to > change some code and he approves I think this is the route to go. > > So say rather than having > > HKCU\Software\Wine\AppDefaults\setup.exe\Version win98 > > you would have something like > > HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\Version > win98 > HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\filename > setup.exe > > HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\Version > win2000 > HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\filename > setup.exe > > This way two installers both named setup.exe can have their own > windows version and dlloverrides set. > > Thanks > Steven > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > The system on windows doesn't use the md5sum (I think it has one) but it looks for the product ID which is burried into most executables first. It also checks for other things but in a hackier way. As there are a lot of different versions of a program but which all need the same override. 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
Re: [1/3] WineD3D: Fix a problem in BltOverride
I don't have this game, so I can't check myself, but I think that the reason of slowdown may be not only that a err message is printed, but also because it exists with error, and that means it will have to do slower, software blit. But in older versions in this situation it would try hardware accelerated blit, I think. Can you try commenting or removing the line with ERR() to check? It's wine/dlls/wined3d/surface.c:2976. If the game is still slower than it used to be, another thing you can try is also comment/remove 'return ...' statement just after that ERR and see what happens. After more careful look at that code, it looks to me both ERR and return there may be a mistake, because it causes regular texture -> render target blits not to happen in hardware, but it will be safer if you test first if it works at all without these lines :). Maxime Bellengé wrote: > Hi, > > Yes the problem is fixed with this patch although I have millions > traces like this one : > > err:d3d_surface:IWineD3DSurfaceImpl_BltOverride Unexpected render target > -> render target blit > > It makes the game slow whereas before wine 0.9.51 if I remember exactly, > the game was fast without this message. Maybe this trace should be made > a warn instead of en error ?
Re: bug 9986
* On Fri, 26 Oct 2007, Damjan Jovanovic wrote: > * On 10/26/07, Reece Dunn wrote: > > * On 25/10/2007, Juan Lang wrote: > > > > > > > Tests would also be useful here as well, so that there is not a > > > > regression. > > > > > > That's good general advice, but hard to implement without a serial > > > device to test against, which our test systems won't have. > > > > You could always skip the tests when a serial connection is not > > present. That way, you get coverage on systems that do have them. It > > should be possible to configure Virtual Machines that have serial > > ports suitable for use in these tests. ... > You can emulate a serial port, but that requires kernel-mode drivers > in at least Windows, and emulating hardware that plugs into the > emulated port isn't much easier. Yes, but this is possible. I believe, the ideal state would be when MinGW support for compiling device drivers + Wine support for running KMD is good enough. It probably should be a separate software project, though, as it will require very specific driver coding and testing-on-Windows manpower. No?
Re: COM/DCOM of WINE
* On Thu, 25 Oct 2007, L. Rahyen wrote: > * On Thursday October 25 2007 08:08, Fong, Man To wrote: > > > > > The communication protocol, pre-defined by TCS manufacturing, is > > > DCOM. Since the communication protocol is not opened by the > > > manufacturer. We must install the API provided by the manufacturer > > > on our workstation running on Linux. Does WINE support the DCOM > > > function? ... > If something will not work for you please fill a bug report at > http://bugs.winehq.org . In case if builtin DCOM support doesn't work as > expected you can run "winetricks dcom98" to use native DCOM instead (you > can download winetricks at http://kegel.com/wine/winetricks ). If this > workaround helps you should mention this in your bug report as well. IANAL, but for being legal this way requires a user to have valid Windows Licence (or so). One of at least Win98, AFAIK.
Re: What happened to the videos from WineConf?
On 28/12/2007, Lei Zhang <[EMAIL PROTECTED]> wrote: > On Dec 28, 2007 8:54 AM, Maarten Lankhorst <[EMAIL PROTECTED]> wrote: > > I remember at wineconf there were some videos created, what happened > > with those? I tried to look on youtube for wineconf, but I didn't find > > anything. Are they online yet? Or will they be put online? > > > > -Maarten > > > > The videos have been processed and encoded, but we ran into problems > getting them on youtube. I've found the right person to talk to about > this, so hopefully they'll get the videos online in the next couple > weeks. > FWIW, personally I don't care much for youtube. Just having an .ogg we can download somewhere would be enough for me. Related to this subject, what happened to the group foto? I don't think it was posted to winehq like last year.
err:ntdll:RtlpWaitForCriticalSection blocked
Hi, i still try since more than two years to bring up the old windows 95 game "pitfall: the mayan adventure". The games runs well without sound, but if i try to enable the sound a small sound chuck will be played and the games freeze with the message: err:ntdll:RtlpWaitForCriticalSection section 0x20017c90 "?" wait timed out in thread 0009, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x20017c90 "?" wait timed out in thread 000e, blocked by 000f, retrying (60 sec) All Wine Versions since the last two years have the same effect, included the newest 0.9.52. Any idea? Thanx for helping me... Stefani
Re: .NET apps with mono... some testing.
Le Saturday 29 December 2007 16:55:28 Jérôme Gardou, vous avez écrit : > Le Saturday 29 December 2007 16:43:45 Maarten Lankhorst, vous avez écrit : > > Jérôme Gardou schreef: > > > Many .NET/C# apps don't work with the combination wine-mono. > > > > > > I've discovered that installing the arial32 from msttcorefonts solves a > > > lot of problems, especially with graphical apps. > > > > > > I've tested a few apps (supreme commander patches, fastmd5 (tested here > > > http://bugs.winehq.org/show_bug.cgi?id=10467 with native .NET...) and > > > all of them worked quite well, although not quite beautiful. > > > > Which mono version did you use? > > mono-1.2.6 with gtksharp 2.10.2 . the latest available on mono website. > > I'm trying to figure out why font rendering is so bad on gtk# applications. > (try gtk theme manager... it's awful) > > Some more feedback here. Changing the key HKEY_CURRENT_CONFIG\Software\Fonts\LogPixels from 96 to 2 changes everything. From enormous characters in gtk# programs, there is now a good size in those apps. Obviously, this is not the good way to get it working. ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Re: splitting out on_winver_change() and friends
On Dec 29, 2007 10:45 AM, Robert Millan <[EMAIL PROTECTED]> wrote: > I'd like to avoid duplication if possible. Also as a follow-up again, you can also just hack Dan's winetricks script for your needs as it does the winversion magic with the registry I was talking about. I think doing that would be a hack and if you want to properly fix the problem (if I understand what you need correctly) is to enhance the entire application default override system like I described in the last email. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: splitting out on_winver_change() and friends
On Dec 29, 2007 10:45 AM, Robert Millan <[EMAIL PROTECTED]> wrote: > I was thinking in doing something like this already, but you still need a > way to set winver, so it boils down to either sharing code with winecfg or > duplicating it. > > I'd like to avoid duplication if possible. I am not sure where the global winver is set but I am sure its still in the registry so you can change it with a registry key as Julliard said. For just running per-application all you need to do is set it as HKCU\Software\Wine\AppDefaults\foo.exe\Version which is a string resource, again this can be done via a reg file that regedit can import. Thats even less complicated then then inf route I suggested. Do you mean you have a situation like a broken application AND installer that only works under win98 but the default version is win2000? Maybe you only want that installer to run in win98 mode but the rest of wine to run in win2000 mode? Wine used to have the -winver option I think and CrossOver has this setting but I can't see anyway to set the windows version on the command line for a buggy installer. The solution (which I also think kind of sucks) would be to do something like script wine regedit add-setup.exe-version.reg wine setup.exe wine regedit remove-setup.exe-version.reg wine regedit add-foo.exe-version.reg wine foo.exe Of course steps 3 and 4 could be combined in one registry file and 1 and 3 would not even be needed if you could set the version on the command line but we don't seem to support that anymore for quite a long time. I think the solution to have multiple appdefaults with programs having generic names like setup.exe and install.exe is to enhance the support in wine and winecfg application/dlloverrides to use md5sum/sha hashes. I don't know how julliard really feels about this but this is similar to what was discussed with having a custom Wine shim engine for application compatibly. If you were going to change some code and he approves I think this is the route to go. So say rather than having HKCU\Software\Wine\AppDefaults\setup.exe\Version win98 you would have something like HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\Version win98 HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\filename setup.exe HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\Version win2000 HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\filename setup.exe This way two installers both named setup.exe can have their own windows version and dlloverrides set. Thanks Steven -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Where are the bugzilla admins?
Where did our buzilla admins go? 3 weeks and nothing is changing! Vitaliy.
Re: .NET apps with mono... some testing.
Le Saturday 29 December 2007 16:43:45 Maarten Lankhorst, vous avez écrit : > Jérôme Gardou schreef: > > Many .NET/C# apps don't work with the combination wine-mono. > > > > I've discovered that installing the arial32 from msttcorefonts solves a > > lot of problems, especially with graphical apps. > > > > I've tested a few apps (supreme commander patches, fastmd5 (tested here > > http://bugs.winehq.org/show_bug.cgi?id=10467 with native .NET...) and all > > of them worked quite well, although not quite beautiful. > > Which mono version did you use? mono-1.2.6 with gtksharp 2.10.2 . the latest available on mono website. I'm trying to figure out why font rendering is so bad on gtk# applications. (try gtk theme manager... it's awful) ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Re: splitting out on_winver_change() and friends
On Fri, Dec 28, 2007 at 05:49:39AM -0500, Steven Edwards wrote: > On Dec 28, 2007 5:43 AM, Steven Edwards <[EMAIL PROTECTED]> wrote: > > How about rather than writing another application to do this, you make > > winecfg take arguments on the command line so you could set something > > like > > > > winecfg foo.exe --winver win98 --dll=gdiplus.dll=n > > > > Then all you need is a script for your known bad applications > > Actually, another way you could do it is to use inf files and store > them in a database. We discussed something like this for the appdb. > Using inf's would be a cleaner method than hacking winecfg to automate > importing this data in to the registry and then everyone can use it. > I'd suggest if you know of an application thats buggy, needs the > version and dll information hard set, you try the inf route and submit > it to appdb if its an application listed there. I was thinking in doing something like this already, but you still need a way to set winver, so it boils down to either sharing code with winecfg or duplicating it. I'd like to avoid duplication if possible. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.)
Re: .NET apps with mono... some testing.
Jérôme Gardou schreef: > Many .NET/C# apps don't work with the combination wine-mono. > > I've discovered that installing the arial32 from msttcorefonts solves a lot > of > problems, especially with graphical apps. > > I've tested a few apps (supreme commander patches, fastmd5 (tested here > http://bugs.winehq.org/show_bug.cgi?id=10467 with native .NET...) and all of > them worked quite well, although not quite beautiful. > Which mono version did you use?
.NET apps with mono... some testing.
Many .NET/C# apps don't work with the combination wine-mono. I've discovered that installing the arial32 from msttcorefonts solves a lot of problems, especially with graphical apps. I've tested a few apps (supreme commander patches, fastmd5 (tested here http://bugs.winehq.org/show_bug.cgi?id=10467 with native .NET...) and all of them worked quite well, although not quite beautiful. ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Re: splitting out on_winver_change() and friends
On Sat, Dec 29, 2007 at 01:04:50PM +0100, Alexandre Julliard wrote: > Robert Millan <[EMAIL PROTECTED]> writes: > > > On Fri, Dec 28, 2007 at 05:43:40AM -0500, Steven Edwards wrote: > >> How about rather than writing another application to do this, you make > >> winecfg take arguments on the command line so you could set something > >> like > >> > >> winecfg foo.exe --winver win98 --dll=gdiplus.dll=n > > > > Yes, I suppose that'll do. Want a patch for --winver ? > > It's only a matter of setting a registry key, that can be done easily by > calling regedit, there's no need to involve winecfg. Looking at winecfg/appdefaults.c, there seems to be several keys involved. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.)
Re: splitting out on_winver_change() and friends
Robert Millan <[EMAIL PROTECTED]> writes: > On Fri, Dec 28, 2007 at 05:43:40AM -0500, Steven Edwards wrote: >> How about rather than writing another application to do this, you make >> winecfg take arguments on the command line so you could set something >> like >> >> winecfg foo.exe --winver win98 --dll=gdiplus.dll=n > > Yes, I suppose that'll do. Want a patch for --winver ? It's only a matter of setting a registry key, that can be done easily by calling regedit, there's no need to involve winecfg. -- Alexandre Julliard [EMAIL PROTECTED]
Re: splitting out on_winver_change() and friends
On Fri, Dec 28, 2007 at 05:43:40AM -0500, Steven Edwards wrote: > Hi, > > On Dec 27, 2007 4:50 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > > I'm writing a small application to automate the process of setting Windows > > version for executables that are known to require a specific one. I'd like > > it to use the knowledge about defining Windows versions contained in > > winecfg/appdefaults.c instead of duplicating/forking code from it. > > > > Would it be ok to move on_winver_change() and some of its friends like > > win_versions[] and set_reg_key() to libwine.so.1 for this purpose ? > > How about rather than writing another application to do this, you make > winecfg take arguments on the command line so you could set something > like > > winecfg foo.exe --winver win98 --dll=gdiplus.dll=n Yes, I suppose that'll do. Want a patch for --winver ? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.)
Re: user32: Remove unneeded casts.
Andrew Talbot <[EMAIL PROTECTED]> writes:
> In general, I have left the casts in where one PVOID-type handle was cast as
> another, e.g. HMODULE as HANDLE: I wasn't sure if strict typing might (one
> day) be an issue. AFAIK, my only transgressions were when I removed the
> casts from the return values of some {Local|Global}Alloc() and family
> functions, where they, strictly speaking, return a handle, not a literal
> PVOID, so arguably should be cast. For example:
>
> PSID pSid = (PSID)LocalAlloc(0, cBytes);
>
> Since LocalAlloc() returns a HLOCAL - which just happens to be a PVOID - one
> might argue that the cast should remain. As another example of
> type-equivalence versus -distinction, DWORD and ULONG are both defined as
> unsigned long, but I have currently left them as distinct types, too.
>
> I would be glad for feedback on how type-strict we should be, please.
We want to be as type-strict as possible, but that doesn't mean we want
explicit typecasts, just the opposite in fact. The only way to benefit
from type strictness is to not use casts and let the compiler warn about
mismatches. That's also why generic handles like HANDLE or HLOCAL are
defined as void*, so that they can be assigned to other types without
casting. So typecasts of generic handle types, or of integer types,
should all be avoided as far as possible.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [1/3] WineD3D: Fix a problem in BltOverride
Hi, Yes the problem is fixed with this patch although I have millions traces like this one : err:d3d_surface:IWineD3DSurfaceImpl_BltOverride Unexpected render target -> render target blit It makes the game slow whereas before wine 0.9.51 if I remember exactly, the game was fast without this message. Maybe this trace should be made a warn instead of en error ? Maxime On Sat, 2007-12-29 at 02:32 -0800, Alexander Dorofeyev wrote: > Hi. > > I think it may be the same regression I also saw in another app. At least it > seems to be in that place too. Can you check if this patch helps? > > Maxime Bellengé wrote: > > Hi Stephan, > > > > Since this patch has been commited to git I have a big regression in > the > > game Syberia. Everything is black. Nothing is displayed expected some > > menu items. > > > > In order to determine that this is this patch which is the problem I > did > > a "git bisect". > > > > Maxime > > > > > > >
Re: user32: Remove unneeded casts.
Michael Stefaniuc wrote:
> I just stumbled upon those while researching a potential problem for
> which Smatch issued a warning.
> [...]
> @@ -1324,7 +1324,7 @@ HDDEDATA WINAPI DdeAddData(HDDEDATA hData, LPBYTE
> pSrc, DWORD cb, DWORD cbOff)
> if (new_sz > old_sz)
> {
> DdeUnaccessData(hData);
> - hData = GlobalReAlloc((HGLOBAL)hData, new_sz +
> sizeof(DDE_DATAHANDLE_HEAD),
> + hData = GlobalReAlloc(hData, new_sz + sizeof(DDE_DATAHANDLE_HEAD),
[...]
Hi,
In general, I have left the casts in where one PVOID-type handle was cast as
another, e.g. HMODULE as HANDLE: I wasn't sure if strict typing might (one
day) be an issue. AFAIK, my only transgressions were when I removed the
casts from the return values of some {Local|Global}Alloc() and family
functions, where they, strictly speaking, return a handle, not a literal
PVOID, so arguably should be cast. For example:
PSID pSid = (PSID)LocalAlloc(0, cBytes);
Since LocalAlloc() returns a HLOCAL - which just happens to be a PVOID - one
might argue that the cast should remain. As another example of
type-equivalence versus -distinction, DWORD and ULONG are both defined as
unsigned long, but I have currently left them as distinct types, too.
I would be glad for feedback on how type-strict we should be, please.
Thanks,
--
Andy.
