a new trick to add to winetricks
I've found the winetricks script invaluable in trying to get my app running on Wine. But I found that when installing msxml6, I needed to change the overrides for msi.dll and msiexec.exe to builtin,native. I previously installed the native msi20, and msxml6 wouldn't install with the native installer. It installs fine with the builtin installer. Thanks, Troy
Re: winebrowser: Fix obtaining of the ASCII strings through the DDE
Ilya Shpigor shpi...@etersoft.ru wrote: [skipped] If it could be that easy this would be fixed already. There is a bug in bugzilla with the details about this problem. -- Dmitry.
Re: a new trick to add to winetricks
On 4/7/2010 17:12, Troy Wolbrink wrote: I've found the winetricks script invaluable in trying to get my app running on Wine. But I found that when installing msxml6, I needed to change the overrides for msi.dll and msiexec.exe to builtin,native. I previously installed the native msi20, and msxml6 wouldn't install with the native installer. It installs fine with the builtin installer. Hi, Troy. Could you also open a bug for this msxml6 installer problem? Thanks, Troy
Re: a new trick to add to winetricks
On Thu, Apr 8, 2010 at 3:09 AM, Nikolay Sivov bungleh...@gmail.com wrote: On 4/7/2010 17:12, Troy Wolbrink wrote: I’ve found the winetricks script invaluable in trying to get my app running on Wine. But I found that when installing msxml6, I needed to change the overrides for msi.dll and msiexec.exe to “builtin,native”. I previously installed the native msi20, and msxml6 wouldn’t install with the native installer. It installs fine with the builtin installer. Hi, Troy. Could you also open a bug for this msxml6 installer problem? Thanks, Troy Actually, from Troy's description, there isn't any valid bug at all. Troy claims that the msxml6 installer broke when using native msi.dll but succeeded with Wine's msi implementation. Native msi tends to be pretty useless and break when used on Wine, and there's no problem in Wine, so a bug would be useless here.
Re: Direct3D testing project (GSoC)
On Wed, Apr 7, 2010 at 4:21 AM, Conrad Buck conarti...@gmail.com wrote: Hello devels, I'm looking at submitting a SoC proposal to the wine project, but I'm feeling a little overwhelmed as my current coding experience is all over the place, and very little of it working with existing projects. My most recent work has been looking low-level code and algorithms behind basic OpenGL, so I thought perhaps I might be able to make relevant contributions to the project of testing and improving Direct3D support. Can anyone that knows more about whats under the hood for that sort of functionality in wine tell me what kind of magnitude of project I might be looking at? Only a limited number of bug reports have been filed, but all seem to be indicative of fairly major issues. Once I get more of an idea of what I might be dealing with (and examine some of the problems myself) I can fine-tune my proposal. Thanks, Conrad Hi, First of all welcome to Wine. Our Direct3D - OpenGL code is quite complex and has a steep learning curve, so just hacking on Direct3D to improve big chunks of code isn't that suited. That said there is certainly work which you could do in the testing / bug hunting area. For instance you could work on improving our test suite. Currently mostly Nvidia systems pass the tests. For a part this is due to driver bugs in the other drivers but some tests are also too strict and there might be some WineD3D bugs. You could fix broken tests, fix bugs in our Direct3D code found by the tests, you could add new tests and perhaps you could also improve the tests on Windows. If you want you might be able to fix some normal Direct3D bug reports as well (those will likely require new tests). It might be hard to write a good proposal though (especially judging whether you reached your goals might be hard). Another form of testing which you could improve is our 'gaming' test suite in which performance in games is tested for regressions. I have never used those tests but according to Stefan the test suite can use improvements. Perhaps some visual tests could be added to them as well, to see if there are no visual regressions. Not sure how that should work but I guess you would need a mechanism for recording keyboard/mouse movements and playing them back, so that you reach fixed spots at which you can make screenshots for comparisons. The two suggestions and some more info can also be found in a recent thread which can be found here: http://www.winehq.org/pipermail/wine-devel/2010-March/082698.html http://www.winehq.org/pipermail/wine-devel/2010-March/082707.html Good luck writing a proposal and if you have questions just ask! Roderick
Re: [GSoC] IUri Implementations
Hi Thomas, On 4/8/10 3:43 AM, Thomas Mullaly wrote: In general, the idea looks right, that's how it probably should be implemented. This is an implementation detail through. The bigger and more important problem is URI parsing and canonicalization. That's where most of work needs to be done. In this case tests will be also very important. You don't know how it should work until you have a test. The first step would be to write a test infrastructure some tests (adding new test shouldn't be harder than filling a table with more data). Once it's done, you'll be able to decide on best way to implement parser and IUri interface. The project should result in many tests and good support for at least more useful flags and IUri functions. Hi Jacek, Sorry for my delayed response. Thank you for your suggestions. For the testing infrastructure, I was thinking about writing a few Windows programs that use Microsoft's IUri implementation to generate the results that my testing infrastructure would use to make sure my implementation is working correctly. Is this the right approach or would you recommend doing it another way? Test should be integrated with Wine tests. See dlls/shlwapi/tests/url.c and dlls/wininet/tests/url.c for an idea of how it should be done. Also, I have finished a rough draft of my proposal and I was wondering if it would appropriate to post to it to the mailing list in order to receive feedback from you and others. If you have specific questions, feel free to ask here. Proposal itself should be posted to gsoc app. It's capable of editing proposals and getting feedback. Jacek
Re: [PATCH 4/4] wined3d: Add an initial fbo_blit implementation.
I don't think so. Looking at cpu_blit, that blitter has exactly a single function that's actually used, and it might as well have been a function on its own. I've twice pointed out how to avoid that situation, but for some reason you ignored that. In the case of cpu_blit I went along with that in the assumption that later patches would fix it, but I'm not having another implementation like that.
Re: [PATCH 3/4] wined3d: Start moving texture format fixups to the formats table.
On 7 April 2010 23:12, Roderick Colenbrander thunderbir...@gmail.com wrote: @@ -236,9 +236,55 @@ struct wined3d_format_texture_info GLint gl_format; GLint gl_type; unsigned int flags; + unsigned int conv_byte_count; GL_SupportedExt extension; + void (*convert)(const BYTE *src, BYTE *dst, UINT pitch, UINT width, UINT height); }; ... - GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, + GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, 0, WINED3DFMT_FLAG_FILTERING, - WINED3D_GL_EXT_NONE}, + WINED3D_GL_EXT_NONE, NULL}, Did you test this patch much?
Re: [PATCH 2/4] wined3d: Let d3dfmt_get_conv return a wined3d_format_desc. This required some code shuffling mostly in the SRGB area.
On 7 April 2010 23:12, Roderick Colenbrander thunderbir...@gmail.com wrote: --- dlls/wined3d/device.c | 5 +- dlls/wined3d/surface.c | 169 +++- dlls/wined3d/utils.c | 1 + dlls/wined3d/wined3d_private.h | 5 +- 4 files changed, 102 insertions(+), 78 deletions(-) I'm not so convinced by the idea of having mutable format descriptions. What problem are you solving, and why is this the best solution? At the very least the patch looks like it could be split though.
Re: [PATCH 2/4] wined3d: Let d3dfmt_get_conv return a wined3d_format_desc. This required some code shuffling mostly in the SRGB area.
On Thu, Apr 8, 2010 at 11:59 AM, Henri Verbeet hverb...@gmail.com wrote: On 7 April 2010 23:12, Roderick Colenbrander thunderbir...@gmail.com wrote: --- dlls/wined3d/device.c | 5 +- dlls/wined3d/surface.c | 169 +++- dlls/wined3d/utils.c | 1 + dlls/wined3d/wined3d_private.h | 5 +- 4 files changed, 102 insertions(+), 78 deletions(-) I'm not so convinced by the idea of having mutable format descriptions. What problem are you solving, and why is this the best solution? At the very least the patch looks like it could be split though. The ultimate goals are to reduce the use of d3dfmt_get_conv (some places can just use the format table) and to clean up d3dfmt_get_conv. I don't like a mutable format descriptor either but it is temporarily. The texture format fixups can all be moved over to the formats table (see patch 3). In a next step the color keying part could be cleaned up. The switch statement there could for instance be turned into a small wined3d_format_desc table. Roderick
Re: [PATCH 01/10] server: allow polling for no events in set_fd_events
Mike Kaplinskiy mike.kaplins...@gmail.com writes: But I see your point that perhaps it doesn't belong in the main loop when one of the halves gets closed. I guess we can keep sock_try_event around but only use it when the socket has been removed from the main loop. I'll also add detection of half-closed connection and drop that event if the other half hasn't hung up yet. Sadly looks like MacOS will be left out of that detection since it reports POLLIN|POLLHUP for everything. Does that sound good? I think sock_try_event shouldn't even do a poll() at all. Once we have received POLLHUP there's no point in continuing to poll. All it should have to do is try a MSG_PEEK read to detect EOF for platforms where that triggers a POLLHUP. All other cases should be handled by the main loop. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 3/4] wined3d: Start moving texture format fixups to the formats table.
On Thu, Apr 8, 2010 at 11:58 AM, Henri Verbeet hverb...@gmail.com wrote: On 7 April 2010 23:12, Roderick Colenbrander thunderbir...@gmail.com wrote: @@ -236,9 +236,55 @@ struct wined3d_format_texture_info GLint gl_format; GLint gl_type; unsigned int flags; + unsigned int conv_byte_count; GL_SupportedExt extension; + void (*convert)(const BYTE *src, BYTE *dst, UINT pitch, UINT width, UINT height); }; ... - GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, + GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, 0, WINED3DFMT_FLAG_FILTERING, - WINED3D_GL_EXT_NONE}, + WINED3D_GL_EXT_NONE, NULL}, Did you test this patch much? Argh, it seems I made a stupid copypaste error. I wrote the code a few weeks ago and did test that well on my desktop but on my laptop (ATi..) the d3d9 V8U8 test and a lot of others never worked :( The original patch code worked fine, I assumed it would still work (bad, bad, bad but I only have the laptop) ... +unsigned intbyte_count_fixup, Flags; GL_SupportedExt extension; +void (*convert)(const BYTE *src, BYTE *dst, UINT pitch, UINT width, +UINT height, UINT outpitch); } GlPixelFormatDescTemplate; When I resubmit it, I will test it with another format which has tests which work on my laptop first. Roderick
Re: [3/3] d3dx9: Add source register modifiers (sm 2+) support to the shader assembler.
Hi Matteo, This causes the test to crash on Vista and Windows 2008, see http://winetestbot.geldorp.nl/JobDetails.pl?Key=1315 Ge.
RE: a new trick to add to winetricks
Correct. This isn't a bug in Wine. It's a suggestion for making WineTricks more robust. The reason I sent this email re WineTricks is because at: http://wiki.winehq.org/winetricks It says: Reporting bugs *in* Winetricks Winetricks has a bug tracking system at http://code.google.com/p/winezeug/issues/list though sending email to wine-devel at winehq.org is usually good enough. --Troy From: Andrew Nguyen [mailto:arethus...@gmail.com] Sent: Thu 4/8/2010 4:15 AM To: Nikolay Sivov Cc: wine-devel@winehq.org; Troy Wolbrink Subject: Re: a new trick to add to winetricks On Thu, Apr 8, 2010 at 3:09 AM, Nikolay Sivov bungleh...@gmail.com wrote: On 4/7/2010 17:12, Troy Wolbrink wrote: I've found the winetricks script invaluable in trying to get my app running on Wine. But I found that when installing msxml6, I needed to change the overrides for msi.dll and msiexec.exe to builtin,native. I previously installed the native msi20, and msxml6 wouldn't install with the native installer. It installs fine with the builtin installer. Hi, Troy. Could you also open a bug for this msxml6 installer problem? Thanks, Troy Actually, from Troy's description, there isn't any valid bug at all. Troy claims that the msxml6 installer broke when using native msi.dll but succeeded with Wine's msi implementation. Native msi tends to be pretty useless and break when used on Wine, and there's no problem in Wine, so a bug would be useless here.
Re: winmm: MCI system commands are not eligible for auto-open.
joerg-cyril.hoe...@t-systems.com writes:
@@ -1341,6 +1343,7 @@ DWORD WINAPI mciSendStringW(LPCWSTR lpstrCommand,
LPWSTR lpstrRet,
if (wmd)
data[4] = wmd-wType;
}
+} else if (!strcmpW(verb, wszSound) || !strcmpW(verb, wszBreak)) {
} else if ((MCI_ALL_DEVICE_ID != uDevID) !(wmd =
MCI_GetDriver(mciGetDeviceIDW(dev {
You should at the very least add a comment to that empty block.
Also it fails here:
../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so
mci.c touch mci.ok
mci.c:808: Test failed: got 0008 instead of MCI_NOTIFY_xyz from command
sound notify
mci.c:820: Tests skipped: Skipping auto-open tests in Wine
make[1]: *** [mci.ok] Error 1
--
Alexandre Julliard
julli...@winehq.org
Re: a new trick to add to winetricks
On Thu, Apr 8, 2010 at 7:04 AM, Troy Wolbrink troy.wolbr...@ccci.org wrote: Correct. This isn't a bug in Wine. It's a suggestion for making WineTricks more robust. The reason I sent this email re WineTricks is because at: It's not a winetricks bug either, it doesn't set msi2 to native when install msxml6, you did that. Winetricks doesn't try to second guess the user, it does exactly what you tell it. http://wiki.winehq.org/winetricks It says: Reporting bugs *in* Winetricks Winetricks has a bug tracking system at http://code.google.com/p/winezeug/issues/list though sending email to wine-devel at winehq.org is usually good enough. Reporting issues here is fine, Dan and I will see them here, and it saves you trouble from registering on google code. Emailing me/Dan directly is also fine. -- -Austin
Re: [GSoC] IUri Implementations
Hi Jacek, Test should be integrated with Wine tests. See dlls/shlwapi/tests/url.c and dlls/wininet/tests/url.c for an idea of how it should be done. Thank you, shlwapi's url test was very helpful and has given me some good ideas for testing. If you have specific questions, feel free to ask here. Proposal itself should be posted to gsoc app. It's capable of editing proposals and getting feedback. Here's the link to my proposal http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/thomas_mullaly/t127066435448 I would greatly appreciate it if anybody would check it out and leave feedback/suggestions for it.
Re: [PATCH 01/10] server: allow polling for no events in set_fd_events
On Thu, Apr 8, 2010 at 11:16 AM, Alexandre Julliard julli...@winehq.org wrote: Mike Kaplinskiy mike.kaplins...@gmail.com writes: But I see your point that perhaps it doesn't belong in the main loop when one of the halves gets closed. I guess we can keep sock_try_event around but only use it when the socket has been removed from the main loop. I'll also add detection of half-closed connection and drop that event if the other half hasn't hung up yet. Sadly looks like MacOS will be left out of that detection since it reports POLLIN|POLLHUP for everything. Does that sound good? I think sock_try_event shouldn't even do a poll() at all. Once we have received POLLHUP there's no point in continuing to poll. All it should have to do is try a MSG_PEEK read to detect EOF for platforms where that triggers a POLLHUP. All other cases should be handled by the main loop. -- Alexandre Julliard julli...@winehq.org This won't work for implementing half-closed sockets. If we have only the read half is closed, we will get POLLIN/0 recv indefinitely if we keep polling (not POLLHUP). If we remove it from the loop, we have to keep polling (once in a while, i.e. when an enable_socket_event gets through) until we get a POLLHUP/POLLERR which signals the other half is closed. On some platforms this won't work, but they will jump to a full close automatically (i.e. POLLHUP right away). The problem now is that if we receive a shutdown, we will spam FD_CLOSE on every successful send. I suppose if we don't care to send more than 1 FD_CLOSE (which windows does do), we can just remove the socket from the loop and be done with it. I don't know if any apps actually depend on receiving a second FD_CLOSE after the remote end has sent a shutdown. Should we just implement the 1 FD_CLOSE behavior and then if any regressions relating to it pop up bring back try_event? Mike.
Re: [PATCH 01/10] server: allow polling for no events in set_fd_events
Mike Kaplinskiy mike.kaplins...@gmail.com writes: This won't work for implementing half-closed sockets. If we have only the read half is closed, we will get POLLIN/0 recv indefinitely if we keep polling (not POLLHUP). If we remove it from the loop, we have to keep polling (once in a while, i.e. when an enable_socket_event gets through) until we get a POLLHUP/POLLERR which signals the other half is closed. On some platforms this won't work, but they will jump to a full close automatically (i.e. POLLHUP right away). The problem now is that if we receive a shutdown, we will spam FD_CLOSE on every successful send. I don't see why. If you don't get POLLHUP then you can keep polling, just don't select for POLLIN once you have seen EOF. The problem with POLLHUP/POLLERR is that they can't be masked, but POLLIN doesn't have that issue. -- Alexandre Julliard julli...@winehq.org
Re: a new trick to add to winetricks
On Thu, Apr 8, 2010 at 3:26 PM, Troy Wolbrink troy.wolbr...@ccci.org wrote: I'm not suggesting it's a *bug* in winetricks either. I'm saying it's a possible way to make it more robust. Since it's known that the native msi installer doesn't work, it seems reasonable to me that you'd set the override to use the builtin msi. This is similar to how it overrides the winver to win98 when installing mdac. It's a known trick to get it to install. How is this second guessing the user? By that logic, winetricks would need to set most dll's to native when installing _anything_, on the off chance that the user has overridden the builtin dll. -- -Austin
RE: a new trick to add to winetricks
I'm not suggesting it's a *bug* in winetricks either. I'm saying it's a possible way to make it more robust. Since it's known that the native msi installer doesn't work, it seems reasonable to me that you'd set the override to use the builtin msi. This is similar to how it overrides the winver to win98 when installing mdac. It's a known trick to get it to install. How is this second guessing the user? --Troy -Original Message- From: Austin English [mailto:austinengl...@gmail.com] Sent: Thursday, April 08, 2010 11:48 AM To: Troy Wolbrink Cc: Andrew Nguyen; Nikolay Sivov; wine-devel@winehq.org Subject: Re: a new trick to add to winetricks On Thu, Apr 8, 2010 at 7:04 AM, Troy Wolbrink troy.wolbr...@ccci.org wrote: Correct. This isn't a bug in Wine. It's a suggestion for making WineTricks more robust. The reason I sent this email re WineTricks is because at: It's not a winetricks bug either, it doesn't set msi2 to native when install msxml6, you did that. Winetricks doesn't try to second guess the user, it does exactly what you tell it. http://wiki.winehq.org/winetricks It says: Reporting bugs *in* Winetricks Winetricks has a bug tracking system at http://code.google.com/p/winezeug/issues/list though sending email to wine-devel at winehq.org is usually good enough. Reporting issues here is fine, Dan and I will see them here, and it saves you trouble from registering on google code. Emailing me/Dan directly is also fine. -- -Austin
Google Summer of Code
Respected, I would like to contribute to the Wine development under the Google Summer Code. Have a knowledge of C Language and Vast Experience on Operating Systems I have worked and managed various OS ( OPERATING SYSTEMS ) of various PLATFORMS like:- * * * * *LINUX Platform* Ubuntu 6.10 Ubuntu 7.04 Ubuntu 7.10 Ubuntu 8.04 Ubuntu 8.10 Ubutnu 9.04 Ubuntu Server 9.04 Fedora 9 Suse *Microsoft Windows Platform* Microsoft Windows 3x Microsoft Windows 95 Microsoft Windows 98 Microsoft Windows ME Microsoft Windows Server 2000 Microsoft Windows XP Microsoft Windows Server 2003 Microsoft Windows Vista Microsoft Windows 7 * * *Macintosh Platform* Tiger MAC OSX 10.4 ** Leopard MAC OSX 10.5 Opensource is what i promote and as is visible from my mention above, I am a Linux ( opensource supported ). My idea/purposal would be to make wine, powerful-enough interms of its felxibilty to automatically find the .dll and other lib files req. for the functioning of .exe files in the Linux OS. Inturn making the Opensource world more friendly to the Other side. Like the MACFUSE on Mac OS X utilises a folder approach i.e. it creates a folder with a file index so that the efficiency of MAC is maintained while making NTFS 3G compatible with HFS+, similarly as Wine can identify the Windows Drive, it should also be able to think like a windows OS not as a Program on Linux running .exe files. To this there are two approaches:- 1. Decrypting the .exe file to its skin and recompiling it to run in the Linux way 2. Making the .exe files a better illusion of windows while providing a better experience of the Linux world to the User I'm keen to learn as much as I can from this opportunity provided and contribute to the Development to the best of my caliber. Regards Jasneet Singh Kandhari Chandigarh India
RE: a new trick to add to winetricks
That's a good point, Austin. --Troy From: Austin English [mailto:austinengl...@gmail.com] Sent: Thu 4/8/2010 4:30 PM To: Troy Wolbrink Cc: Andrew Nguyen; Nikolay Sivov; wine-devel@winehq.org Subject: Re: a new trick to add to winetricks On Thu, Apr 8, 2010 at 3:26 PM, Troy Wolbrink troy.wolbr...@ccci.org wrote: I'm not suggesting it's a *bug* in winetricks either. I'm saying it's a possible way to make it more robust. Since it's known that the native msi installer doesn't work, it seems reasonable to me that you'd set the override to use the builtin msi. This is similar to how it overrides the winver to win98 when installing mdac. It's a known trick to get it to install. How is this second guessing the user? By that logic, winetricks would need to set most dll's to native when installing _anything_, on the off chance that the user has overridden the builtin dll. -- -Austin
Re: Google Summer of Code
It's very unclear what you're proposing. Running Wine from an NTFS partition would provide little benefit, and Wine cannot interact sensibly with a real Windows install. Wine includes a loader capable of loading/linking PE .exe and .dll files in memory. Attempting to take apart a PE file and put it together in a different format wouldn't provide any compatibility benefits. What is the problem you want to solve?
