April 2010 - Wine-devel - list.winehq.org

tuxradar's map of linux audio
by Dan Kegel 09 Apr '10

09 Apr '10

This seemed like a useful overview of how the various layers relate to each other: http://tuxradar.com/content/how-it-works-linux-audio-explained

5 5

Re: shlwapi: Skip tests on IE < 6 (try 2)
by Alexandre Julliard 09 Apr '10

09 Apr '10

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -617,6 +617,12 @@ static void test_UrlGetPart(void) > dwSize = sizeof szPart; > szPart[0]='x'; szPart[1]=0; > res = pUrlGetPartA("hi", szPart, &dwSize, URL_PART_SCHEME, 0); > + > + if (res) { > + win_skip("probably too old IE\n"); > + return; > + } There's no reason to skip the whole thing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oleaut32: be more explicit with locale dependent parsing of dates
by Alexandre Julliard 09 Apr '10

09 Apr '10

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -7708,7 +7708,7 @@ HRESULT WINAPI VarDateFromStr(OLECHAR* strIn, LCID lcid, ULONG dwFlags, DATE* pd > break; > > case 0x1B: /* localized DDDTTT */ > - if (!iDate) > + if (PRIMARYLANGID(lcid) != LANG_GERMAN) Obviously you cannot hardcode specific locales like that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: loader: Fix French translation of wine manpage
by Nicolas Le Cam 09 Apr '10

09 Apr '10

Hi Frédéric, >+\fIwineserver\fR dans le chemin système ou quelques autres emplacements vraisemblables. >[...] >+"wine" dans le chemin système ou quelques autres emplacements vraisemblables. Even if "likely" literally means "vraisemblable" I think the previous use of "potentiel" or even "possible" suits better. >+n'est spécifiée, le caractère + peut être omis. Notez que les espaces ne sont pas >+autorisées dans cette chaîne de caractères. Should be "autorisés" >+Définit le type de remplacement et l'ordre de chargement des DLL utilisées lors du >+processus de chargement d'une DLL. Le comportement par défaut est spécifié dans le >+fichier de configuration. Deux types de bibliothèques peuvent actuellement être chargées >+dans l'espace d'adressage d'un processus : les DLL natives de >+Windows Should be "chargés" Thanks for your work. -- Nicolas Le Cam

1 0

Google Summer of Code
by Jasneet Singh 08 Apr '10

08 Apr '10

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

2 1

a new trick to add to winetricks
by Troy Wolbrink 08 Apr '10

08 Apr '10

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

4 7

[GSoC] IUri Implementations
by Thomas Mullaly 08 Apr '10

08 Apr '10

Hi, my name is Thomas Mullaly and I am a undergraduate in the Computer Science department at Kent State University and I would very much like to participate in this years GSoC. I saw under your project ideas page that the IUri API still needs implemented and I thought that this would be a good project for me, but, before I submit a proposal on it I have a few questions about the project itself. Firstly, on the project page it says that the main goal is to have the IUri interface and CreateUri function implemented, but, on MSDN they also have functions and interfaces for creating/manipulating IUriBuilder's and I was wondering if these were also part of the project goals. If not can they be or would this be to ambitious to have finished by the end of the summer. Secondly (more of a design question), I see that the Uri structure and functions are already stubbed out in the "dlls/urlmon/uri.c" file and I was thinking for my implementation I would add another BSTR* member to the Uri struct, which will point to the encoded version of the URI (which will be generated during the CreateUri() call). Since most of the functions that interact with the IUri return components of the URI (e.g. scheme, host, query, etc.) I was thinking about adding more data members to the Uri struct which store the location in the encoded Uri string where each component exists (or -1 if it does not exist) and by doing this the runtimes of the IUri functions will be reduced since the function will already know where to look inside the encoded string for the component it needs. A drawback to this design is that each Uri struct will be bloated with a decent amount of ints which may or may not be used depending on the type of the URI that the IUri represents. The second approach I was thinking of is to not store any locations inside the Uri struct and to compute them on the fly every time the IUri is queried for one of its components, this would result in a smaller memory footprint of the Uri structure but will increase the runtimes of all the functions that access the URI. I was wondering if anyone might have suggestions for which way they think might be better. Any input will be greatly appreciated! -Thomas Mullaly

3 6

Re: winmm: MCI system commands are not eligible for auto-open.
by Alexandre Julliard 08 Apr '10

08 Apr '10

<Joerg-Cyril.Hoehle(a)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 0000 from command sound notify mci.c:820: Tests skipped: Skipping auto-open tests in Wine make[1]: *** [mci.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/3] d3dx9: Add swizzle and writemask support to the shader assembler.
by Henri Verbeet 08 Apr '10

08 Apr '10

On 8 April 2010 14:20, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Wouldn't it make a lot more sense to simply define a swizzle as something like "([xyzw]{1,4})|([rgba]{1,4})" and handle write masks separately?

1 0

[PATCH 1/2] ntdll: Queue WT_EXECUTEINTIMERTHREAD timers as APC
by Joerg-Cyril.Hoehle＠t-systems.com 08 Apr '10

08 Apr '10

>According to the windows documentation about CreateTimerQueueTimer its >how its done. Indeed, and I believe MS puts APC to even more uses than documented, c.f. http://bugs.winehq.org/show_bug.cgi?id=3930#c37 Maybe there are other places where Wine ought to use APC. One issue with APC for WINMM is that one needs further tests to investigate which call causes memoization of the GetCurrentThread() field to which the callback will be delivered? - Is is the thread that called midiOpen? - The thread that called midiWrite? BTW, would it be ok for Wine to a) include a patch that introduces version-specific behaviour (as mentioned in the above bug)? b) Or should Wine's WINMM generally behave like Win9X because it's old and many newer apps use another API? c) Like W2k/xp/7 because that's what's current now. Regards, Jörg Höhle

1 0