November 2007 - Wine-Devel - list.winehq.org

Wrong comparison in ntdll/actctx.c

by nlataill

Hi, Working on a D3D game, I have found that wine is refusing to load the following manifest file (when Windows does not fail). <?xml version="1.0" encoding="UTF-8" standalone="yes"?>  <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <noInheritable/> <assemblyIdentity type="win32" name="Microsoft.VC80.OpenMP" version=" 8.0.50727.42" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/> <file name="vcomp.dll" hash="0d009725bd5653af143fdfd9d8abf8adad533d16" hashalg="SHA1"/> </assembly> Adding verbosity to actctx.c, it seems that this game is requesting version 8.0.50608.0, which does match major.minor, but not the whole version number (*major.minor.build.revision)*. trace:actctx:parse_assembly_identity_elem name=L"Microsoft.VC80.OpenMP" version=8.0.50727.42 arch=L"x86" fixme:actctx:parse_assembly_elem VERBOSE: wrong version FOUND: 8/0/50727/42 fixme:actctx:parse_assembly_elem VERBOSE: wrong version EXP: 8/0/50608/0 fixme:actctx:parse_manifest_buffer failed to parse manifest L"C:\\Program Files\\Microsoft.VC80.OpenMP.manifest" fixme:actctx:parse_depend_manifests Could not find dependent assembly L" Microsoft.VC80.OpenMP" According to MSDN, it seems only major.minor is considered for version matching: - http://msdn2.microsoft.com/en-us/library/aa374234.aspx : A version number that changes only in the *build* or *revision* parts indicates that the assembly is backward compatible with prior versions. - http://msdn2.microsoft.com/en-us/library/aa375365.aspx: [...] are manifests used to redirect the version of a side-by-side assembly to another compatible version. The version that the assembly is being redirected to should have the same major.minor values as the original version. I am proposing the following one-liner to ntdll/actctx.c: isa(a)isa:~/downloads/tmp$ diff -u wine-0.9.49/dlls/ntdll/actctx.c /home/isa/downloads/wine-0.9.49/dlls/ntdll/actctx.c --- wine-0.9.49/dlls/ntdll/actctx.c 2007-11-09 17:56:12.000000000 +0100 +++ /home/isa/downloads/wine-0.9.49/dlls/ntdll/actctx.c 2007-11-19 21:07: 35.000000000 +0100 @@ -1390,8 +1390,8 @@ if (expected_ai) { /* FIXME: more tests */ - if (assembly->type == ASSEMBLY_MANIFEST && - memcmp(&assembly->id.version, &expected_ai->version, sizeof(assembly->id.version))) + if (assembly->type == ASSEMBLY_MANIFEST && + ((assembly->id.version.major != expected_ai->version.major) || (assembly->id.version.minor != expected_ai->version.minor)) ) { FIXME("wrong version\n"); return FALSE; With this patch, the manifest (and related DLL) is loading correctly. This does not prevent my game die shortly after, in D3D code this time. Still work to do ;-) Thanks, Norbert Lataille

Nov. 19, 2007

Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW

by Hans Leidekker

On Monday 19 November 2007 20:59:46 devzero(a)web.de wrote: > when scannnig trough drive z:\ , my notebook reboots ! > wasn`t wine a userspace application with no kernel related stuff ? > so it`s weird, that windirstat is crashing my notebook, isn`t it ? Yes, Wine shouldn't be able to do that. You're not running Wine as root are you? Does your system log reveal anything about the crash? -Hans

Nov. 19, 2007

Re: d3dx8 [patch 1/10] Implement D3DXPlaneFromPointNormal

by Vijay Kiran Kamuju

On 11/19/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > > It's not really about this patch, but I am curious what the plans about > sharing code between the various d3dx?_* libraries are. I think a big amount > of functionality can be shared among d3dx8.dll, d3dx9_*.dll, and propably > d3dxof.dll and d3drm.dll. > > I think this was discussed in the past, but I am not sure if there was any > outcome. The solution chosen for d3d was to create an internal library > wined3d.dll, and have the other libs call it. I guess something similar > should be done for d3dx as well. > > For non COM interfaces this is pretty easy anyway. We can rename d3dx8 to > wined3dx at any time and just load the functions into a new d3d8 thunk using > the .spec file, without any C code. So I guess we can leave things as they > currently are and move over to a shared lib once non-math functions are > implemented, or someone starts d3dx9_*.dll > > Functions like D3DXCreateTextureFromFileA seem to be a bit harder. Since > they > take an IDirect3DDevice8 * interface pointer d3dx9 cannot use them as is. > Making a shared implementation is also not quite possible because it would > need a wined3ddevice then, but only d3d8.dll knows how to get a > wined3ddevice > from a d3ddevice8. Also, d3dx* would depend on wined3d then, which is > propably not what we want. > > David, do you have any plans regarding that? > > As a sidenote, I really like your patches! The patches are small but still > every patch makes sense for itself, and tests in every patch :-) > > I will write a HLSL compiler at some point, and propably a shader assembler. > This will be needed for a complete d3dx8 and d3dx9 implementation, as well > as > d3d10. I am not yet sure where to put it, but it could be a standalone lib > in > libs/, to allow using the compiler at build time, or just include it in > wined3dx, if we decide to add such a library. > Why not having the functionality of d3dx in wined3d, instead of having a separate d3dx library called wined3dx? I like the having all the common functionality of d3drm,d3dx8, d3dx9_* and d3dxof dlls at one place and for all the version dependent stuff, we keep it the respective dlls. -- VJ

Nov. 19, 2007

Re: d3dx8 [patch 1/10] Implement D3DXPlaneFromPointNormal

by Stefan Dösinger

Hi, It's not really about this patch, but I am curious what the plans about sharing code between the various d3dx?_* libraries are. I think a big amount of functionality can be shared among d3dx8.dll, d3dx9_*.dll, and propably d3dxof.dll and d3drm.dll. I think this was discussed in the past, but I am not sure if there was any outcome. The solution chosen for d3d was to create an internal library wined3d.dll, and have the other libs call it. I guess something similar should be done for d3dx as well. For non COM interfaces this is pretty easy anyway. We can rename d3dx8 to wined3dx at any time and just load the functions into a new d3d8 thunk using the .spec file, without any C code. So I guess we can leave things as they currently are and move over to a shared lib once non-math functions are implemented, or someone starts d3dx9_*.dll Functions like D3DXCreateTextureFromFileA seem to be a bit harder. Since they take an IDirect3DDevice8 * interface pointer d3dx9 cannot use them as is. Making a shared implementation is also not quite possible because it would need a wined3ddevice then, but only d3d8.dll knows how to get a wined3ddevice from a d3ddevice8. Also, d3dx* would depend on wined3d then, which is propably not what we want. David, do you have any plans regarding that? As a sidenote, I really like your patches! The patches are small but still every patch makes sense for itself, and tests in every patch :-) I will write a HLSL compiler at some point, and propably a shader assembler. This will be needed for a complete d3dx8 and d3dx9 implementation, as well as d3d10. I am not yet sure where to put it, but it could be a standalone lib in libs/, to allow using the compiler at build time, or just include it in wined3dx, if we decide to add such a library.

Nov. 19, 2007

Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW

by devzero＠web.de

Hello Marcus, hello Hans, thanks very much - that was a quick fix ! :) I tried the latest snapshot and now was going able start windirstat. great! i can tell , that it basically works and i`m able to scan a disk. despite some minor quirks like crash of the app when i click trough the cushion treemap, there seems some major issue. at least some very weird major issue: when scannnig trough drive z:\ , my notebook reboots ! This happens reproduceably when windirstat is at ~100.000 entries i had absolutely no stability issues with my notebook so far, running it for some days now and using it very very intensive (much i/o, firefox/open with many many windows containing flash etc) i did an test afterwards to see if this is caused by some corrupt files or whatever, but some find / -type f -exec stat {} \; >/dev/null ls -laR / >/dev/null completes without an error. there are around 200.000 files on my notebook. wasn`t wine a userspace application with no kernel related stuff ? so it`s weird, that windirstat is crashing my notebook, isn`t it ? maybe somebody is able to reproduce ? regards roland > -----Ursprüngliche Nachricht----- > Von: "Marcus Meissner" <marcus(a)jet.franken.de> > Gesendet: 19.11.07 07:48:04 > An: devzero(a)web.de > CC: Hans Leidekker <hans(a)it.vu.nl>, wine-devel(a)winehq.org > Betreff: Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW > > On Sun, Nov 18, 2007 at 10:14:17PM +0100, devzero(a)web.de wrote: > > Hello Hans, > > > > thanks for that info. > > > > latest version i tried here is > > > > wine-0.9.49-11.3.i586.rpm > > wine-snapshot-0.9.49.20071118-11.1.i586.rpm > > > > but same error. > > maybe that`s not recent enough ? > > > > do i need to enable special option or add some files ? > > > > sorry, i`m quite new to wine and maybe i should read deeper into the docs instead of posting :) > > It is not yet committed to the mainline repository. Once it > is it will show up in "wine-snapshot" of the openSUSE buildservice > of this day. > > Ciao, Marcus > _______________________________________________________________________ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220

Nov. 19, 2007

Re: credui: Show a balloon tip in the credential dialog if CREDUI_FLAGS_INCORRECT_PASSWORD was specified.

by Juan Lang

Hi Rob, + IDS_INCORRECTPASSWORDTITLE "Logon unsucessful" The typo's your own work too, eh? --Juan

Nov. 19, 2007

Re: svchost: Added base implementation of svchost (1/27)

by Juan Lang

Hi Roy, > The docs for HeapFree state "If this pointer is NULL, the behavior is > undefined." So in practice the undefined behavior is benign? Yes. There are tests for that, and in fact there's a janitorial project about removing redundant NULL pointer checks before HeapFree. Michael Stefaniuc wrote about it here: http://www.mail-archive.com/wine-devel(a)winehq.org/msg11972.html You'll still see occasional commits along those lines, often from Michael, tagged with "found by Smatch." E.g.: http://www.winehq.org/pipermail/wine-cvs/2007-November/038118.html --Juan

Nov. 19, 2007

Re: svchost: Added base implementation of svchost (1/27)

by Roy Shea

Hello Juan, Thank you for the code review! A quick clarification about HeapFree: > Some judicious use of goto could reduce code for all your error paths. > Remember that HeapFree of a NULL pointer is allowed. The docs for HeapFree state "If this pointer is NULL, the behavior is undefined." So in practice the undefined behavior is benign? Peace, -Roy

Nov. 19, 2007

Re: Removing Windows and Solaris from the Downloads page

by Steven Edwards

On Nov 19, 2007 5:40 AM, Hans Leidekker <hans(a)it.vu.nl> wrote: > I recall Alexandre saying that he wants the exposure to alternative headers > and import libraries because it brings up bugs in Wine. He also suggested > that the wininet/winsock issue could be solved by making wininet build > against either Windows sockets or Unix sockets. I did this so it should still work. I was just pointing to it as an example of how/why things break on the mingw build. -- 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

Nov. 19, 2007

Re: wininet: InternetAttemptConnect() Stub

by Juan Lang

Hi Pavel, On Nov 19, 2007 6:30 AM, Pavel Troller <patrol(a)sinus.cz> wrote: > I have a problem running an offline client for ordering photo prints from > digital cameras. > Even it is an "offline" client, it requires the computer to be online. > It seems that in wine, it feels to be offline, thus refusing further > operation with a dialog saying something like "Internet connection unavailable" > and terminating. The machine is normally connected to the LAN with full net > availability. > The following is its full console log. > > patrol(a)gonio:~/.wine/drive_c/Program Files/droxi/OfflineClient$ wine PhotoOfflineClient.exe > fixme:wininet:InternetGetConnectedState always returning LAN connection. > fixme:win:SetLayeredWindowAttributes (0x10030,0x00000000,255,2): stub! > fixme:win:LockWindowUpdate (0x10028), partial stub! > fixme:win:LockWindowUpdate ((nil)), partial stub! > fixme:shdocvw:OleObject_Close (0x199510)->(1) > fixme:wininet:InternetAttemptConnect Stub I don't think either wininet fixme is telling you anything worthwhile. As you already pointed out, the first one seems okay: a LAN connection is what it most likely expects anyway. The second stub, if you look at the source, returns ERROR_SUCCESS, which is what MSDN says it should return if it succeeds. I think you're going to have to try a +relay log and scanning through it ti figure out why it thinks it's offline. --Juan

Nov. 19, 2007