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

Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)
by Daniel Santos 13 May '09

13 May '09

ooh! shiny! thank you! Too bad it doesn't work with +all. I suppose I can just list them out individually in my WINEDEBUG though. --- On Wed, 5/13/09, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: From: Roderick Colenbrander <thunderbird2k(a)gmail.com> Subject: Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags) To: daniel.santos(a)pobox.com Cc: wine-devel(a)winehq.org, "Steven Edwards" <winehacker(a)gmail.com> Date: Wednesday, May 13, 2009, 3:05 PM You might also want to check the debug patch in here: http://wiki.winehq.org/InterestingPatches It allows you to enable debugging when you need it by ahttp://wiki.winehq.org/InterestingPatches keypress. E.g. WINEDEBUG=+some_channel (except for +all) WINEDELAY=enable wine app.exe Roderick

1 0

Re: Wine policy question: What is considered "reverse engineering"/what is acceptable?
by Daniel Santos 13 May '09

13 May '09

Thank you all very much for the clarification, it is exceedingly helpful! I don't care to look at microsoft's code because I doubt I have the stomach for it! But now I feel much better, that I wasn't doing anything wrong by examining the program state of the misbehaving app (it was on wine anyway). I don't mind jumping through hoops of various sizes to isolate a problem, but to have to do that without debugging, yikes!, that's like having both hands tied behind your back! --- On Wed, 5/13/09, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: From: Roderick Colenbrander <thunderbird2k(a)gmail.com> Subject: Re: Wine policy question: What is considered "reverse engineering"/what is acceptable? To: "Jerome Leclanche" <adys.wh(a)gmail.com> Cc: daniel.santos(a)pobox.com, wine-devel(a)winehq.org Date: Wednesday, May 13, 2009, 3:11 PM On Wed, May 13, 2009 at 10:02 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > I thought reverse engineering was only relevant to MS code? As in > reverse engineering of windows dlls and so on; another application > would be irrelevant. > > That's what I understood from it anyway. First of all I'm not a lawyer ;) Correct you should avoid looking at windows code. Regarding Microsoft code we only allow black box reverse engineering, so you feed the dll with some input and check the outcome without looking what happens inside (so without checking debug logs of MS dlls). Looking at Microsoft debug traces should be avoided as it is similar to disassembling a program IF it is for the purpose of figuring out what the black box is doing. Looking at debug traces of programs is fine and as I said it is similar to looking at the output of a disassembler. Sure it can happen that you are looking at calls made by Microsoft code since some Microsoft dlls are being used but you are not aware of that and you are not trying to reverse engineer the particular Microsoft dll, so that would also be fine (though it is a gray area). Roderick

1 0

Wine policy question: What is considered "reverse engineering"/what is acceptable?
by Daniel Santos 13 May '09

13 May '09

I was recently attempting to isolate the cause of a hang in Lord of the Rings Online and had it in a debugger. I mentioned this on IRC and was told that I was "reverse engineering" and any patch I came up with would not be accepted. I find this rather confusing and would like to better understand the "dos and don'ts" of wine development. Is this documented anywhere? If it matters any, the license agreement says that you may not reverse engineering it including "decompiling or disassembling" but it does not specifically mention using a debugger (although viewing disassembly from the debugger would obviously be covered). My aim was only to attempt to determine which thread(s) were hanging so I could isolate my logging to those thread(s) and try to figure out what was going wrong. Thanks, Daniel

4 3

Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)
by Daniel Santos 13 May '09

13 May '09

Steven, sorry for the slow response, I got tied up in some other stuff. But now back to fun. =) And thanks for your response! The application is Lord of the Rings Online. They don't use normal version numbers, so this bug actually started with "Book 14". In Book 14, the problem would manifest as a crash. The current version is "Mines of Moria" and now I will get either a crash (segfault) or a hang, but the result is a hang 6 times out of 7 (or so). However, I've run into a more serious problem that I have yet to resolve, and I'll post it in a new thread. This problem is related to what is considered acceptable behavior and what is not and what is considered "reverse engineering". I mentioned that I had the program in winedbg and was examining the threads when I was informed that I was reverse engineering and any patch I came up with doing this would not be accepted. I found this rather confounding to say the least!! Anyway, the hang or crash may occur immediately (under 50 milliseconds) after switching to the LOTRO window or it may only occur after I start moving around. It will always occur within 10 or 20 seconds of having switched to the window, usually within 4 or 5. So if I start playing after swithcing to the window and I make it 30 seconds, I'm confident that it wont crash that time. If you want to install this app, I have recently written up a pretty install script to do some enviroment setup and posted it on the appdb here: http://appdb.winehq.org/objectManager.php?sClass=version&iId=14566 You can even create a trial account for testing. Unfortunately, it's a 7GB download. One of my shortcomings in troubleshooting this is that I've never done directx or direct3d, so I don't understand all of the implications of these window events from that perspective (or direct input). I'm going to play more with this today as well. Daniel --- On Sat, 5/9/09, Steven Edwards <winehacker(a)gmail.com> wrote: From: Steven Edwards <winehacker(a)gmail.com> Subject: Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags) To: daniel.santos(a)pobox.com Date: Saturday, May 9, 2009, 3:16 PM On Sat, May 9, 2009 at 3:44 PM, Daniel Santos <javatroubadour(a)yahoo.com> wrote: > Additionally, as far as I can tell, there is no mechanism to change it for > all channels. This is actually what I need to do since I do not know where > the specific problem is that I'm troubleshooting and I don't even know for > certain that it isn't a bug in the 3rd party software. What I do know is > that it does not occur on windows and I suspect it's a case of the 3rd party > app entering "undefined results" territory and that on windows, this result > is consistent and does not cause a problem. > > When I attempt to run the app with WINEDEBUG=+all, it appears to enter some > type of deadlock state before I can even get to the point where the bug > normally happens. This hang is probably due to poor timing management in > the app and may indeed be another expression of the same core problem. > > Speaking of the wine task manager, where is that? (or which executable is > it)? Its taskmgr in the source tree as wine/programs/taskmgr. You might try doing something like +relay,+seh,+tid for your channels to isolate the problem down. I might be able to help you isolate the problem but I doubt I can fix it for you even if we are able to find it but that's at least a start. What software are you trying to get to work? Can you describe the exact nature of the problem? Sorry I must confess I've not been following the thread very closely. -- 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

2 1

Adding broken() information to the test output
by Paul Vriens 13 May '09

13 May '09

Hi, While going over some just committed patches of mine I saw (again) that we now have some tests that do: ok(ret || broken(!ret), "call failed") The good thing is that tests succeed on all Windows versions and will fail if Wine returns !ret. The bad thing is that changes in the Windows implementation won't be catched. If MS decides to change the return value (in current or newer versions) we won't see this. Is adding broken() information to the test output helpful? So, if a test succeeds due to the broken() it will put out a message like: <file.c>:<line> Test marked broken() succeeded: call failed. I'm only proposing to have this in the output, not visible on test.winehq.org (for now?). Thoughts anybody? -- Cheers, Paul.

1 0

Re: dplayx: Enclose NS_GetOtherMagic() in #if 0 since it's only used from code enclosed in #if 0.
by Kai Blin 13 May '09

13 May '09

On Wednesday 13 May 2009 10:38:08 Francois Gouget wrote: Personally I think we should just kill all that unused code and be done with it. Currently the only way to get a working dplay implementation is to use the native dlls anyway. Our version has been bit-rotting for quite some time. Cheers, Kai > 1) Remove this dead code altogether... > 2) Replace the #if 0 with an if (0) so that the function is 'used' > 3) Fix the code so it has neither #if 0 nor if (0) (which might be the > same as option 1, I have no idea) > > > dlls/dplayx/name_server.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/dplayx/name_server.c b/dlls/dplayx/name_server.c > index e6a6b62..a503270 100644 > --- a/dlls/dplayx/name_server.c > +++ b/dlls/dplayx/name_server.c > @@ -183,6 +183,7 @@ DWORD NS_GetNsMagic( LPVOID lpNSInfo ) > return lpHdrInfo[1]; > } > > +#if 0 > /* Get the magic number associated with the non NS end */ > DWORD NS_GetOtherMagic( LPVOID lpNSInfo ) > { > @@ -190,6 +191,7 @@ DWORD NS_GetOtherMagic( LPVOID lpNSInfo ) > > return ((LPDWORD)lpCache->lpLocalAddrHdr)[1]; > } > +#endif > > void NS_SetLocalAddr( LPVOID lpNSInfo, LPCVOID lpHdr, DWORD dwHdrSize ) > { -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

2 1

Re: [1/2] wininet: Implement GetDiskInfoA.
by Alexandre Julliard 13 May '09

13 May '09

Hans Leidekker <hans(a)codeweavers.com> writes: > + if ((ret = GetDiskFreeSpaceA(path, &cluster_sectors, &sector_bytes, &free_clusters, &total_clusters))) > + { > + if (cluster_size) *cluster_size = 1; > + if (free) *free = free_clusters * cluster_sectors * sector_bytes; > + if (total) *total = total_clusters * cluster_sectors * sector_bytes; > + } You should use GetDiskFreeSpaceExA to avoid trouble on large disks. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: C_ASSERT portability fixes and simplification [PATCH 1/2]
by Alexandre Julliard 13 May '09

13 May '09

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > This patch moves these into main() in main.c, which has several > advantages: > > 1. The asserts are only evaluated once, not for every #inclusion > of request.h, which simplifies/speeds up the compilation. It doesn't make any difference, that stuff is inside a #ifdef. Also it's auto-generated, so moving it manually won't help. > 2. More importantly, these were the only occurences of C_ASSERT at > file level. By moving these at function level use thereof becomes > consistent which will allow the fix from PATCH 2/2 to work at all. C_ASSERT is supposed to work at the file level too. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [1/3] WineD3D: Separate Tx tempregs from Tx varyings in ARB
by Henri Verbeet 13 May '09

13 May '09

2009/5/12 Stefan Dösinger <stefan(a)codeweavers.com>: > ps_1_3 uses Tx to pass in texture coordinates, but also as temporary > registers. ps_1_4 and ps_2_0 only use them for texture coordinates. This patch > gets rid of the Tx = fragment.texcoord[x] assign in all shader versions, and > doesn't even declare Tx in ps_1_4 and ps_2_0. > > The <=ps_1_3 instructions know which kind of input they expect from the Tx > register, so the instruction handlers now know if they have to read the > tempreg Tx or the varying fragment.texcoord[x] I'm probably missing something obvious, but with pre-1.4 texcoord registers being read-write, what happens when you write to the register before using it to sample a texture? > I've put it in the backend and not the frontend because a hypothetical nvts > shader backend would be confused by this. > Completely off-topic of course, but isn't it somewhat questionable to anthropomorphize source code?

2 2

wined3d: Fix ATI dx10 cards max varying quirk
by Robert Key 12 May '09

12 May '09

I fiddled around with the test and I was able to use varying vec4 var_in[13] as a max in one array. 14 - 16 resulted in a segmentation fault and 17 resulted in glLinK failure error. I was able to create a second array of varying vec4 testa[3] though and it compiled successfully resulting in 64 varyings. I'll attach what I did.

2 1