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

Allowed reverse engineering methods
by Mariusz Pluciński 30 May '10

30 May '10

Hello I'm working on implementation of Games Explorer for Wine (in Google Summer of Code). My work gets progress, but to finish it, I need to get more information about Windows implementation. My question is: which reverse engineering methods are legal and accepted while working in Wine project? Only information I found is located on Wine's wiki page (http://wiki.winehq.org/SummerOfCode) > * You are not allowed to read or reuse Windows source code >(leaked source / Windows >Research Kernel* / ...) >(* we are following the SFLC's advice) > * You are not allowed to reverse engineer Windows files by >disassembling or >decompiling them > * You are not allowed to analyze Windows files with the >trace functions of Wine But which methods are allowed? I assume that "obvious" methods (reading header files, registry dumps, etc.) are acceptable, but can I e.g. analyze .pdb symbol files (availble in e.g. Microsoft's DirectX SDK)? Can I copy executable from Windows (.exe) and analyze it in Wine using winedebug's "relay" channel? (last point from website I linked above says that I can't analyze "Windows files" this way, but I'm not sure is it apply for executables in way I described). Mariusz Pluciński

4 3

Replacement of "#if 0" by "if (0)" blocks
by Frédéric Delanoy 30 May '10

30 May '10

Hi folks, after seeing aafef7cdd56e488d2f42eb01190e51ce6148b664 (Use if(0) instead of #if 0 to make sure code still compiles), IMHO, except special cases (like maybe in headers files), those '#if 0' have no advantages compared to "if (0)" (besides being highlighted in vim), because they may induce code rot and hence prevent maintenance (and why not delete them to begin with?)... I'm looking at the remaining cases, and have some questions: - should this situation be changed/cleaned up (I wouldn't want to spend time only to see my patches automatically refused...)? Are there any reasons for those #if blocks other than easier commenting? - if yes, is it preferable to (1) delete those sections or (2) replace them with "if" blocks (and delete them if they don't compile?)? Frédéric

2 1

"Powered by Mozilla" somewhere subtle on winehq?
by Scott Ritchie 30 May '10

30 May '10

http://www.mozilla.org/projects/powered-by.html Mozilla has a small campaign to mention projects that depend on them in various fashions. I think it'd be neat to get listed there on that page. Mozilla in turn would like us to mention Mozilla somewhere on our site. This seems like something we should do anyway, along with all our other dependencies - I'm thinking a link off the about page would be nice. Thoughts? Thanks, Scott Ritchie

3 2

Re: localspl: Add Italian translation
by Sven Baars 30 May '10

30 May '10

Luca Bennati wrote: > +/* + * English resources for localspl + * + * Copyright 2005 Huw > Davies + * Copyright 2006 Detlef Riekenberg + * Hey Luca, This should probably be +/* + * Italian resources for localspl + * + * Copyright 2010Luca Bennati + * Same for your other patches ;) Sven

2 1

Building a CUDA 3.0 dll wrapper, compile errors
by Seth Shelnutt 30 May '10

30 May '10

I've done this before, with no problems for cuda 2.x, but it's been a while and I'm having troubles. I think I have everything configured right, as I got the cufft dll wrapper compiled but the cudart dll wrapper is acting like I am not linking it to the linux libcudart.so, but I am. I've noticed a few changed in winemaker, and I thought I'd get some to check my make file / see if they can see anything wrong. My source can be found here, http://shelnutt2.host56.com/cudart/ . I'm assuming your cuda toolkit is installed in the default location of /usr/local/cuda . My errors are: winegcc -shared cudart.dll.spec -mno-cygwin -o cudart.dll.so cudart.o -L/usr/local/cuda/lib/ -lcudart -lodbc32 -lole32 -loleaut32 -lwinspool -lodbccp32 -luuid cudart.o: In function `__saturatef': cudart.c:(.text+0x3b6c): undefined reference to `__cuda___isnanf' cudart.o: In function `__sad': cudart.c:(.text+0x3bfc): undefined reference to `__cuda_llabs' cudart.o: In function `__usad': cudart.c:(.text+0x3c47): undefined reference to `__cuda_llabs' cudart.o: In function `__internal_float2ll_kernel': cudart.c:(.text+0x3d2b): undefined reference to `__cuda___isnanf' cudart.o: In function `__internal_float2ull_kernel': cudart.c:(.text+0x4082): undefined reference to `__cuda___isnanf' cudart.o: In function `__fdividef': cudart.c:(.text+0x4eaa): undefined reference to `__cuda_fabsf' cudart.c:(.text+0x4ecf): undefined reference to `__cuda_fabsf' cudart.o: In function `__expf': cudart.c:(.text+0x5085): undefined reference to `__cuda_exp2f' cudart.o: In function `__exp10f': cudart.c:(.text+0x50b6): undefined reference to `__cuda_exp2f' cudart.o: In function `__powf': cudart.c:(.text+0x5140): undefined reference to `__cuda_exp2f' cudart.o: In function `__internal_double2ll_kernel': cudart.c:(.text+0x6130): undefined reference to `__cuda___isnan' cudart.o: In function `__internal_double2ull_kernel': cudart.c:(.text+0x6383): undefined reference to `__cuda___isnan' cudart.o: In function `clock64': cudart.c:(.text+0x7f61): undefined reference to `__cuda_clock' Thanks, Seth Shelnutt

2 1

Re: comctl32/tests: Added a test that checks whether setting a custom default button in a property sheet works
by Nikolay Sivov 29 May '10

29 May '10

On 5/30/2010 02:12, Alexandru Băluț wrote: > The test I added checks that in a property sheet the custom default > button is pressed when the ENTER key is pressed and a different > control, a combobox, has the keyboard focus. The test succeeds when > running on Vista, and fails when running on Wine, that's why I added > "todo_wine" before it. > > This problem is described in bug 22862: "Setting the default button in > a PropertySheetPage does not work". You forgot a patch.

1 0

Re: [Wine] How do I fix the 'fixme's
by Frédéric Delanoy 29 May '10

29 May '10

On Sat, May 29, 2010 at 02:53, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > trapspringer wrote: >> >> How can i fix this? >> > > Become a Wine developer and write the code that implements these features! > Fixme's are for code that is missing to implement functions that exist in > the Win32/Win64 APIs that are partially implemented and need further work to > become fully implemented. I always found this naming a bit confusing. "fixme" sounds like "there's a bug/workaround here" IMHO. (That's not the first post I read about this IIRC) "todo" or similar would be more consistent, don't you think? > James McKenzie Frédéric

2 1

Regression Statistics
by Michael Stefaniuc 29 May '10

29 May '10

Hello guys, I thought about doing a regression report like Rafael Wysocki is doing for the Linux Kernel http://marc.info/?l=linux-kernel&m=127344241607730&w=4 but I got cured when looking at the regression list on bugs.winehq.org. We have at least by a factor of three too many regressions. So here is just a high level overview; the numbers were taken on 2010/05/29 at 10:00 UTC. Regressions ----------- Open: 316 Status Regressions Patch Download Download+Patch UNCONFIRMED 164 3 46 0 NEW 139 20 85 11 REOPENED 10 2 2 0 ASSIGNED 3 1 1 0 Of course there should be no UNCONFIRMED regression with a "download" keyword, right? Alexandre also said on irc that most of the open regressions are valid so the UNCONFIRMED count could be even lower. While gathering those numbers bugzilla presented me with the proper wisdom: "Don't let a bug in your wine bother you. Just remove it." If somebody is desperately looking for an interesting challenge during the boring feature freeze times the regression list on bugs.winehq.org has it! As always: "Limited stock available; first come first serve". :) bye michael

1 0

d3dx9effect.h; Errors in h files are bugs?
by Luis Busquets 29 May '10

29 May '10

winehq in include/d3dx9effect.h adds in the definition of ID3DXEffectCompiler the methods: STDMETHOD(SetPixelShader)(THIS_ D3DXHANDLE parameter, LPDIRECT3DPIXELSHADER9 pshader) PURE; STDMETHOD(SetVertexShader)(THIS_ D3DXHANDLE parameter, LPDIRECT3DVERTEXSHADER9 vshader) PURE; None of this methods is part of ID3DXBaseEffect (the group of the methods ID3DXEffectCompiler in which they are set) and none is part of the specific methods of ID3DXEffectCompiler Thus, these two methods should be removed from the .h file? Does this qualify as a bug to put in winebugs or is the winehq policy to report these kind of source code bugs to the wine-devel list?

2 1

Re: [PATCH] msi: Publish icons into the correct directory
by testbot＠testbot.winehq.org 29 May '10

29 May '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2384 Your paranoid android. === W98SE (32 bit install) === Failure running script in VM: Exceeded timeout limit of 315 sec === WNT4WSSP6 (32 bit install) === Timeout === W7PROX64 (32 bit install) === install.c:5402: Test failed: Expected "C:\Program Files (x86)\msitest\maximus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5421: Test failed: Expected "01\msitest\augustus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5446: Test failed: Expected "C:\Program Files (x86)\msitest\maximus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5465: Test failed: Expected "01\msitest\augustus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" === W7PROX64 (64 bit install) === install.c:3525: Test failed: Expected 314, got 30 install.c:8255: Test failed: RegQueryValueExA failed 2 (0)

1 0