June 2009 - Wine-devel - list.winehq.org

Re: advpack: Implement ExtractFilesW [try 2]
by James Hawkins 19 Jun '09

19 Jun '09

2009/6/11 Vladimir Pankratov <scriptkid(a)mail.ru>: > Hello all. > > Implemented ExtractFilesW > > Changed files: > advpack/files.c > + if (GetFileAttributesA(ExpandDir) == INVALID_FILE_ATTRIBUTES) + return HRESULT_FROM_WIN32(ERROR_PATH_NOT_FOUND); Why are you testing this in ExtractFilesA? Almost all of the logic should be passed on to ExtractFilesW so we don't duplicate code. + if (FileList != NULL) Please don't change the style of the file. if (FileList) is fine. + WideCharToMultiByte( CP_ACP, 0, FileList, -1, szFileList, sizeof(szFileList), NULL, NULL ); + szConvertedList = convert_file_list(szFileList, &dwFileCount); I'm not sure this is the way to go. You're converting A -> W -> A. This happens because cabinet.Extract is (as far as we know) ansi-only. In this case, I think it's ok to make ExtractFilesW call into ExtractFilesA, with an appropriate comment as to why this is happening. -- James Hawkins

2 1

Looking for a fast way to clean up AppDB comments
by Florian Köberle 19 Jun '09

19 Jun '09

Hi, I now became one of the application maintainers of Warcraft 3 The Frozen Throne and got asked to cleanup the comments. I started to do so, but there are just to much comments. I stopped deleting with 459 comments remaining. See: (http://appdb.winehq.org/objectManager.php?sClass=version&iId=3126) Is there a way to delete multiple comments at once? E.g. it would be cool if I could just check the comments to delete and hit then a button "delete selected comments" which opens the dialogue for the delete reason. Or some button "Delete all comments older then one year" would be quite useful. Best regards, Florian Köberle

4 4

NT4 passing
by André Hentschel 19 Jun '09

19 Jun '09

WinNT4 is passing now for the first time since a long time(maybe since ever?). So special congratulations to Paul Vriens, who spent much time making the test-suite run on NT4. This is a great step for the test-suite. Now NT4, 2K, XP and 2K3 are passing partially. Keep it up!

4 6

Wine MIME handling
by Roderick Colenbrander 18 Jun '09

18 Jun '09

Hi, For the past few days I have been looking at MIME handling in Wine. A program I'm using uses CreateProcess to launch a pdf file and I would like to use the default native pdf viewer. Initially I wrote a simple script which calls xdg-open to launch the file offered by Wine. (xdg-open "`wine winepath -u "$1"`") The script works properly and it could be used for all sorts of file formats. It would be useful to have a 'winemime' mechanism for this in Wine (either a script, program or shell32 code). The issue could be solved in different ways. For instance there is already some XDG MIME code in shell32 which could be extended, a winebrowser-like winelib program could be written or we could use a script. Personally I would favor either of the last two solutions. The main downside of a script is that as far as I know I need to set the whole linux path (e.g. /usr/local/bin/winemime) in the registry and this could be avoided if the tool was a winelib program as it would be in the wine path by default. Second I would like not to depend on the xds-open script on linux but have this code merged inside winemime. A winelib based winemime would be very similar to winebrowser, so if we would go the winelib way might it make sense to extend winebrowser for this? I hope to get some feedback and suggestions on how to proceed before I start writing code. Thanks, Roderick Colenbrander

2 3

Re: user32/tests: Added tests for DrawIcon and DrawIconEx (try 6)
by Joel Holdsworth 18 Jun '09

18 Jun '09

> cursoricon.c:1039: Test failed: Overlaying Mask 0 on Color 00A0B0C0 with DrawIcon. Expected 00003163 (modern), or 00003868 (legacy). Got 000020B8 from line 1109 > cursoricon.c:1039: Test failed: Overlaying Mask 1 on Color 00A0B0C0 with DrawIcon. Expected 00FFCE9C (modern), or 00FFD0A0 (legacy). Got 00FFE850 from line 1110 > cursoricon.c:1039: Test failed: Overlaying Mask 0 on Color FFA0B0C0 with DrawIcon. Expected 00003163 (modern), or 00003868 (legacy). Got 000020B8 from line 1112 > cursoricon.c:1039: Test failed: Overlaying Mask 1 on Color FFA0B0C0 with DrawIcon. Expected 00FFCE9C (modern), or 00FFD0A0 (legacy). Got 00FFE850 from line 1113 > cursoricon.c:1039: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIcon. Expected 00003163 (modern), or 00003868 (legacy). Got 000020B8 from line 1114 > cursoricon.c:1039: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIcon. Expected 00FFCE9C (modern), or 00FFD0A0 (legacy). Got 00FFE850 from line 1115 > cursoricon.c:1171: Test failed: Overlaying Mask 0 on Color 00A0B0C0 with DrawIconEx flags 00000003. Expected 00003163 (modern) or 00003868 (legacy). Got 000020B8 from line 1256 > cursoricon.c:1171: Test failed: Overlaying Mask 1 on Color 00A0B0C0 with DrawIconEx flags 00000003. Expected 00FFCE9C (modern) or 00FFD0A0 (legacy). Got 00FFE850 from line 1257 > cursoricon.c:1171: Test failed: Overlaying Mask 0 on Color FFA0B0C0 with DrawIconEx flags 00000003. Expected 00003163 (modern) or 00003868 (legacy). Got 000020B8 from line 1259 > cursoricon.c:1171: Test failed: Overlaying Mask 1 on Color FFA0B0C0 with DrawIconEx flags 00000003. Expected 00FFCE9C (modern) or 00FFD0A0 (legacy). Got 00FFE850 from line 1260 > cursoricon.c:1171: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIconEx flags 00000003. Expected 00003163 (modern) or 00003868 (legacy). Got 000020B8 from line 1261 > cursoricon.c:1171: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIconEx flags 00000003. Expected 00FFCE9C (modern) or 00FFD0A0 (legacy). Got 00FFE850 from line 1262 > I've tracked down the problems with an NT4 VM. The problem comes when screen depth is set to less than 32-bit. Even though I'm drawing from an icon made from 32-bit bitmaps, and making DrawIcon draw to a 32-bit DIB section, old versions of windows don't respect that, and will truncate the color data. In 16-bit only the top 5 bits of a color channels emerge ungarbled, and in 8-bit and less, the colors go via the palette (logical palette?), which knocks them completely off. The most obvious solution would be something like this as a color test: const int screen_bpp = GetDeviceCaps(hdc, BITSPIXEL); ok (result == modern_expected || /* Windows 2000 and up */ broken(result == legacy_expected) || /* Windows NT 4.0, 9X and below */ broken((result & 0x00F8F8F8) == (legacy_expected & 0x00F8F8F8) && screen_bpp == 16) || broken(result != legacy_expected && screen_bpp <= 8), How acceptable would that be?

2 3

Sugestion to Wine
by Sérgio R. da Silva 18 Jun '09

18 Jun '09

Hello to all developers of wine. My name is Sergio R. da Silva, and I sent some suggestions to improve the wine. First of all I apologize for any errors in spelling, because I am Brazilian and I do not know very well and I write in English using Google Translator to send these suggestions and also send the wrong address, if possible please move to the correct department or send me an email where I send my suggestions. Here are my suggestions: 1) I suggest that in the file. Conf of wine is possible to configure other extensions without the DLL, such as OCX, EXE, CAB, etc.. or create a tab to add these extensions, this flap could be close to the tab "Libraries" and could be called "Extensions" which add extensions without which DLL that windows USA, such as. CAB,. ini (boot.ini). bat (autoexec.bat). msc (gpedit.msc). config,. sys ( pagefile.sys, etc.). This is my first suggestion will soon send more. PS: If you have any questions about my suggestion is just send me an email to sergiordasilva17(a)gmail.com

2 1

[Bug 18786] patch
by Guy Albertelli 18 Jun '09

18 Jun '09

Hello Juan, Could you look at bug 18786 and my suggested patch to get MINITAB working again. It is a partial revert of one of your patches from 6/25/08 (see comment #7). I have verified that the associated tests (dlls/inetmib1/tests/main.c) exercise that code both pre and post revert. However the tests don't detect an error either way. I know nothing about this code. Thanks, Guy

2 2

Fate of PulseAudio in WINE
by Arthur Taylor 18 Jun '09

18 Jun '09

Recent activity in http://bugs.winehq.org/show_bug.cgi?id=10495 has caused some issues. This is also a response to http://www.winehq.org/pipermail/wine-devel/2009-April/074666.html First the background. WinePulse has been an attempt to write a winmm backend for pulseaudio for wine. Currently the primary audio system used by wine is through winmm.dll which sends messages to a backend which basically represents the MS waveOut and waveIn APIs. WaveOut works through wavehdrs, a single-linked list structure which contains a data field pointing at a buffer. Applications feed wavehdrs via waveOutWrite and receive a message when they have finished being played. wavehdrs can be formed into loops using flags. This is all simple enough except for how variable it is. Applications usually allocate a set size of wavehdrs and then use them circularly. Applications usually use when a wavehdr is returned for timing purposes rather than waveOutGetPosition. The number of wavehdrs and their sizes is entirely up to the application. There are two common problems with audio drivers implementing this system. The first is drivers which return a wavehdr as soon as it is written to output (waveesd.dr for example) as it will cause timing issues for applications when large batches of wavehdrs are returned at once. The second problem is when a windows application makes a smaller buffer of wavehdrs than the backend provides. In this case wavehdrs are not returned because they have not been played, and no more data can be written to fill the buffer because all the wavehdrs are waiting to be returned from the playback that is stalled. This can happen with alsa on top of plugins. If the buffered wavehdrs and playback buffer are very close in size sometimes the audio stutters by, oscillating to and from underrun and playback. Winepulse attempts to overcome these problems. It returns wavehdrs accurately and avoids stalls by modifying the pulseaudio server buffer size. In tests it works consistently. Most of the people I've had contact with have been positive toward development of such a backend. That said, the response from wine developers has been overwhelmingly negative. I can understand the desire for only clean and maintainable code to be considered for submissions. However, often it appears that the rejection is wholly philosophical rather than logical. Continual reports of problems are always contributed to silly users who are not using ALSA on top of direct hardware. I do not dislike either ALSA nor winealsa.drv, but I do reject this skepticism toward a world of Linux audio beyond SB-16 style "direct hardware." The arguments that PulseAudio adds latency or is not suitable for professional audio are not relevant to the issue of whether or not a pulseaudio backend for wine should be added. The _addition_ of said backend _enables_ audio in wine for those who _choose_ to use pulseaudio. I can't imagine stopping pulseaudio just so I can listen to music through foobar2000, as that would stop all my voice chats, notification sounds, and other native audio, etc. For those whom pulseaudio is not appropriate, the other backends would still exist and pulseaudio can either be disabled temporarily via pasuspender, not started or not installed. That said, latency in pulseaudio is managed and through the winepulse patch exposed to the windows application. The daemon is usually run with realtime priority and will use data buffers if the requesting application locks temporarily, allowing less worry with recording. The method of audio playback and capture through waveOut and waveIn are quite broken. Even if winealsa uses the "safe ALSA api subset" it means that the poor and varied behaviours are translated to poor and varied alsa calls (DSound HEL is an exception here.) The winepulse patch attempts to overcome these issues by buffering sanely while trying to keep applications happy in a _consistant_ way. It is true that currently whitespace is an issue with the patches in the bug report. I will work to resolve this. The file was (supposed to be) indented using 4 spaces as this was the convention in all the other audio backends. Frankly, calling the code a search and replace from ALSA to PULSE is insulting. If this is true then it is therefore true that winealsa was a search and replace from OSS to ALSA. Almost all the wine audio backends share a common ancestor. The latest patch does not contain comment out code. There has been no *useful assistance* from wine developers (re "No Fucking Way"). As for which parts of the code aren't wine-64 ready, could you please expand? A detailed, constructive response with a clear vision for where the future of audio in wine lies would be appreciated. Thanks -- Arthur Taylor art(a)ified.ca theycallhimart(a)gmail.com

12 15

[review] np2 fixup patch for ARB path
by Tobias Jakobi 17 Jun '09

17 Jun '09

You can find the current patchset here: http://www.math.uni-bielefeld.de/~tjakobi/wine/np2fixup_arb/ Of course the GLSL patchset is needed as well: http://www.math.uni-bielefeld.de/~tjakobi/wine/np2fixup_glsl/ I hope both can finally go into master, so please take a look. Going to resend the GLSL part tomorrow if they don't make it in by then. Greets, Tobias

1 0

Re: [3/6] WineD3D: Handle SM 3.0 varyings in ARB
by Henri Verbeet 17 Jun '09

17 Jun '09

2009/6/17 Stefan Dösinger <stefan(a)codeweavers.com>: > > +struct wine_rb_functions sig_tree_functions = > +{ > + sig_tree_alloc, > + sig_tree_realloc, > + sig_tree_free, > + sig_tree_compare > +}; Sorry for not mentioning this before, but you can just use wined3d_rb_alloc() etc. for that. wine_rb_init() can fail, although it should be rare enough that you might not care.

1 0