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

Unused functions in fusion.dll
by Francois Gouget May 14, 2009

May 14, 2009

The following fusion.dll functions are unused: nobody calls them and they are not exported. CompareAssemblyIdentity() GetAssemblyIdentityFromFile() I checked a Windows fusion.dll I have here and I did not see them being exported there either. Yet, the MSDN documents them and presumably there's a way a application can call them... Does anyone know what's up? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner

4 5

Re: Unused functions in fusion.dll
by Paul Vriens May 14, 2009

May 14, 2009

Luke Benstead wrote: > 2009/5/14 Paul Vriens <paul.vriens.wine(a)gmail.com>: >> Paul Vriens wrote: >>> Francois Gouget wrote: >>>> The following fusion.dll functions are unused: nobody calls them and they >>>> are not exported. >>>> >>>> CompareAssemblyIdentity() >>>> GetAssemblyIdentityFromFile() >>>> >>>> I checked a Windows fusion.dll I have here and I did not see them being >>>> exported there either. Yet, the MSDN documents them and presumably there's a >>>> way a application can call them... >>>> >>>> Does anyone know what's up? >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>> What version of the .NET framework do you have? It looks like these came >>> with 2.0 >>> >> Forget that remark. Just checked both fusion and mscoree on .NET 1.1 and 3.5 >> and neither have these exports. >> >> So, no clue ;) >> >> -- >> Cheers, >> >> Paul. >> >> >> > > Just a pure guess, but Googling for CompareAssemblyIdentity returns > this: http://forums.iis.net/t/1149942.aspx which shows: > > mscorwks!CompareAssemblyIdentity+b04a > > Is it possible that the actual exported CompareAssemblyIdentity (and > the one documented on MSDN) should be in mscorwks.dll and NOT in > fusion.dll? > > Just thinking aloud. > > Luke. Spot on: (Vista with .NET3.5SP1): winedump -v -j export mscorwks.dll | grep -e CompareAssemblyIdentity -e GetAssemblyIdentityFromFile 002FF322 48 CompareAssemblyIdentity 00300A41 69 GetAssemblyIdentityFromFile (W2K3 with .NET1.1): not present (W2K3 with .NET2.0): 000F3C2F 47 CompareAssemblyIdentity 002DE14F 68 GetAssemblyIdentityFromFile (W2K3 / .NET 2.0SP1/3.0/3.0SP1/3.5): 0013A67D 47 CompareAssemblyIdentity 003277D3 68 GetAssemblyIdentityFromFile (W2K3 with .NET 3.5SP1): 002FF132 48 CompareAssemblyIdentity 00300851 69 GetAssemblyIdentityFromFile -- Cheers, Paul.

2 1

Re: Fix ATI HD4800 being reported as ATI 9500
by Roderick Colenbrander May 14, 2009

May 14, 2009

I would recommend to add a new if-statement for hd48xx cards (detect the 4830, 4850, 4870, 4890) and set those cards to the pci id of the 4830 and set the video memory to let say 512MB for now. Roderick On Thu, May 14, 2009 at 7:08 AM, Robert Key <hpestilence(a)gmail.com> wrote: > Changelog: > * Add HD4800 series to be detected in graphics card table. > This makes it so that the ati dx9 quirks aren't applied. > > Also added the pci id of HD4850 to wined3d_gl.h > > > >

1 0

Re: wined3d: Updated NVIDIA mobile GT GPUs
by Roderick Colenbrander May 14, 2009

May 14, 2009

Hi, In order to not let the card database become too long I group a lot of boards together. That should be doable for the 96xx / 97xx / 98xx boards you added below and then I use the lowest number of video memory (512MB). This should be fine for apps as they only need a reasonable estimate of the card. Further we can't use all video memory anyway. In the near future I plan to add a better mechanism which will detect the actual card using nv-control. Roderick 2009/5/13 Łukasz Wojniłowicz <lukasz.wojnilowicz(a)gmail.com>: > --- > dlls/wined3d/directx.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > dlls/wined3d/wined3d_gl.h | 7 +++++++ > 2 files changed, 49 insertions(+), 0 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index f5d4d3e..989ab7f 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -1112,11 +1112,46 @@ static BOOL IWineD3DImpl_FillGLCaps(WineD3D_GL_Info *gl_info) { > gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800GT; > vidmem = 512; > } > + /* Geforce9800M GTX - highend */ > + else if(strstr(gl_info->gl_renderer, "9800M GTX")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800MGTX; > + vidmem = 1024; /* The 9800M GTX has 1024MB */ > + } > + /* Geforce9800M GTS - highend */ > + else if(strstr(gl_info->gl_renderer, "9800M GTS")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800MGTS; > + vidmem = 1024; /* The 9800M GTS has 1024MB */ > + } > + /* Geforce9800M GT - highend */ > + else if(strstr(gl_info->gl_renderer, "9800M GT")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800MGT; > + vidmem = 512; /* The 9800M GT has 512MB */ > + } > /* Geforce9 - midend */ > else if(strstr(gl_info->gl_renderer, "9600")) { > gl_info->gl_card = CARD_NVIDIA_GEFORCE_9600GT; > vidmem = 384; /* The 9600GSO has 384MB, the 9600GT has 512-1024MB */ > } > + /* Geforce9700M GTS - midend */ > + else if(strstr(gl_info->gl_renderer, "9700M GTS")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9700MGTS; > + vidmem = 512; /* The 9700M GTS has 512MB */ > + } > + /* Geforce9700M GT - midend */ > + else if(strstr(gl_info->gl_renderer, "9700M GT")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9700MGT; > + vidmem = 512; /* The 9700M GT has 512MB */ > + } > + /* Geforce9650M GT - midend */ > + else if(strstr(gl_info->gl_renderer, "9650M GT")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9650MGT; > + vidmem = 512; /* The 9650M GT has 512-1024MB */ > + } > + /* Geforce9600M GT - midend */ > + else if(strstr(gl_info->gl_renderer, "9600M GT")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9600MGT; > + vidmem = 512; /* The 9600M GT has 512-1024MB */ > + } > /* Geforce9 - midend low / Geforce 200 - low*/ > else if(strstr(gl_info->gl_renderer, "9500") || > strstr(gl_info->gl_renderer, "GT 120") || > @@ -3991,7 +4026,14 @@ static const struct driver_version_information driver_version_table[] = { > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9400GT, "NVIDIA GeForce 9400 GT", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9500GT, "NVIDIA GeForce 9500 GT", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9600GT, "NVIDIA GeForce 9600 GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9600MGT, "NVIDIA GeForce 9600M GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9650MGT, "NVIDIA GeForce 9650M GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9700MGT, "NVIDIA GeForce 9700M GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9700MGTS, "NVIDIA GeForce 9700M GTS", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800GT, "NVIDIA GeForce 9800 GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800MGT, "NVIDIA GeForce 9800M GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800MGTS, "NVIDIA GeForce 9800M GTS", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800MGTX, "NVIDIA GeForce 9800M GTX", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_GTX260, "NVIDIA GeForce GTX 260", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_GTX275, "NVIDIA GeForce GTX 275", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_GTX280, "NVIDIA GeForce GTX 280", 7, 15, 11, 8044 }, > diff --git a/dlls/wined3d/wined3d_gl.h b/dlls/wined3d/wined3d_gl.h > index 1a9c925..4f3542d 100644 > --- a/dlls/wined3d/wined3d_gl.h > +++ b/dlls/wined3d/wined3d_gl.h > @@ -3330,7 +3330,14 @@ typedef enum _GL_Cards { > CARD_NVIDIA_GEFORCE_9400GT = 0x042c, > CARD_NVIDIA_GEFORCE_9500GT = 0x0640, > CARD_NVIDIA_GEFORCE_9600GT = 0x0622, > + CARD_NVIDIA_GEFORCE_9600MGT = 0x0649, > + CARD_NVIDIA_GEFORCE_9650MGT = 0x064C, > + CARD_NVIDIA_GEFORCE_9700MGT = 0x064A, > + CARD_NVIDIA_GEFORCE_9700MGTS = 0x062A, > CARD_NVIDIA_GEFORCE_9800GT = 0x0614, > + CARD_NVIDIA_GEFORCE_9800MGT = 0x060B, > + CARD_NVIDIA_GEFORCE_9800MGTS = 0x0628, > + CARD_NVIDIA_GEFORCE_9800MGTX = 0x0608, > CARD_NVIDIA_GEFORCE_GTX260 = 0x05e2, > CARD_NVIDIA_GEFORCE_GTX275 = 0x05e6, > CARD_NVIDIA_GEFORCE_GTX280 = 0x05e1, > -- > 1.6.0.6 > > > >

1 0

Re: winhlp32: Avoid duplicate assignment in WINHELP_GetWindowInfo().
by John Klehm May 14, 2009

May 14, 2009

On Wed, May 13, 2009 at 4:18 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > Most straightforward, I hope. :-) > > Gerald > > ChangeLog: > Avoid duplicate assignment in WINHELP_GetWindowInfo(). > > diff --git a/programs/winhlp32/winhelp.c b/programs/winhlp32/winhelp.c > index 7f74d8b..d1980e5 100644 > --- a/programs/winhlp32/winhelp.c > +++ b/programs/winhlp32/winhelp.c > @@ -278,7 +278,7 @@ HLPFILE_WINDOWINFO* WINHELP_GetWindowInfo(HLPFILE* hlpfile, LPCSTR name) > mwi.origin.x = mwi.origin.y = mwi.size.cx = mwi.size.cy = CW_USEDEFAULT; > mwi.style = SW_SHOW; > mwi.win_style = WS_OVERLAPPEDWINDOW; > - mwi.sr_color = mwi.sr_color = 0xFFFFFF; > + mwi.sr_color = 0xFFFFFF; > } > return &mwi; > } > Maybe one of was intended to be nsr_color?

1 0

Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)
by Daniel Santos May 13, 2009

May 13, 2009

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 May 13, 2009

May 13, 2009

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 May 13, 2009

May 13, 2009

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 May 13, 2009

May 13, 2009

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 May 13, 2009

May 13, 2009

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 May 13, 2009

May 13, 2009

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 May 13, 2009

May 13, 2009

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 May 13, 2009

May 13, 2009

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 May 13, 2009

May 13, 2009

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 May 12, 2009

May 12, 2009

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

Re: Question on writing a testcase..
by chris ahrendt May 12, 2009

May 12, 2009

Paul Vriens wrote: > chris ahrendt wrote: >> I have two test cases for the file.c test in kernel32 to show two >> problems I have found and reported as bugs that wine should be able >> to handle. >> >> first problem : >> >> I/O warning : failed to load external entity >> "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" >> >> Wine does not seem to be parsing this correctly while the various >> windows platforms do correctly. >> So I would like to put a test for this in the test case. >> >> Second file issue I found that needs a test case : >> >> I/O warning : failed to load external entity "EQ/updatestatus.xml" >> >> It seems wine is expecting a fully qualified path in this case where >> as windows uses the application running directory and then looks >> there... >> I am not even sure where this is looking in wine. I would guess at >> the root level from the z: mapping if I had to venture a guess >> instead of the current running directory. >> >> Would I just write the two subroutines and then submit them to >> wine-patch? >> >> Chris >> >> > What function(s) are the tests for? Did you already write some > testcases and run them on Windows? > > -- Cheers, > > Paul. > > They are for the open file api let me find the exact API.. filehandle = _lopen( filename, OF_READ ); in the dlls/kernel32/tests/file.c I also would write the test for _lcreate and the other couple of API's that return a file handle. And I am using an application on windows already that does the open in this manner... but could hack something out really quick. Chris

1 0

Question on writing a testcase..
by chris ahrendt May 12, 2009

May 12, 2009

I have two test cases for the file.c test in kernel32 to show two problems I have found and reported as bugs that wine should be able to handle. first problem : I/O warning : failed to load external entity "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" Wine does not seem to be parsing this correctly while the various windows platforms do correctly. So I would like to put a test for this in the test case. Second file issue I found that needs a test case : I/O warning : failed to load external entity "EQ/updatestatus.xml" It seems wine is expecting a fully qualified path in this case where as windows uses the application running directory and then looks there... I am not even sure where this is looking in wine. I would guess at the root level from the z: mapping if I had to venture a guess instead of the current running directory. Would I just write the two subroutines and then submit them to wine-patch? Chris

2 1

Re: [2/2] kernel32: Fix GetVolumeNameForVolumeMountPointW to match Mountmgr
by Vitaliy Margolen May 12, 2009

May 12, 2009

Few nitpicks about your patch. Guy Albertelli wrote: > + if (!(input = HeapAlloc( GetProcessHeap(), 0, i_size ))) > + { > + SetLastError( ERROR_NOT_ENOUGH_MEMORY ); > + goto err_ret; > + } > + memset( input, 0, i_size ); To zero out allocated memory you should use HEAP_ZERO_MEMORY allocation flag: input = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, i_size ); However there is no need to do any of that - do not just clear memory without a good reason. It takes time to do it, especially that you doing it several times. What you do need to do in your code is explicitly zero-terminate all strings you receive from mount manager after you copy them. > + p = (WCHAR *) input; This is wrong - types of "p" and "input" has nothing to do with each other. > + p = (WCHAR*)((char *)input + sizeof(MOUNTMGR_MOUNT_POINT)); > + input->DeviceNameOffset = (char *)p - (char *)input; > + memcpy( p, nonpersist_name, lstrlenW( nonpersist_name )*sizeof(WCHAR) ); > + input->DeviceNameLength = lstrlenW( nonpersist_name )*sizeof(WCHAR); This is ugly. You can write it like this: input->DeviceNameOffset = sizeof(*input); input->DeviceNameLength = lstrlenW( nonpersist_name ) * sizeof(WCHAR) memcpy( input + 1, nonpersist_name, input->DeviceNameLength ); > + /* is there space in the return variable ?? */ > + if ((o1->SymbolicLinkNameLength/sizeof(WCHAR))+2 > size) > + { > + SetLastError( ERROR_INVALID_PARAMETER ); > + goto err_ret; > + } This doesn't look right. There are several other error codes that more appropriate. You should expand your tests to check what native returns here. Also are you sure that "size" is in chars not bytes? > + /* make string null terminated */ > + p = (WCHAR*)((char*)volume + o1->SymbolicLinkNameLength); > + memset( p, 0, sizeof(WCHAR) ); Again ugly. You can write it like: volume[o1->SymbolicLinkNameLength / sizeof(WCHAR)] = 0; > + if (input) HeapFree( GetProcessHeap(), 0, input ); > + if (output) HeapFree( GetProcessHeap(), 0, output ); You do not need to check for pointer != NULL before freeing it. All free() functions already doing it. Vitaliy.

2 1

DIB Engine : Almost 100% working
by Massimo Del Fedele May 11, 2009

May 11, 2009

Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost 100% operational. On one of tested apps (MSN Messenger) it behaves even better than original one :-) For whom wish to test it, bug 421 page. Ciao Max

12 29

Re: comctl32/listview: WinSCP dogfood fix
by Nikolay Sivov May 11, 2009

May 11, 2009

Stefan Stranz wrote: > Fixes bug #13867 > Original fix by GameZelda A test needed for such changes. Especially for that part: @@ -519,7 +519,7 @@ static inline int textcmpWT(LPCWSTR aw, LPCWSTR bt, BOOL isW) if (!aw) return bt ? -1 : 0; if (!bt) return aw ? 1 : 0; if (aw == LPSTR_TEXTCALLBACKW) - return bt == LPSTR_TEXTCALLBACKW ? 0 : -1; + return bt == LPSTR_TEXTCALLBACKW ? 1 : -1; if (bt != LPSTR_TEXTCALLBACKW) { LPWSTR bw = textdupTtoW(bt, isW);

1 0

Impossible to register to Bugzilla
by Alain Aupeix May 11, 2009

May 11, 2009

2 2

Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState with tests(try5)
by Nikolay Sivov May 11, 2009

May 11, 2009

André Hentschel wrote: > now PSDK compatible > --- > dlls/comctl32/listview.c | 1 - > dlls/comctl32/tests/listview.c | 8 ++++++++ > include/commctrl.h | 6 ++++++ > 3 files changed, 14 insertions(+), 1 deletions(-) Still wrong: +#define ListView_SetCheckState(hwndLV, i, bCheck) \ + { LVITEMA _LVi; _LVi.state = ((bCheck?2:1) << 12); _LVi.stateMask = LVIS_STATEIMAGEMASK;\ + SNDMSG(hwndLV, LVM_SETITEMSTATE, (WPARAM)(UINT)(i), (LPARAM)(LPLVITEMA)&_LVi);} 'A' structure for both SNDMSG[A,W]. Try with neutral LVITEM. +#define ListView_GetCheckState(hwndLV, i) \ + ((((BOOL)(SNDMSGW((hwndLV), LVM_GETITEMSTATE, (i), \ + LVIS_STATEIMAGEMASK))) >> 12) -1) Always W version used. Why?

2 1

Re: DIB Engine : Almost 100% working
by Reece Dunn May 11, 2009

May 11, 2009

Jeremy White wrote: > Reece Dunn wrote: >> Also, doesn't CodeWeavers have the ability to pledge for features >> (such as DirectX) as well as specific applications? > > Well, kinda sorta, but not really. It's on our todo list and has > been for a long time. > > I think Roderick summarized the issue from our perspective correctly. > Everyone wishes it will be a magic bullet, so we all get excited about it. >From Massimo's report, his DIB engine looks like it fixes a few issues on some games - like Age of Empires 2 - and has some speedups there. Not sure how much of a benefit this is going to be overall. > But in practice, it helps very few applications. Improving gdiplus > (an easier task), we have found to have far more dramatic benefits. I understand this approach. The DIB engine is not a trivial, or isolated piece of functionality, to develop. There are some things I'd be interested in seeing: 1. how this affects double-buffering performance (which a lot of applications make use of, as well as the common controls), which uses DIBs to draw the data off-screen; 2. how this affects theme performance (the repainting of winecfg with the Gem theme is glacially slow); 3. whether this will support alpha blending (useful for themes that support it - such as is likely to be used to provide better integration look and feel - as well as the Wine icon refresh that was being looked at). I wonder if there are any media players or video editing applications that would benefit? Anyway, I'll hopefully get around to do some testing on the DIB engine at some point to test these out. - Reece

1 0

Re: Severity levels
by Nicklas Börjesson May 11, 2009

May 11, 2009

>How many times does this have to be repeated? Severity levels are NOT >determined by how much a user wants the app to work. They're just not, >deal with it. I have never said it is, either. I said it think it should be determined by how severe the user thinks it is(if devs then cares about it is another matter). You seem to be convinced that all users are morons hyping their own stuff. >>>If a set of devs decide to work on getting a particular app working >>>that's up to them, and we've already been over this too. >> Obviously. I can't remember opposing that? >Who said you had? Why writing that we've had already been over it, then?!?? .....etc.... "you can't see the picture" .....etc.... "Not to you, no. Only what you think is right." .....etc.... Huh? This doesn't lead anywhere, you constantly misread me and I don't seem to understand what you are getting at. For some reason, I seem to annoy the hell out if you. I really don't get it, it is not my intention. Do I have some kind of attitude I need to be aware of? I am not a native English speaker. Anyway, it has been obvious from the start that you and I can't communicate. Therefore, I am backing out(hands in air) of this discussion before...uh.. after it has gotten out of hand. //Nicklas

9 24

Winelib - Getting Started guide
by Josef Šimánek May 11, 2009

May 11, 2009

Hi ! I was reading Winelib GSG and I tried to compile notepad from Wine sources. So I downloaded Wine sources (version 1.1.21) and I installed wine from Wine Ubuntu repository (version 1.1.21). I edit Makefile and type make into console. My problem above. In the guide is written to report bad compiling behaviour. So I did it. Any hints ? mirindoslav(a)mirindoslav-laptop:~/Plocha/notepad$ make winegcc -c -mno-cygwin -I. -o dialog.o dialog.c winegcc -c -mno-cygwin -I. -o main.o main.c wrc -I. -forsrc.res rsrc.rc winegcc -mwindows -mno-cygwin -m32 -o notepad.exe.so dialog.o main.o rsrc.res -lodbc32 -lole32 -loleaut32 -lwinspool -lodbccp32 -luuid dialog.o: In function `DIALOG_StringMsgBox': dialog.c:(.text+0x235): undefined reference to `wnsprintfW' main.o: In function `HandleCommandLine': main.c:(.text+0x25a5): undefined reference to `PathFindFileNameW' collect2: ld returned 1 exit status winegcc: i486-linux-gnu-gcc failed make: *** [notepad.exe.so] Error 2

2 2