June 2006 - Wine-Devel - list.winehq.org

RE: Win64 patch 1/13

by Ge van Geldorp

> From: Mike McCormack [mailto:mike(a)codeweavers.com] > > > Except that dlls/ntdll/tests/generated.c was hand-modified. > > That would explain the rather large diff that I saw when I > regenerated these tests :/ Sorry, I mixed up two files :( I have no evidence that dlls/ntdll/tests/generated.c was hand-modified (dlls/oleaut32/oaidl_p.c, another file for which I sent a patch, was). After updating to current git I saw that you already changed tools/winapi/tests.dat, but it seems the tests were not regenerated (so the dlls/*/tests/generated.c files are out of sync). Should I send a patch with the regenerated files or is it easier if Alexandre just runs tools/winapi/winapi_test? Gé van Geldorp.

June 20, 2006

ddraw assert prevents Ankh from starting

by Christoph Frick

hiho on the end of this mail is a patch, that removes an assert(0) from the surface code in ddraw. but removing it let Ankh[1][2] start (it started before, but there where no loading screen visible). yet there are other problems with this game - but it now actually works better than before. so let the ddraw developers decide what to do there - this mail is just a reminder, that there is a poor little homeless assert, that needs your attention ;) [1] german demo: http://www.gamershell.com/download_12062.shtml [2] engl. demo: http://www.gamershell.com/download_12202.shtml -- cu Index: dlls/ddraw/surface.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/surface.c,v retrieving revision 1.4 diff -u -r1.4 surface.c --- dlls/ddraw/surface.c 19 Jun 2006 10:44:41 -0000 1.4 +++ dlls/ddraw/surface.c 20 Jun 2006 07:10:07 -0000 @@ -1865,7 +1865,6 @@ WINED3DFORMAT newFormat = WINED3DFMT_UNKNOWN; HRESULT hr; FIXME("(%p)->(%p,%lx)\n", This, DDSD, Flags); - assert(0); if(!DDSD) return DDERR_INVALIDPARAMS;

June 20, 2006

Re: Win64 status

by Alexandre Julliard

"Ge van Geldorp" <ge(a)gse.nl> writes: > __attribute__ seems most logical to me. Perhaps __attribute__(__msvccall__) > (in the __attribute__(__stdcall__) tradition? An alternative to -msvc could > perhaps be -mrtd ("Alternate calling convention"). For i386 builds of gcc, > -mrtd makes stdcall the default calling convention. It is currently a noop > for x86_64. I kind of like your -msvc though :-) > For Wine the compiler option seems more important then the override. Just the other way around actually, Wine can't use a global option since we have to call Unix functions. The only way is to have an explicit attribute on Windows APIs. -- Alexandre Julliard julliard(a)winehq.org

June 20, 2006

Re: MSI database _Streams table

by Andrey Turkin

Dan Kegel wrote: > In http://www.winehq.org/pipermail/wine-patches/2006-June/027528.html, > Andrey Turkin wrote: > >> Some installers depends on _Streams built-in table > > Which installers? > It'd be nice to have a bug in bugzilla to hang your MSI work on. > Thanks! > - Dan > For example, Microsoft's .NET Framework 1.1 installer. With my MSI fixes it almost completes install, but fails inside .NET programs (RegSvcs).

June 20, 2006

Re: Win64 patch 9/13

by Dmitry Timoshkov

"Ge van Geldorp" <ge(a)gse.nl> wrote: > - GWL_HINSTANCE is not defined on Win64, hInstance is documented as not > required in CreateWindowEx calls > - HINSTANCE hInstance = (HINSTANCE)GetWindowLong(hWnd, GWL_HINSTANCE); > + HINSTANCE hInstance; Please use HINSTANCE hInstance = GetWindowLongPtr(hWnd, GWLP_HINSTANCE); instead. -- Dmitry.

June 19, 2006

Re: ntoskrnl status

by Mike McCormack

Saulius Krasuckas wrote: >> http://wiki.winehq.org/GitWine seems to be more oriented at making >> patches, not importing a patch made by someone else. > $ cat origin_sd1.diff | patch -p1 > $ tools/make_requests > $ git commit -a -m "ntoskrnl: Experimental implementation." If the patch is created with "git format-message", you can use "git am origin_sd1.diff" to add it to your tree. 'am' applies a mailbox, which is a series of patches and their commit info. Mike

June 19, 2006

Re: ntoskrnl status

by Saulius Krasuckas

* On Tue, 20 Jun 2006, Jaap Stolk wrote: > I uninstalled and deleted my cvs wine, updated python and installed > git, and completed "Cloning the Wine GIT repository". I had a little > peek at the patch by renaming it to .bz2, but how do I add this patch > to to my local wine copy, using git ? I'd make some experimental branch or "master" or defined commit, then patch it with given diff, and commit the changes under single name. > http://wiki.winehq.org/GitWine seems to be more oriented at making > patches, not importing a patch made by someone else. $ bunzip2 --keep origin_sd1.diff.bz2 $ git branch ntoskrnl 1d40bf0141b7f67b1188555962698f5dab631bc3 $ git branch $ git checkout ntoskrnl $ git branch $ cat origin_sd1.diff | patch -p1 $ tools/make_requests $ git commit -a -m "ntoskrnl: Experimental implementation." # recompile Wine $ ./configure && make depend && make && tools/wineprefixcreate --use-wine-tree . # below goes your experiments $ ... # and here we go back to the normal tree $ git checkout master # recompile Wine $ ./configure && make depend && make && tools/wineprefixcreate --use-wine-tree . # and do our stuff $ ...

June 19, 2006

Re: Winelib Getting Started 1.3.2. Test Drive

by Robert Muller

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dee Ayy wrote: | As a newbie, the statement "It can be found in the programs subdirectory." | had me lost. It seems that the Winelib guide assumes that you know how to download the wine sources already. (Quick and dirty meathod of downloading the latest official tarball: On the main WineHQ page, the latest announcement "Wine 0.9.x released" or somesuch has a link "available now"; move it to an appropriate place, then unarchive it: $tar -xjf wine-0.9.15.tar.bz2 <or somesuch>) At this point, the sentance that gave you problems could be modified to say: It can be found in the programs subdirectory of the wine source. - -RFMuller -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFElz0yjfMdLxNd9ZERAqW4AKD2XDfJCevbr/qipE4mT0FVhX60eQCgzSm0 Hp4nNg6jwdIsMrik6hA7kFs= =lg1u -----END PGP SIGNATURE-----

June 19, 2006

Re: Win64 status

by Kuba Ober

> > I'd be submitting a patch to mingw32 people as soon as it's > > done, in addition to posting it here. Note that the only way > > for me to test it would be to inspect the assembly output, as > > I'm not running 64 bit environment here (even though I'm on a > > 64 bit AMD processor). So it'd need testing from 64 bit > > people here at least. > > I'm volunteering. I could also give you ssh access to a 64 bit environment. Once I get sensible assembly coming out I'll let you know. I'll try the __attribute__(__msvccall__) for per-function, and -msvc for per-file. Cheers, Kuba

June 19, 2006

RE: Win64 status

by Ge van Geldorp

> From: Kuba Ober <kuba(a)mareimbrium.org> > > I'm currently hacking on gcc for an embedded target (Z8 > Encore), but I wouldn't mind giving it a try while I'm > digging in the gcc tree. Cool! > I'd like to hear any suggestions as to how to tell the > compiler to use that calling convention (I'm not talking > about implementation, just how the compiler used would tell it). > > I presume it'd need to be something that can be set globally > per each compiler invocation, as well as a per declaration override. > > I'm thinking of "-msvc" (like -liberty ;) compiler option to > force a MSVC-compatible ABI, and for now that'd only apply to > 64 bit code (i.e. with -m64). Maybe in the future it could > enable something special for 32 bit code as well. > > I'm all ears about the per-declaration override (a pragma? an > __attribute__?), and about alternatives to -msvc. __attribute__ seems most logical to me. Perhaps __attribute__(__msvccall__) (in the __attribute__(__stdcall__) tradition? An alternative to -msvc could perhaps be -mrtd ("Alternate calling convention"). For i386 builds of gcc, -mrtd makes stdcall the default calling convention. It is currently a noop for x86_64. I kind of like your -msvc though :-) For Wine the compiler option seems more important then the override. > I'd be submitting a patch to mingw32 people as soon as it's > done, in addition to posting it here. Note that the only way > for me to test it would be to inspect the assembly output, as > I'm not running 64 bit environment here (even though I'm on a > 64 bit AMD processor). So it'd need testing from 64 bit > people here at least. I'm volunteering. I could also give you ssh access to a 64 bit environment. Ge van Geldorp.

June 19, 2006

Re: Usage of checkGLcall in wined3d

by H. Verbeet

On 19/06/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Yes, the the examples you listed are wrong, most likely due to bad copy + > paste. It should be corrected. > > There are some cases when a gl call is not followed by a checkGLcall, for > example in the code I just sent with my vbo patch. This is the case when > wined3d can handle the error somehow and fall back to an alternate code path. Also, keep in mind that checkGLcall actually checks all GL calls since the previous checkGLcall. There are probably enough places where just putting the checkGLcall at the end of a block of code is sufficient.

June 19, 2006

Re: Recording with "Lexia" (mci "open new")

by Robert Reif

Damjan Jovanovic wrote: >>3) Most importantly: Why is it necessary to add >>CAPTURE to system.ini? >> Perhaps the "alias" argument isn't correctly >>handled? >> >> > >Yes wine's MCI is broken: the parsing of some >formats >of MCI commands is incorrect, one of the examples I >clearly remember being: > >"open G: type cdaudio alias cd" >and wine complains that it could not load driver for >type G: (whereas the driver type is cdaudio, no?) >and you have to add "G:=mcicda.dll" in system.ini > > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > > > > > I'm having a simular problem with G711Tool.exe 0009:trace:mci:mciSendStringW (L"open waveaudio alias snd", 0x40371358, 512, (nil)) 0009:trace:mci:MCI_LoadMciDriver wDevID=0001 0009:trace:mci:mciSetDriverData (0001, 40371848) 0009:trace:mci:MCI_LoadMciDriver Loaded driver 0x40371a98 (L"WAVEAUDIO"), type is 522, cmdTable=0000ffff 0009:trace:mci:MCI_LoadMciDriver mcidev=1, uDevTyp=020A wDeviceID=0001 ! 0009:trace:mci:MCI_SetCommandTable (0x408bca7c, 0) 0009:trace:mci:MCI_IsCommandTableValid Dumping cmdTbl=0 [lpTable=0x408bca7c devType=0] 0009:trace:mci:MCI_GetCommandTable => 0 0009:trace:mci:MCI_SetCommandTable (0x408be900, 522) 0009:trace:mci:MCI_IsCommandTableValid Dumping cmdTbl=1 [lpTable=0x408be900 devType=522] 0009:trace:mci:MCI_GetCommandTable => 1 0009:trace:mci:mciSendStringW verb=L"open" on dev=L"waveaudio"; offset=2 0009:trace:mci:MCI_ParseOptArgs args=L"alias snd" offset=2 0009:trace:mci:mciSendStringW [1, MCI_OPEN, 00002400, 00000000/(null) 00000000/(null) 4037176a/L"waveaudio" 00000000/(null) 4037178a/L"snd" 00000000/(null)] 0009:trace:mci:mciGetDriverData (0001) 0009:trace:mci:mciSendStringW => 1/ 0 (L"") 0009:trace:mci:mciSendStringW => 2/ 0 (L"1") 0009:trace:mci:mciSendStringW (L"capability snd can play", 0x40371318, 512, (nil)) 0009:trace:mci:mciSendStringW verb=L"capability" on dev=L"snd"; offset=2 0009:trace:mci:MCI_ParseOptArgs args=L"can play" offset=2 0009:trace:mci:mciSendStringW [1, MCI_GETDEVCAPS, 00000100, 00000000/(null) 00000000/(null) 00000008/#0008 00000000/(null) 00000000/(null) 00000000/(null)] 0009:trace:mci:mciGetDriverData (0001) 0009:trace:mci:mciSendStringW => 1/ 10000 (L"") 0009:trace:mci:mciSendStringW => 2/ 0 (L"true") 0009:trace:mci:mciSendStringW (L"close snd", 0x40371318, 512, (nil)) 0009:trace:mci:mciSendStringW verb=L"close" on dev=L"snd"; offset=1 0009:trace:mci:mciSendStringW [1, MCI_CLOSE, 00000000, 00000000/(null) 00000000/(null) 00000000/(null) 00000000/(null) 00000000/(null) 00000000/(null)] 0009:trace:mci:MCI_Close (0001, 00000000, 0x4083f408) 0009:trace:mci:mciGetDriverData (0001) 0009:trace:mci:mciGetDriverData (0001) 0009:trace:mci:mciSetDriverData (0001, 00000000) 0009:trace:mci:mciGetDriverData (ffffffff) 0009:warn:mci:mciGetDriverData Bad uDeviceID 0009:trace:mci:mciSendStringW => 1/ 0 (L"") 0009:trace:mci:mciSendStringW => 2/ 0 (L"") 0009:trace:mci:mciSendStringW (L"capability waveaudio can save", 0x40371318, 512, (nil)) 0009:trace:mci:mciSendStringW (L"open waveaudio wait", (nil), 0, (nil)) 0009:trace:mci:MCI_LoadMciDriver wDevID=0001 0009:trace:mci:mciSetDriverData (0001, 40371998) 0009:trace:mci:MCI_LoadMciDriver Loaded driver 0x40371970 (L"WAVEAUDIO"), type is 522, cmdTable=0000ffff 0009:trace:mci:MCI_LoadMciDriver mcidev=1, uDevTyp=020A wDeviceID=0001 ! 0009:trace:mci:mciSendStringW verb=L"open" on dev=L"waveaudio"; offset=2 0009:trace:mci:MCI_ParseOptArgs args=L"wait" offset=2 0009:trace:mci:mciSendStringW [1, MCI_OPEN, 00002002, 00000000/(null) 00000000/(null) 40371802/L"waveaudio" 00000000/(null) 00000000/(null) 00000000/(null)] 0009:trace:mci:mciGetDriverData (0001) 0009:trace:mci:mciSendStringW => 1/ 0 ((null)) 0009:trace:mci:mciSendStringW => 2/ 0 ((null)) 0009:trace:mci:mciSendStringW verb=L"capability" on dev=L"waveaudio"; offset=2 0009:trace:mci:MCI_ParseOptArgs args=L"can save" offset=2 0009:trace:mci:mciSendStringW [1, MCI_GETDEVCAPS, 00000100, 00000000/(null) 00000000/(null) 00000009/#0009 00000000/(null) 00000000/(null) 00000000/(null)] 0009:trace:mci:mciGetDriverData (0001) 0009:trace:mci:mciSendStringW => 1/ 10000 (L"") 0009:trace:mci:mciSendStringW => 2/ 0 (L"true") 0009:trace:mci:mciSendStringW (L"capability waveaudio can record", 0x40371318, 512, (nil)) 0009:trace:mci:mciSendStringW verb=L"capability" on dev=L"waveaudio"; offset=2 0009:trace:mci:MCI_ParseOptArgs args=L"can record" offset=2 0009:trace:mci:mciSendStringW [1, MCI_GETDEVCAPS, 00000100, 00000000/(null) 00000000/(null) 00000001/#0001 00000000/(null) 00000000/(null) 00000000/(null)] 0009:trace:mci:mciGetDriverData (0001) 0009:trace:mci:mciSendStringW => 1/ 10000 (L"") 0009:trace:mci:mciSendStringW => 2/ 0 (L"true") 0009:trace:mci:mciSendStringW (L"close all", 0x403768a8, 512, (nil)) 0009:trace:mci:mciSendStringW (L"open all wait", (nil), 0, (nil)) 0009:trace:mci:MCI_LoadMciDriver wDevID=0002 0009:trace:mci:mciSendStringW (L"close all", 0x40376930, 512, (nil)) 0009:trace:mci:mciSendStringW (L"open all wait", (nil), 0, (nil)) 0009:trace:mci:MCI_LoadMciDriver wDevID=0002 0009:trace:mci:mciSendStringW (L"close all", 0x40376930, 512, (nil)) 0009:trace:mci:mciSendStringW (L"open all wait", (nil), 0, (nil)) 0009:trace:mci:MCI_LoadMciDriver wDevID=0002 0009:trace:mci:mciSendStringW (L"status snd mode", 0x403769b0, 512, (nil)) 0009:trace:mci:mciSendStringW (L"open snd wait", (nil), 0, (nil)) 0009:trace:mci:MCI_LoadMciDriver wDevID=0002 0009:fixme:mci:MCI_LoadMciDriver Couldn't load driver for type L"SND". If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini

June 19, 2006

Re: ntoskrnl status

by Jaap Stolk

I also would like to try the ntoskrnl.exe patch. I uninstalled and deleted my cvs wine, updated python and installed git, and completed "Cloning the Wine GIT repository". I had a little peek at the patch by renaming it to .bz2, but how do I add this patch to to my local wine copy, using git ? http://wiki.winehq.org/GitWine seems to be more oriented at making patches, not importing a patch made by someone else.

June 19, 2006

Re: Usage of checkGLcall in wined3d

by Stefan Dösinger

Am Montag 19 Juni 2006 21:25 schrieb Paul Vriens: > Hi, > > while going through some wined3d code I've seen that a 'normal' sequence > is: > > <some call>; > checkGLcall("<some call>"); > > there are however several cases where the call isn't followed by a > checkGLcall: > <snip> > Should this one be defined as a janitorial task? Yes, the the examples you listed are wrong, most likely due to bad copy + paste. It should be corrected. There are some cases when a gl call is not followed by a checkGLcall, for example in the code I just sent with my vbo patch. This is the case when wined3d can handle the error somehow and fall back to an alternate code path. Stefan

June 19, 2006

Re: Win64 status

by Kuba Ober

On Monday 19 June 2006 14:17, Ge van Geldorp wrote: > With the Win64 patches I just submitted to wine-patches, I'm able to > successfully build Win64-enabled Wine and execute the following 64-bit > winelib (winelib64? wine64lib?) application: > > #include "windows.h" > > int WINAPI WinMain(HINSTANCE hinst, HINSTANCE hprev, LPSTR cmdline, int > cmdshow) > { > DWORD Written; > > WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), "Hello, world\r\n", 14, > &Written, NULL); > > return 0; > } > > Unfortunately, compiling the above app as a true 64-bit HELLO64.EXE using > Microsoft Visual Studio and then executing it using Wine doesn't work. The > problem is that the calling convention for functions is different between > MSVC and GCC generated apps. Basically, MSVC puts the function arguments in > registers RCX, RDX, R8, R9 while GCC puts function arguments in registers > RDI, RSI, RDX, RCX, R8, R9. I guess we'll have to wait for true .EXE > support until someone teaches GCC the MSVC calling convention. I'm currently hacking on gcc for an embedded target (Z8 Encore), but I wouldn't mind giving it a try while I'm digging in the gcc tree. I'd like to hear any suggestions as to how to tell the compiler to use that calling convention (I'm not talking about implementation, just how the compiler used would tell it). I presume it'd need to be something that can be set globally per each compiler invocation, as well as a per declaration override. I'm thinking of "-msvc" (like -liberty ;) compiler option to force a MSVC-compatible ABI, and for now that'd only apply to 64 bit code (i.e. with -m64). Maybe in the future it could enable something special for 32 bit code as well. I'm all ears about the per-declaration override (a pragma? an __attribute__?), and about alternatives to -msvc. I'd be submitting a patch to mingw32 people as soon as it's done, in addition to posting it here. Note that the only way for me to test it would be to inspect the assembly output, as I'm not running 64 bit environment here (even though I'm on a 64 bit AMD processor). So it'd need testing from 64 bit people here at least. Cheers, Kuba

June 19, 2006

Usage of checkGLcall in wined3d

by Paul Vriens

Hi, while going through some wined3d code I've seen that a 'normal' sequence is: <some call>; checkGLcall("<some call>"); there are however several cases where the call isn't followed by a checkGLcall: surface.c:1713: glEnable(GL_TEXTURE_2D); surface.c:2165: glEnable(GL_SCISSOR_TEST); or that parameters/text are wrong for checkGLcall: surface.c-2220- glBindTexture(GL_TEXTURE_2D, 0); surface.c:2221: checkGLcall("glEnable glBindTexture"); surface.c-2406- glGetIntegerv(GL_DRAW_BUFFER, &prev_draw); surface.c:2407: vcheckGLcall("glIntegerv"); Should this one be defined as a janitorial task? Cheers, Paul.

June 19, 2006

CVS server

by Ge van Geldorp

> From: Mike McCormack [mailto:mike(a)codeweavers.com] > > I think you're a bit behind the times: > > http://cvs.winehq.org/cvsweb/wine/dlls/mapi32/mapi32_main.c.diff?r1=1.13&r2= 1.14 > http://cvs.winehq.org/cvsweb/wine/dlls/user/user32.spec.diff?r1=1.114&r2=1.1 15 Indeed... Being on the European side of the ocean, I used the rhlx01.fht-esslingen.de mirror. Seems it's no longer up-to-date. Apparently, it has been removed from http://www.winehq.org/site/cvs too. Time to make the switch to git I guess. Gé.

June 19, 2006

Re: Win64 patch 1/13

by Mike McCormack

Ge van Geldorp wrote: > I don't want them either, but I didn't see another option. 32-bit doesn't > export Get/SetWindowLongPtrA/W and GetSetClassLongPtrA/W (they are just > #defines in winuser.h), while 64-bit has to export them. > Is there a portable solution to set a Make variable only when it doesn't > have a value yet? Is there any problem with just exporting them in win32 also? Last time I talked to Alexandre about this, I think that was the conclusion that was reached. >> I thought I already fixed these... I don't think these will >> apply to the current git tree. > > Changes are against current CVS. I think you're a bit behind the times: http://cvs.winehq.org/cvsweb/wine/dlls/mapi32/mapi32_main.c.diff?r1=1.13&r2… http://cvs.winehq.org/cvsweb/wine/dlls/user/user32.spec.diff?r1=1.114&r2=1.… > Except that dlls/ntdll/tests/generated.c was hand-modified. That would explain the rather large diff that I saw when I regenerated these tests :/ Mike

June 19, 2006

RE: Win64 patch 1/13

by Ge van Geldorp

> From: Mike McCormack [mailto:mike(a)codeweavers.com] > > Ge van Geldorp wrote: > > > +SPEC_SRC32 = $(BASEMODULE).spec > > +SPEC_SRC64 ?= $(SPEC_SRC32) > > Not sure we want seperate spec files. In any case, ?= > doesn't look portable. I don't want them either, but I didn't see another option. 32-bit doesn't export Get/SetWindowLongPtrA/W and GetSetClassLongPtrA/W (they are just #defines in winuser.h), while 64-bit has to export them. Is there a portable solution to set a Make variable only when it doesn't have a value yet? > I thought I already fixed these... I don't think these will > apply to the current git tree. Changes are against current CVS. > > --- dlls/ntdll/tests/generated.c 3 Jul 2005 11:23:30 > -0000 1.23 > > +++ dlls/ntdll/tests/generated.c 19 Jun 2006 17:20:17 -0000 > > You should be changing tools/winapi/winapi_test*, not the > generated files. Except that dlls/ntdll/tests/generated.c was hand-modified. Thanks for your comments, Gé.

June 19, 2006

Re: [MSI 1/4] add streams table

by Mike McCormack

Hi, Thanks for submitting the patch, and keeping the coding style consistent! Andrey Turkin wrote: > This patch adds virtual _Streams table to MSI because native MSI > maintains such table > > ChangeLog: > virtual _Streams table added > +static UINT STREAMS_fetch_stream( struct tagMSIVIEW *view, UINT row, UINT col, IStream **stm ) > +{ .... > + > + /* > + * The column marked with the type stream data seems to have a single number > + * which references the column containing the name of the stream data > + * > + * Fetch the column to reference first. > + */ > + r = view->ops->fetch_int( view, row, col, &ival ); I'm not so keen on the way this is done. You seem to have duplicated alot of code from TABLE_fetch_stream here. > + if( r != ERROR_SUCCESS ) > + { > + ERR("1: %d\n", r); > + return r; > + } > + > + ERR("fetched %d\n", ival); And forgotten to remove your debug code. > +MSIVIEWOPS streams_ops = > +{ > + TABLE_fetch_int, > + STREAMS_fetch_stream, > + TABLE_set_int, > + TABLE_insert_row, > + STREAMS_execute, > + TABLE_close, > + TABLE_get_dimensions, > + TABLE_get_column_info, > + TABLE_modify, > + TABLE_delete, > + TABLE_find_matching_rows > +}; The streams table is just another table. How about generating an MSITABLE structure containing the data rather than treat it as a special case in here? Mike

June 19, 2006

Re: Win64 patch 1/13

by Mike McCormack

Ge van Geldorp wrote: > +SPEC_SRC32 = $(BASEMODULE).spec > +SPEC_SRC64 ?= $(SPEC_SRC32) Not sure we want seperate spec files. In any case, ?= doesn't look portable. > -ULONG WINAPI MAPILogon(ULONG uiparam, LPSTR profile, LPSTR password, > +ULONG WINAPI MAPILogon(ULONG_PTR uiparam, LPSTR profile, LPSTR password, > FLAGS flags, ULONG reserved, LPLHANDLE session) > --- programs/wordpad/wordpad.c 14 Feb 2006 16:48:40 -0000 1.1 > +++ programs/wordpad/wordpad.c 19 Jun 2006 17:34:48 -0000 I thought I already fixed these... I don't think these will apply to the current git tree. > --- dlls/ntdll/tests/generated.c 3 Jul 2005 11:23:30 -0000 1.23 > +++ dlls/ntdll/tests/generated.c 19 Jun 2006 17:20:17 -0000 You should be changing tools/winapi/winapi_test*, not the generated files. The heap changes look useful, I will check them out when I get back from my holiday. Mike

June 19, 2006

Win64 status

by Ge van Geldorp

With the Win64 patches I just submitted to wine-patches, I'm able to successfully build Win64-enabled Wine and execute the following 64-bit winelib (winelib64? wine64lib?) application: #include "windows.h" int WINAPI WinMain(HINSTANCE hinst, HINSTANCE hprev, LPSTR cmdline, int cmdshow) { DWORD Written; WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), "Hello, world\r\n", 14, &Written, NULL); return 0; } Unfortunately, compiling the above app as a true 64-bit HELLO64.EXE using Microsoft Visual Studio and then executing it using Wine doesn't work. The problem is that the calling convention for functions is different between MSVC and GCC generated apps. Basically, MSVC puts the function arguments in registers RCX, RDX, R8, R9 while GCC puts function arguments in registers RDI, RSI, RDX, RCX, R8, R9. I guess we'll have to wait for true .EXE support until someone teaches GCC the MSVC calling convention. To prevent confusion: the "normal" 32-bit Wine version runs fine on x86_64 Linux. This is the version you'll want to use, it allows you to run 32-bit Windows stuff. The remarks above are about running 64-bit Windows executables which are virtually non-existant at the moment. Gé van Geldorp.

June 19, 2006

re: MSI database _Streams table

by Dan Kegel

In http://www.winehq.org/pipermail/wine-patches/2006-June/027528.html, Andrey Turkin wrote: > Some installers depends on _Streams built-in table Which installers? It'd be nice to have a bug in bugzilla to hang your MSI work on. Thanks! - Dan

June 19, 2006

Re: wined3d: declaration/FVF conversion test

by Jason Green

On 6/15/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > Hi, I'm attaching test, which demonstrates incorrect behavior of SetFVF > and SetVertexDeclaration. > Windows converts one to the other and backwards (at least partially), > and we do not such thing - this breaks at least 2 demos (dx9_hlsl_*) > > I'm posting it here, because: > > - I don't have Windows, and I need someone to try it on machine with > pixel shader support (preferably 3.0, will need to enable pshaders and > GLSL registry key). The whole first part of the test checks decl to fvf > conversions, and they're almost all set to 0 in order to pass on H. > Verbeet and V. Margolen's setups [ which have no pshaders ]. MSDN has a > whole page on how to convert to an fvf, and the values there are > definitely *not* 0, so that's why I'm suspicious. I just tested this on a Windows box that supports Shader model 2.0, and all tests came back positive without failures. So, now we need to clean up the test so it doesn't report twice the number of errors and get it applied. Then, we fix Wine. ;-) Jason

June 19, 2006

Re: wine XShm problem on remote display

by Benjamin Fabricius

Am Mittwoch, den 14.06.2006, 13:40 +0100 schrieb Mike Hearn: > On Tue, 13 Jun 2006 16:22:17 +0200, Alexandre Julliard wrote: > > Wine will handle that error properly, but here it sounds like fst (or > > more likely Gtk) has replaced the Wine error handler with its own, so > > Wine doesn't get a chance to handle it. > > Yes, that's the GTK+ error handler. Benjamin, this is a bug in FreeST and > you should report it to the developers there. Fixing this is not very > difficult, hopefully it can be resolved soon. > Hey, Thanks for the help! I added an empty error handler and it seems as if wine is now taking care of turning xshm off... just as it is supposed to! This would have taken me ages without your hint.. thanks! A big thank you also to Alexandre Julliard who gave the me the same advice. Have a great day.. Cheers, ..Ben > thanks -mike > > > -- ------------------- Benjamin Fabricius German Student Lawo AG

June 19, 2006

Re: x11drv: Escape international characters

by Andreas Mohr

Hi, On Fri, Jun 16, 2006 at 11:46:02PM +0900, Dmitry Timoshkov wrote: > "Andrew Talbot" <Andrew.Talbot(a)talbotville.com> wrote: > > >It seems better to represent international characters with escape > >sequences, > >both to increase clarity - especially for those who do not normally use > >ISO-8859-1 encoding - and to make editing easier for some. > > Please don't do that. Anyone who wants to edit keyboard tables should > set editor to ISO-8859-1 encoding. Otherwise it becomes really hard to > add new tables or fix existing ones by just comparing or even copy/pasting > from the +key log. So? Then why don't I see a *very prominent* notice in this file that tells me to do just that whenever I plan to submit a patch? ;) Could you perhaps add that if possible? (I don't have a current Wine tree here right now, sorry) Andreas

June 19, 2006

Re: configure: datarootdir is unused, and causes a warning with newer versions of autoconf.

by Mike McCormack

Marcus Meissner wrote: >> -datarootdir = @datarootdir@ > We added this especially because configure warned about it. With Debian/amd64 unstable which has autoconf 2.59.cvs.2006.06.05-1, I get: config.status: WARNING: tools/wmc/Makefile contains a reference to the variable `datarootdir' which seems to be undefined. Please make sure it is defined. Alexandre is wondering whether it might be an autoconf bug. Mike

June 19, 2006

Re: Fix definition of SECURITY_INTEGER

by Thomas Weidenmueller

Kai Blin wrote: > Be aware that negotiate.c is a complete stub. If this function is > changed, it should be changed like this: I didn't intend to fix the logic or implementation, just the fact that the structure was defined incorrectly. The fixes in the .c files are just neccessary because the structure is defined differently. I just noticed I forgot to fix the usage in schannel.c, I'll resend a fixed patch. > There's just no use in fixing negotiate.c as long as ntlm.c is in flux. > Negotiate will use the same solution as NTLM. See above. - Thomas

June 19, 2006

Re: appdb security

by Jonathan Ernst

Hi, The recent changes you made have resulted in a regression at least in the note edition. \'s and ''s are too much addslashized again. I remember having fixed this some time ago... Thanks. Jonathan

June 19, 2006

Re: Fix definition of SECURITY_INTEGER

by Kai Blin

* Thomas Weidenmueller <wine-patches(a)reactsoft.com> [19/06/06, 11:38:54]: > Index: dlls/secur32/negotiate.c > =================================================================== > RCS file: /home/wine/wine/dlls/secur32/negotiate.c,v > retrieving revision 1.3 > diff -u -r1.3 negotiate.c > --- dlls/secur32/negotiate.c 23 May 2006 12:48:34 -0000 1.3 > +++ dlls/secur32/negotiate.c 19 Jun 2006 09:10:31 -0000 > @@ -110,7 +110,10 @@ > phCredential->dwUpper = fCredentialsUse; > /* Same here, shamelessly stolen from schannel.c */ > if (ptsExpiry) > - ptsExpiry->QuadPart = 0; > + { > + ptsExpiry->LowPart = 0; > + ptsExpiry->HighPart = 0; > + } > ret = SEC_E_OK; > } > return ret; Be aware that negotiate.c is a complete stub. If this function is changed, it should be changed like this: diff --git a/dlls/secur32/negotiate.c b/dlls/secur32/negotiate.c index b8531aa..586e559 100644 --- a/dlls/secur32/negotiate.c +++ b/dlls/secur32/negotiate.c @@ -93,28 +93,6 @@ static SECURITY_STATUS SEC_ENTRY nego_Qu return ret; } -static SECURITY_STATUS nego_AcquireCredentialsHandle(ULONG fCredentialsUse, - PCredHandle phCredential, PTimeStamp ptsExpiry) -{ - SECURITY_STATUS ret; - - if(fCredentialsUse == SECPKG_CRED_BOTH) - { - ret = SEC_E_NO_CREDENTIALS; - } - else - { - /* Ok, just store the direction like schannel does for now. - * FIXME: This should probably do something useful later on - */ - phCredential->dwUpper = fCredentialsUse; - /* Same here, shamelessly stolen from schannel.c */ - if (ptsExpiry) - ptsExpiry->QuadPart = 0; - ret = SEC_E_OK; - } - return ret; -} /*********************************************************************** * AcquireCredentialsHandleA @@ -124,11 +102,10 @@ static SECURITY_STATUS SEC_ENTRY nego_Ac PLUID pLogonID, PVOID pAuthData, SEC_GET_KEY_FN pGetKeyFn, PVOID pGetKeyArgument, PCredHandle phCredential, PTimeStamp ptsExpiry) { - TRACE("(%s, %s, 0x%08lx, %p, %p, %p, %p, %p, %p)\n", + TRACE("(%s, %s, 0x%08lx, %p, %p, %p, %p, %p, %p) stub\n", debugstr_a(pszPrincipal), debugstr_a(pszPackage), fCredentialUse, pLogonID, pAuthData, pGetKeyFn, pGetKeyArgument, phCredential, ptsExpiry); - return nego_AcquireCredentialsHandle(fCredentialUse, phCredential, - ptsExpiry); + return SEC_E_UNSUPPORTED_FUNCTION; } /*********************************************************************** @@ -139,11 +116,10 @@ static SECURITY_STATUS SEC_ENTRY nego_Ac PLUID pLogonID, PVOID pAuthData, SEC_GET_KEY_FN pGetKeyFn, PVOID pGetKeyArgument, PCredHandle phCredential, PTimeStamp ptsExpiry) { - TRACE("(%s, %s, 0x%08lx, %p, %p, %p, %p, %p, %p)\n", + TRACE("(%s, %s, 0x%08lx, %p, %p, %p, %p, %p, %p) stub\n", debugstr_w(pszPrincipal), debugstr_w(pszPackage), fCredentialUse, pLogonID, pAuthData, pGetKeyFn, pGetKeyArgument, phCredential, ptsExpiry); - return nego_AcquireCredentialsHandle(fCredentialUse, phCredential, - ptsExpiry); + return SEC_E_UNSUPPORTED_FUNCTION; } /*********************************************************************** There's just no use in fixing negotiate.c as long as ntlm.c is in flux. Negotiate will use the same solution as NTLM. Cheers, Kai -- Kai Blin, (blin at gmx dot net) "There are things that are so serious that you can only joke about them" - Heisenberg

June 19, 2006

Re: configure: datarootdir is unused, and causes a warning with newer versions of autoconf.

by Marcus Meissner

On Mon, Jun 19, 2006 at 06:12:38PM +0900, Mike McCormack wrote: > diff --git a/Make.rules.in b/Make.rules.in > index 9af2d3e..9deee72 100644 > --- a/Make.rules.in > +++ b/Make.rules.in > @@ -98,7 +98,6 @@ prefix = @prefix@ > exec_prefix = @exec_prefix@ > bindir = @bindir@ > libdir = @libdir@ > -datarootdir = @datarootdir@ > datadir = @datadir@ > infodir = @infodir@ > mandir = @mandir@ We added this especially because configure warned about it. Ciao, Marcus

June 19, 2006

Re: [PATCH 2/3] server: add calls to get/set menu info

by Robert Shearman

tkho(a)ucla.edu wrote: >+typedef struct { >+ /* ----------- MENUITEMINFO Stuff ----------- */ >+ UINT fType; /* Item type. */ >+ UINT fState; /* Item state. */ >+ UINT_PTR wID; /* Item id. */ >+ HMENU hSubMenu; /* Pop-up menu. */ >+ HBITMAP hCheckBit; /* Bitmap when checked. */ >+ HBITMAP hUnCheckBit; /* Bitmap when unchecked. */ >+ LPWSTR text; /* Item text. */ >+ ULONG_PTR dwItemData; /* Application defined. */ >+ LPWSTR dwTypeData; /* depends on fMask */ >+ HBITMAP hbmpItem; /* bitmap */ >+ /* ----------- Wine stuff ----------- */ >+ RECT rect; /* Item area (relative to menu window) */ >+ UINT xTab; /* X position of text after Tab */ >+ SIZE bmpsize; /* size needed for the HBMMENU_CALLBACK >+ * bitmap */ >+} MENUITEM; >+ >+/* Popup menu structure */ >+typedef struct { >+ WORD wFlags; /* Menu flags (MF_POPUP, MF_SYSMENU) */ >+ WORD wMagic; /* Magic number */ >+ WORD Width; /* Width of the whole menu */ >+ WORD Height; /* Height of the whole menu */ >+ UINT nItems; /* Number of items in the menu */ >+ HWND hWnd; /* Window containing the menu */ >+ MENUITEM *items; /* Array of menu items */ >+ UINT FocusedItem; /* Currently focused item */ >+ HWND hwndOwner; /* window receiving the messages for ownerdraw */ >+ BOOL bTimeToHide; /* Request hiding when receiving a second click in the top-level menu item */ >+ BOOL bScrolling; /* Scroll arrows are active */ >+ UINT nScrollPos; /* Current scroll position */ >+ UINT nTotalHeight; /* Total height of menu items inside menu */ >+ /* ------------ MENUINFO members ------ */ >+ DWORD dwStyle; /* Extended menu style */ >+ UINT cyMax; /* max height of the whole menu, 0 is screen height */ >+ HBRUSH hbrBack; /* brush for menu background */ >+ DWORD dwContextHelpID; >+ DWORD dwMenuData; /* application defined value */ >+ HMENU hSysMenuOwner; /* Handle to the dummy sys menu holder */ >+ SIZE maxBmpSize; /* Maximum size of the bitmap items */ >+} POPUPMENU, *LPPOPUPMENU; > Hi Thomas, This needs to be cleaned up a lot more before it will be accepted. For a start, the members of this structure need to be cleaned up. Some of the members of the POPUPMENU structure are for keeping track of the menu while it's in use (bTimeToHide, bScrolling, nScrollPos, FocusedItem), so these could be kept on the client side. Also, everything needs to be converted to wineserver types. It should become clear what needs to change as menu item handling is moved into the server, so I would urge you to work on that and then rework these patches. Thanks, -- Rob Shearman

June 19, 2006

[dinput] multiple /dev/input joysticks (for test/review)

by Christoph Frick

hiho, the attached patch detects _all_ joysticks of /dev/input/event%d; please have a test before i refine the patch for submission. i tried it with Il2 Sturmovik and with Live For Speed - both games worked. as neither my cougar nor my brd wheel have force feedback i was not able to test, if everything still works. details: - use a seperate struct for holding infos about the /dev/input/event devices - use the general infos about the devices instead of acquiring/unacquiring before/after infos about the device are needed - changed the dinput_main to use three states to return on create_device: -1 == dont try further, 0 == there is no such device, 1 == there we go next ideas/patches: - use a linked list for storing only the JoyDev's that there are - the guid is stored in the JoyImpl and the JoyDev - the logic in setting the guids is as "first joystick == GUID_Joystick" then use the wine default; this currently leads into the same GUID for instance and product; i saw in joystick_linux.c how this is solved there - as dmesg shows a proper name for the device we might somehow retrieve it with an ioctl-call; currently the /dev/... name is used, which is good for developers but not for users - per-device-config via registry (e.g. combine axes) this patch actually is longer than the things it really does - introducing a "sub-struct" for holding common data adds lots of ``->joydev'' so i decided instead of splitting this patch into several fragments send an "unfinished" version and then finish the job with the following small patches. please note: the patch is against ~wine/dll/dinput (i use cvs for the wine original and git where i need it for patching) -- cu diff --git a/device.c b/device.c diff --git a/dinput_main.c b/dinput_main.c index 9f93a52..d928d96 100644 --- a/dinput_main.c +++ b/dinput_main.c @@ -220,10 +220,11 @@ static HRESULT WINAPI IDirectInputAImpl_ for (i = 0; i < NB_DINPUT_DEVICES; i++) { if (!dinput_devices[i]->enum_deviceA) continue; - for (j = 0, r = -1; r != 0; j++) { + TRACE(" - checking device %d ('%s')\n", i, dinput_devices[i]->name); + for (j = 0, r = 0; r != -1; j++) { devInstance.dwSize = sizeof(devInstance); - TRACE(" - checking device %d ('%s')\n", i, dinput_devices[i]->name); - if ((r = dinput_devices[i]->enum_deviceA(dwDevType, dwFlags, &devInstance, This->dwVersion, j))) { + if (1 == (r = dinput_devices[i]->enum_deviceA(dwDevType, dwFlags, &devInstance, This->dwVersion, j))) { + TRACE(" - found id %d\n", j); if (lpCallback(&devInstance,pvRef) == DIENUM_STOP) return 0; } @@ -250,10 +251,11 @@ static HRESULT WINAPI IDirectInputWImpl_ for (i = 0; i < NB_DINPUT_DEVICES; i++) { if (!dinput_devices[i]->enum_deviceW) continue; - for (j = 0, r = -1; r != 0; j++) { + TRACE(" - checking device %d ('%s')\n", i, dinput_devices[i]->name); + for (j = 0, r = 0; r != -1; j++) { devInstance.dwSize = sizeof(devInstance); - TRACE(" - checking device %d ('%s')\n", i, dinput_devices[i]->name); - if ((r = dinput_devices[i]->enum_deviceW(dwDevType, dwFlags, &devInstance, This->dwVersion, j))) { + if (1 == (r = dinput_devices[i]->enum_deviceW(dwDevType, dwFlags, &devInstance, This->dwVersion, j))) { + TRACE(" - found id %d\n", j); if (lpCallback(&devInstance,pvRef) == DIENUM_STOP) return 0; } diff --git a/joystick_linux.c b/joystick_linux.c index d56271d..abedc5c 100644 --- a/joystick_linux.c +++ b/joystick_linux.c @@ -162,11 +162,15 @@ static int joydev_get_device(char *dev, return ret; } -static BOOL joydev_enum_deviceA(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEA lpddi, DWORD version, int id) +static int joydev_enum_deviceA(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEA lpddi, DWORD version, int id) { int fd = -1; char dev[32]; + if (id>0) { + return -1; + } + if (dwFlags & DIEDFL_FORCEFEEDBACK) { WARN("force feedback not supported\n"); return FALSE; @@ -209,13 +213,17 @@ static BOOL joydev_enum_deviceA(DWORD dw return FALSE; } -static BOOL joydev_enum_deviceW(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEW lpddi, DWORD version, int id) +static int joydev_enum_deviceW(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEW lpddi, DWORD version, int id) { int fd = -1; char name[MAX_PATH]; char dev[32]; char friendly[32]; + if (id>0) { + return -1; + } + if (dwFlags & DIEDFL_FORCEFEEDBACK) { WARN("force feedback not supported\n"); return FALSE; diff --git a/joystick_linuxinput.c b/joystick_linuxinput.c index 30f81f1..94a0383 100644 --- a/joystick_linuxinput.c +++ b/joystick_linuxinput.c @@ -85,12 +85,28 @@ HRESULT linuxinput_get_info_W(int fd, RE typedef struct JoystickImpl JoystickImpl; static const IDirectInputDevice8AVtbl JoystickAvt; static const IDirectInputDevice8WVtbl JoystickWvt; + +struct JoyDev { + int is_joystick; + char *device; + GUID guid; + + int has_ff; + int num_effects; + + /* data returned by EVIOCGBIT for caps, EV_ABS, EV_KEY, and EV_FF */ + BYTE evbits[(EV_MAX+7)/8]; + BYTE absbits[(ABS_MAX+7)/8]; + BYTE keybits[(KEY_MAX+7)/8]; + BYTE ffbits[(FF_MAX+7)/8]; +}; + struct JoystickImpl { const void *lpVtbl; LONG ref; GUID guid; - + struct JoyDev *joydev; /* The 'parent' DInput */ IDirectInputImpl *dinput; @@ -130,100 +146,115 @@ struct JoystickImpl #define AXE_ABSMAX 2 #define AXE_ABSFUZZ 3 #define AXE_ABSFLAT 4 - - - /* data returned by EVIOCGBIT for caps, EV_ABS, EV_KEY, and EV_FF */ - BYTE evbits[(EV_MAX+7)/8]; - BYTE absbits[(ABS_MAX+7)/8]; - BYTE keybits[(KEY_MAX+7)/8]; - BYTE ffbits[(FF_MAX+7)/8]; }; +static void fake_current_js_state(JoystickImpl *ji); +static int find_property_offset(JoystickImpl *This, LPCDIPROPHEADER ph); +static DWORD map_pov(int event_value, int is_x); +static void find_joydevs(void); + /* This GUID is slightly different from the linux joystick one. Take note. */ -static GUID DInput_Wine_Joystick_GUID = { /* 9e573eda-7734-11d2-8d4a-23903fb6bdf7 */ +static const GUID DInput_Wine_Joystick_Base_GUID = { /* 9e573eda-7734-11d2-8d4a-23903fb6bdf7 */ 0x9e573eda, 0x7734, 0x11d2, {0x8d, 0x4a, 0x23, 0x90, 0x3f, 0xb6, 0xbd, 0xf7} }; -static void fake_current_js_state(JoystickImpl *ji); -static int find_property_offset(JoystickImpl *This, LPCDIPROPHEADER ph); -static DWORD map_pov(int event_value, int is_x); - #define test_bit(arr,bit) (((BYTE*)(arr))[(bit)>>3]&(1<<((bit)&7))) -static int joydev_have(BOOL require_ff) +#define MAX_JOYDEV 64 + +static int have_joydevs = -1; +static int first_joydev = -1; +static struct JoyDev joydevs[MAX_JOYDEV] = {}; + +static void find_joydevs(void) { - int i, fd, flags, num_effects; - int havejoy = 0; + int i; + + if (have_joydevs!=-1) { + return; + } + + have_joydevs = 0; + + for (i=0;i<MAX_JOYDEV;i++) { + char buf[200]; + struct JoyDev *joydev = &joydevs[i]; + int fd; + int no_ff_check = 0; + + sprintf(buf,EVDEVPREFIX"%d",i); + + if ((fd=open(buf, O_RDWR))==-1) { + fd = open(buf, O_RDONLY); + no_ff_check = 1; + } + + if (fd!=-1) { + if ((-1==ioctl(fd,EVIOCGBIT(0,sizeof(joydev->evbits)),joydev->evbits))) { + perror("EVIOCGBIT 0"); + close(fd); + continue; + } + if (-1==ioctl(fd,EVIOCGBIT(EV_ABS,sizeof(joydev->absbits)),joydev->absbits)) { + perror("EVIOCGBIT EV_ABS"); + close(fd); + continue; + } + if (-1==ioctl(fd,EVIOCGBIT(EV_KEY,sizeof(joydev->keybits)),joydev->keybits)) { + perror("EVIOCGBIT EV_KEY"); + close(fd); + continue; + } + /* A true joystick has at least axis X and Y, and at least 1 + * button. copied from linux/drivers/input/joydev.c */ + if (test_bit(joydev->absbits,ABS_X) && test_bit(joydev->absbits,ABS_Y) && + ( test_bit(joydev->keybits,BTN_TRIGGER) || + test_bit(joydev->keybits,BTN_A) || + test_bit(joydev->keybits,BTN_1) + ) + ) { + TRACE("Found a joystick '%s'\n", buf); + + joydev->is_joystick = 1; + joydev->device = strdup(buf); + joydev->guid = DInput_Wine_Joystick_Base_GUID; + joydev->guid.Data1 += have_joydevs; + have_joydevs++; + if (first_joydev==-1) { + first_joydev = i; + } + +#ifdef HAVE_STRUCT_FF_EFFECT_DIRECTION + if (!no_ff_check) { + if ((!test_bit(joydev->evbits,EV_FF)) + || (-1==ioctl(fd,EVIOCGBIT(EV_FF,sizeof(joydev->ffbits)),joydev->ffbits)) + || (-1==ioctl(fd,EVIOCGEFFECTS,&joydev->num_effects)) + || (joydev->num_effects <= 0)) { + close(fd); + continue; + } - for (i=0;i<64;i++) { - char buf[200]; - BYTE absbits[(ABS_MAX+7)/8],keybits[(KEY_MAX+7)/8]; - BYTE evbits[(EV_MAX+7)/8],ffbits[(FF_MAX+7)/8]; - - sprintf(buf,EVDEVPREFIX"%d",i); - - if (require_ff) - flags = O_RDWR; - else - flags = O_RDONLY; - - if (-1!=(fd=open(buf,flags))) { - if (-1==ioctl(fd,EVIOCGBIT(EV_ABS,sizeof(absbits)),absbits)) { - perror("EVIOCGBIT EV_ABS"); - close(fd); - continue; - } - if (-1==ioctl(fd,EVIOCGBIT(EV_KEY,sizeof(keybits)),keybits)) { - perror("EVIOCGBIT EV_KEY"); - close(fd); - continue; - } - - /* test for force feedback if it's required */ - if (require_ff) { - if ((-1==ioctl(fd,EVIOCGBIT(0,sizeof(evbits)),evbits))) { - perror("EVIOCGBIT 0"); - close(fd); - continue; - } - if ( (!test_bit(evbits,EV_FF)) - || (-1==ioctl(fd,EVIOCGBIT(EV_FF,sizeof(ffbits)),ffbits)) - || (-1==ioctl(fd,EVIOCGEFFECTS,&num_effects)) - || (num_effects <= 0)) { - close(fd); - continue; - } - } - - /* A true joystick has at least axis X and Y, and at least 1 - * button. copied from linux/drivers/input/joydev.c */ - if (test_bit(absbits,ABS_X) && test_bit(absbits,ABS_Y) && - ( test_bit(keybits,BTN_TRIGGER) || - test_bit(keybits,BTN_A) || - test_bit(keybits,BTN_1) - ) - ) { - FIXME("found a joystick at %s!\n",buf); - havejoy = 1; - } - close(fd); + TRACE(" ... with force feedback\n"); + + joydev->has_ff = 1; + } +#endif } - if (havejoy || (errno==ENODEV)) - break; + + close(fd); + } } - return havejoy; } -static BOOL joydev_enum_deviceA(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEA lpddi, DWORD version, int id) +static int joydev_enum_deviceA(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEA lpddi, DWORD version, int id) { - int havejoy = 0; - - if (id != 0) - return FALSE; - + if (id >= MAX_JOYDEV) { + return -1; + } + if (!((dwDevType == 0) || ((dwDevType == DIDEVTYPE_JOYSTICK) && (version < 0x0800)) || (((dwDevType == DI8DEVCLASS_GAMECTRL) || (dwDevType == DI8DEVTYPE_JOYSTICK)) && (version >= 0x0800)))) @@ -234,35 +265,34 @@ static BOOL joydev_enum_deviceA(DWORD dw return FALSE; #endif - havejoy = joydev_have(dwFlags & DIEDFL_FORCEFEEDBACK); - - if (!havejoy) - return FALSE; + find_joydevs(); - TRACE("Enumerating the linuxinput Joystick device\n"); - - /* Return joystick */ - lpddi->guidInstance = GUID_Joystick; - lpddi->guidProduct = DInput_Wine_Joystick_GUID; + if (joydevs[id].is_joystick && ((!(dwFlags & DIEDFL_FORCEFEEDBACK)) || joydevs[id].has_ff)) { + if (id==first_joydev) { + lpddi->guidInstance = GUID_Joystick; + } else { + lpddi->guidInstance = joydevs[id].guid; + } + lpddi->guidProduct = joydevs[id].guid; - lpddi->guidFFDriver = GUID_NULL; - if (version >= 0x0800) - lpddi->dwDevType = DI8DEVTYPE_JOYSTICK | (DI8DEVTYPEJOYSTICK_STANDARD << 8); - else - lpddi->dwDevType = DIDEVTYPE_JOYSTICK | (DIDEVTYPEJOYSTICK_TRADITIONAL << 8); + lpddi->guidFFDriver = GUID_NULL; + if (version >= 0x0800) + lpddi->dwDevType = DI8DEVTYPE_JOYSTICK | (DI8DEVTYPEJOYSTICK_STANDARD << 8); + else + lpddi->dwDevType = DIDEVTYPE_JOYSTICK | (DIDEVTYPEJOYSTICK_TRADITIONAL << 8); - strcpy(lpddi->tszInstanceName, "Joystick"); - /* ioctl JSIOCGNAME(len) */ - strcpy(lpddi->tszProductName, "Wine Joystick"); - return TRUE; + strcpy(lpddi->tszInstanceName, "Joystick"); + strcpy(lpddi->tszProductName, joydevs[id].device); + return TRUE; + } + return FALSE; } -static BOOL joydev_enum_deviceW(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEW lpddi, DWORD version, int id) +static int joydev_enum_deviceW(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEW lpddi, DWORD version, int id) { - int havejoy = 0; - - if (id != 0) - return FALSE; + if (id >= MAX_JOYDEV) { + return -1; + } if (!((dwDevType == 0) || ((dwDevType == DIDEVTYPE_JOYSTICK) && (version < 0x0800)) || @@ -274,30 +304,27 @@ static BOOL joydev_enum_deviceW(DWORD dw return FALSE; #endif - havejoy = joydev_have(dwFlags & DIEDFL_FORCEFEEDBACK); - - if (!havejoy) - return FALSE; - - TRACE("Enumerating the linuxinput Joystick device\n"); - - /* Return joystick */ - lpddi->guidInstance = GUID_Joystick; - lpddi->guidProduct = DInput_Wine_Joystick_GUID; + find_joydevs(); - lpddi->guidFFDriver = GUID_NULL; - if (version >= 0x0800) - lpddi->dwDevType = DI8DEVTYPE_JOYSTICK | (DI8DEVTYPEJOYSTICK_STANDARD << 8); - else - lpddi->dwDevType = DIDEVTYPE_JOYSTICK | (DIDEVTYPEJOYSTICK_TRADITIONAL << 8); + if (joydevs[id].is_joystick && ((!(dwFlags & DIEDFL_FORCEFEEDBACK)) || joydevs[id].has_ff)) { + /* Return joystick */ + lpddi->guidInstance = GUID_Joystick; + lpddi->guidProduct = joydevs[id].guid; + + lpddi->guidFFDriver = GUID_NULL; + if (version >= 0x0800) + lpddi->dwDevType = DI8DEVTYPE_JOYSTICK | (DI8DEVTYPEJOYSTICK_STANDARD << 8); + else + lpddi->dwDevType = DIDEVTYPE_JOYSTICK | (DIDEVTYPEJOYSTICK_TRADITIONAL << 8); - MultiByteToWideChar(CP_ACP, 0, "Joystick", -1, lpddi->tszInstanceName, MAX_PATH); - /* ioctl JSIOCGNAME(len) */ - MultiByteToWideChar(CP_ACP, 0, "Wine Joystick", -1, lpddi->tszProductName, MAX_PATH); - return TRUE; + MultiByteToWideChar(CP_ACP, 0, "Joystick", -1, lpddi->tszInstanceName, MAX_PATH); + MultiByteToWideChar(CP_ACP, 0, joydevs[id].device, -1, lpddi->tszProductName, MAX_PATH); + return TRUE; + } + return FALSE; } -static JoystickImpl *alloc_device(REFGUID rguid, const void *jvt, IDirectInputImpl *dinput) +static JoystickImpl *alloc_device(REFGUID rguid, const void *jvt, IDirectInputImpl *dinput, struct JoyDev *joydev) { JoystickImpl* newDevice; int i; @@ -307,6 +334,7 @@ static JoystickImpl *alloc_device(REFGUI newDevice->ref = 1; newDevice->joyfd = -1; newDevice->dinput = dinput; + newDevice->joydev = joydev; #ifdef HAVE_STRUCT_FF_EFFECT_DIRECTION newDevice->ff_state = FF_STATUS_STOPPED; #endif @@ -327,25 +355,30 @@ static JoystickImpl *alloc_device(REFGUI static HRESULT joydev_create_deviceA(IDirectInputImpl *dinput, REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEA* pdev) { - int havejoy = 0; + int i; - havejoy = joydev_have(FALSE); + find_joydevs(); - if (!havejoy) + if (!have_joydevs) return DIERR_DEVICENOTREG; - if ((IsEqualGUID(&GUID_Joystick,rguid)) || - (IsEqualGUID(&DInput_Wine_Joystick_GUID,rguid))) { - if ((riid == NULL) || - IsEqualGUID(&IID_IDirectInputDeviceA,riid) || - IsEqualGUID(&IID_IDirectInputDevice2A,riid) || - IsEqualGUID(&IID_IDirectInputDevice7A,riid) || - IsEqualGUID(&IID_IDirectInputDevice8A,riid)) { - *pdev = (IDirectInputDeviceA*) alloc_device(rguid, &JoystickAvt, dinput); - TRACE("Creating a Joystick device (%p)\n", *pdev); - return DI_OK; - } else - return DIERR_NOINTERFACE; + for (i=0; i<MAX_JOYDEV; i++) { + if (joydevs[i].is_joystick && ( + IsEqualGUID(&GUID_Joystick,rguid) || + IsEqualGUID(&joydevs[i].guid,rguid) + )) { + if ((riid == NULL) || + IsEqualGUID(&IID_IDirectInputDeviceA,riid) || + IsEqualGUID(&IID_IDirectInputDevice2A,riid) || + IsEqualGUID(&IID_IDirectInputDevice7A,riid) || + IsEqualGUID(&IID_IDirectInputDevice8A,riid)) { + *pdev = (IDirectInputDeviceA*) alloc_device(rguid, &JoystickAvt, dinput, &joydevs[i]); + TRACE("Creating a Joystick device (%p)\n", *pdev); + return DI_OK; + } else { + return DIERR_NOINTERFACE; + } + } } return DIERR_DEVICENOTREG; @@ -354,25 +387,30 @@ static HRESULT joydev_create_deviceA(IDi static HRESULT joydev_create_deviceW(IDirectInputImpl *dinput, REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEW* pdev) { - int havejoy = 0; + int i; - havejoy = joydev_have(FALSE); + find_joydevs(); - if (!havejoy) + if (!have_joydevs) return DIERR_DEVICENOTREG; - if ((IsEqualGUID(&GUID_Joystick,rguid)) || - (IsEqualGUID(&DInput_Wine_Joystick_GUID,rguid))) { - if ((riid == NULL) || - IsEqualGUID(&IID_IDirectInputDeviceW,riid) || - IsEqualGUID(&IID_IDirectInputDevice2W,riid) || - IsEqualGUID(&IID_IDirectInputDevice7W,riid) || - IsEqualGUID(&IID_IDirectInputDevice8W,riid)) { - *pdev = (IDirectInputDeviceW*) alloc_device(rguid, &JoystickWvt, dinput); - TRACE("Creating a Joystick device (%p)\n", *pdev); - return DI_OK; - } else - return DIERR_NOINTERFACE; + for (i=0; i<MAX_JOYDEV; i++) { + if (joydevs[i].is_joystick && ( + IsEqualGUID(&GUID_Joystick,rguid) || + IsEqualGUID(&joydevs[i].guid,rguid) + )) { + if ((riid == NULL) || + IsEqualGUID(&IID_IDirectInputDeviceW,riid) || + IsEqualGUID(&IID_IDirectInputDevice2W,riid) || + IsEqualGUID(&IID_IDirectInputDevice7W,riid) || + IsEqualGUID(&IID_IDirectInputDevice8W,riid)) { + *pdev = (IDirectInputDeviceW*) alloc_device(rguid, &JoystickWvt, dinput, &joydevs[i]); + TRACE("Creating a Joystick device (%p)\n", *pdev); + return DI_OK; + } else { + return DIERR_NOINTERFACE; + } + } } return DIERR_DEVICENOTREG; @@ -461,9 +499,8 @@ static HRESULT WINAPI JoystickAImpl_SetD */ static HRESULT WINAPI JoystickAImpl_Acquire(LPDIRECTINPUTDEVICE8A iface) { - int i,buttons; + int i, buttons; JoystickImpl *This = (JoystickImpl *)iface; - char buf[200]; BOOL readonly = TRUE; TRACE("(this=%p)\n",This); @@ -472,68 +509,23 @@ static HRESULT WINAPI JoystickAImpl_Acqu if (This->df==NULL) { return DIERR_INVALIDPARAM; } - for (i=0;i<64;i++) { - sprintf(buf,EVDEVPREFIX"%d",i); - if (-1==(This->joyfd=open(buf,O_RDWR))) { - if (-1==(This->joyfd=open(buf,O_RDONLY))) { - /* Couldn't open the device at all */ - if (errno==ENODEV) - return DIERR_NOTFOUND; - perror(buf); - continue; - } - else { - /* Couldn't open in r/w but opened in read-only. */ - WARN("Could not open %s in read-write mode. Force feedback will be disabled.\n",buf); - } - } - else { - /* Opened device in read-write */ - readonly = FALSE; - } - if ((-1!=ioctl(This->joyfd,EVIOCGBIT(0,sizeof(This->evbits)),This->evbits)) && - (-1!=ioctl(This->joyfd,EVIOCGBIT(EV_ABS,sizeof(This->absbits)),This->absbits)) && - (-1!=ioctl(This->joyfd,EVIOCGBIT(EV_KEY,sizeof(This->keybits)),This->keybits)) && - (test_bit(This->absbits,ABS_X) && test_bit(This->absbits,ABS_Y) && - (test_bit(This->keybits,BTN_TRIGGER)|| - test_bit(This->keybits,BTN_A) || - test_bit(This->keybits,BTN_1) - ) - ) - ) - break; - close(This->joyfd); - This->joyfd = -1; - } - if (This->joyfd==-1) - return DIERR_NOTFOUND; - This->has_ff = FALSE; - This->num_effects = 0; - -#ifdef HAVE_STRUCT_FF_EFFECT_DIRECTION - if (!readonly && test_bit(This->evbits, EV_FF)) { - if (-1!=ioctl(This->joyfd,EVIOCGBIT(EV_FF,sizeof(This->ffbits)),This->ffbits)) { - if (-1!=ioctl(This->joyfd,EVIOCGEFFECTS,&This->num_effects) - && This->num_effects > 0) { - This->has_ff = TRUE; - TRACE("Joystick seems to be capable of force feedback.\n"); - } - else { - TRACE("Joystick does not support any effects, disabling force feedback.\n"); - } - } - else { - TRACE("Could not get EV_FF bits; disabling force feedback.\n"); - } - } - else { - TRACE("Force feedback disabled (device is readonly or joystick incapable).\n"); + if (-1==(This->joyfd=open(This->joydev->device,O_RDWR))) { + if (-1==(This->joyfd=open(This->joydev->device,O_RDONLY))) { + /* Couldn't open the device at all */ + perror(This->joydev->device); + return DIERR_NOTFOUND; + } else { + /* Couldn't open in r/w but opened in read-only. */ + WARN("Could not open %s in read-write mode. Force feedback will be disabled.\n", This->joydev->device); + } + } else { + /* Opened device in read-write */ + readonly = FALSE; } -#endif for (i=0;i<ABS_MAX;i++) { - if (test_bit(This->absbits,i)) { + if (test_bit(This->joydev->absbits,i)) { if (-1==ioctl(This->joyfd,EVIOCGABS(i),&(This->axes[i]))) continue; TRACE("axe %d: cur=%d, min=%d, max=%d, fuzz=%d, flat=%d\n", @@ -550,14 +542,14 @@ static HRESULT WINAPI JoystickAImpl_Acqu } buttons = 0; for (i=0;i<KEY_MAX;i++) { - if (test_bit(This->keybits,i)) { + if (test_bit(This->joydev->keybits,i)) { TRACE("button %d: %d\n", i, buttons); This->buttons[i] = 0x80 | buttons; buttons++; } } - fake_current_js_state(This); + fake_current_js_state(This); return 0; } @@ -985,7 +977,6 @@ static HRESULT WINAPI JoystickAImpl_GetC LPDIDEVCAPS lpDIDevCaps) { JoystickImpl *This = (JoystickImpl *)iface; - int xfd = This->joyfd; int i,axes,buttons; TRACE("%p->(%p)\n",iface,lpDIDevCaps); @@ -1000,11 +991,6 @@ static HRESULT WINAPI JoystickAImpl_GetC return DIERR_INVALIDPARAM; } - if (xfd==-1) { - /* yes, games assume we return something, even if unacquired */ - JoystickAImpl_Acquire(iface); - } - lpDIDevCaps->dwFlags = DIDC_ATTACHED; if (This->dinput->dwVersion >= 0x0800) lpDIDevCaps->dwDevType = DI8DEVTYPE_JOYSTICK | (DI8DEVTYPEJOYSTICK_STANDARD << 8); @@ -1012,9 +998,9 @@ static HRESULT WINAPI JoystickAImpl_GetC lpDIDevCaps->dwDevType = DIDEVTYPE_JOYSTICK | (DIDEVTYPEJOYSTICK_TRADITIONAL << 8); axes=0; - for (i=0;i<ABS_MAX;i++) if (test_bit(This->absbits,i)) axes++; + for (i=0;i<ABS_MAX;i++) if (test_bit(This->joydev->absbits,i)) axes++; buttons=0; - for (i=0;i<KEY_MAX;i++) if (test_bit(This->keybits,i)) buttons++; + for (i=0;i<KEY_MAX;i++) if (test_bit(This->joydev->keybits,i)) buttons++; if (This->has_ff) lpDIDevCaps->dwFlags |= DIDC_FORCEFEEDBACK; @@ -1022,10 +1008,6 @@ static HRESULT WINAPI JoystickAImpl_GetC lpDIDevCaps->dwAxes = axes; lpDIDevCaps->dwButtons = buttons; - if (xfd==-1) { - JoystickAImpl_Unacquire(iface); - } - return DI_OK; } @@ -1052,7 +1034,6 @@ static HRESULT WINAPI JoystickAImpl_Enum { JoystickImpl *This = (JoystickImpl *)iface; DIDEVICEOBJECTINSTANCEA ddoi; - int xfd = This->joyfd; TRACE("(this=%p,%p,%p,%08lx)\n", This, lpCallback, lpvRef, dwFlags); if (TRACE_ON(dinput)) { @@ -1061,10 +1042,6 @@ static HRESULT WINAPI JoystickAImpl_Enum TRACE("\n"); } - /* We need to work even if we're not yet acquired */ - if (xfd == -1) - IDirectInputDevice8_Acquire(iface); - /* Only the fields till dwFFMaxForce are relevant */ ddoi.dwSize = FIELD_OFFSET(DIDEVICEOBJECTINSTANCEA, dwFFMaxForce); @@ -1075,7 +1052,7 @@ static HRESULT WINAPI JoystickAImpl_Enum BYTE i; for (i = 0; i < ABS_MAX; i++) { - if (!test_bit(This->absbits,i)) continue; + if (!test_bit(This->joydev->absbits,i)) continue; switch (i) { case ABS_X: @@ -1122,9 +1099,6 @@ static HRESULT WINAPI JoystickAImpl_Enum sprintf(ddoi.tszName, "%d-Axis", i); _dump_OBJECTINSTANCEA(&ddoi); if (lpCallback(&ddoi, lpvRef) != DIENUM_CONTINUE) { - /* return to unaquired state if that's where we were */ - if (xfd == -1) - IDirectInputDevice8_Unacquire(iface); return DI_OK; } } @@ -1135,15 +1109,12 @@ static HRESULT WINAPI JoystickAImpl_Enum int i; ddoi.guidType = GUID_POV; for (i=0; i<4; i++) { - if (test_bit(This->absbits,ABS_HAT0X+(i<<1)) && test_bit(This->absbits,ABS_HAT0Y+(i<<1))) { + if (test_bit(This->joydev->absbits,ABS_HAT0X+(i<<1)) && test_bit(This->joydev->absbits,ABS_HAT0Y+(i<<1))) { ddoi.dwOfs = DIJOFS_POV(i); ddoi.dwType = DIDFT_MAKEINSTANCE(i << WINE_JOYSTICK_POV_BASE) | DIDFT_POV; sprintf(ddoi.tszName, "%d-POV", i); _dump_OBJECTINSTANCEA(&ddoi); if (lpCallback(&ddoi, lpvRef) != DIENUM_CONTINUE) { - /* return to unaquired state if that's where we were */ - if (xfd == -1) - IDirectInputDevice8_Unacquire(iface); return DI_OK; } } @@ -1159,25 +1130,18 @@ static HRESULT WINAPI JoystickAImpl_Enum ddoi.guidType = GUID_Button; for (i = 0; i < KEY_MAX; i++) { - if (!test_bit(This->keybits,i)) continue; + if (!test_bit(This->joydev->keybits,i)) continue; ddoi.dwOfs = DIJOFS_BUTTON(btncount); ddoi.dwType = DIDFT_MAKEINSTANCE(btncount << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; sprintf(ddoi.tszName, "%d-Button", btncount); btncount++; _dump_OBJECTINSTANCEA(&ddoi); if (lpCallback(&ddoi, lpvRef) != DIENUM_CONTINUE) { - /* return to unaquired state if that's where we were */ - if (xfd == -1) - IDirectInputDevice8_Unacquire(iface); return DI_OK; } } } - /* return to unaquired state if that's where we were */ - if (xfd == -1) - IDirectInputDevice8_Unacquire(iface); - return DI_OK; } @@ -1300,74 +1264,66 @@ static HRESULT WINAPI JoystickAImpl_Enum DIEFFECTINFOA dei; /* feif */ DWORD type = DIEFT_GETTYPE(dwEffType); JoystickImpl* This = (JoystickImpl*)iface; - int xfd = This->joyfd; - TRACE("(this=%p,%p,%ld) type=%ld fd=%d\n", This, pvRef, dwEffType, type, xfd); + TRACE("(this=%p,%p,%ld) type=%ld\n", This, pvRef, dwEffType, type); dei.dwSize = sizeof(DIEFFECTINFOA); - /* We need to return something even if we're not yet acquired */ - if (xfd == -1) - IDirectInputDevice8_Acquire(iface); - if ((type == DIEFT_ALL || type == DIEFT_CONSTANTFORCE) - && test_bit(This->ffbits, FF_CONSTANT)) { + && test_bit(This->joydev->ffbits, FF_CONSTANT)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_ConstantForce); (*lpCallback)(&dei, pvRef); } if ((type == DIEFT_ALL || type == DIEFT_PERIODIC) - && test_bit(This->ffbits, FF_PERIODIC)) { - if (test_bit(This->ffbits, FF_SQUARE)) { + && test_bit(This->joydev->ffbits, FF_PERIODIC)) { + if (test_bit(This->joydev->ffbits, FF_SQUARE)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Square); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_SINE)) { + if (test_bit(This->joydev->ffbits, FF_SINE)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Sine); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_TRIANGLE)) { + if (test_bit(This->joydev->ffbits, FF_TRIANGLE)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Triangle); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_SAW_UP)) { + if (test_bit(This->joydev->ffbits, FF_SAW_UP)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_SawtoothUp); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_SAW_DOWN)) { + if (test_bit(This->joydev->ffbits, FF_SAW_DOWN)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_SawtoothDown); (*lpCallback)(&dei, pvRef); } } if ((type == DIEFT_ALL || type == DIEFT_RAMPFORCE) - && test_bit(This->ffbits, FF_RAMP)) { + && test_bit(This->joydev->ffbits, FF_RAMP)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_RampForce); (*lpCallback)(&dei, pvRef); } if (type == DIEFT_ALL || type == DIEFT_CONDITION) { - if (test_bit(This->ffbits, FF_SPRING)) { + if (test_bit(This->joydev->ffbits, FF_SPRING)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Spring); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_DAMPER)) { + if (test_bit(This->joydev->ffbits, FF_DAMPER)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Damper); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_INERTIA)) { + if (test_bit(This->joydev->ffbits, FF_INERTIA)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Inertia); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_FRICTION)) { + if (test_bit(This->joydev->ffbits, FF_FRICTION)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Friction); (*lpCallback)(&dei, pvRef); } } - /* return to unaquired state if that's where it was */ - if (xfd == -1) - IDirectInputDevice8_Unacquire(iface); #endif return DI_OK; @@ -1390,60 +1346,56 @@ static HRESULT WINAPI JoystickWImpl_Enum dei.dwSize = sizeof(DIEFFECTINFOW); - /* We need to return something even if we're not yet acquired */ - if (xfd == -1) - IDirectInputDevice8_Acquire(iface); - if ((type == DIEFT_ALL || type == DIEFT_CONSTANTFORCE) - && test_bit(This->ffbits, FF_CONSTANT)) { + && test_bit(This->joydev->ffbits, FF_CONSTANT)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_ConstantForce); (*lpCallback)(&dei, pvRef); } if ((type == DIEFT_ALL || type == DIEFT_PERIODIC) - && test_bit(This->ffbits, FF_PERIODIC)) { - if (test_bit(This->ffbits, FF_SQUARE)) { + && test_bit(This->joydev->ffbits, FF_PERIODIC)) { + if (test_bit(This->joydev->ffbits, FF_SQUARE)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Square); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_SINE)) { + if (test_bit(This->joydev->ffbits, FF_SINE)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Sine); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_TRIANGLE)) { + if (test_bit(This->joydev->ffbits, FF_TRIANGLE)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Triangle); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_SAW_UP)) { + if (test_bit(This->joydev->ffbits, FF_SAW_UP)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_SawtoothUp); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_SAW_DOWN)) { + if (test_bit(This->joydev->ffbits, FF_SAW_DOWN)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_SawtoothDown); (*lpCallback)(&dei, pvRef); } } if ((type == DIEFT_ALL || type == DIEFT_RAMPFORCE) - && test_bit(This->ffbits, FF_RAMP)) { + && test_bit(This->joydev->ffbits, FF_RAMP)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_RampForce); (*lpCallback)(&dei, pvRef); } if (type == DIEFT_ALL || type == DIEFT_CONDITION) { - if (test_bit(This->ffbits, FF_SPRING)) { + if (test_bit(This->joydev->ffbits, FF_SPRING)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Spring); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_DAMPER)) { + if (test_bit(This->joydev->ffbits, FF_DAMPER)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Damper); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_INERTIA)) { + if (test_bit(This->joydev->ffbits, FF_INERTIA)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Inertia); (*lpCallback)(&dei, pvRef); } - if (test_bit(This->ffbits, FF_FRICTION)) { + if (test_bit(This->joydev->ffbits, FF_FRICTION)) { IDirectInputDevice8_GetEffectInfo(iface, &dei, &GUID_Friction); (*lpCallback)(&dei, pvRef); } diff --git a/keyboard.c b/keyboard.c index 9640db9..2cd9314 100644 --- a/keyboard.c +++ b/keyboard.c @@ -186,10 +186,10 @@ static void fill_keyboard_dideviceinstan memcpy(lpddi, &ddi, (dwSize < sizeof(ddi) ? dwSize : sizeof(ddi))); } -static BOOL keyboarddev_enum_deviceA(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEA lpddi, DWORD version, int id) +static int keyboarddev_enum_deviceA(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEA lpddi, DWORD version, int id) { if (id != 0) - return FALSE; + return -1; if ((dwDevType == 0) || ((dwDevType == DIDEVTYPE_KEYBOARD) && (version < 0x0800)) || @@ -204,10 +204,10 @@ static BOOL keyboarddev_enum_deviceA(DWO return FALSE; } -static BOOL keyboarddev_enum_deviceW(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEW lpddi, DWORD version, int id) +static int keyboarddev_enum_deviceW(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEW lpddi, DWORD version, int id) { if (id != 0) - return FALSE; + return -1; if ((dwDevType == 0) || ((dwDevType == DIDEVTYPE_KEYBOARD) && (version < 0x0800)) || diff --git a/mouse.c b/mouse.c index 8bd395e..f313b10 100644 --- a/mouse.c +++ b/mouse.c @@ -202,10 +202,10 @@ static void fill_mouse_dideviceinstanceW memcpy(lpddi, &ddi, (dwSize < sizeof(ddi) ? dwSize : sizeof(ddi))); } -static BOOL mousedev_enum_deviceA(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEA lpddi, DWORD version, int id) +static int mousedev_enum_deviceA(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEA lpddi, DWORD version, int id) { if (id != 0) - return FALSE; + return -1; if ((dwDevType == 0) || ((dwDevType == DIDEVTYPE_MOUSE) && (version < 0x0800)) || @@ -220,10 +220,10 @@ static BOOL mousedev_enum_deviceA(DWORD return FALSE; } -static BOOL mousedev_enum_deviceW(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEW lpddi, DWORD version, int id) +static int mousedev_enum_deviceW(DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEW lpddi, DWORD version, int id) { if (id != 0) - return FALSE; + return -1; if ((dwDevType == 0) || ((dwDevType == DIDEVTYPE_MOUSE) && (version < 0x0800)) ||

June 19, 2006

Re: wininet file scheme

by Nick Cronin

I think your right Travis, there is a difference however I'm not removing it per-say. If file:// is sent, InternetCrackUrl does not take out the %xx ascii values, however if file:/// is sent, it does. I've added a test case for these both. I also wrote a test case for http:/// which currently the code I'm suggesting passes (although the output is useless). On 6/17/06, Travis Watkins <alleykat(a)gmail.com> wrote: > > On 6/16/06, Mike McCormack <mike(a)codeweavers.com> wrote: > > > > Nick Cronin wrote: > > > unlike http:// etc, file:/// has 3 slashes, this patch removes the > third > > > slash. > > > > Could you provide a test case for this please? > > > > Specifically, is "http:///foo.bar" different to "http://foo.bar"? Your > > code treats them equally. How about "file:///" and "file://"? > > > > Mike > > > > > > > > I thought it was file://computername/path/to/file with > file:///path/to/file implying the local machine. I'm not so sure this > should be changed, it's some kind of a standard. > > -- > Travis Watkins > http://www.realistanew.com >

June 19, 2006

Re: Allow 'wine foo.exe' to work when foo.exe is a symlink

by Jesse Allen

On 6/18/06, Dan Kegel <dank(a)kegel.com> wrote: > Currently, when I install a Windows app on Ubuntu, > the apps don't show up in the system menus. > I'm doing a demo of Wine for a users' group in a few > days, so I thought "How would the average user deal with this?" > Probably they'd navigate down to the directory > where the app was installed, make a shortcut to the app, > and drag the shortcut to the desktop. So I tried > that -- and it didn't work. But it does work if I apply > the following trivial patch, which just uses readlink() to find the > target of the shortcut. I didn't really analyze the > code, just slammed the readlink in there, and was happy to > see it worked. > > Changelog: > kernel/process.c: if argv[1] is a symlink, use its target > > process.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > >From my own playing around with the issue, I believe I understand why you are making this change for shortcuts. I do have to state, that with this change, it will break the method using symlinks to pass the exe check on blizzard games logging into battle.net. It will also break my workaround for an app that expands its program path funny (symlinking again). However, you can still use a hard link to do the same thing so there's nothing wrong with this change happening. Now I have to go tell everyone to use a hard link instead. :)

June 19, 2006

Winelib Getting Started 1.3.2. Test Drive

by Dee Ayy

Hello, Would a wine developer please revisit this page http://www.winehq.org/site/docs/winelib-guide/winelib-getting-started and modify it to have a step by step guide to take a Linux box without wine nor winelib to a running notepad exe built by the newbie (and not downloaded)? Or if you are a wine-user, please provide such steps to this list. As a newbie, the statement "It can be found in the programs subdirectory." had me lost. I don't know if the steps I took are correct, but somehow I found http://www.winehq.org/site/cvs. Perhaps the winelib-getting-started page could be modified to direct a newbie how to download the "test drive" at this point. Then I only checked out wine/programs/notepad since the statement "(but read the next section before actually doing this!)" intimidated me on the cvs page. The first error after a make was "dialog.c:27:21: error windows.h: No such file or directory". Then I had the brilliant idea to checkout all of wine, even though I was intimidated initially by the statement "(but read the next section before actually doing this!)". The make still failed with the same error, even though I now have the wine/include directory. Not knowing any better, I modified the Makefile from INCLUDE_PATH = -I. to INCLUDE_PATH = -I.:/my/path/to/wine/include. I retried make and get the same error. I'm stumped. The 1.3.3 Step by step guide was too general for me. But maybe that's because I needed section 1.3.2 to be more detailed for the task at hand, building notepad. And perhaps 1.3.3 can be left alone for more general information. Please advise. Thanks, D

June 18, 2006

Forcing Wine process to use a specific IP address

by Keshav Attrey

I want to make a process running under Wine believe that its machine's IP address is whatever IP address I specify. More specifically: I have set up several virtual interfaces on my machine. When I run a process under Wine, it by default uses the actual IP address of the machine, which is normal. But I want to force the process to be able to see and use only the virtual IP address that I specify, and not the real IP address of the machine. Do you have any ideas on how to do this? I have been trying to go through the Wine source code, and have been looking in socket.c and iphlpapi_main.c, but I have not been able to find the right places to change to force Wine to use only one particular IP address. The big idea is to run many copies of a Windows app on the same machine and make each copy think that it is running on a separate machine, each with its own IP address. Although VMWare or QEMU would make this possible, Wine is so much lighter that I could have many more copies of Wine running than VMWare. I imagine Wine would also be lighter than using Wine over Linux VServer or FreeBSD Jail... but I'm not quite sure. Any ideas? Thanks, Keshav

June 18, 2006

re: how to debug a segfault in wine-preloader?

by Dan Kegel

paul wrote: > when i run the result with wine, i get a segfault long before control > has been transferred to my code. it appears to be in wine-preloader > i cannot see how to debug this without endless printf's Don't pooh-pooh print statements as a debugging technique. It's like the duct tape of the debugging world. wine-preloader is a special environment, though; you'll have to use wld_printf rather than normal printf. - Dan

June 18, 2006

Re: acad 2004 license file bug

by Jaap Stolk

autocad 2004 update: (install sort-of completed) Internet Explorer 6: (resolved) -add registry key -change version of fake SHDOCVW.DLL to 6.0 or replace with native 6.0. "EULA not found" error: (bug 3226) (workaround) -the path to the file is not constructed correctly (not a full path) -copy eula directory to drive_c, copy cd to drive_c and install from there. "Unhandled page fault" error: (workaround) -msi_scrolltext_add_text crases with NULL parameter add to msi_scrolltext_add_text in /dlls/msi/dialog.c : if( !text ){ FIXME("msi_scrolltext_add_text( , NULL)\n"); return; } -The eula text is missing, and there are no languages to choose from, but it works. After that I was able to fill in user details and the serial number, ans I chose the "compact" install. "Error restarting the computer": not needed for wine anyway. "Acad.exe can't find DLL's in drive_c/Program Files/Common Files/Autodesk Shared": -I copied them to drive_c/windows/system32 -I was unable to add a path with a space in it to my .bash_profile. Now I'm getting into the fun part: (Macromedia Security driver) err:module:import_dll Library ntoskrnl.exe (which is needed by L"C:\\windows\\system32\\drivers\\CDAC15BA.SYS") not found

June 18, 2006

Re: acad 2004 license file bug

by Jaap Stolk

On 6/18/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Sunday, June 18, 2006, 5:36:42 AM, Jaap Stolk wrote: > > Now, my question is: how can i set the version of the buildin SHDOCVW.DLL ? > > And would MSI actually return the version of the buildin dll ? > You need to use latest Wine version that creates "fake dlls" in the system32 > dir. And to set the version, you just edit .rc file and recompile that dll. Of > course you'll need to re-create ~/.wine dir to have new version of fake dll. I was running wine 9.14 (from cvs) and I do actually have the fake dll's. It looks like I have overwritten one of them with a native one :-) So a fake dll with the correct version number should work. I changed all 5.50 to 6.00 in /dlls/shdocvw/version.rc but got the following compile error: In function `register_interfaces': /home/jaap/wine/dlls/shdocvw/regsvr.c:138: undefined reference to `CLSID_ShellSearchAssistantOC' regsvr.o(.data.rel.ro+0x80):/home/jaap/wine/dlls/shdocvw/regsvr.c:143: undefined reference to `CLSID_ShellShellNameSpace' > It seems that our version is 5.50.0.0. We might want to change that since we > already have IE version in the registry . I did not have the IE version in the registry. I added it manually using regedit. Anyway, for now I'm happy that i know what the problem is, and for now it works with the copy of the native dll and winecfg set to "buildin". The solution for the EULA error (Bug 3226) doesn't work for me, so i will be looking into that now. Jaap.

June 18, 2006

Re: acad 2004 license file bug

by Vitaliy Margolen

Sunday, June 18, 2006, 5:36:42 AM, Jaap Stolk wrote: > Now, my question is: how can i set the version of the buildin SHDOCVW.DLL ? > And would MSI actually return the version of the buildin dll ? You need to use latest Wine version that creates "fake dlls" in the system32 dir. And to set the version, you just edit .rc file and recompile that dll. Of course you'll need to re-create ~/.wine dir to have new version of fake dll. It seems that our version is 5.50.0.0. We might want to change that since we already have IE version in the registry . Vitaliy

June 18, 2006

Re: acad 2004 license file bug

by Jaap Stolk

update: I'm trying to install autoCad 2004. Without winetools I got an error message about IE6 not being found. adding the Software\\Microsoft\\Internet Explorer\Version=6.0.2900.2180 registry key (suggested by Dan Kegel) resulted in a similar error further on in the installation process. I'm using a clean ".wine" with the build in MSI. After a lot of digging through WINEDEBUG=+all and WINEDEBUG=+msimg,+msi,+msidb I found that the installer sets the value of ACAD_MSIE_INSTALLED based in the version of SHDOCVW.DLL (as suggested in http://support.microsoft.com/kb/164539 ). It is done by searching for a signature in MSI: msi:ACTION_AppSearch Searching for Property L"ACAD_MSIE_INSTALLED", Signature_ L"SHDOCVW.DLL" (The +msidb is missing in the Debug Channels list at: http://www.winehq.com/site/docs/wineusr-guide/x509 ) Adding this dll to /windows/system32/ "solved" this problem. Note that i have set this dll to "buildin" in winecfg, but it seems that the native dll is still used to check the version number. Now, my question is: how can i set the version of the buildin SHDOCVW.DLL ? And would MSI actually return the version of the buildin dll ? I'm now back onto the "EULA not found" error. (Bug 3226) but this time without having the winetools installed :-) I added /.wine/dosdevices/d: -> /mnt/cdrom1 (using winecfg) and started "wine setup.exe" from there. still no luck. Jaap.

June 18, 2006

Re: Dogfood report: Firefox autoupdate works

by Olaf Leidinger

Hello! > Oh yes, as newest GenuineCheck.exe crashes, newest > WGAPluginInstall.exe may fail also. For this > reason I've put online older versions of both: [2] > > > [1] http://www.microsoft.com/downloads/details.aspx?FamilyID=7b9ba261-7a9c-43e7… > [2] http://193.219.43.130/~winetester/bin/win32/WindowsValidation/20060517/ > Well, GenuineCheck.exe works for me on wine-0.9.15 with a fresh wine install. I wanted to install MDAC, so I applied [3] as proposed by dan and downloaded it from [4]. This is where I had to pass the GenuineCheck and it workd just fine, even with a fresh wine install. Have a look at [5] as a proof *g* Ciao, Olaf [3] cat >> $HOME/.wine/system.reg <<"_EOF_" [Software\\Microsoft\\Internet Explorer] "Version"="6.0.2900.2180" _EOF_ [4] http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=6c0… [5] http://leidola.newcon.de/pixmap/wga.jpg

June 18, 2006

Re: wined3d: declaration/FVF conversion test

by H. Verbeet

On 18/06/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > Well, caching is already accomplished by storing the FVF [ so no need > for backwards conversion]. Pretty much agreed. I think we should keep the FVF around (perhaps only in the d3d8/d3d9 part?), but use declarations for everything internally in wined3d.

June 18, 2006

Re: wined3d: declaration/FVF conversion test

by Ivan Gyurdiev

Stefan Dösinger wrote: >> and those currently fail, because that case isn't handled at all in the >> FVF loading code. It thinks this is a multi-stream case, when in fact >> only the 0th stream is used. Jason Green has a demo - >> dx9_hdr_texture_loader, which is broken exactly by this. >> > How about getting rid about the fvf in the device entirely and converting the > fvf to a vertex decl in SetFVF? That's what I was suggesting in the next sentence of that email :) > This would make the drawprim code > simpler(only vertex declaration to consider) and avoid inconsistency. In > GetFVF we convert the declaration back to a FVF(and propably cache the > result, but don't use that for rendering). > Well, caching is already accomplished by storing the FVF [ so no need for backwards conversion]. Furthermore, the backwards conversion isn't very clear at the moment - the tests show that almost all FVF fields are 0'ed when a declaration is implicitly converted to FVF by windows. I have no idea why that is yet...

June 18, 2006

Re: wined3d: declaration/FVF conversion test

by Stefan Dösinger

> and those currently fail, because that case isn't handled at all in the > FVF loading code. It thinks this is a multi-stream case, when in fact > only the 0th stream is used. Jason Green has a demo - > dx9_hdr_texture_loader, which is broken exactly by this. How about getting rid about the fvf in the device entirely and converting the fvf to a vertex decl in SetFVF? This would make the drawprim code simpler(only vertex declaration to consider) and avoid inconsistency. In GetFVF we convert the declaration back to a FVF(and propably cache the result, but don't use that for rendering).

June 18, 2006

Re: wined3d: declaration/FVF conversion test

by Ivan Gyurdiev

Ivan Gyurdiev wrote: > H. Verbeet wrote: >> On 17/06/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: >>> Comments? >> A few points: >> - Taking only the first element of the declaration into account >> seems unlikely to be correct >> - Is there a reason you're using pDeclaration9 instead of >> pDeclarationWine? It would be usefull if dx8 applications worked as >> well. >> - Let's not dump large amounts of code in >> IWineD3DDeviceImpl_SetVertexDeclaration > Ditto. I should note that fixing the fvf -> decl conversion seems > rather important, because the FVF loading code will not work with a > vertex shader at the moment - as far as I can see this will break 3 > more demos, so that brings the count of broken demos up to 5 (ASCII, > Sketch, RollerCoaster, dx9_hlsl_* (2) ). Those demos will set a > shader, and then call SetFVF() afterwards (but > primitiveConvertToStridedData will see that shader != NULL and will > not do anything) Ok I kind of lied here - those demos will not be fixed since they use the DrawPrimitiveUP function, which works differently. However, there are certainly demos which follow this pattern: - setStreamSource[0] - setVertexShader - setFVF - drawPrimitive or drawIndexedPrimitive (not UP variant). and those currently fail, because that case isn't handled at all in the FVF loading code. It thinks this is a multi-stream case, when in fact only the 0th stream is used. Jason Green has a demo - dx9_hdr_texture_loader, which is broken exactly by this. Instead of changing the FVF loading code, however, we should just translate it to a vertex declaration, and use the decl loading code.

June 17, 2006

Re: wined3d: declaration/FVF conversion test

by Ivan Gyurdiev

H. Verbeet wrote: > On 17/06/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: >> Comments? > A few points: > - Taking only the first element of the declaration into account > seems unlikely to be correct > - Is there a reason you're using pDeclaration9 instead of > pDeclarationWine? It would be usefull if dx8 applications worked as > well. > - Let's not dump large amounts of code in > IWineD3DDeviceImpl_SetVertexDeclaration Ditto. I should note that fixing the fvf -> decl conversion seems rather important, because the FVF loading code will not work with a vertex shader at the moment - as far as I can see this will break 3 more demos, so that brings the count of broken demos up to 5 (ASCII, Sketch, RollerCoaster, dx9_hlsl_* (2) ). Those demos will set a shader, and then call SetFVF() afterwards (but primitiveConvertToStridedData will see that shader != NULL and will not do anything) The current code has 2 routines - primitiveConvertToStridedData (for FVF) and primitiveDeclarationConvertToStridedData (for declaration). It seems as if the FVF should just be converted to a declaration when it is set, and a single function should be used afterwards. I could be wrong though, haven't looked at this in great detail yet...

June 17, 2006

Re: Add support for full screen window state using the NETWMprotocol

by Dmitry Timoshkov

"Mike Hearn" <mike(a)plan99.net> wrote: > I think for full IE support we need more; if you start IE, set it to > fullscreen then quit and restart it the window will now be created > unmanaged. Or at least this is how it used to work. Did you actully test the patch? It allows to leave IE in a full screen state and once it's restarted it correctly restores its state and its main window is managed. -- Dmitry.

June 17, 2006

Re: wined3d: declaration/FVF conversion test

by H. Verbeet

On 17/06/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > Comments? A few points: - Taking only the first element of the declaration into account seems unlikely to be correct - Is there a reason you're using pDeclaration9 instead of pDeclarationWine? It would be usefull if dx8 applications worked as well. - Let's not dump large amounts of code in IWineD3DDeviceImpl_SetVertexDeclaration

June 17, 2006

Re: wined3d: declaration/FVF conversion test

by Ivan Gyurdiev

> > I've attached a patch which seems to fix the first set of failures. > This sets FVF values(from converted declarations) which were not set > before. I'm still getting a lot of 0 results myself. Pretty sure I > have everything enabled. > > Comments? - If the values really are supposed to be (almost) all 0, then so be it... but then there's no point to enumerate them all in the code. - I was thinking this might go into vertexdeclaration.c instead, as vdecl_from_fvf() and vdecl_to_fvf() functions, instead of in the device code. In general way too many things are in the device code that probably should be distributed into more logical files. Anyway, thanks for working on this...

June 17, 2006

Re: wined3d: declaration/FVF conversion test

by Vitaly Budovski

Ivan Gyurdiev wrote: > Hi, I'm attaching test, which demonstrates incorrect behavior of > SetFVF and SetVertexDeclaration. > Windows converts one to the other and backwards (at least partially), > and we do not such thing - this breaks at least 2 demos (dx9_hlsl_*) > > I'm posting it here, because: > > - I don't have Windows, and I need someone to try it on machine with > pixel shader support (preferably 3.0, will need to enable pshaders and > GLSL registry key). The whole first part of the test checks decl to > fvf conversions, and they're almost all set to 0 in order to pass on > H. Verbeet and V. Margolen's setups [ which have no pshaders ]. MSDN > has a whole page on how to convert to an fvf, and the values there are > definitely *not* 0, so that's why I'm suspicious. > > - Secondly, I am leaving for NYC in 2 days to look for a place to > live, so I have limited time to clean up the test (ok/trace usage and > the like), and I have no time to implement the fix. I am hoping > someone else can finish it, because afterwards I go to Denver for a > month, where I will have limited computing capabilities. Then I start > a full time job back at NYC, so I'll be pretty busy. Anyway, I'm sure > Jave has shaders under control and will be done with sm 2, 3, 4, 5.. > 10 by the end of the summer whether I help or not :) Hi, I've attached a patch which seems to fix the first set of failures. This sets FVF values(from converted declarations) which were not set before. I'm still getting a lot of 0 results myself. Pretty sure I have everything enabled. Comments? diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c index e635352..7116d2f 100644 --- a/dlls/wined3d/device.c +++ b/dlls/wined3d/device.c @@ -4480,6 +4480,66 @@ static HRESULT WINAPI IWineD3DDeviceImpl } if (NULL != pDecl) { + DWORD fvf = 0; + D3DVERTEXELEMENT9 * declaration = ((IWineD3DVertexDeclarationImpl *)pDecl)->pDeclaration9; + if(D3DDECLTYPE_FLOAT3 == declaration->Type && + D3DDECLUSAGE_POSITION == declaration->Usage && + 0 == declaration->UsageIndex) { + fvf = D3DFVF_XYZ; + } else if(D3DDECLTYPE_FLOAT4 == declaration->Type && + D3DDECLUSAGE_POSITIONT == declaration->Usage && + 0 == declaration->UsageIndex) { + fvf = D3DFVF_XYZRHW; + } else if(D3DDECLTYPE_FLOAT1 == declaration->Type && + D3DDECLUSAGE_BLENDWEIGHT == declaration->Usage && + 0 == declaration->UsageIndex) { + fvf = 0/*D3DFVF_XYZB1*/; + } else if(D3DDECLTYPE_FLOAT2 == declaration->Type && + D3DDECLUSAGE_BLENDWEIGHT == declaration->Usage && + 0 == declaration->UsageIndex) { + fvf = 0/*D3DFVF_XYZB2*/; + } else if(D3DDECLTYPE_FLOAT3 == declaration->Type && + D3DDECLUSAGE_BLENDWEIGHT == declaration->Usage && + 0 == declaration->UsageIndex) { + fvf = 0/*D3DFVF_XYZB3*/; + } else if(D3DDECLTYPE_FLOAT4 == declaration->Type && + D3DDECLUSAGE_BLENDWEIGHT == declaration->Usage && + 0 == declaration->UsageIndex) { + fvf = 0/*D3DFVF_XYZB4*/; + } else if(D3DDECLTYPE_UBYTE4 == declaration->Type && + D3DDECLUSAGE_BLENDINDICES == declaration->Usage && + 0 == declaration->UsageIndex) { + fvf = 0/*D3DFVF_XYZB5*/; + } else if(D3DDECLTYPE_FLOAT3 == declaration->Type && + D3DDECLUSAGE_NORMAL == declaration->Usage && + 0 == declaration->UsageIndex) { + fvf = 0/*D3DFVF_NORMAL*/; + } else if(D3DDECLTYPE_FLOAT1 == declaration->Type && + D3DDECLUSAGE_PSIZE == declaration->Usage && + 0 == declaration->UsageIndex) { + fvf = 0/*D3DFVF_PSIZE*/; + } else if(D3DDECLTYPE_D3DCOLOR == declaration->Type && + D3DDECLUSAGE_COLOR == declaration->Usage && + 0 == declaration->UsageIndex) { + fvf = 0/*D3DFVF_DIFFUSE*/; + } else if(D3DDECLTYPE_D3DCOLOR == declaration->Type && + D3DDECLUSAGE_COLOR == declaration->Usage && + 1 == declaration->UsageIndex) { + fvf = 0/*D3DFVF_SPECULAR*/; + } else if(D3DDECLTYPE_FLOAT1 == declaration->Type && + D3DDECLUSAGE_TEXCOORD == declaration->Usage) { + fvf = 0/*D3DFVF_TEXCOORDSIZE1(declaration->UsageIndex)*/; + } else if(D3DDECLTYPE_FLOAT2 == declaration->Type && + D3DDECLUSAGE_TEXCOORD == declaration->Usage) { + fvf = 0/*D3DFVF_TEXCOORDSIZE2(declaration->UsageIndex)*/; + } else if(D3DDECLTYPE_FLOAT3 == declaration->Type && + D3DDECLUSAGE_TEXCOORD == declaration->Usage) { + fvf = 0/*D3DFVF_TEXCOORDSIZE3(declaration->UsageIndex)*/; + } else if(D3DDECLTYPE_FLOAT4 == declaration->Type && + D3DDECLUSAGE_TEXCOORD == declaration->Usage) { + fvf = 0/*D3DFVF_TEXCOORDSIZE4(declaration->UsageIndex)*/; + } + IWineD3DDeviceImpl_SetFVF(iface, fvf); IWineD3DVertexDeclaration_AddRef(pDecl); } if (NULL != oldDecl) {

June 17, 2006

Re: wininet file scheme

by Travis Watkins

On 6/16/06, Mike McCormack <mike(a)codeweavers.com> wrote: > > Nick Cronin wrote: > > unlike http:// etc, file:/// has 3 slashes, this patch removes the third > > slash. > > Could you provide a test case for this please? > > Specifically, is "http:///foo.bar" different to "http://foo.bar"? Your > code treats them equally. How about "file:///" and "file://"? > > Mike > > > I thought it was file://computername/path/to/file with file:///path/to/file implying the local machine. I'm not so sure this should be changed, it's some kind of a standard. -- Travis Watkins http://www.realistanew.com

June 17, 2006

Re: wininet file scheme

by Mike McCormack

Nick Cronin wrote: > unlike http:// etc, file:/// has 3 slashes, this patch removes the third > slash. Could you provide a test case for this please? Specifically, is "http:///foo.bar" different to "http://foo.bar"? Your code treats them equally. How about "file:///" and "file://"? Mike

June 16, 2006

Re: [PATCH 1/3] user: extend conformance test for remote-menu accesses

by Dmitry Timoshkov

<tkho(a)ucla.edu> wrote: > + ok (CreateProcess(NULL, "notepad.exe", NULL, NULL, FALSE, 0, NULL, NULL, > + &si, &pi), > + "CreateProcess error=%ld\n", GetLastError()); > + > + while (elapsed < timeout) > + { > + Sleep(50); > + elapsed += 50; > + > + hNotepad = GetForegroundWindow(); > + if (!hNotepad) > + continue; > + if (GetWindowText(hNotepad, wndTitle, 30) == 0) > + continue; > + if (strstr(wndTitle, "Notepad")) > + break; > + } WaitForInputIdle is supposed to be used instead of the while loop above. -- Dmitry.

June 16, 2006

Re: Build on kubuntu 6.06,amd_64 works

by Detlef Riekenberg

Hi David Anderson: > AMD_64 cpu, Kubuntu 6.06 (Dapper Drake), on HP laptop. > I finally got around to finishing a build, with current cvs sources. > Hope this is of some interest. Thanks for your Hints. I added them to the Wiki: http://wiki.winehq.org/WineOn64bit If you have updates, or a List of the required Packages, please let us know. Thanks. -- By By ... ... Detlef

June 16, 2006

Re: [WINED3D 7/7] Fix lookup for LOOP register

by Ivan Gyurdiev

Jason Green wrote: > - The LOOP register is an extended register and wasn't being checked > for in the current code. This moves the check up a level and checks > against the instruction code which is more efficient anyway. It's important to also correct the reason why it wasn't being detected where it was - instead of using the REGTYPE mask, we should call the shader_get_regtype function, which takes into account extended registers.

June 16, 2006

MS-Announced: Bill Gates will transition out of a day-to-day role in the company

by Detlef Riekenberg

15. June 2006: --- quote --- Microsoft Corp. today announced that effective July 2008 Bill Gates, chairman, will transition out of a day-to-day role in the company --- quote --- http://www.microsoft.com/presspass/press/2006/jun06/06-15CorpNewsPR.mspx Just for info. -- By By ... ... Detlef

June 16, 2006

Re: [dbghelp] improve dwarf support

by Raphael

On Friday 16 June 2006 13:06, Eric Pouech wrote: > 2006/6/16, Raphael <fenix(a)club-internet.fr>: > > Hi, > > > > Changelog: > > - map lines section > > - better robustness > > - support of unamed syms > > - better traces > > - ref hash table to stabilize model > > > > TODO: > > - find a clean way to handle forward declarations (some assertions can > > happen) > > - debug lines parsing > > I did (in parallel) some work on the dwarf2 support. I have 20+ patches to > make it really work. Those patches bring : > > - type support, including forward declarations (which really requires a two > pass parser, hence a major rewrite of the code) > - function's variables & parameter support > - line information is ok (except for inlined functions) > - a couple of bug fixes from current code > > I'd suggest hence not to apply this patch and to wait for the full solution > (likely sometimes this week-end). Yak, i was working on it too :( i'm waiting for your patches Note: i was planning to support forward checking wihout two pass Regards, Raphael

June 16, 2006

Re: slight modification to debug issue

by Alexandre Julliard

Paul Davis <paul(a)linuxaudiosystems.com> writes: > seg fault is in wine-pthread, not wine-preloader, which is even tougher > - two exec boundaries to cross. You don't need the execs, you can simply run wine-pthread directly (unless the problem is only triggered by the preloader of course). -- Alexandre Julliard julliard(a)winehq.org

June 16, 2006

Re: slight modification to debug issue

by Eric Pouech

Paul Davis wrote: >seg fault is in wine-pthread, not wine-preloader, which is even tougher >- two exec boundaries to cross. > > > > > > > > Hi Paul, did you try to do something along those lines? - insert a long loop in wine-pthread code before the crash to wait for, say, 30 seconds - after starting wine, try attaching to it with gdb (attach command) this should allow you to let gdb debug the part you want (you may have to tweak gdb to tell it which image you're referring to) A+

June 16, 2006

Re: Build on kubuntu 6.06,amd_64 works

by Scott Ritchie

On Wed, 2006-06-14 at 21:21 -0700, David Anderson wrote: > AMD_64 cpu, Kubuntu 6.06 (Dapper Drake), on HP laptop. > > I finally got around to finishing a build, with current cvs sources. > First one must install the necessary libraries: Finding the correct > set may take a few minutes and several tries. > > configure will find several omissions, but a few will only > be noticed by the 'make' steps. > > > # The following is links that the library install does not make: > # Do this by hand, it won't work as a script as written. > sudo sh > cd /usr/lib32 > ln -s libX11.so.6 libX11.so > ln -s libXext.so.6 libXext.so > > LDFLAGS="-L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32" \ > ./configure > make depend > make all > sudo make install > > > If all needed libraries are present there will be no missing-library warnings or errors anywhere. > wine seems to work (installed in /usr/local) > > Hope this is of some interest. > David Anderson > > It is, actually. It's basically a step-by-step to rewriting the build script to work on AMD-64 for the packages. I'll try hacking around with it once 0.9.16 comes out. I suspect, however, that doing it this way doesn't include EVERY lib that Wine can use properly, as there are still some libs missing from the 32bitlibs package in Ubuntu. Thanks, Scott Ritchie

June 16, 2006

Re: gdiplus.dll

by Mike Hearn

On Fri, 16 Jun 2006 11:52:37 -0400, Steven Edwards wrote: > Like the parent said, some installers don't ship with it, they expect > the OS to have it. Office 2007 only runs on XP and higher and it > expects the dll to already be there. So we find some free application that contains it and install that first :) thanks -mike

June 16, 2006

Re: Added initial version of OleView (part 1/8)

by Piotr Caban

Is there anything wrong with my patches?

June 16, 2006

Re: gdiplus.dll

by Steven Edwards

On 6/16/06, Mike Hearn <mike(a)plan99.net> wrote: > Why? GDI+ is distributed with applications, so we can put off implementing > it for some time yet. Using Monos GDI+ means using the Windows build of > Cairo too; definitely a good idea IMHO as GDI+ is somewhat nontrivial and > the code has already been written. Like the parent said, some installers don't ship with it, they expect the OS to have it. Office 2007 only runs on XP and higher and it expects the dll to already be there. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

June 16, 2006

Re: [WiKI] Common site menu 4/4

by Jeremy Newman

I'd commit it, but I'd rather hear from Dimi first. Dimi, FYI in about a month or so we are going to upgrade the WineHQ server. The old server is running out of disk space fast. Part of the reason I didn't want to host a Wiki before. With plenty of HDD that issue is gone. We are also moving the server to a new ISP with very good bandwidth. When I finish building it, I'd like to take over hosting the Wiki on the WineHQ box. Sound cool? On Thu, 2006-06-15 at 16:49 -0600, Tony Lambregts wrote: > Is there anything wrong with this patch? > > Change log: update menus for all sites to have a common "WineHQ Menu". > > files changed: winehq/winehq.py

June 16, 2006

Re: Add support for full screen window state using the NETWM protocol

by Mike Hearn

On Fri, 16 Jun 2006 18:24:34 +0900, Dmitry Timoshkov wrote: > Hello, > > this patch works for me with Internet Explorer and Diablo II demo. I think for full IE support we need more; if you start IE, set it to fullscreen then quit and restart it the window will now be created unmanaged. Or at least this is how it used to work. Still this is fine for the usual case of having it temporarily full screen. It is most instructive to compare this with my own patch. I can see how you have simplified some of the logic there. So, thankyou for that. thanks -mike

June 16, 2006

Re: monitoring WinAPI calls (Was: setupapi.dll: partially implement SetupDiGetClassDevsExA)

by Saulius Krasuckas

* On Fri, 16 Jun 2006, Mike McCormack wrote: > * Saulius Krasuckas wrote: > > > > Well, next example hasn't forced us to wait long for it. It's > > Direct3DShaderValidatorCreate9!d3d9 : (I'm sorry for swapping both parts of a function name each with other;) > Do you really need to look at assembly to figure out that you can just return > FALSE/0/NULL and make the program or dll that's calling this function happy? No, I don't. I was speaking about passing unknown count of parameters to a function. > If that doesn't make it happy, you could always write a test program > that calls the function and prints out the return value. That is not > hard either. If I know what to pass to the fn, I can, of course. > You want to tell me that it's easier to try decipher a bunch of asm that > it is to write a 10 line test program?? No, I am all just about the CPU registers and stack content, not an asm. To be honest, Mike, at start I was trying to see, whether my idea of API monitoring [4] would be acceptable for wine-developers (esp. starters). Now I want to correct myself--I was talking about +relay debug only. But at some time this discussion got slightly different point, which still has some relation to my idea. Why is all this? I am trying start my master thesis and have a thought: can't I link my favourite project (Wine) with one which has something to do with computer hardware--with BOCHS? (as I study electronics) [5] Here, we are urged to create mathematical model for every research object. I thought well, what can present a norma, an abstract system to measure difference between real WinAPI and WineAPI? Maybe count of lines of a unified diff of relay traces would help? And if BOCHS starts supporting adiabatic machine simulation once, we get nice ability to rewind process execution back in time. No? Plus I remembered I did always want to have a nice, non-intrusive WinAPI monitoring. So was the decision made to ask wine-devs about API monitoring and its usefullness :) Thank you for reading this. [4] http://winehq.org/pipermail/wine-devel/2006-March/045907.html [5] http://medeine.vtu.lt/programos/programa.jsp?fak=5&prog=7542217&sid=D&rus=U…

June 16, 2006

Re: gdiplus.dll

by Mike Hearn

On Fri, 16 Jun 2006 03:56:04 -0400, Steven Edwards wrote: > What do you mean? I looked at this before and even if we are to use > libgdiplus we need some way to wrap it in a way the Windows app > expects. Why? GDI+ is distributed with applications, so we can put off implementing it for some time yet. Using Monos GDI+ means using the Windows build of Cairo too; definitely a good idea IMHO as GDI+ is somewhat nontrivial and the code has already been written. thanks -mike

June 16, 2006

Re: Shell integration

by Mike Hearn

On Fri, 16 Jun 2006 08:54:04 -0400, Ulrich Czekalla wrote: > That's why I like the idea of using COM. All the infrastructure is already > there. For now we can implement the trash shell object inside shell32 and > if someone wants to write a OS/X version all they need to do is override a > registry key. Other shell integration objects can even be implemented > out-of-proc in the explorer process all this can be cleanly hidden from the > shell32 code that uses it. Out of process COM is never cleanly hidden; if nothing else it can cause unexpected threads to be created and unexpected re-entrancy via the implicit message loops. Given that we already have platform specific handling infrastructure in the form of the configure script, it could be as simple as having a conditional Makefile that compiles functions with magic names. thanks -mike

June 16, 2006

Re: gdiplus.dll

by Vijay Kiran Kamuju

Hi, The libgdiplus for mono is implementing things quite differently. I think its only working with mono. We need to modify our wine code so that it works with mono. (You must really ask Julliard for this) or modify libgdiplus of mono to work with wine. What I am saying is why re-invent the wheel, its already implemented by mono project or we can keep a modified version of libgdiplus in our sources. (This might cause some problems if you have mono installed). Regarding the stub dll, how does mono install the gdiplus, if it install the gdiplus as gdiplus.dll.so, it might be a problem. Those are all my concerns. Thanks, Vijay On 6/16/06, Steven Edwards <winehacker(a)gmail.com> wrote: > Hi, > > On 6/15/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > > I think we rather use mono project's libgdiplus(gdiplus.dll > > implementation) than a stub implementation. > > This will help in later implementing the .Net Compatibility Layer to Wine. > > What do you mean? I looked at this before and even if we are to use > libgdiplus we need some way to wrap it in a way the Windows app > expects. I tried to make a stub wrapper that dlopened libgdiplus and > forwarded the calls but I kept running in to some sort of problem. In > any case I don't see whats wrong with accepting this stub dll. It will > force us to implement it rather than depending on the Microsoft > version of the dll. > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo >

June 16, 2006

Re: x11drv: Escape international characters

by Andrew Talbot

Dmitry Timoshkov wrote: > "Andrew Talbot" <Andrew.Talbot(a)talbotville.com> wrote: > >> It seems better to represent international characters with escape >> sequences, both to increase clarity - especially for those who do not >> normally use ISO-8859-1 encoding - and to make editing easier for some. > > Please don't do that. Anyone who wants to edit keyboard tables should > set editor to ISO-8859-1 encoding. Otherwise it becomes really hard to > add new tables or fix existing ones by just comparing or even copy/pasting > from the +key log. > Hi Dmitry, I am very happy not to spoil anyone's day. :) I have followed my patch submission with your objection on wine-patches. -- Andy.

June 16, 2006

Re: x11drv: Escape international characters

by Dmitry Timoshkov

"Andrew Talbot" <Andrew.Talbot(a)talbotville.com> wrote: > It seems better to represent international characters with escape sequences, > both to increase clarity - especially for those who do not normally use > ISO-8859-1 encoding - and to make editing easier for some. Please don't do that. Anyone who wants to edit keyboard tables should set editor to ISO-8859-1 encoding. Otherwise it becomes really hard to add new tables or fix existing ones by just comparing or even copy/pasting from the +key log. -- Dmitry.

June 16, 2006

Re: [uxtheme] Added test for IsAppThemed and grouped it with IsThemeActive

by Alexandre Julliard

Paul Vriens <Paul.Vriens(a)xs4all.nl> writes: > On Fri, 2006-06-16 at 15:25 +0200, Alexandre Julliard wrote: >> This won't work right if theming is disabled, since IsAppThemed >> returns FALSE in that case. Also note that GetLastError doesn't return >> an HRESULT, so ERROR_SUCCESS is a better name than S_OK. >> > Well, tests (XP-enabled and W2K3-disabled) both return FALSE as our app > is not themed (I guess). Yes, the thing is that on Wine it currently returns FALSE too if theming is disabled, so it can't be a todo_wine. -- Alexandre Julliard julliard(a)winehq.org

June 16, 2006

Re: [uxtheme] Added test for IsAppThemed and grouped it with IsThemeActive

by Paul Vriens

On Fri, 2006-06-16 at 15:25 +0200, Alexandre Julliard wrote: > Paul Vriens <Paul.Vriens(a)xs4all.nl> writes: > > > + SetLastError(0xdeadbeef); > > + bAppThemed = pIsAppThemed(); > > + todo_wine > > + { > > + ok( bAppThemed == FALSE, "Expected FALSE as this test executable is not (yet) themed.\n"); > > + ok( GetLastError() == S_OK, > > + "Expected S_OK, got 0x%08lx\n", > > + GetLastError()); > > + } > > This won't work right if theming is disabled, since IsAppThemed > returns FALSE in that case. Also note that GetLastError doesn't return > an HRESULT, so ERROR_SUCCESS is a better name than S_OK. > Well, tests (XP-enabled and W2K3-disabled) both return FALSE as our app is not themed (I guess). I'll do some rediffs and tests and start again. First patch will change S_OK into ERROR_SUCCESS. Cheers, Paul.

June 16, 2006

Re: [uxtheme] Added test for IsAppThemed and grouped it with IsThemeActive

by Alexandre Julliard

Paul Vriens <Paul.Vriens(a)xs4all.nl> writes: > + SetLastError(0xdeadbeef); > + bAppThemed = pIsAppThemed(); > + todo_wine > + { > + ok( bAppThemed == FALSE, "Expected FALSE as this test executable is not (yet) themed.\n"); > + ok( GetLastError() == S_OK, > + "Expected S_OK, got 0x%08lx\n", > + GetLastError()); > + } This won't work right if theming is disabled, since IsAppThemed returns FALSE in that case. Also note that GetLastError doesn't return an HRESULT, so ERROR_SUCCESS is a better name than S_OK. -- Alexandre Julliard julliard(a)winehq.org

June 16, 2006

Re: PATCH: sane.ds / DECLSPEC hidden

by Alexandre Julliard

"Mike Hearn" <mike(a)plan99.net> writes: > On 6/15/06, Alexandre Julliard <julliard(a)winehq.org> wrote: >> No, we only want the internal functions to be hidden. > > Right, so we set default visibility to hidden then change WINAPI and > WINAPIV to include __attribute__((visibility(default))). That way only > WINAPI declarations are exported. Sure, but then it's not really useful. The whole point of marking functions explicitly is that it lets you document whether the function is intended to be private or not, and lets you spot functions that should have been static. Doing it all automatically doesn't gain you much, especially since relocations are already resolved at link time by our use of -Bsymbolic. Now for Winelib it's a different issue, there it would make sense at some point to support setting visibility to hidden and explicitly marking exported functions, so that winebuild could build the import table without requiring a spec file. But even then you have to mark exports explicitly, you can't just redefine WINAPI for that. -- Alexandre Julliard julliard(a)winehq.org

June 16, 2006

Re: PATCH: sane.ds / DECLSPEC hidden

by Mike Hearn

On 6/16/06, Robert Shearman <rob(a)codeweavers.com> wrote: > It's a little harder than that. I experimented with doing this before > and it is necessary to apply that same attribute to all of the functions > exported from libwine and libunicode. We're already forcing all exported symbols in those libraries to be visible using the linker script though so I don't see why it'd matter for them? thanks -mike

June 16, 2006

Re: Gecko installer

by Saulius Krasuckas

* On Thu, 15 Jun 2006, Jacek Caban wrote: > * Mike Hearn wrote: > > * On 6/14/06, Jacek Caban <jacek(a)codeweavers.com> wrote: > > > I'd really like to use Linux Gecko, but it's impossible because > > > we'd need XEmbed embedder support that's impossible to implement in > > > Wine (perhaps if we added what we need to XEmbed spec?). > > > > OK. What exactly *do* we need from XEmbed? Is this because we can no > > longer use child X windows? > > I think Alexandre can give you the best answer. Yes, the problem is > mostly because of lack of child X windows. The main thing we'd have to > add to XEmbed spec is clipping but probably there will be more problems. > And I have no idea if freedesktop guys will accept what we need as > clipping in XEmbed spec is useless for most apps (probably everyone > except Wine). Then maybe we can say to freedesktop folks Wine isn't one application. It's tens of applications. Or maybe they would accept spec for independent protocol, called XWine (e.g.) for the mentioned reason? :]

June 16, 2006

Re: Shell integration

by Ulrich Czekalla

On Thu, Jun 15, 2006 at 11:26:02AM +0100, Robert Shearman wrote: > I don't think it is. I think it would be better to start off with by > just doing the shell integration in shell32. If a framework like this is > needed, then it will become obvious later on. > That's why I like the idea of using COM. All the infrastructure is already there. For now we can implement the trash shell object inside shell32 and if someone wants to write a OS/X version all they need to do is override a registry key. Other shell integration objects can even be implemented out-of-proc in the explorer process all this can be cleanly hidden from the shell32 code that uses it. /Ulrich

June 16, 2006

Re: PATCH: sane.ds / DECLSPEC hidden

by Robert Shearman

Mike Hearn wrote: > On 6/15/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > >> No, we only want the internal functions to be hidden. > > > Right, so we set default visibility to hidden then change WINAPI and > WINAPIV to include __attribute__((visibility(default))). That way only > WINAPI declarations are exported. It's a little harder than that. I experimented with doing this before and it is necessary to apply that same attribute to all of the functions exported from libwine and libunicode. -- Rob Shearman

June 16, 2006

Re: Broken FC5 packages - stay clear.

by Vitaliy Margolen

Friday, June 16, 2006, 1:04:52 AM, Andreas Bierfert wrote: > On Wed, 14 Jun 2006 13:36:03 +0100 > Mike Hearn <mike(a)plan99.net> wrote: >> I think a meta package called "wine" that installed everything would be >> much better because that would do what end users would intuitively expect. >> And Wine isn't really a suite. It's a large, monolithic program. If it was >> a suite we'd realease separate tarballs upstream. > I would like that a lot better but then you have the problem that people who > have wine installed now (and don't want the rest) will get everything on the > next upgrade... I will think about it and discuss it with some other Fedora > Extras people and see what their opinion is... The single argument that I can add here to make Wine into a monolith package is: Where have you seen windows without *. (replace * with each possible package you are trying to create). And I'm not talking about xp embedded. It's not a matter if we like it or not. Lots of applications depend on one functionality or another. As well as developers, when they code some features in. Or ask for the debug output. Besides, all the stuff that you split is small (for anyone to be concerned with package sizes). Vitaliy

June 16, 2006

Re: PATCH: sane.ds / DECLSPEC hidden

by Mike Hearn

On 6/15/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > No, we only want the internal functions to be hidden. Right, so we set default visibility to hidden then change WINAPI and WINAPIV to include __attribute__((visibility(default))). That way only WINAPI declarations are exported. thanks -mike

June 16, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Saulius Krasuckas

* On Tue, 13 Jun 2006, Dmitry Timoshkov wrote: > * "Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: > > * On Mon, 12 Jun 2006, Mike McCormack wrote: > > > * Saulius Krasuckas wrote: > > > > > > > > And what if interface is blackboxed? > > > > > > I don't know what a "blackboxed interface" is. If you could name > > > the interface you're talking about it would be easier to understand > > > what you mean. > > > > I remember that last one was GetUName!getuname: > > [2] http://www.winehq.org/pipermail/wine-devel/2006-June/048500.html > > That one doesn't count (there were enough explanations why). Another one? Well, next example hasn't forced us to wait long for it. It's Direct3DShaderValidatorCreate9!d3d9 : [3] http://www.winehq.org/pipermail/wine-patches/2006-June/027601.html

June 16, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Mike McCormack

Saulius Krasuckas wrote: > Well, next example hasn't forced us to wait long for it. > It's Direct3DShaderValidatorCreate9!d3d9 : Do you really need to look at assembly to figure out that you can just return FALSE/0/NULL and make the program or dll that's calling this function happy? If that doesn't make it happy, you could always write a test program that calls the function and prints out the return value. That is not hard either. You want to tell me that it's easier to try decipher a bunch of asm that it is to write a 10 line test program?? I fail to see anything different here. Mike

June 16, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Dmitry Timoshkov

"Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: > Well, next example hasn't forced us to wait long for it. > It's Direct3DShaderValidatorCreate9!d3d9 : > > [3] http://www.winehq.org/pipermail/wine-patches/2006-June/027601.html Just replied to that e-mail. So that one doesn't count either. My guess is the author of the "patch" is using a load of native d3d dlls. -- Dmitry.

June 16, 2006

Re: add stub for Direct3DShaderValidatorCreate9 (d3d9)

by Dmitry Timoshkov

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > It's not really possible to test this function on windows , but > i think this is quite a good guess for the function's prototype. > I've tested with quite some samples from www.codesampler.com. Other > implementations make the samples crash . > > (http://www.codesampler.com/source/dx9_cg_simple.zip is an example > of an app that calls this function) You're must be doing something not usual, but the .exe pointed out above doesn't contain Direct3DShaderValidatorCreate9 in its imports. -- Dmitry.

June 16, 2006

Re: Remove an assert in StgStreamImpl_Write()

by Mike McCormack

Robert Shearman wrote: > Francois Gouget wrote: > >> >> Changelog: >> >> * dlls/ole32/stg_stream.c >> >> Aric Stewart <aric(a)codeweavers.com> >> Remove an assert and instead just fail. >> This allows iTunes to finish installing with the reboot. >> > > A better fix would be to check the result of IStream_SetSize in this > function, although I think the original problem may well be fixed after > the STG_E_REVERTED checks. If we can still run into the assert, a test case showing that would be welcome ... Mike

June 16, 2006

Re: Remove an assert in StgStreamImpl_Write()

by Robert Shearman

Francois Gouget wrote: > > Changelog: > > * dlls/ole32/stg_stream.c > > Aric Stewart <aric(a)codeweavers.com> > Remove an assert and instead just fail. > This allows iTunes to finish installing with the reboot. > A better fix would be to check the result of IStream_SetSize in this function, although I think the original problem may well be fixed after the STG_E_REVERTED checks. -- Rob Shearman

June 16, 2006

Re: [dbghelp] improve dwarf support

by Eric Pouech

2006/6/16, Raphael <fenix(a)club-internet.fr>: > > Hi, > > Changelog: > - map lines section > - better robustness > - support of unamed syms > - better traces > - ref hash table to stabilize model > > TODO: > - find a clean way to handle forward declarations (some assertions can > happen) > - debug lines parsing I did (in parallel) some work on the dwarf2 support. I have 20+ patches to make it really work. Those patches bring : - type support, including forward declarations (which really requires a two pass parser, hence a major rewrite of the code) - function's variables & parameter support - line information is ok (except for inlined functions) - a couple of bug fixes from current code I'd suggest hence not to apply this patch and to wait for the full solution (likely sometimes this week-end). -- Eric Pouech

June 16, 2006

Re: Quartz: Improve a stub

by Robert Shearman

ivanleo(a)gmail.com wrote: > It looks like someone was implementing some stuff and left it half way > through, That was me. I didn't have any documentation on how the extensions processing was meant to work. > so the result is GetClassMediaFile was hard coded to fail > because process_extensions always fails. Err, no. Did you read the code? The fallback is the more common method of recognising a byte sequence at the start of the file. > This patch is needed by the > IAMMultiMediaStreamImpl_OpenFile which will follow. The two together > allow Crimson Skies to start and get to the menu instead of crashing. >--- winenew/dlls/quartz/filesource.c 2006-05-23 13:48:29.000000000 +0100 >+++ wine/dlls/quartz/filesource.c 2006-06-15 22:50:40.000000000 +0100 >@@ -65,7 +65,10 @@ > static HRESULT process_extensions(HKEY hkeyExtensions, LPCOLESTR pszFileName, GUID * majorType, GUID * minorType) > { > /* FIXME: implement */ >- return E_NOTIMPL; >+ >+ FIXME("(%p, %s, %p, %p), stub!\n", hkeyExtensions, debugstr_w(pszFileName), majorType, minorType); >+ >+ return S_OK; > } > > Great. Now majorType and minorType will be left uninitialised, causing weird and hard-to-debug problems later on. -- Rob Shearman

June 16, 2006

Re: ntoskrnl status

by Mike McCormack

Mario Demontis wrote: > I read that the patch is Diffed against > 1d40bf0141b7f67b1188555962698f5dab631bc3 > What does it mean? How can I get my cvs directory to that state? http://wiki.winehq.org/GitWine Mike

June 16, 2006

Re: ntoskrnl status

by Mario Demontis

In http://www.winehq.com/pipermail/wine-devel/2006-June/048583.html I read that the patch is Diffed against 1d40bf0141b7f67b1188555962698f5dab631bc3 What does it mean? How can I get my cvs directory to that state? Thanks Mario On gio, 2006-06-15 at 20:48 -0600, Vitaliy Margolen wrote: > Thursday, June 15, 2006, 10:01:03 AM, Brian Vincent wrote: > > On 6/15/06, Mario Demontis <mario.demontis(a)email.it> wrote: > >> Any news about ntoskrnl.exe support? > >> As far as I can understand it's not yet integrated... > >> Are there any new patches? > > > Read here first: > > http://www.winehq.com/pipermail/wine-devel/2006-April/047262.html > > > Read here next: > > http://www.winehq.com/pipermail/wine-devel/2006-June/048583.html > > > Vitaliy Margolen seems to be working on it a bit. > > > Vitaliy - in your email above you wrote, "Here is last instalment". > > Did you mean, "Here is _the latest_ installment."? I was going to > > include that post in this week's WWN and just wanted to make it > > correct. > > Yes sorry. It was last at the time I sent it. Now I have one more (with > suggested fixes and against yesterday's git. > > As far as state of it: > 1. It runs again using new method of communications to ntoskrnl. > 2. It's still more of the prove of concept stage then production quality code. > 3. There are several hacks that needs to be dealt with. > 4. Not yet agreed on what ntoskrnl.exe should be (a dll, or a separate process). > > > 1) We used named pipe to talk to ntoskrnl directly from the user space. Now all > the communication is going through wineserver. > > 2) New ioctl code is highly experimental. wineserver needs to use already setup > objects and structures. To start with, I think user space code and ntoskrnl code > are good enough. > Driver loading looks fine, with exception of service query. We need some way to > check if driver is loaded and running (might need to add one more ioctl to the > ntoskrnl). > > 3) ntoskrnl startup is suboptimal. It should look like explorer's startup (there > are few problems and major differences however). One more hack is associated > with process startup sequence of events. Wine differs from native in such a way > that brakes safedisc. > > 4) Alexandre offered an idea to make ntoskrnl.exe a dll that could be loaded by > an existent explorer process. This is an interesting approach, but there could > be some complications associated with it. > > > So to sum it up: we have a working prototype that's been in this state for > almost a year now. It's big project with number of different parts. Each part > could be a big project on it's own if implemented all the way. So if anyone > wants to spend some time learning the subject and getting it into Wine, they are > very welcome to jump on board. > > Vitaliy. > > > > > -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Ascolta tutta la musica che vuoi gratis! * Clicca su www.radiosnj.com Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5176&d=16-6

June 16, 2006

Re: ntoskrnl status

by Jonathan Ernst

Le vendredi 16 juin 2006 à 11:37 +0200, Mario Demontis a écrit : > In http://www.winehq.com/pipermail/wine-devel/2006-June/048583.html > I read that the patch is Diffed against > 1d40bf0141b7f67b1188555962698f5dab631bc3 > What does it mean? How can I get my cvs directory to that state? > > Thanks > Mario You can use Git: http://wiki.winehq.org/GitWine Regards. P.S. please don't top-post bottom-posted e-mails/threads

June 16, 2006

Re: wined3d compile failure

by stefan＠codeweavers.com

On Thursday 15 June 2006 20:03, James Hawkins wrote: > Hi, > > I'm getting this compile failure as of today: > > make[2]: Entering directory `/home/jhawkins/wine/dlls/wined3d' > gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include > -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -gstabs+ -Wpointer-arith -g -O2 -o device.o device.c > device.c: In function `IWineD3DDeviceImpl_SetRenderState': > device.c:3833: `GL_FOG_COORD_SRC' undeclared (first use in this function) > device.c:3833: (Each undeclared identifier is reported only once > device.c:3833: for each function it appears in.) > device.c:3873: `GL_FOG_COORD' undeclared (first use in this function) > make[2]: *** [device.o] Error 1 > make[2]: Leaving directory `/home/jhawkins/wine/dlls/wined3d' > make[1]: *** [wined3d] Error 2 > make[1]: Leaving directory `/home/jhawkins/wine/dlls' > make: *** [dlls] Error 2 Uh oh, this was my fault :-( I did't think that the constants need the _EXT too. But apparently H. Verbeet was faster in creating a fix. Thanks :-) I will watch out better when using extensions the next time :-)

June 16, 2006

Re: gdiplus.dll

by Steven Edwards

Hi, On 6/15/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > I think we rather use mono project's libgdiplus(gdiplus.dll > implementation) than a stub implementation. > This will help in later implementing the .Net Compatibility Layer to Wine. What do you mean? I looked at this before and even if we are to use libgdiplus we need some way to wrap it in a way the Windows app expects. I tried to make a stub wrapper that dlopened libgdiplus and forwarded the calls but I kept running in to some sort of problem. In any case I don't see whats wrong with accepting this stub dll. It will force us to implement it rather than depending on the Microsoft version of the dll. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

June 16, 2006

Re: Broken FC5 packages - stay clear.

by Andreas Bierfert

On Wed, 14 Jun 2006 13:36:03 +0100 Mike Hearn <mike(a)plan99.net> wrote: > Well, that would be an improvement but people tend to just guess > at what they need to type for programs like yum/apt. It's one of the > problems they have. Does "yum install epiphany" install a web browser or a > card game? You don't know unless you check beforehand (or try it). That probably is true for a lot of users... > I think a meta package called "wine" that installed everything would be > much better because that would do what end users would intuitively expect. > And Wine isn't really a suite. It's a large, monolithic program. If it was > a suite we'd realease separate tarballs upstream. I would like that a lot better but then you have the problem that people who have wine installed now (and don't want the rest) will get everything on the next upgrade... I will think about it and discuss it with some other Fedora Extras people and see what their opinion is... > I know, and apologise for my harsh tone earlier. I think it's great you > are here on wine-devel and working through the problems with us. No problem... as long as we work for the same goals I don't mind it to much ;) > Hopefully you also understand the source of our frustration - I have > wasted *many* hours debugging problems that turned out to be caused by bad > packaging. This problem occurs all the time and when we eventually get one > problem fixed, some other distro somewhere else gets it wrong again and we > are back to square one. It feels like we never move forward on this issue. I understand that and I hope that with some changes here and there we can (at least for the fedora stuff) minimize these problems. That is one part why I value input from upstream that much... > Also I'm afraid the answer of "report bugs to bugzilla.redhat.com" > is not OK because it is not under our control. I'd say the vast > majority of end users don't use distributor bug systems and never have, > not even for Debian which has always had this policy. They post to > wine-users, or IRC, or our bugzilla, or random web forums. And then we get > to pick up the pieces. Yes, and I hope in the future when they do report stuff it really is something with wine and not with the packages behind it. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred

June 16, 2006

Re: ntoskrnl status

by Vijay Kiran Kamuju

If Alexander agrees on what path we should take on this, we should be having some real stuff getting in. A'int it Vitaly. Well i will look into the ntoskrnl stuff as soon as i get my laptop I think should be like a seperate process as in windows. Just my two cents. On 6/15/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Thursday, June 15, 2006, 10:01:03 AM, Brian Vincent wrote: > > On 6/15/06, Mario Demontis <mario.demontis(a)email.it> wrote: > >> Any news about ntoskrnl.exe support? > >> As far as I can understand it's not yet integrated... > >> Are there any new patches? > > > Read here first: > > http://www.winehq.com/pipermail/wine-devel/2006-April/047262.html > > > Read here next: > > http://www.winehq.com/pipermail/wine-devel/2006-June/048583.html > > > Vitaliy Margolen seems to be working on it a bit. > > > Vitaliy - in your email above you wrote, "Here is last instalment". > > Did you mean, "Here is _the latest_ installment."? I was going to > > include that post in this week's WWN and just wanted to make it > > correct. > > Yes sorry. It was last at the time I sent it. Now I have one more (with > suggested fixes and against yesterday's git. > > As far as state of it: > 1. It runs again using new method of communications to ntoskrnl. > 2. It's still more of the prove of concept stage then production quality code. > 3. There are several hacks that needs to be dealt with. > 4. Not yet agreed on what ntoskrnl.exe should be (a dll, or a separate process). > > > 1) We used named pipe to talk to ntoskrnl directly from the user space. Now all > the communication is going through wineserver. > > 2) New ioctl code is highly experimental. wineserver needs to use already setup > objects and structures. To start with, I think user space code and ntoskrnl code > are good enough. > Driver loading looks fine, with exception of service query. We need some way to > check if driver is loaded and running (might need to add one more ioctl to the > ntoskrnl). > > 3) ntoskrnl startup is suboptimal. It should look like explorer's startup (there > are few problems and major differences however). One more hack is associated > with process startup sequence of events. Wine differs from native in such a way > that brakes safedisc. > > 4) Alexandre offered an idea to make ntoskrnl.exe a dll that could be loaded by > an existent explorer process. This is an interesting approach, but there could > be some complications associated with it. > > > So to sum it up: we have a working prototype that's been in this state for > almost a year now. It's big project with number of different parts. Each part > could be a big project on it's own if implemented all the way. So if anyone > wants to spend some time learning the subject and getting it into Wine, they are > very welcome to jump on board. > > Vitaliy. > > > > > > > >

June 15, 2006

Re: ntoskrnl status

by Vitaliy Margolen

Thursday, June 15, 2006, 10:01:03 AM, Brian Vincent wrote: > On 6/15/06, Mario Demontis <mario.demontis(a)email.it> wrote: >> Any news about ntoskrnl.exe support? >> As far as I can understand it's not yet integrated... >> Are there any new patches? > Read here first: > http://www.winehq.com/pipermail/wine-devel/2006-April/047262.html > Read here next: > http://www.winehq.com/pipermail/wine-devel/2006-June/048583.html > Vitaliy Margolen seems to be working on it a bit. > Vitaliy - in your email above you wrote, "Here is last instalment". > Did you mean, "Here is _the latest_ installment."? I was going to > include that post in this week's WWN and just wanted to make it > correct. Yes sorry. It was last at the time I sent it. Now I have one more (with suggested fixes and against yesterday's git. As far as state of it: 1. It runs again using new method of communications to ntoskrnl. 2. It's still more of the prove of concept stage then production quality code. 3. There are several hacks that needs to be dealt with. 4. Not yet agreed on what ntoskrnl.exe should be (a dll, or a separate process). 1) We used named pipe to talk to ntoskrnl directly from the user space. Now all the communication is going through wineserver. 2) New ioctl code is highly experimental. wineserver needs to use already setup objects and structures. To start with, I think user space code and ntoskrnl code are good enough. Driver loading looks fine, with exception of service query. We need some way to check if driver is loaded and running (might need to add one more ioctl to the ntoskrnl). 3) ntoskrnl startup is suboptimal. It should look like explorer's startup (there are few problems and major differences however). One more hack is associated with process startup sequence of events. Wine differs from native in such a way that brakes safedisc. 4) Alexandre offered an idea to make ntoskrnl.exe a dll that could be loaded by an existent explorer process. This is an interesting approach, but there could be some complications associated with it. So to sum it up: we have a working prototype that's been in this state for almost a year now. It's big project with number of different parts. Each part could be a big project on it's own if implemented all the way. So if anyone wants to spend some time learning the subject and getting it into Wine, they are very welcome to jump on board. Vitaliy.

June 15, 2006

slight modification to debug issue

by Paul Davis

seg fault is in wine-pthread, not wine-preloader, which is even tougher - two exec boundaries to cross.

June 15, 2006