Re: Build and override a simple winelib DLL
On Fri, Apr 5, 2013 at 6:34 PM, Maxime Sednaoui maximesed...@gmail.comwrote:
Hi,
First, I already asked for the same thing at the forum where I've been
told to post here for my question
Link here : http://forum.winehq.org/viewtopic.php?f=8t=18675
I have a Windows executable that load a really simple DLL (it is a test)
and I want to create a Winelib DLL that will override the Windows DLL.
Basically, I created mylib_main.c and mylib.spec to build the Winelib DLL
with the command:
winegcc -mwindows -o mylib.dll.so mylib_main.c -I${WINE_ROOT}/include
-shared mylib.spec
winebuild -w --def -o libmylib.def --export mylib.spec
Now I have mylib.dll.so and I want to override mylib.dll
What should I do ? I removed the Windows library but then I got a Page
Fault when the function is called. I also tried to configure the override
with winecfg or set environment variables like WINEDLLPATH or add a DllMain
in my library. I don't understand how to proceed.
Is this because of the way I build my library ? Or maybe I forget a step
to link it properly ?
Hi,
I'm not an expert on this, but anyway: the docs say:
If you have problems then set the WINEDEBUG=+module environment variable
before running wine to see what is actually happening.
So I would suggest to try that first.
Second, it might be that your dll is loaded, but that it crashes inside?
Have you got a trace of the crash? Or have you ran winedbg/wine with gdb to
analyze the crash?
Regards,
Matijn
Re: MSVCP60.dll
On Fri, Jun 15, 2012 at 11:59 PM, John Emmas john...@tiscali.co.uk wrote: On 15 Jun 2012, at 10:41, Michael Stefaniuc wrote: Hello John! On 06/15/2012 06:22 AM, John Emmas wrote: Firstly, I'm not a Linux user. I'm a Windows programmer but I have a passing knowledge of Linux (and several friends who are Linux programmers). I write a Windows application which gets launched as a child process by a popular Linux DAW. My program was first written many years ago when the (then) current version of Wine was about v0.9.58. Over a hundred people are using my program with old versions of Wine and I've had no complaints so far. Recently however, two customers tried to use it with Wine v1.5.35. In both cases the program crashed - apparently because some particular function wasn't found in MSVCP60.dll (at the moment, we don't know which function). Both customers went to a web site called WineTricks from That is fairly trivial to figure out. Start your app with Wine on the command line and it will crash with an exception: Call from address to unimplemented function MSVCP60.function Once you have those please open a bug on http://bugs.winehq.org/ for them. Thanks for the suggestion Michael, I'm still trying to track this down with my 2 customers but one of them told me something very interesting this afternoon. It seems that the more recent versions of Wine have 2 distinct modes:- a 'native' mode (which he thinks uses genuine Microsoft DLLs) and some other mode which uses what he called 'fake' DLLs. The native mode seems to be working. It's the other mode that crashes. I need to check if that's the same with the second customer but in the meantime, can anyone confirm if these two modes do co-exist these days? It's very different from my older Wine which used only Microsoft DLLs AFAIK. I should have some better info next week. John You can set this for each dll (in winecfg for example), it's not a some kind of mode. Have a look at the wiki for winecfg [1]. - Matijn [1] http://wiki.winehq.org/winecfg
Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono
On Wed, Jun 6, 2012 at 3:36 PM, Vincent Povirk madewokh...@gmail.com wrote: It is not so much the technical details that are the problem. It is the LEGAL problems and potential legal problems that are at the root of my complaint. Telling me that I have the technical details wrong does not help. I have very carefully tried to move the discussion away from secondary technical points and onto the strategic issues that are not being addressed. Well, it didn't seem like you were interested in diving into specifics. I don't know the details of Microsoft's patents relating to .NET or any promises they've made regarding those patents. Even if I did, I'm probably not qualified to evaluate them. I simply assumed that because so many mainstream distros and open source projects seemed to think that use of Mono didn't pose a significant legal risk, it wasn't a problem to include it in Wine. If there's some specific action we could take to reduce our legal risk without impairing Wine's compatibility with Windows, we should probably do that and/or ask Mono to do it. However, it seems unlikely to me that there is something Wine could do in this area that Mono cannot, and I am not in a position to go looking for patents that might be relevant to our use case. This may be naive, but it seems obvious to me that the technical details are what ultimately determine the legal situation, and appearances have a much smaller effect. You also have to understand that this is a development mailing list, and it's full of programmers, not lawyers. So there's far more knowledge here of technical details (personally, I consider those details my responsibility) than legal strategy. The core of mono is safe. It is covered under ECMA-334 (C# language) and ECMA-335 (CLIR vm). The mono MS Compatibility Stack, which includes: - XML - ASP.NET - Windows.Forms - ADO.NET - Core cryptography - Transactions is a grey area now since the project is not part of Novell anymore. Novell and Microsoft had joint patent agreement, so there were no problems. So the question is, does wine-mono include the compatibility stack? - Matijn
Re: know more about Win API's
On Mon, Feb 20, 2012 at 12:17 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: prateek papriwal papriwalprat...@gmail.com wrote: can anyone suggest me how to get knowledge of windows API's and Wine Internals. I am reading the documentation provided on the site but i am finding it hard to grasp the things .. if u can suggest me some good readings or moreover a structured way of reading things it would be helpful for me ... Try msdn.microsoft.com -- Dmitry. Source code is the best documentation there is, try http://source.winehq.org, or grab the source from git. Matijn
Re: Translators wanted!
On Fri, Feb 17, 2012 at 8:02 AM, Francois Gouget fgou...@free.fr wrote: On Fri, 17 Feb 2012, Matijn Woudt wrote: [...] Francois: The untranslated errors at the consistency are almost all because of the use of english words in dutch. Would it be OK if I send you the L numbers that can have # potool-flags=translated so you can send a patch? Line numbers are unreliable. Send me the msgids instead. So for instance if the following in the report is a false positive: L339:[translated]: not translated: 'Help' msgid Help msgstr Help Then tell me: msgid Help is a false positive Attached is a list that are all false positives, they are all the same in dutch and english. - Matijn msgid Contact: msgid Product Updates: msgid frames msgid Waveform: %s msgid Waveform msgid Help msgid Help msgid Status: msgid Type: msgid Details msgid Printer offline; msgctxt Certification Practice Statement msgid CPS msgid CMC Data msgid PKCS 7 Data msgid URL= msgctxt Certificate Authority msgid CA msgctxt Online Certificate Status Protocol msgid OCSP msgid SSL CA msgid S/MIME CA msgid Disclaimer msgid %1 (%2!d! bits) msgid SHA1 hash msgid Arial msgid DirectSound: %s msgid Object msgid CHINESE_GB2312 msgid Hangul msgid CHINESE_BIG5 msgid Hangul(Johab) msgid OEM/DOS msgid Stop msgid Index msgid Stop msgid Cinepak Video codec msgid Open URL msgid Open: msgid Stack overflow.\n msgid Service start-hang.\n msgid Timeout.\n msgid Proxy msgid URL: msgid Compressor: msgid Wine Video 1 video codec msgid cursor msgid client msgid document msgid link msgid indicator msgid diagram msgctxt unit: dots/inch msgid dpi msgid Details msgid Type msgid Start Menu msgid Program Files msgid Program Files (x86) msgid Links msgid Status msgid Model msgid Downloads msgid Realm msgid Server msgid Timeout msgid %1 adapter %2\n msgid Ethernet msgid Broadcast msgid Peer-to-peer msgid Unicode (UTF-16) msgid Unicode (UTF-16 big-endian) msgid Unicode (UTF-8) msgid Object msgid Interface msgid OleView msgid ver. msgid Interfaces msgid Realtime msgid CPU 0 msgid CPU 1 msgid CPU 2 msgid CPU 3 msgid CPU 4 msgid CPU 5 msgid CPU 6 msgid CPU 7 msgid CPU 8 msgid CPU 9 msgid CPU 10 msgid CPU 11 msgid CPU 12 msgid CPU 13 msgid CPU 14 msgid CPU 15 msgid CPU 16 msgid CPU 17 msgid CPU 18 msgid CPU 19 msgid CPU 20 msgid CPU 21 msgid CPU 22 msgid CPU 23 msgid CPU 24 msgid CPU 25 msgid CPU 26 msgid CPU 27 msgid CPU 28 msgid CPU 29 msgid CPU 30 msgid CPU 31 msgid Wine msgctxt Drive letter msgid Letter msgid Popup menu msgid Control msgid Shift msgid Copyright: msgid Index/Inode msgid Beginner msgid Expert msgid Beginner msgid Expert msgid Copyright 2000 Joshua Thielen msgid Index msgid Tabs... msgid Tabs msgctxt unit: inch msgid in msgid inch msgctxt unit: point msgid pt msgid Document
Re: Translators wanted!
On Thu, Feb 16, 2012 at 7:13 PM, Francois Gouget fgou...@free.fr wrote: Wine 1.4 is making good progress. Unfortunately we still have a lot of translations that are quite incomplete and have no active translators, thus making Wine unusable in many countries. You track progress on this page: http://fgouget.free.fr/wine-po/ Hi Francois, I checked the dutch translation, and your site gives 95% for nl. I have a few questions 1) It says there are 39 todo, is it possible to show which ones still need to be done? 2) Most of the consistency errors are false positives (whe use quite a lot english words), is it possible to mark them as false positive or something? 3) There's an consistency ignore list, does that mean that the original english translation is used there? 4) Same for spell list, there are also quite a few false positives there. I'd like to help get the dutch translation to 100%, but I would need to filter out the false positives first. Thanks, Matijn
Re: Translators wanted!
On Fri, Feb 17, 2012 at 12:40 AM, Sven Baars sven.w...@gmail.com wrote: On 16-02-2012 at 7:55 PM, Matijn Woudt tijn...@gmail.com wrote: I'd like to help get the dutch translation to 100%, but I would need to filter out the false positives first. I started with this a while ago, but every time I was nearly done, more translations were marked as fuzzy, more strings were introduced, and usually Francois changed some strings, which meant that I had to manually apply the patch I was working on (with some conflicts). After a while I just gave up on this (I don't have the time to fix it all in one day), so for me the po system actually works counterproductive... What I want to say here is that if that if you want to get some small fixes in without actually knowing the language you're working on (like Francois), please don't send separate patches every few days, because that's really annoying. Just send them all at once, or just let translators fix it. Or at least set a string freeze, after which people who are actual translators can translate strings. @Matijn, please go ahead and update the Dutch translation. Sven You may be right on that, especially because there are translators that don't know how to fix things after their patch --merge fails. I didn't start too because I thought that it might conflict with Francois patches too. Francois: The untranslated errors at the consistency are almost all because of the use of english words in dutch. Would it be OK if I send you the L numbers that can have # potool-flags=translated so you can send a patch? - Matijn
Re: HRBlock error. Sure would like to do my taxes on Linux using Wine.
On Sat, Jan 28, 2012 at 2:12 AM, Ken Stephens k...@cad2cam.com wrote: I get the following error when trying to load HRBlock software: [kens@atlas HRBlock2011]$ wine tcauto.exe err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth = 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution. Have you even looked at your output log? It seems that this might be the problem. Other than that, this list is for Wine development, not for any bugs. Try bugzilla for that [1]. - Matijn [1] http://bugs.winehq.org
Re: Vista/w2k8/w7 + ALSA users, please test mmdevapi capture
On Thu, Jan 12, 2012 at 9:50 AM, joerg-cyril.hoe...@t-systems.com wrote: Hi, Thanks to all five users who sent me data. I've a new testbot job. Please download mmdevapi_test32|64.exe http://testbot.winehq.org/JobDetails.pl?Key=16386 you don't need a microphone, just a capture capable sound card, unlike testbot. there should be next to 0 failures in lines 200-410. Failures in 411-600 (function test_capture2) are not interesting. It would be good to repeat the test a few times to see whether there's a random failure. Also, please compare mmdevapi_test[64].exe capture with mmdevapi_test[64].exe capture capture.log Redirecting to a file leads to vastly different results (in the render tests) because output to the MS-DOS shell is extremely slow and thus affects timing. On a 64bit machine, you may also compare the output of both executables. The behaviour is apparently not the same! You'll find 4 text files with the different possibilities. Each contains data of 5 runs. Matijn capture.c:691: Returned periods: 10. ms 3. ms capture.c:703: pwfx: 006ED3A8 capture.c:704: Tag: fffe capture.c:705: bits: 32 capture.c:706: chan: 2 capture.c:707: rate: 48000 capture.c:708: align: 8 capture.c:709: extra: 22 capture.c:714: Res: 32 capture.c:715: Mask: 3 capture.c:716: Alg: FLOAT capture.c:773: Returned latency: 5. ms capture.c:180: Wait'ed position -1 pad 0 flags abadcafe, amount of frames locked : 0 capture.c:242: Sleep.1 position 0 pad 16800 flags 1, amount of frames locked: 48 0 capture.c:288: GetBufferSize 23941 period size 480 capture.c:298: Overrun position 960 pad 23941 flags 1, amount of frames locked: 480 capture.c:325: Cont'ed position 1440 pad 23461 flags 0, amount of frames locked: 480 capture.c:348: Restart position 1920 pad 22981 flags 0, amount of frames locked: 480 capture.c:377: Reset position -1 pad 0 flags abadcafe, amount of frames locked : 0 capture.c:401: Running position 37440 pad 9120 flags 0, amount of frames locked: 480 capture.c:512: Device position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:516: Test failed: GetNextPacketSize 480 vs. GetBuffer 0 capture.c:572: Device position 46560 pad 17280 flags 0, amount of frames locked: 480 capture.c:580: Test failed: Position 46560 expected 0 capture.c:618: GetBufferSize 23941 period size 480 capture.c:627: Device position 47520 pad 23941 flags 1, amount of frames locked: 480 capture.c:633: Test failed: Position 47520 expected 480 capture: 303 tests executed (0 marked as todo, 3 failures), 0 skipped. D:\Downloadsmmdevapi_test.exe capture capture.c:691: Returned periods: 10. ms 3. ms capture.c:703: pwfx: 0070D3A8 capture.c:704: Tag: fffe capture.c:705: bits: 32 capture.c:706: chan: 2 capture.c:707: rate: 48000 capture.c:708: align: 8 capture.c:709: extra: 22 capture.c:714: Res: 32 capture.c:715: Mask: 3 capture.c:716: Alg: FLOAT capture.c:773: Returned latency: 5. ms capture.c:180: Wait'ed position -1 pad 0 flags abadcafe, amount of frames locked : 0 capture.c:242: Sleep.1 position 0 pad 16800 flags 1, amount of frames locked: 48 0 capture.c:288: GetBufferSize 23941 period size 480 capture.c:298: Overrun position 960 pad 23941 flags 1, amount of frames locked: 480 capture.c:325: Cont'ed position 1440 pad 23461 flags 0, amount of frames locked: 480 capture.c:348: Restart position 1920 pad 23461 flags 0, amount of frames locked: 480 capture.c:377: Reset position -1 pad 0 flags abadcafe, amount of frames locked : 0 capture.c:401: Running position 37920 pad 9120 flags 0, amount of frames locked: 480 capture.c:512: Device position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:516: Test failed: GetNextPacketSize 480 vs. GetBuffer 0 capture.c:572: Device position 47040 pad 17760 flags 0, amount of frames locked: 480 capture.c:580: Test failed: Position 47040 expected 0 capture.c:618: GetBufferSize 23941 period size 480 capture.c:627: Device position 48000 pad 23941 flags 1, amount of frames locked: 480 capture.c:633: Test failed: Position 48000 expected 480 capture: 303 tests executed (0 marked as todo, 3 failures), 0 skipped. D:\Downloadsmmdevapi_test.exe capture capture.c:691: Returned periods: 10. ms 3. ms capture.c:703: pwfx: 00A5D3A8 capture.c:704: Tag: fffe capture.c:705: bits: 32 capture.c:706: chan: 2 capture.c:707: rate: 48000 capture.c:708: align: 8 capture.c:709: extra: 22 capture.c:714: Res: 32 capture.c:715: Mask: 3 capture.c:716: Alg: FLOAT capture.c:773: Returned latency: 5. ms capture.c:180: Wait'ed position -1 pad 0 flags abadcafe, amount of frames locked : 0 capture.c:242: Sleep.1 position 0 pad 16800 flags 1, amount of frames locked: 48 0 capture.c:288: GetBufferSize 23941 period size 480 capture.c:298: Overrun position 960 pad 23941 flags 1, amount of frames locked: 480 capture.c:325: Cont'ed position 1440 pad 23461 flags 0, amount of frames locked: 480 capture.c:348: Restart position 1920 pad 23461 flags 0, amount of
Re: Vista/w2k8/w7 users, please test mmdevapi capture
On Wed, Jan 11, 2012 at 9:51 AM, joerg-cyril.hoe...@t-systems.com wrote: Hi, you don't need a microphone, just a capture capable sound card, unlike testbot. Please download mmdevapi_test32|64.exe from testbot: http://testbot.winehq.org/JobDetails.pl?Key=16376 run: mmdevapi_test capture and post or send me the results -- not just the failures, the console output too including position/padding/flags. Don't be afraid of some test failures in lines 300-499. I'm still investigating underrun and start/stop/reset behaviour. Thank you for testing, Jörg Höhle Hi, Attached are my results from Win7 x64 (both 32bit and 64bit test results). Matijn mmdevapi_test.exe capture capture.c:663: Returned periods: 10. ms 3. ms capture.c:675: pwfx: 0095D368 capture.c:676: Tag: fffe capture.c:677: bits: 32 capture.c:678: chan: 2 capture.c:679: rate: 48000 capture.c:680: align: 8 capture.c:681: extra: 22 capture.c:686: Res: 32 capture.c:687: Mask: 3 capture.c:688: Alg: FLOAT capture.c:745: Returned latency: 5. ms capture.c:170: Test failed: Position 480 expected 0 capture.c:175: Device position 480 pad 0 flags 1, amount of frames locked: 480 capture.c:217: Test failed: Position 960 expected 480 capture.c:225: Test failed: GCP 17280 past ReleaseBuffer(0) initially 16800 capture.c:235: Device position 960 pad 16800 flags 0, amount of frames locked: 480 capture.c:243: Test failed: Position 960 expected 480 capture.c:281: GetBufferSize 23941 period size 480 capture.c:290: Device position 1920 pad 23941 flags 1, amount of frames locked:480 capture.c:298: Test failed: Position 1920 expected 960 capture.c:312: Device position 2400 pad 23461 flags 0, amount of frames locked:480 capture.c:333: Device position 2880 pad 23461 flags 0, amount of frames locked:480 capture.c:356: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001 capture.c:357: Device position -1 pad 0 flags 0, amount of frames locked: 0 capture.c:372: Device position 39840 pad 0 flags 0, amount of frames locked: 480 capture.c:375: Test failed: Position 39840 expected 3360 capture.c:484: Device position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:544: Device position 55680 pad 16800 flags 0, amount of frames locked: 480 capture.c:552: Test failed: Position 55680 expected 0 capture.c:590: GetBufferSize 23941 period size 480 capture.c:599: Device position 56640 pad 23941 flags 1, amount of frames locked: 480 capture.c:605: Test failed: Position 56640 expected 480 capture.c:1020: Test failed: Master volume wasn't 1: 0.199526 capture: 302 tests executed (0 marked as todo, 10 failures), 0 skipped. mmdevapi_test64.exe capture capture.c:663: Returned periods: 10. ms 3. ms capture.c:675: pwfx: 0058BD80 capture.c:676: Tag: fffe capture.c:677: bits: 32 capture.c:678: chan: 2 capture.c:679: rate: 48000 capture.c:680: align: 8 capture.c:681: extra: 22 capture.c:686: Res: 32 capture.c:687: Mask: 3 capture.c:688: Alg: FLOAT capture.c:713: Test failed: IsFormatSupported(0x) call returns 88890008 capture.c:745: Returned latency: 5. ms capture.c:175: Device position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:235: Device position 0 pad 16800 flags 1, amount of frames locked: 480 capture.c:281: GetBufferSize 23941 period size 480 capture.c:290: Device position 960 pad 23941 flags 1, amount of frames locked: 480 capture.c:298: Test failed: Position 960 expected 480 capture.c:312: Device position 1440 pad 23461 flags 0, amount of frames locked:480 capture.c:333: Device position 1920 pad 23461 flags 0, amount of frames locked:480 capture.c:356: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001 capture.c:357: Device position -1 pad 0 flags 0, amount of frames locked: 0 capture.c:372: Device position 37920 pad 0 flags 0, amount of frames locked: 480 capture.c:375: Test failed: Position 37920 expected 2400 capture.c:484: Device position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:544: Device position 53760 pad 16800 flags 0, amount of frames locked: 480 capture.c:552: Test failed: Position 53760 expected 0 capture.c:590: GetBufferSize 23941 period size 480 capture.c:599: Device position 54720 pad 23941 flags 1, amount of frames locked: 480 capture.c:605: Test failed: Position 54720 expected 480 capture: 301 tests executed (0 marked as todo, 6 failures), 0 skipped.
Re: Rethinking WineConf
On Tue, Jan 10, 2012 at 11:00 PM, Marcus Meissner mar...@jet.franken.de wrote: The workshop elements we introduced in the last years are however more the direction to go. So something of a workshop is my best bet at keeping interest. Question is whether we can find workshop style things besides fixing the testsuite that attract all developers? I think that will be hard. I think that a workshop 'How to start coding for wine' workshop would do good. That might attract programmers that really want to help out, but as you probably all know, the learning curve for wine is pretty steep. Matijn
Re: Sugestion about wine
On Thu, Nov 24, 2011 at 8:27 PM, Kane Jade xneoman...@gmail.com wrote: Perhaps the program Zynamics BinNavi is useful to analyze the win32 applications, etc: Zynamics BinNavi is the primary binary code reverse engineering tool based on graph visualization Hi, Most likely this is your own software and you're trying to sell it to many people, but it's not allowed for wine anyway. Have a look at: http://wiki.winehq.org/CleanRoomGuidelines Matijn
Re: Vista/w2k8/w7 users, please test mmdevapi with exclusive mode disabled
On Mon, Nov 14, 2011 at 2:29 PM, joerg-cyril.hoe...@t-systems.com wrote: Hi, Please test mmdevapi again using testbot job #15369 with exclusive mode disabled. With exclusive mode enabled (both 32bit and 64bit): render: 884 tests executed (0 marked as todo, 49 failures), 1 skipped. With exclusive mode disabled: 32bit: render: 884 tests executed (0 marked as todo, 43 failures), 1 skipped. 64bit: render: 884 tests executed (0 marked as todo, 44 failures), 1 skipped. I attached logs for you. Cheers, Matijn render.c:159: Returned periods: 10. ms 3. ms render.c:171: pwfx: 009BCA08 render.c:172: Tag: fffe render.c:173: bits: 32 render.c:174: chan: 6 render.c:175: rate: 48000 render.c:176: align: 24 render.c:177: extra: 22 render.c:182: Res: 32 render.c:183: Mask: 3f render.c:184: Alg: FLOAT render.c:242: Initialize(duration=0) GetBufferSize is 1440 render.c:306: Returned latency: 14.3853 ms render.c:317: Test failed: SetEventHandle returns render.c:379: IsSupported(exclus., 8000x 8x1) disabled render.c:379: IsSupported(exclus., 8000x 8x2) disabled render.c:379: IsSupported(exclus., 8000x16x1) disabled render.c:379: IsSupported(exclus., 8000x16x2) disabled render.c:379: IsSupported(exclus., 11025x 8x1) disabled render.c:379: IsSupported(exclus., 11025x 8x2) disabled render.c:379: IsSupported(exclus., 11025x16x1) disabled render.c:379: IsSupported(exclus., 11025x16x2) disabled render.c:379: IsSupported(exclus., 12000x 8x1) disabled render.c:379: IsSupported(exclus., 12000x 8x2) disabled render.c:379: IsSupported(exclus., 12000x16x1) disabled render.c:379: IsSupported(exclus., 12000x16x2) disabled render.c:379: IsSupported(exclus., 16000x 8x1) disabled render.c:379: IsSupported(exclus., 16000x 8x2) disabled render.c:379: IsSupported(exclus., 16000x16x1) disabled render.c:379: IsSupported(exclus., 16000x16x2) disabled render.c:379: IsSupported(exclus., 22050x 8x1) disabled render.c:379: IsSupported(exclus., 22050x 8x2) disabled render.c:379: IsSupported(exclus., 22050x16x1) disabled render.c:379: IsSupported(exclus., 22050x16x2) disabled render.c:379: IsSupported(exclus., 44100x 8x1) disabled render.c:379: IsSupported(exclus., 44100x 8x2) disabled render.c:379: IsSupported(exclus., 44100x16x1) disabled render.c:379: IsSupported(exclus., 44100x16x2) disabled render.c:379: IsSupported(exclus., 48000x 8x1) disabled render.c:379: IsSupported(exclus., 48000x 8x2) disabled render.c:379: IsSupported(exclus., 48000x16x1) disabled render.c:379: IsSupported(exclus., 48000x16x2) disabled render.c:379: IsSupported(exclus., 96000x 8x1) disabled render.c:379: IsSupported(exclus., 96000x 8x2) disabled render.c:379: IsSupported(exclus., 96000x16x1) disabled render.c:379: IsSupported(exclus., 96000x16x2) disabled render.c:374: Test failed: IsFormatSupported(0, 48000x 8x1) returns 88890008 render.c:379: IsSupported(shared , 48000x 8x2) render.c:374: Test failed: IsFormatSupported(0, 48000x16x1) returns 88890008 render.c:379: IsSupported(shared , 48000x16x2) render.c:824: Testing shared mode render.c:851: Latency: 14.3853 ms render.c:863: BufferSize 24000 estimated fragment 480 render.c:887: Clock Frequency 1152000 render.c:916: data at 00661000 render.c:931: Test failed: Start failed: 88890014 render.c:942: Test failed: Position should have been further along... render.c:946: Test failed: Stop failed: 0001 render.c:955: Test failed: Start failed: 88890014 render.c:962: padding 24000 past sleep #2 render.c:967: Test failed: Stop failed: 0001 render.c:974: padding 24000 position 0 past stop #2 render.c:981: Test failed: Position should have been further along... render.c:1007: data at 00661000 render.c:1023: Test failed: Start failed: 88890014 render.c:1030: position 0 past 100ms sleep #3 render.c:1031: Test failed: Position should have been further along... render.c:1036: Tests skipped: Rerun with WINETEST_DEBUG=2 for GetPosition tests. render.c:1040: Test failed: Reset while playing: render.c:1043: Test failed: Stop failed: 0001 render.c:1050: padding 0 position 0 past stop #3 render.c:1071: Test failed: Start failed: 88890014 render.c:1077: data at 00661000 for prefill 22500 render.c:1106: hpctime 357 after 350ms render.c:: Test failed: Position should have been further along... render.c:1125: hpctime 465 pcpos 468 render.c:1130: padding 22500 position 0/0 slept 450ms iteration 0 render.c:1131: Test failed: Position should have been further along... render.c:1164: data at 006E4D60 (small 1500) render.c:1125: hpctime 581 pcpos 584 render.c:1130: padding 24000 position 0/0 slept 550ms iteration 1 render.c:1131: Test failed: Position should have been further along... render.c:1164: data at (small 0) render.c:1166: Test failed: NULL buffer returned render.c:1125: hpctime 700 pcpos 703 render.c:1130: padding 24000 position 0/0 slept 650ms iteration 2 render.c:1131: Test failed: Position should have been further along... render.c:1164: data at (small 0) render.c:1166:
Re: WineHQ database compromise
On Tue, Oct 11, 2011 at 9:13 PM, Jeremy White jwh...@codeweavers.com wrote: Hi, I am sad to say that there was a compromise of the WineHQ database system. What we know at this point that someone was able to obtain unauthorized access to the phpmyadmin utility. We do not exactly how they obtained access; it was either by compromising an admins credentials, or by exploiting an unpatched vulnerability in phpmyadmin. Jeremy, Almost 2 years ago I have sent you an email privately about a security hole with the database. To be exactly, the date of the email is Wed, Jul 29, 2009, 12:00 AM (GMT +02:00). I guess that's probably the same trick the bad guys have used... Kind regards, Matijn Woudt
Re: Vista/w2k8/w7 users, please test mmdevapi capture
From my Win7 x64 with a Soundblaster X-Fi: D:\Downloadsmmdevapi_test64.exe capture capture.c:208: Returned periods: 10.0 ms 3.0 ms capture.c:220: pwfx: 0067A8C0 capture.c:221: Tag: fffe capture.c:222: bits: 32 capture.c:223: chan: 2 capture.c:224: rate: 48000 capture.c:225: align: 8 capture.c:226: extra: 22 capture.c:231: Res: 32 capture.c:232: Mask: 3 capture.c:233: Alg: FLOAT capture.c:258: Test failed: IsFormatSupported(0x) call returns 88890008 capture.c:290: Returned latency: 5.0 ms capture.c:128: Device position is at 0, amount of frames locked: 480 capture.c:548: Test failed: Master volume wasn't 1: 0.501187 capture: 177 tests executed (0 marked as todo, 2 failures), 0 skipped. D:\Downloadsmmdevapi_test64.exe render render.c:145: Returned periods: 10.0 ms 3.0 ms render.c:157: pwfx: 0068A8C0 render.c:158: Tag: fffe render.c:159: bits: 32 render.c:160: chan: 6 render.c:161: rate: 48000 render.c:162: align: 24 render.c:163: extra: 22 render.c:168: Res: 32 render.c:169: Mask: 3f render.c:170: Alg: FLOAT render.c:238: Returned latency: 14.03853 ms render.c:595: Test failed: Position should have been further along... render.c:648: Test failed: Position should have been further along... render: 344 tests executed (0 marked as todo, 2 failures), 0 skipped. D:\Downloadsmmdevapi_test.exe capture capture.c:208: Returned periods: 10.0 ms 3.0 ms capture.c:220: pwfx: 00AAC820 capture.c:221: Tag: fffe capture.c:222: bits: 32 capture.c:223: chan: 2 capture.c:224: rate: 48000 capture.c:225: align: 8 capture.c:226: extra: 22 capture.c:231: Res: 32 capture.c:232: Mask: 3 capture.c:233: Alg: FLOAT capture.c:290: Returned latency: 5.0 ms capture.c:128: Device position is at 0, amount of frames locked: 480 capture: 177 tests executed (0 marked as todo, 0 failures), 0 skipped. D:\Downloadsmmdevapi_test.exe render render.c:145: Returned periods: 10.0 ms 3.0 ms render.c:157: pwfx: 0088C820 render.c:158: Tag: fffe render.c:159: bits: 32 render.c:160: chan: 6 render.c:161: rate: 48000 render.c:162: align: 24 render.c:163: extra: 22 render.c:168: Res: 32 render.c:169: Mask: 3f render.c:170: Alg: FLOAT render.c:238: Returned latency: 14.03853 ms render.c:595: Test failed: Position should have been further along... render.c:648: Test failed: Position should have been further along... render: 344 tests executed (0 marked as todo, 2 failures), 0 skipped. Just let me know if you need me to run more tests. Note that there's a secondary soundcard (Realtek HDA onboard) which has input, but it ain't the default so I don't know if it actually matters. There's also an AMD HDMI output, but that should not give any trouble to capturing. Matijn On Fri, Aug 12, 2011 at 6:07 PM, joerg-cyril.hoe...@t-systems.com wrote: Dear users of machines with Vista/w2k8/w7, Unfortunately, testbot has no mmdevapi-capture enabled machine. If you have a capture-enabled sound card, could you please run the attached patch and report results to me? How you can tell if capture/recording works on your machine: Run the regular mmdevapi:capture and render tests as well as winmm:* (mci, wave etc.) and see if and why they skip tests. You'll find a binary mmdevapi_test.exe (and test64.exe) on testbot: https://testbot.winehq.org/JobDetails.pl?Key=13426 Testbot's machines say: capture.c:724: Tests skipped: No sound card available capture: 1 tests executed (0 marked as todo, 0 failures), 1 skipped. 1 test is too little and shows capture was skipped. Background: I wrote a patch to fix the Get/ReleaseBuffer protocol in the renderer. Looking at the capture code, I suppose a similar patch could apply, but I've no machine at all to test it! (Protocol means the order in which methods can be invoked and implies testing the error codes and effects). Thank you for testing, Jörg Höhle
Re: wine bug 27600
On Thu, Jun 30, 2011 at 4:52 PM, Austin English austinengl...@gmail.com wrote: 2011/6/30 wy...@volny.cz: Ok, try with a modified header: OK no problem, i will try later today. But i don't think it's a bug in applicability of those patches. I began with wine testing 2 years ago and did many regression tests, reverse reg.testing, found faulty commit even though it was covered by several other faulty commits etc. I think I can find a problem between patches quite well. I can't go under patch level aka go into lines of code and that's the helping hand i would need here, i.e. i know, that 3rd patch of your series makes troubles to me and i also know, that your one big merged and modified patch works for me. Unfortunately as i said, i can't search a regression between lines of code. And this is a place we should look in, i guess... Sure, i will try again your modified script later today and let you know. For the other guys, could i call for help?? Could you please try to apply the Vincas's 9 patch raw-input series to the current git, try to compile and let me know, if you succeed? I really would like to know if i'm the only one with such problem. Thank you all, W. $ cd wine-git $ wget http://dl.dropbox.com/u/6901628/raw.patch $ patch -p1 raw.patch $ ./tools/make_requests $ ./configure $ make works here: austin@debian:~/wine-git$ cat /etc/issue Debian GNU/Linux wheezy/sid \n \l austin@debian:~/wine-git$ uname -a Linux debian 2.6.39-2-686-pae #1 SMP Wed Jun 8 11:33:14 UTC 2011 i686 GNU/Linux -- -Austin Wylda already reported that this big patch worked, but the 9-patch series didn't. Can you try those?
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
On Wed, Nov 24, 2010 at 11:30 PM, Henri Verbeet hverb...@gmail.com wrote: On 23 November 2010 23:57, Matijn Woudt tijn...@gmail.com wrote: I have created a patch that uses a dummy window. Please let me know if this is what you had in mind. It works for the game I created the original patch for. The basic idea is similar, but it would have to be done in wined3d, and integrated with the rest of the context management. Look at e.g. context_update_window(), context_validate(), context_create() and WineD3D_CreateFakeGLContext(). That's what I had in mind first too, but I couldn't figure out how to get that handle over to device_init (in d3d9) where the window is used too.
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
On Wed, Nov 24, 2010 at 11:37 PM, Henri Verbeet hverb...@gmail.com wrote: On 24 November 2010 23:34, Matijn Woudt tijn...@gmail.com wrote: That's what I had in mind first too, but I couldn't figure out how to get that handle over to device_init (in d3d9) where the window is used too. Why do you need it there? The current code is using the window, I guess it wouldn't work if focus_window is still pointing to the main device context. I might be missing something here, but I don't see how this can possibly work.
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
On Sun, Nov 21, 2010 at 8:23 PM, Roderick Colenbrander
thunderbir...@gmail.com wrote:
On Sat, Nov 20, 2010 at 3:17 AM, Stefan Dösinger ste...@codeweavers.com
wrote:
Am Donnerstag 18 November 2010, 16:41:53 schrieb Matijn Woudt:
There's only 1 difference, the first one really shows a window with
all the triangle's, like it should. Second one doesn't show anything.
So all the functions don't fail, they just don't seem to do anything.
I think we should set up the swapchain to use a dummy window, GL bitmap or
WGL
pbuffer and turn on render to fbo.
That's what I would suggest as well, but remove GL bitmap from the set
of options. It means software GDI on windows and on Wine it means
indirect rendering which can be bad. The pbuffer would be quite
reliable but it is not around everywhere, if a dummy window works fine
lets try that first.
Roderick
I have created a patch that uses a dummy window. Please let me know if
this is what you had in mind. It works for the game I created the
original patch for.
Matijn
From 9fa163c4f47355fc3f4940e1c966aa93ba0c64e3 Mon Sep 17 00:00:00 2001
From: Matijn Woudt tijn...@gmail.com
Date: Tue, 23 Nov 2010 23:51:06 +0100
Subject: d3d9: Create dummy window if focus window is the desktop window
---
dlls/d3d9/Makefile.in|2 +-
dlls/d3d9/d3d9_private.h |2 ++
dlls/d3d9/device.c | 12
3 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/dlls/d3d9/Makefile.in b/dlls/d3d9/Makefile.in
index 9d5a4d8..ed949d3 100644
--- a/dlls/d3d9/Makefile.in
+++ b/dlls/d3d9/Makefile.in
@@ -1,6 +1,6 @@
MODULE= d3d9.dll
IMPORTLIB = d3d9
-IMPORTS = dxguid uuid wined3d
+IMPORTS = dxguid uuid wined3d user32
C_SRCS = \
buffer.c \
diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h
index 02f9c20..7d8d45e 100644
--- a/dlls/d3d9/d3d9_private.h
+++ b/dlls/d3d9/d3d9_private.h
@@ -178,6 +178,8 @@ typedef struct IDirect3DDevice9Impl
unsigned int numConvertedDecls, declArraySize;
BOOL notreset;
+
+HWND dummy_window;
} IDirect3DDevice9Impl;
HRESULT device_init(IDirect3DDevice9Impl *device, IWineD3D *wined3d, UINT
adapter, D3DDEVTYPE device_type,
diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c
index 349bde4..ddf431d 100644
--- a/dlls/d3d9/device.c
+++ b/dlls/d3d9/device.c
@@ -275,6 +275,7 @@ static ULONG WINAPI DECLSPEC_HOTPATCH
IDirect3DDevice9Impl_Release(LPDIRECT3DDEV
IWineD3DDevice_ReleaseFocusWindow(This-WineD3DDevice);
IWineD3DDevice_Release(This-WineD3DDevice);
wined3d_mutex_unlock();
+ if(This-dummy_window) DestroyWindow(This-dummy_window);
HeapFree(GetProcessHeap(), 0, This);
}
@@ -3255,6 +3256,17 @@ HRESULT device_init(IDirect3DDevice9Impl *device,
IWineD3D *wined3d, UINT adapte
device-device_parent_vtbl = d3d9_wined3d_device_parent_vtbl;
device-ref = 1;
+if(focus_window == GetDesktopWindow()) {
+WNDCLASSA wc = {0};
+wc.lpfnWndProc = DefWindowProcA;
+wc.lpszClassName = wine_d3d9_dummy_window;
+RegisterClassA(wc);
+
+focus_window = CreateWindowA(wine_d3d9_dummy_window,
wine_d3d9_dummy_window, WS_POPUP, 0, 0, 640, 480, 0, 0, 0, 0);
+parameters-hDeviceWindow = focus_window;
+device-dummy_window = focus_window;
+}
+
if (!(flags D3DCREATE_FPU_PRESERVE)) setup_fpu();
wined3d_mutex_lock();
--
1.7.0.4
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
I got confused by the relay logs earlier (they don't include the calls to com objects), it's our implementation of IDirect3D9::CreateDevice which is calling SetPixelFormat. The application calls CreateDevice with focus_window a handle from GetDesktopWindow(); You're right that the game isn't actually drawing to this device, it calls a few functions (see attached files) and then it releases this device and creates a new one with an appropriate window for the game itself. There are currently no test cases for using a 'root_window'. What test cases do you want to see? I can duplicate the current tests for use with a root_window, but that's probably not what you want. For the implementation, we might be able to detect this inside CreateDevice, and skip the creation of a swapchain. Not sure if that's a correct fix though. Thanks again, Matijn On Mon, Nov 15, 2010 at 2:24 AM, Roderick Colenbrander thunderbir...@gmail.com wrote: It has been a while since I last looked at this area. The following bug came to my mind which is the same thing http://bugs.winehq.org/show_bug.cgi?id=9786 I would start by figuring out for what purpose and for what calls the game is using GetDC(0). Turn on some d3d debug channels and try to figure that out. You might have to write some test cases (though they might exists already in d3d, but I haven't looked at the test in a while). I don't know for sure but can Direct3D actually render to the 'root_window'? I guess you can't .. Roderick On Sun, Nov 14, 2010 at 3:33 PM, Matijn Woudt tijn...@gmail.com wrote: On Mon, Nov 15, 2010 at 12:06 AM, Roderick Colenbrander thunderbir...@gmail.com wrote: Hi Matijn, What 3D API is this game using? Is it using Direct3D or OpenGL? If it is Direct3D then I have the feeling the 'issue' is getting fixed in the wrong layer. It's using Direct3D, but I don't see how this can be fixed in Direct3D. Further I'm not really sure whether we want to allow pixel format 1 to be used at all. In case of Wine all pixel formats are hardware accelerated (okay, the bitmaps one are set to indirect rendering so might be software based depending on the GLX implementation). On Windows you essentially have two GL implementations namely the Microsoft GDI renderer and the OpenGL ICD driver. The first several pixel formats are the ones from the software based GDI renderer... So even though Windows might allow setting pixel format 1 on HDC 0, I don't think it is the right thing to do. Roderick Not setting the pixel format (e.g. just returning TRUE) won't help the game. Setting a different (hardware accelerated) format will probably work, but that doesn't feel right. I'd really like to fix this bug, but if the patch isn't right I don't have a clue how to fix it 'the right way'. Any hints? Thanks, Matijn ps. Trial for the game is available at: http://www.sandlotgames.com/w5/hearts_medicine_season_1.html (200MB), after installing run bin/prog.exe, launcher doesn't work. On Sun, Nov 14, 2010 at 9:55 AM, Matijn Woudt tijn...@gmail.com wrote: Add tests for special case of SetPixelFormat Tests pass on my Windows XP laptop and Windows 7 PC. The game 'Heart's Medicine Season One' depends on this behaviour. calls Description: Binary data
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
On Thu, Nov 18, 2010 at 3:35 PM, Henri Verbeet hverb...@gmail.com wrote: On 18 November 2010 15:05, Matijn Woudt tijn...@gmail.com wrote: For the implementation, we might be able to detect this inside CreateDevice, and skip the creation of a swapchain. Not sure if that's a correct fix though. Swapchain creation isn't something you want to skip. Perhaps it's possible to delay GL context creation until something actually needs it though. I'm curious if things like DrawPrimitive() shouldn't fail anyway when the device is created with GetDesktopWindow() as window. Another option may be to allow the D3D context to be created, but immediately mark it invalid. I gave the visual test suite a shot, normal test run on my Windows 7 x64: visual.c:196: Driver string: atiumdag.dl visual.c:197: Description string: ATI Ra visual.c:199: Device name string: \\.\DI visual.c:201: Driver version 8.14.10.678 visual: 5493 tests executed (0 marked as todo, 75 failures), 3 skipped. now, changing the code in create_window to return GetDesktopWindow(), gives visual.c:196: Driver string: atiumdag.dl visual.c:197: Description string: ATI Ra visual.c:199: Device name string: \\.\DI visual.c:201: Driver version 8.14.10.678 visual: 5493 tests executed (0 marked as todo, 75 failures), 3 skipped. There's only 1 difference, the first one really shows a window with all the triangle's, like it should. Second one doesn't show anything. So all the functions don't fail, they just don't seem to do anything.
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
On Mon, Nov 15, 2010 at 12:06 AM, Roderick Colenbrander thunderbir...@gmail.com wrote: Hi Matijn, What 3D API is this game using? Is it using Direct3D or OpenGL? If it is Direct3D then I have the feeling the 'issue' is getting fixed in the wrong layer. It's using Direct3D, but I don't see how this can be fixed in Direct3D. Further I'm not really sure whether we want to allow pixel format 1 to be used at all. In case of Wine all pixel formats are hardware accelerated (okay, the bitmaps one are set to indirect rendering so might be software based depending on the GLX implementation). On Windows you essentially have two GL implementations namely the Microsoft GDI renderer and the OpenGL ICD driver. The first several pixel formats are the ones from the software based GDI renderer... So even though Windows might allow setting pixel format 1 on HDC 0, I don't think it is the right thing to do. Roderick Not setting the pixel format (e.g. just returning TRUE) won't help the game. Setting a different (hardware accelerated) format will probably work, but that doesn't feel right. I'd really like to fix this bug, but if the patch isn't right I don't have a clue how to fix it 'the right way'. Any hints? Thanks, Matijn ps. Trial for the game is available at: http://www.sandlotgames.com/w5/hearts_medicine_season_1.html (200MB), after installing run bin/prog.exe, launcher doesn't work. On Sun, Nov 14, 2010 at 9:55 AM, Matijn Woudt tijn...@gmail.com wrote: Add tests for special case of SetPixelFormat Tests pass on my Windows XP laptop and Windows 7 PC. The game 'Heart's Medicine Season One' depends on this behaviour.
[no subject]
Re: Wine users with a CD-ROM drive, please test
On Fri, Aug 13, 2010 at 3:03 PM, joerg-cyril.hoe...@t-systems.com wrote: Hi, I found out that some machines ignore set c audio all off which was in the testsuite, while others react to it and even update the system preferences volume mixer control if it happens to be open. I don't know whether that difference depends on the HW (CD-ROM driver) or the OS. You can find it out by posting your results here. I'm now using set c audio all on (which should be the default) such that all users running the testsuite get to hear something. https://testbot.winehq.org/JobDetails.pl?Key=4434 mcicda.c:612: Test failed: STOP all returned MCIERR_HARDWARE (I fixed that, but not yet on testbot). Regards, Jörg Höhle That fixed playback. One thing, with my Beethoven CD: mcicda.c:300: Test failed: status position initially 00:03:00 mcicda.c:306: Test failed: status position start 00:03:00 mcicda.c:350: Test failed: status position initially 3001ms IIRC, it can be anything, but should atleast be 2 seconds. - Matijn
Re: Wine users with a CD-ROM drive, please test
Test results from Windows 7 x64: I tried with original audio CD, and a burned copy, mcicda_test.exe and mcicda_test64.exe, and they all give: mcicda.c:270: CD length 46:20:53 mcicda.c:325: track #1 length 118107ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:15s:37frames mcicda.c:418: last track position: 42m:07s:16frames mcicda.c:425: Test failed: SEEK to 0035162E position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 1. mcicda: 64 tests executed (0 marked as todo, 2 failures), 2 skipped. David c/o paulo lesgaz wrote: mcicda.c:425: Test failed: SEEK to 00203A43 position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE Same as Jeff, please see if one of you can identify which prior MCI command causes this. Do you have any instructions how I can identify this?
Re: Implement ID3DXConstantTable::GetConstantDesc
On Tue, Jun 8, 2010 at 3:09 PM, Marvin test...@testbot.winehq.org wrote: 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=2526 Your paranoid android. === WINEBUILD (build) === Patch failed This one should be patch 4/4, then it will build correctly. Do I have to resend this one as 4/4 or do I have to resend the whole series?
Re: Call for translators
I totally agree (and have already talked to Francois a few times about this) that we need a nicer/better way for translators to help us out. Could it be integrated in http://source.winehq.org/transl/index.php? Having some sort of edit button there allowing people to translate it without having to send patches?
Re: software built and worked under wine but not in vista?
On Thu, May 20, 2010 at 3:54 AM, Hin-Tak Leung hintak_le...@yahoo.co.uk wrote: Saulius Krasuckas wrote: I sorry for stepping into Alexandre's or Dmitry's shoes, but.. * On Tue, 18 May 2010, Hin-Tak Leung wrote: So it seems that setupgs.exe is mis-compiled under wine with win7 sdk but just happened to also work under wine. Any idea how it might happen? ... there could be a pair of bugs: one in PE image manipulation functions plus another in Wine PE loading mechanism(s). I could imagine the first easily inside a IMAGEHLP, eg. functions ImageAddCertificate() or CheckSumMappedFile(). If you find the first one, then it should be possible to write a test to reveal the second one. I have checked things like end-of-line, but it is curious why the setupgs program works under wine but not in vista, the reverse situation compared to most. Could you build the same project under real Windows? Then I would run winedump dump -f or even -x on both files to compare the outputs (probably line by line) and to find the essential difference. I have gone ahead and done exactly that - the correct behavior should be a msg box saying filelist.txt is missing, rather than setupgs.exe not a valid win32 application. http://www.ghostscript.com/~hintak/setupgs-vista.exe http://www.ghostscript.com/~hintak/setupgs-wine.exe I haven't tried the uninstaller yet, so I don't know if the wine-built uninstaller work: http://www.ghostscript.com/~hintak/uninstgs-vista.exe http://www.ghostscript.com/~hintak/uninstgs-wine.exe To analyse the executables are a bit beyond me, but I hope somebody can do that. under either system, if I compile the file twice quickly, the result differs only by the datestamp and checksum (and in two wine-compiled executable built a bit of time between , also a few bytes in the .text section after what looks like an import table in a hex editor? There are a few differences I spotted between the two executables: 1) setupgs-wine.exe has wrong image size, changing it from 0x2b200 to 0x2b000 makes the executable working under win7. 2) setupgs-wine.exe has wrong resource size, probably related to 1), because the size of both executables are the same. 3) The assembly in setupgs-wine.exe has only LF line endings, vista has CRLF. This explains 2). I don't know the reason for 3), I assume it's a bug somewhere in wine.
Re: HLSL Compiler and d3dcompiler_xx.dll
On Thu, Apr 15, 2010 at 11:23 AM, Stefan Dösinger stefandoesin...@gmx.at wrote: Am 14.04.2010 um 20:45 schrieb Jason Green: FYI, we encountered a game a while back which used a few shaders that depended on being compiled with a particular version for d3dx9_##.dll. There was a compiler bug which the game engine knew about and accounted for. If you tried to use the compiled shader from a newer d3dx9_##.dll, then the rendering wouldn't look quite right on certain objects. So, there's one argument for identical bytecode compatibility, but it's likely that very few apps will exhibit behavior like this. I think it's only an argument that we may need some specific tests that check for identical bytecode. And by your description it sounds like the compiler bug can be detected by looking at the rendering output. I still think that having the majority of tests check the generated bytecode is a bad idea: * It will be hard to implement the same compiler result As long as it is possible, I think we should do. * It will make our own optimizations impossible(the MS compiler is very good optimization wise, so that point is mostly moot) * It will be hard to maintain the tests when we're moving them to a newer MS compiler version Tests should fail if a newer version of MS compiler is used and different code is produced. Or, if you prefer, win_skip if version is newer than what the tests expect. * There are things that can be translated into different bytecodes, and all are equally valid and optimal, like constants ordering. Same as your first concern.
HLSL Compiler and d3dcompiler_xx.dll
Hi, I'm about to implement the HLSL compiler, but I want to make sure I'm taking the right direction. For the compiler: preprocessor(wpp)-hlslparser/compiler(lex/bison)-bytecode writer(same as for the shader assembler). Now the question is where to implement the compiler. It can be called from at least 3 places, d3dx9_xx, d3d10_xx and d3dcompiler_xx. It seems to me that d3dx9_xx and d3d10_xx are forwarding their calls to d3dcompiler_xx. My proposal is: 1) Create the d3dcompiler_xx.dll structure in wine. Is it legal to use a program like dll export viewer to get the exported functions for each dll? 2) Move the assembler to d3dcompiler_xx.dll and forward calls from d3dx9. This is needed because the assembler and compiler can share the same bytecode writer this way. 3) Implement the compiler in d3dcompiler_xx. Regards, Matijn
Re: HLSL Compiler and d3dcompiler_xx.dll
On Wed, Apr 14, 2010 at 3:07 PM, Stefan Dösinger stefandoesin...@gmx.at wrote: Am 14.04.2010 um 13:08 schrieb Matijn Woudt: 2) Move the assembler to d3dcompiler_xx.dll and forward calls from d3dx9. This is needed because the assembler and compiler can share the same bytecode writer this way. When Mattheo implemented the assembler in the gsoc project we decided to put the assembler into d3dx9 because we assumed MS implements it there as well, and there are no assembler specific exports in d3dcompiler.dll. Using wine-internal exports is generally a bad idea and should only be used if there are clear advantages. (It e.g. makes it impossible to use the native d3dcompiler.dll with builtin d3dx9) In the last two versions of d3dcompiler (41 42), there's an undocumented export D3DAssemble, which makes me assume that MS has moved the Assembler there too. We can define D3DAssemble just like D3DXAssembleShader for now, and once Microsoft documents this function (or defines in d3dcompiler.h), we can adjust the definition if needed. Before moving the assembler into d3dcompiler.dll we have to be sure that sharing the bytecode writer is possible and is worth the problems it introduces. I'm not sure why sharing the bytecode writer wouldn't be possible. If the shader assembler is moved along, there shouldn't be problems (or am I missing something?). 3) Implement the compiler in d3dcompiler_xx. I wrote a basic HLSL compiler as university project in 2008, this is where part of the assembler code came from. Do you have the sources, do you need them? Matteo told me about it, and he was going to send your code to me after he checked if it was ok with you. But if you can send them to me directly, that's fine too, of course.
Re: HLSL Compiler and d3dcompiler_xx.dll
On Wed, Apr 14, 2010 at 4:27 PM, Stefan Dösinger stefandoesin...@gmx.at wrote: Am 14.04.2010 um 15:44 schrieb Henri Verbeet: On 14 April 2010 15:07, Stefan Dösinger stefandoesin...@gmx.at wrote: 3) Implement the compiler in d3dcompiler_xx. I wrote a basic HLSL compiler as university project in 2008, this is where part of the assembler code came from. Do you have the sources, do you need them? Quite frankly, I also believe that's where some of the issues in the early versions of those assembler patches came from. I don't know if that compiler has seen any work since 2008, but I'd be careful with taking it as too much of an example. Yep, I recommend using Mattheo's code if possible. He has rebased my old code and fixed a bunch of issues. Beyond that, my compiler is fairly minimalistic. I think it supports most features except arrays(needs loop unrolling support). However, the optimizer is fairly simplistic. For better optimizations you may want to investigate SSA transformations and related stuff. I guess perfect optimization isn't a requirement for a first version though. First thing would probably be cleaning up and getting something minimal past AJ. Just in case my git tree is here: http://84.112.174.163/~stefan/wine/ . It's not online all the time, and I am not guaranted a fixed IP(although it hasn't changed in years), so check it out as long as you can if you need it. Am I supposed to find your compiler code there? It seems like a git tree of ages ago (where d3dx9_36 only contains math and font code).
Re: HLSL Compiler and d3dcompiler_xx.dll
On Wed, Apr 14, 2010 at 4:51 PM, Roderick Colenbrander thunderbir...@gmail.com wrote: On Wed, Apr 14, 2010 at 4:38 PM, Matijn Woudt tijn...@gmail.com wrote: On Wed, Apr 14, 2010 at 4:27 PM, Stefan Dösinger stefandoesin...@gmx.at wrote: Am 14.04.2010 um 15:44 schrieb Henri Verbeet: On 14 April 2010 15:07, Stefan Dösinger stefandoesin...@gmx.at wrote: 3) Implement the compiler in d3dcompiler_xx. I wrote a basic HLSL compiler as university project in 2008, this is where part of the assembler code came from. Do you have the sources, do you need them? Quite frankly, I also believe that's where some of the issues in the early versions of those assembler patches came from. I don't know if that compiler has seen any work since 2008, but I'd be careful with taking it as too much of an example. Yep, I recommend using Mattheo's code if possible. He has rebased my old code and fixed a bunch of issues. Beyond that, my compiler is fairly minimalistic. I think it supports most features except arrays(needs loop unrolling support). However, the optimizer is fairly simplistic. For better optimizations you may want to investigate SSA transformations and related stuff. I guess perfect optimization isn't a requirement for a first version though. First thing would probably be cleaning up and getting something minimal past AJ. Just in case my git tree is here: http://84.112.174.163/~stefan/wine/ . It's not online all the time, and I am not guaranted a fixed IP(although it hasn't changed in years), so check it out as long as you can if you need it. Am I supposed to find your compiler code there? It seems like a git tree of ages ago (where d3dx9_36 only contains math and font code). It might also make sense to explore whether compilers like LLVM (used a lot these days including for OpenCL implementations by Apple, Nvidia; and don't forget Gallium3D) and Open64 (used in Cuda) and others. Roderick I have thought about using LLVM, but I don't like it because of: 1) Having another wine dependency (~40MB for me on ubuntu) 2) Code generated by LLVM will most likely not generated exactly the same bytecode as native compiler does, even though the shader has same effect on both. This makes it really hard to verify the HLSL compiler is working. My idea was to make wine's hlsl compiler produce exactly the same bytecode as native does. We might even find bugs in the native compiler, and either fix or duplicate these bugs. LLVM might be useful if we needed a really fast compiler, but native compiler isn't really fast AFAIK. Once games are calling it a few hundred times it might be worth the effort.
Re: HLSL Compiler and d3dcompiler_xx.dll
On Wed, Apr 14, 2010 at 5:59 PM, Matteo Bruni matteo.myst...@gmail.com wrote: 2010/4/14 Matijn Woudt tijn...@gmail.com: On Wed, Apr 14, 2010 at 4:27 PM, Stefan Dösinger stefandoesin...@gmx.at wrote: Am 14.04.2010 um 15:44 schrieb Henri Verbeet: On 14 April 2010 15:07, Stefan Dösinger stefandoesin...@gmx.at wrote: 3) Implement the compiler in d3dcompiler_xx. I wrote a basic HLSL compiler as university project in 2008, this is where part of the assembler code came from. Do you have the sources, do you need them? Quite frankly, I also believe that's where some of the issues in the early versions of those assembler patches came from. I don't know if that compiler has seen any work since 2008, but I'd be careful with taking it as too much of an example. Yep, I recommend using Mattheo's code if possible. He has rebased my old code and fixed a bunch of issues. Beyond that, my compiler is fairly minimalistic. I think it supports most features except arrays(needs loop unrolling support). However, the optimizer is fairly simplistic. For better optimizations you may want to investigate SSA transformations and related stuff. I guess perfect optimization isn't a requirement for a first version though. First thing would probably be cleaning up and getting something minimal past AJ. Just in case my git tree is here: http://84.112.174.163/~stefan/wine/ . It's not online all the time, and I am not guaranted a fixed IP(although it hasn't changed in years), so check it out as long as you can if you need it. Am I supposed to find your compiler code there? It seems like a git tree of ages ago (where d3dx9_36 only contains math and font code). Yeah, Stefan's project is based on wine 1.1.0 and you can find the relevant code into dlls/wineshader. One of the things I did was to port the assembler to current wine and move it into d3dx9_36.dll. In the process I changed quite some things all around and I stripped from the bytecode writer what wasn't needed by the assembler. I didn't update the compiler code, and as Henri said, at this point probably it's better to just continue what you are doing and look at Stefan's implementation only as a source for inspiration. dlls/wineshader doesn't exist in that tree? As d3dcompiler_xx.dll now seems to contain also the assembler, I'm ok to move the assembler there (once completed) to share the bytecode writer with the compiler. Regarding the optimization, I'd suggest to keep it simple in the beginning. I liked the idea in Stefan's compiler to have a parser which produces an abstract intermediate representation, which is then optimized to generate the bwriter_shader. The optimizer could then be implemented from scratch, or using something third-party as LLVM or such, while as a first step the optimizer could (ideally) simply spit out the code unchanged. I believe that some language features cannot be supported without some optimizations, so this problem can crop up sooner than expected. That's the direction I wanted to take indeed. The optimizer should at some point optimize according to the flag setting. At first, I would only create test cases with D3DXSHADER_SKIPOPTIMIZATION. Lastly, a bit on testing the compiler. I'm not sure trying to get exactly the same bytecode as native is a feasible objective: while for an assembler program there is only one correct translation, this is not true for a compiler. Moreover I expect each iteration of the Microsoft compiler could produce a different output with the same shader program, so there isn't a right implementation to compare with. I agree, this makes testing the compiler much harder... I think that with a lot of testing, the logic behind can be figured out. Then the compiler can be built around this logic. This could possibly even work for a lot of optimizations. On Wed, Apr 14, 2010 at 5:44 PM, Roderick Colenbrander thunderbir...@gmail.com wrote: My main worry is that in the end if we use a compiler framework (remember we don't have a lot of manpower for this) I think it would reduce in more efficient shaders and it prevents some reinventing of the wheel. I'm still not convinced it's worth the effort. Also, I think that a parser/compiler written in lex/bison is much easier for other developers to understand and maintain once it is in the tree (And probably also a lot easier to review patches).
Re: HLSL Compiler and d3dcompiler_xx.dll
On Wed, Apr 14, 2010 at 6:47 PM, Matteo Bruni matteo.myst...@gmail.com wrote: dlls/wineshader doesn't exist in that tree? Check if you are in the correct branch (should be the compiler branch in his tree). Right, my mistake. Lastly, a bit on testing the compiler. I'm not sure trying to get exactly the same bytecode as native is a feasible objective: while for an assembler program there is only one correct translation, this is not true for a compiler. Moreover I expect each iteration of the Microsoft compiler could produce a different output with the same shader program, so there isn't a right implementation to compare with. I agree, this makes testing the compiler much harder... I think that with a lot of testing, the logic behind can be figured out. Then the compiler can be built around this logic. This could possibly even work for a lot of optimizations. What I mean is that there could not be a single logic behind, I expect to find differences between the various d3dcompiler_xx dlls, expecially regarding the optimizations. You could just pick a version to compare against and try to stick with that, but maybe this is not the best thing to do. On the other hand, with optimizations disabled maybe this doable (but then you aren't testing the optimizer). It should be same as the latest version available (currently version 42). Changes in the logic when a new version comes out will be caught by test cases. We probably shouldn't directly fail, but perhaps mark it todo_wine when it fails with newer version?
Re: HLSL Compiler and d3dcompiler_xx.dll
On Wed, Apr 14, 2010 at 7:29 PM, Henri Verbeet hverb...@gmail.com wrote: On 14 April 2010 17:19, Matijn Woudt tijn...@gmail.com wrote: I have thought about using LLVM, but I don't like it because of: 1) Having another wine dependency (~40MB for me on ubuntu) 2) Code generated by LLVM will most likely not generated exactly the same bytecode as native compiler does, even though the shader has same effect on both. This makes it really hard to verify the HLSL compiler is working. My idea was to make wine's hlsl compiler produce exactly the same bytecode as native does. We might even find bugs in the native compiler, and either fix or duplicate these bugs. LLVM might be useful if we needed a really fast compiler, but native compiler isn't really fast AFAIK. Once games are calling it a few hundred times it might be worth the effort. I think you want to test if the compiled shader works instead of the exact bytecode. Generating the same bytecode is probably way too hard, fragile to test, and most likely not worth the effort. I think I should go for exact bytecode as long as it is possible, it's the only way we can be sure the implementation is 100% right for each test case. I'm not sure about LLVM. On one hand I don't think we want to be writing and maintaining all the optimizations that LLVM can do inside the d3d compiler dll. On the other hand, it would be a pretty large dependency, and it's not clear if it would gain us anything at all. It's not entirely unlikely that if the driver we're running on has a good GLSL compiler we're not going to see much of a benefit from generating good d3d bytecode. (I can already hear the Mesa people laughing about that one though.) Either way, it would probably already be a good start to have a parser, and generate some basic unoptimized bytecode from that, or even just print an AST. Right, it's probably better to go ahead first, and implement LLVM once we find it necessary (if ever).
Re: HLSL Compiler and d3dcompiler_xx.dll
On Wed, Apr 14, 2010 at 7:30 PM, Roderick Colenbrander thunderbir...@gmail.com wrote: On Wed, Apr 14, 2010 at 7:22 PM, Matijn Woudt tijn...@gmail.com wrote: On Wed, Apr 14, 2010 at 6:47 PM, Matteo Bruni matteo.myst...@gmail.com wrote: dlls/wineshader doesn't exist in that tree? Check if you are in the correct branch (should be the compiler branch in his tree). Right, my mistake. Lastly, a bit on testing the compiler. I'm not sure trying to get exactly the same bytecode as native is a feasible objective: while for an assembler program there is only one correct translation, this is not true for a compiler. Moreover I expect each iteration of the Microsoft compiler could produce a different output with the same shader program, so there isn't a right implementation to compare with. I agree, this makes testing the compiler much harder... I think that with a lot of testing, the logic behind can be figured out. Then the compiler can be built around this logic. This could possibly even work for a lot of optimizations. What I mean is that there could not be a single logic behind, I expect to find differences between the various d3dcompiler_xx dlls, expecially regarding the optimizations. You could just pick a version to compare against and try to stick with that, but maybe this is not the best thing to do. On the other hand, with optimizations disabled maybe this doable (but then you aren't testing the optimizer). It should be same as the latest version available (currently version 42). Changes in the logic when a new version comes out will be caught by test cases. We probably shouldn't directly fail, but perhaps mark it todo_wine when it fails with newer version? Also remember that perhaps based on gpu capabilities (even on different SM3.0 capable GPUs) some different code might get generated. One good reason for not having the same code is vertex / pixel shader constants. For some games d3d9x selects uniforms constants which are close to the SM3.0 limits (wined3d eats a number of constants) and this can cause major issues especially on Geforce6/7 and AMD cards (even modern AMD cards only report SM3.0 limits using glsl; you need UBOs to get more). When we have our own compiler we can 'schedule' the constants in such a way that we might be able to avoid these issues. This leads to different shaders. It is not something to worry about now. I think you just want to focus on rendering tests to see if the shader does the right thing. Roderick I think, for now, we should pass D3DXSHADER_SKIPVALIDATION to the compiler, so the code won't be checked for GPU capabilities. I'm not sure if different code is generated when GPU capabilities are low, but I think it's safe to fail if we request too many constants. In test cases we could check D3DCAPS9 and skip if needed.
Re: New winetricks 20090716: new verbs droid, wenquanyi, dinput8
(to the list this time) On Fri, Jul 17, 2009 at 1:54 AM, Ben Kleinshackl...@gmail.com wrote: 2009/7/16 Hin-Tak Leung hintak_le...@yahoo.co.uk: I have decided against responding to the chinese thread (so much mis-information, ignorance and wrongful entitlement in it, and little substance), but I like to point out that the wenquanyi fonts are shipped with fedora 11. Not sure about fedora 10, but he just needs to upgrade his OS (apparently he is on fedora 10?) to get it, no need to badger the wine people or winetricks. Ubuntu/suse people please comment. On Debian unstable (amd64): $ apt-cache search wenquanyi ttf-wqy-microhei - A droid derived Sans-Seri style CJK font ttf-wqy-zenhei - WenQuanYi Zen Hei A Hei-Ti Style (sans-serif) Chinese font xfonts-wqy - WenQuanYi Bitmap Song CJK font for X Same on latest (K)unbuntu: $ apt-cache search wenquanyi ttf-wqy-zenhei - WenQuanYi Zen Hei A Hei-Ti Style (sans-serif) Chinese font xfonts-wqy - WenQuanYi Bitmap Song CJK font for X ttf-wqy-microhei - A droid derived Sans-Seri style CJK font Though, only ttf-wgy-zenhei was installed by default on my machine.
Re: [Request for review] wrc: Add support for nameID with quotes
On Wed, Jun 3, 2009 at 9:28 AM, Alexandre Julliard julli...@winehq.org wrote:
Tijnema tijn...@gmail.com writes:
Hello all,
I was just checking around some old bugs and found 786 still opened. I've
written a patch for it, but I want to know if I'm anywhere close to get it
in.
That would be a good way to handle quoted strings, but that's not what
Windows does. It doesn't really handle them, the quotes are simply
copied through. You can probably even put quotes in the middle of the
name. The behavior of the RC parser can be quite mysterious at times.
Thanks, didn't notice that one. I've checked it with the rc from
visual studio 2008 and you're right, it's really mysterious(just like
the rest of windows). Single and double quotes are just copied, but
only if they are in pairs. Though, there can be a single quote within
two double quotes, and the other way around.
I've attached a patch for this behaviour, is it ready to send to wine-patches?
Matijn Woudt
From 6064f93f1d0479efa5da627045c693dde8d69f8c Mon Sep 17 00:00:00 2001
From: Matijn Woudt tijn...@gmail.com
Date: Wed, 3 Jun 2009 12:42:21 +0200
Subject: wrc: Add support for nameID with single and double quotes.
---
tools/wrc/parser.l |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/wrc/parser.l b/tools/wrc/parser.l
index bddc309..be73068 100644
--- a/tools/wrc/parser.l
+++ b/tools/wrc/parser.l
@@ -404,7 +404,7 @@ static unsigned long xstrtoul(const char *nptr, char
**endptr, int base)
* and *only* in a filename. In this case, the second
* rule will be reduced because it is longer.
*/
-[A-Za-z_0-9.]+ {
+((['][A-Za-z_0-9.]+['])|([]['A-Za-z_0-9.]+[])|([A-Za-z_0-9.]+))+{
struct keyword *tok = iskeyword(yytext);
if(tok)
--
1.6.0.4
