September 2007 - Wine-Devel

Re: [4/5] WGL: Remove GL scissors/viewport override

by Vitaliy Margolen

Chris Robinson wrote: > > ------------------------------------------------------------------------ > This patch causes crash with virtual desktop. Crash attached. Vitaliy.

Sept. 23, 2007

Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering

by Chris Robinson

On Sunday 23 September 2007 02:22:35 pm you wrote: > Chris Robinson wrote: > > This uses XComposite, when available, to render GL to an offscreen > > window, and updates the win32 window when glFlush/glFinish/SwapBuffers is > > called. When rendering to a top-level window with a matching visual, it > > renders directly "onscreen", and setting the registry key > > HKCU\Software\Wine\X11 Driver\CompositeGL > > to false will disable GL compositing behavior even when XComposite is > > available (default is enabled). > > Same here, default should be disabled. Do not introduce more regressions in > something already broken by default. And don't punish something that works > perfectly without anything extra. I don't think it's necessary since the only apps this patch affects are ones that are currently broken due to the child window rendering bug. Apps that draw to a top-level window continue to do so, and aren't composited.

Sept. 23, 2007

Re: [1/5] winex11: Load the XComposite extension when available

by Chris Robinson

On Sunday 23 September 2007 02:20:06 pm you wrote: > It should be off by default until users will have enough time to test if > it's working properly. > > Vitaliy. This patch itself does nothing but load the XComposite lib and its functions. It's up to the subsystems themselves to do with it what they will (hence why there's the GL-specific compositing option).

Sept. 23, 2007

Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering

by Vitaliy Margolen

Chris Robinson wrote: > This uses XComposite, when available, to render GL to an offscreen window, and > updates the win32 window when glFlush/glFinish/SwapBuffers is called. When > rendering to a top-level window with a matching visual, it renders > directly "onscreen", and setting the registry key > HKCU\Software\Wine\X11 Driver\CompositeGL > to false will disable GL compositing behavior even when XComposite is > available (default is enabled). > > Same here, default should be disabled. Do not introduce more regressions in something already broken by default. And don't punish something that works perfectly without anything extra. Vitaliy.

Sept. 23, 2007

Re: [1/5] winex11: Load the XComposite extension when available

by Vitaliy Margolen

Chris Robinson wrote: > A set of patches to replace the scissors hack with offscreen rendering and > compositing. Step one, look for and load the XComposite extension libs. > > ------------------------------------------------------------------------ > > +int usexcomposite = 1; It should be off by default until users will have enough time to test if it's working properly. Vitaliy.

Sept. 23, 2007

Re: shdocvw: Added WebBrowser::FullScreen property implementation.

by Reece Dunn

On 23/09/2007, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > dlls/shdocvw/shdocvw.h | 1 + > dlls/shdocvw/tests/webbrowser.c | 23 +++++++++++++++++++++++ > dlls/shdocvw/webbrowser.c | 15 +++++++++++---- > 3 files changed, 35 insertions(+), 4 deletions(-) > + hres = IWebBrowser2_get_FullScreen(wb, &b); > + ok(hres == S_OK, "get_FullScreen failed: %08x\n", hres); > + ok(b == VARIANT_TRUE, "b=%x\n", b); > + > + hres = IWebBrowser2_put_FullScreen(wb, VARIANT_FALSE); > + ok(hres == S_OK, "put_FullScreen failed: %08x\n", hres); > + > IWebBrowser2_Release(wb); This last call to put_FullScreen is missing a get_FullScreen check. Everything else looks ok. - Reece

Sept. 23, 2007

Re: [2/5] WineD3D: Recompile glsl pixelshaders if the sampler format changes

by Vitaliy Margolen

Stefan Dösinger wrote: > > ------------------------------------------------------------------------ > > This patch causes noticeable slowdown in Counter Strike Source stress test in the first part of it (rotating panels). Testing in dxlevel 80, 1024x768 fbo, cl_monitors 0. I'm getting ~33 fps in that area before patch and around 7 fps with this patch. Vitaliy.

Sept. 23, 2007

Re: Would like to contribute to wine

by Detlef Riekenberg

On Mo, 2007-09-10 at 10:06 -0600, Jesse Allen wrote: > What about the Drv* functions? Drv* are implemented by the Driver, while Eng* and Friends are the Graphic Rendering Engine (on windows in win32k.sys). The Exports in GDI are parts of the GRE for Usermode Printer Drivers. > Also, I wonder how your Eng* functions would integrate with the dib > engine I'm writing The main Problem with the Rendering-API in Wine (between GDI and our Drivers: winex11, wineps, mfdrv, enhmfdrv) is more like win3x and far away from DDI (Device Driver Interface). -- By by ... Detlef

Sept. 23, 2007

Re: [OT] Freemail Terms Of Use [was: Wine autorunner]

by Reece Dunn

On 23/09/2007, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Sonntag, 23. September 2007 01:42:46 schrieb Computer Dude: > _________________________________________________________________ > > Connect to the next generation of MSN Messenger > > http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source= > >wlmailtagline > This is OT regarding this patch, but most people use freemailers, including > hotmail / msn. Some service providers tried to establish some > all-your-copyright-belong-to-us terms of service. Should we take care about > that in any way? Either by making sure that patches aren't sent from such > services, or to make sure that such conditions do not hold up in court? > > I am using gmx myself, and I haven't checked the TOS for changes since years, > and I only gave them a 5 secound look when signing up, so I should start with > checking that myself(I send most patches from my CW address though) Reading the current GoogleMail terms of usage, there is this: "Your Intellectual Property Rights. Google does not claim any ownership in any of the content, including any text, data, information, images, photographs, music, sound, video, or other material, that you upload, transmit or store in your Google Mail account. We will not use any of your content for any purpose except to provide you with the Service." so there is no problem there. Also, the hotmail legal statement has this: "8. Your Materials. You may be able to submit materials for use in connection with the service. Except for material that we license to you, we do not claim ownership of the materials you post or otherwise provide to us related to the service (called a "submission"). However, by posting or otherwise providing your submission, you are granting to the public free permission to: * use, copy, distribute, display, publish and modify your submission, each in connection with the service; * publish your name in connection with your submission; and * grant these permissions to other persons. This section only applies to legally permissible content and only to the extent that use and publishing of the legally permissible content does not breach the law. We will not pay you for your submission. We may refuse to publish, and may remove your submission from the service at any time. For every submission you make, you must have all rights necessary for you to grant the permissions in this section." So you should also be fine there as well, although I do find it interesting that according to this (if I have read it correctly), anything that you send via hotmail is freely usable by the public! - Reece

Sept. 23, 2007

Re: Wine autorunner

by leszek

Le dimanche 23 septembre 2007 à 20:01 +0200, Stefan Dösinger a écrit : > Am Sonntag, 23. September 2007 01:42:46 schrieb Computer Dude: > > Attached is the git patch for a utility to perform simple parsing of > > Windows autorun.inf files, and to run the associated programs under WINE. > > It will auto-detect the CD drive if not specified on the command line, > > auto-detect the mount point, and attempt to mount it if it i not already > > mounted. > Shouldn't this be implemented in the gnome / kde autorun support? Perhaps in > the form of registering a new autorun "mimetype" which tells gnome/kde about > autorun.inf files, and how to use them? In fact it is already implemented for gnome and now in the gnome svn. More information here: http://bugzilla.gnome.org/show_bug.cgi?id=453266 Hanusz Leszek

Sept. 23, 2007

Re: Wine autorunner

by Stefan Dösinger

Am Sonntag, 23. September 2007 01:42:46 schrieb Computer Dude: > Attached is the git patch for a utility to perform simple parsing of > Windows autorun.inf files, and to run the associated programs under WINE. > It will auto-detect the CD drive if not specified on the command line, > auto-detect the mount point, and attempt to mount it if it i not already > mounted. Shouldn't this be implemented in the gnome / kde autorun support? Perhaps in the form of registering a new autorun "mimetype" which tells gnome/kde about autorun.inf files, and how to use them? _________________________________________________________________ > Connect to the next generation of MSN Messenger > http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source= >wlmailtagline This is OT regarding this patch, but most people use freemailers, including hotmail / msn. Some service providers tried to establish some all-your-copyright-belong-to-us terms of service. Should we take care about that in any way? Either by making sure that patches aren't sent from such services, or to make sure that such conditions do not hold up in court? I am using gmx myself, and I haven't checked the TOS for changes since years, and I only gave them a 5 secound look when signing up, so I should start with checking that myself(I send most patches from my CW address though)

Sept. 23, 2007

Re: Wine autorunner

by Kai Blin

On Sunday 23 September 2007 01:42:46 Computer Dude wrote: > Attached is the git patch for a utility to perform simple parsing of > Windows autorun.inf files, and to run the associated programs under WINE. You need to provide your real name for your patch to be considered at all. Wine will not accept anonymous patches. Cheers, Kai -- 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.

Sept. 23, 2007

The Spouse Test

by Dan Kegel

When will Wine be good enough for the average person to use? One test is, "Is it good enough to let your spouse migrate to Linux from Windows?". My wife's must-have app list is roughly Microsoft Office '97 Adobe Photoshop Elements 1 Ulead PhotoImpact Macromedia Dreamweaver 8 Musicmatch Jukebox 8 FamilyTreeMaker 2006 And you know what? All of those basically work except for Photoshop Elements. They need some cosmetic work, and a native DLL or two, and probably a few obscure bugfixes, but I think that's it. (I didn't test Office '97, since I expect she'll be using Crossover for that, as Codeweavers tests that app pretty well.) It's possible that by this time next year Wine will pass this test for me. - Dan

Sept. 23, 2007

WM_CHAR of Ctrl-C, Ctrl-V appear to have no effect in WinXP-SP2 riched20 control

by a_villacis＠palosanto.com

I am trying to fix a few tests for riched20 that attempt to recover the text from the control with WM_GETTEXT and assume the text will be recovered unchanged. As demostrated in a patch I sent a few minutes ago, this assumption is not true when the text to recover contains unbalanced \r, which are converted to \r\n. However I have a strange problem. On my setup (WinXP-SP2 with cygwin), sending Ctrl-C and Ctrl-V with WM_CHAR appears to have no effect on the riched20 control used for the tests. Therefore the text buffer is not modified and the end text remains unchanged. I want to check whether this tests fails in the same way for anybody else, and if not, to receive suggestions on what might be wrong with my setup.

Sept. 23, 2007

Re: wine.inf: add some four keys in Active Setup\Installed Components [resend]

by Mikołaj Zalewski

Robert Shearman wrote: > You might want to find four real components always present on Windows to > add to this key. > From the keys present on my system I could add HTML Help, DirectDrawEx and some two versions of .NET Framework but I didn't know if it wouldn't interfere with some setup programs - e.g. they would claim the information is incomplete because the others subkeys of Active Setup are missing. Especially that it seems there is no official documentation of it. On the other hand from what I've found on some forums adding new keys is something what sysadmins sometimes do to run software for all users so it should be safe. But if it's better to add real keys I can change the patch. Mikolaj Zalewski

Sept. 23, 2007

Fwd: CryptAcquireContext Failure, default/Type 024 requested

by Rob Seger

Never fails, ask a question and you'll find the answer with your next google.. I found the wincrypt.h #define line that says what type 024 is: #define PROV_RSA_AES 24. Sorry for not having that information before the first e-mail. Rob ---------- Forwarded message ---------- From: Rob Seger <rob.seger(a)gmail.com> Date: Sep 23, 2007 4:52 AM Subject: CryptAcquireContext Failure, default/Type 024 requested To: wine-devel(a)winehq.org Wine currently supports types 001 and 012, but I have a new game attempting to use type 024 (Software\\Microsoft\\Cryptography\\Defaults \\Provider Types\\Type 024). I've googled, as well as searched MSDN, for a reference as to what the crypt provider type 024 even is with no success. Does anyone know? Looking through the advapi32.dll code, this looks like it might be a serious undertaking to implement. Is that estimation accurate? Does anyone have any tips or pointers about implementing an entire CSP in wine? I appreciate any help, keep up the good work all! Rob

Sept. 23, 2007

CryptAcquireContext Failure, default/Type 024 requested

by Rob Seger

Wine currently supports types 001 and 012, but I have a new game attempting to use type 024 (Software\\Microsoft\\Cryptography\\Defaults \\Provider Types\\Type 024). I've googled, as well as searched MSDN, for a reference as to what the crypt provider type 024 even is with no success. Does anyone know? Looking through the advapi32.dll code, this looks like it might be a serious undertaking to implement. Is that estimation accurate? Does anyone have any tips or pointers about implementing an entire CSP in wine? I appreciate any help, keep up the good work all! Rob

Sept. 22, 2007

strange pixel format

by Jose Osvaldo

The No-CD crack for "The Sims" calls to "IDirectDrawImpl_CreateSurface" (ddls/ddraw.c) which calls to "IDirectDrawImpl_CreateNewSurface". One of these calls passes a abnormal value for DDPixelFormat causing "PixelFormat_DD2WineD3D" (dlls/utils.c) to return "WINED3DFMT_UNKNOWN" (0). "IDirectDrawImpl_CreateNewSurface" returns immediately causing the program to fail by raising an exception. In this case, forcing the "IDirectDrawImpl_CreateNewSurface" function to continue with other pixel format, even a not defined one, avoids the exception and "The Sims" starts. The abnormal value is this: dwFlags = 0x00000000 dwSize = 32 dwFourCC = 0x00000000 u1 = 0x00000000 u2 = 0x00000000 u3 = 0x00000000 u4 = 0x00000000 u5 = 0x00000000 I do not know what is the expected behaviour in real Windows. The original executable file crashes with other error, but I think that is caused by the anticopy protection.

Sept. 22, 2007

Re: WineD3D surface management cleanup

by H. Verbeet

On 23/09/2007, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > - /* DXTn textures are based on compressed blocks of 4x4 pixels, each > - * 16 bytes large (8 bytes in case of DXT1). Because of that Pitch has > - * slightly different meaning compared to regular textures. For DXTn > - * textures Pitch is the size of a row of blocks, 4 high and "width" > - * long. The x offset is calculated differently as well, since moving 4 > - * pixels to the right actually moves an entire 4x4 block to right, ie > - * 16 bytes (8 in case of DXT1). */ > - if (This->resource.format == WINED3DFMT_DXT1) { > - pLockedRect->pBits = This->resource.allocatedMemory + (pLockedRect->Pitch * pRect->top / 4) + (pRect->left * 2); > - } else if (This->resource.format == WINED3DFMT_DXT2 || This->resource.format == WINED3DFMT_DXT3 > - || This->resource.format == WINED3DFMT_DXT4 || This->resource.format == WINED3DFMT_DXT5) { > - pLockedRect->pBits = This->resource.allocatedMemory + (pLockedRect->Pitch * pRect->top / 4) + (pRect->left * 4); > - } else { > - pLockedRect->pBits = This->resource.allocatedMemory + (pLockedRect->Pitch * pRect->top) + (pRect->left * This->bytesPerPixel); > - } Where did that part go? > Am Sonntag, 23. September 2007 00:14:06 schrieb Stefan Dösinger: > Ah, and the cleanup needs a cleanup itself too, e.g. RequestLocation should > move most code into subfunctions. > Yes. > The patches don't aim at fixing any bugs themselves, and I hardly tested them, > so there may be a truckload of regressions. I'm mainly showing them to show > the general direction I'm heading into. The general direction of the patches seems ok, although I'm not sure if RequestLocation / ModifyLocation is optimal from a naming point of view. (Ie, RequestLocation typically moves data rather than returning a location for the caller to read/write to, while ModifyLocation just flips a flag rather than modifying the location of the actual data) OT(?): Wrt. regressions, I would like to mention that I think that in general more care should be taken to verify a patch is correct when *writing* the patch. I do sometimes get the feeling that the general approach taken is one of "Throw some patches at it, see what sticks" :-/

Sept. 22, 2007

Re: WineD3D patch submission

by Mitchell Wheeler

Stefan Dösinger wrote: > Hello Mitchell, > > First of all, thank you for your effort in improving Wine. People who pick > their favorite game(s) and fix bugs is exactly what we need these days :-) > > You should really get used to git for submitting patches. It requires a tiny > bit of learning effort in the beginning, but it pays off very soon because it > makes handling patches much easier. > > >> Anyways, in my attempt to get it working I fixed up some issues w/ >> "IWineD3DDeviceImpl_UpdateSurface.c" in dlls/wined3d, not entirely sure >> how you guys do things around here so I thought i'd just post my changes >> to the function in this mailing list and you can do with it what you >> want. (Note: it actually has a few different methods of doing one >> thing, enclosed in macro blocks to toggle between them. Technically the >> first one should work (i think :\) once you guys properly implement >> surface locking/unlocking, and it's 'simplest', but the last one is the >> only one that actually works properly (using standard OpenGL calls). >> > I looked at the diff Mirek supplied. You should add an exact description what > your modifications do because "i also fixed the existing code that didn't > actually do what it was supposed to, heh" does not say much. From reading the > code it seems that you implement support for the source rectangle. Your patch > is mixed with formatting changes, which is not good. Formatting changes > should be separate patches, if really needed. > > As for the code, the memcpy codepath should not be in UpdateSurface. If a > system memory copy is needed, IWineGDISurface_Blt should be called, and the > support for partial rectangles of compressed surfaces added there. Otherwise, > gl(Compressed)TexSubImage2D should be used for performance reasons. > > As for your memcpy() codepath where you said lockrect is broken: What you are > trying here will not work. You have to take the pitch into account when > accessing the data returned from lockrect, the data is not in one continuous > block. > Thanks for the feedback, I didn't really expect you'd keep the first two codepaths, so all of that is understandable. (Also I could be wrong about this as it was a while ago - but I think when I tried the lock/unlock rect codepath, the destination surface never got re-uploaded to the GPU, though I didn't really understand how it was supposed to work (I've never touched DirectX before, I'm an OpenGL person myself) so could very well be mistaken) As for the commenting/reformatting, I didn't actually intend to submit this path (it was a last minute "hmm, they could probably do with this functionality" - hence I got a little 'trigger happy' and ended up rewriting half the function despite not having to, and not making a diff, nor going down the git line). I'm very familiar with subversion, and git looks relatively similar to use - so if I do end up contributing to wine again I'll be sure to put in the extra effort. Thanks again for the feedback, and who knows, you may see more patches from me in the future (when I find another game that doesn't work properly and a free weekend). Cheers.

Sept. 22, 2007

Re: WineD3D surface management cleanup

by Roderick Colenbrander

> Hi, > > This mail is mainly addressed at Henri and Roderick, but I'll send it here > to > allow others to read it too. > > These patches contain some cleanups of the d3d surface loading code. It's > main > aim is to put the code that copies the surface between system memory, > texture > and drawable into a centralized place, make LockRect simpler and pbo > creation > and surface memory allocation in one place(surface allocation is not > completely there yet). It also makes other parts of the code simpler, > avoids > playing with the surface flags in other places, and it will allow us to > centralize the logic that in the case of fbo offscreen rendering the > drawable > is the same as the texture(This is also not implemented yet). > > The patches don't aim at fixing any bugs themselves, and I hardly tested > them, > so there may be a truckload of regressions. I'm mainly showing them to > show > the general direction I'm heading into. I have taken a quick look at it. I think it looks ok (I don't fully understand all changes though but that's because I didn't know the old code that well yet). What I have been wondering why remove flush_to_framebuffer_texture? In ddraw opengl it is a very useful mode. From what I have seen on modern cards textures seem to outperform drawpixels. Roderick -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Sept. 22, 2007

Re: WineD3D surface management cleanup

by Stefan Dösinger

Am Sonntag, 23. September 2007 00:14:06 schrieb Stefan Dösinger: > Hi, > > This mail is mainly addressed at Henri and Roderick, but I'll send it here > to allow others to read it too. > > These patches contain some cleanups of the d3d surface loading code. It's > main aim is to put the code that copies the surface between system memory, > texture and drawable into a centralized place, make LockRect simpler and > pbo creation and surface memory allocation in one place(surface allocation > is not completely there yet). It also makes other parts of the code > simpler, avoids playing with the surface flags in other places, and it will > allow us to centralize the logic that in the case of fbo offscreen > rendering the drawable is the same as the texture(This is also not > implemented yet). > > The patches don't aim at fixing any bugs themselves, and I hardly tested > them, so there may be a truckload of regressions. I'm mainly showing them > to show the general direction I'm heading into. Ah, and the cleanup needs a cleanup itself too, e.g. RequestLocation should move most code into subfunctions.

Sept. 22, 2007

WineD3D surface management cleanup

by Stefan Dösinger

Hi, This mail is mainly addressed at Henri and Roderick, but I'll send it here to allow others to read it too. These patches contain some cleanups of the d3d surface loading code. It's main aim is to put the code that copies the surface between system memory, texture and drawable into a centralized place, make LockRect simpler and pbo creation and surface memory allocation in one place(surface allocation is not completely there yet). It also makes other parts of the code simpler, avoids playing with the surface flags in other places, and it will allow us to centralize the logic that in the case of fbo offscreen rendering the drawable is the same as the texture(This is also not implemented yet). The patches don't aim at fixing any bugs themselves, and I hardly tested them, so there may be a truckload of regressions. I'm mainly showing them to show the general direction I'm heading into.

Sept. 22, 2007

Re: WineD3D patch submission

by Stefan Dösinger

Hello Mitchell, First of all, thank you for your effort in improving Wine. People who pick their favorite game(s) and fix bugs is exactly what we need these days :-) You should really get used to git for submitting patches. It requires a tiny bit of learning effort in the beginning, but it pays off very soon because it makes handling patches much easier. > Anyways, in my attempt to get it working I fixed up some issues w/ > "IWineD3DDeviceImpl_UpdateSurface.c" in dlls/wined3d, not entirely sure > how you guys do things around here so I thought i'd just post my changes > to the function in this mailing list and you can do with it what you > want. (Note: it actually has a few different methods of doing one > thing, enclosed in macro blocks to toggle between them. Technically the > first one should work (i think :\) once you guys properly implement > surface locking/unlocking, and it's 'simplest', but the last one is the > only one that actually works properly (using standard OpenGL calls). I looked at the diff Mirek supplied. You should add an exact description what your modifications do because "i also fixed the existing code that didn't actually do what it was supposed to, heh" does not say much. From reading the code it seems that you implement support for the source rectangle. Your patch is mixed with formatting changes, which is not good. Formatting changes should be separate patches, if really needed. As for the code, the memcpy codepath should not be in UpdateSurface. If a system memory copy is needed, IWineGDISurface_Blt should be called, and the support for partial rectangles of compressed surfaces added there. Otherwise, gl(Compressed)TexSubImage2D should be used for performance reasons. As for your memcpy() codepath where you said lockrect is broken: What you are trying here will not work. You have to take the pitch into account when accessing the data returned from lockrect, the data is not in one continuous block.

Sept. 22, 2007

Re: WineD3D patch submission

by Mirek Slugeň

Sept. 22, 2007

Re: WineD3D patch submission

by Stefan Dösinger

Am Samstag, 22. September 2007 13:45:11 schrieb Roderick Colenbrander: > > I tried this patch, everything works like before, can't find any > > regression in apps like ET: QW, Oblivion, all nvidia D3D SDK tests, > > 3DMarks and others. Titan Quest looks beter, but there are still some > > issues in menu, game is not working because of gdi32.dll functionality. > > I create patch for actual git. > > > > Mirek > > There are a couple of things. First something minor use c-style comments > and not c++ ones (so /* */ instead of //). Further I'm not sure if the code > is correct. It looks to be doing a lot of lowlevel things (directly messing > with the memory) and some of the texture upload code is duplicated. Note > that in most cases the data is already in opengl, we don't have to reupload > it (this is slow). I'm not sure what problems your program is having but I > guess it are depth / pitch related problems. For instance the surface is > storing the bpp as seen by the windows app which can be different from the > real bpp if conversion is needed (that's why d3dfmt_get_conversion exists). > > What sort of issues was your gaming having before these changes? I guess it implements source rectangles.

Sept. 22, 2007

Re: WineD3D patch submission

by Roderick Colenbrander

> I tried this patch, everything works like before, can't find any > regression in apps like ET: QW, Oblivion, all nvidia D3D SDK tests, > 3DMarks and others. Titan Quest looks beter, but there are still some > issues in menu, game is not working because of gdi32.dll functionality. > I create patch for actual git. > > Mirek There are a couple of things. First something minor use c-style comments and not c++ ones (so /* */ instead of //). Further I'm not sure if the code is correct. It looks to be doing a lot of lowlevel things (directly messing with the memory) and some of the texture upload code is duplicated. Note that in most cases the data is already in opengl, we don't have to reupload it (this is slow). I'm not sure what problems your program is having but I guess it are depth / pitch related problems. For instance the surface is storing the bpp as seen by the windows app which can be different from the real bpp if conversion is needed (that's why d3dfmt_get_conversion exists). What sort of issues was your gaming having before these changes? Roderick -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Sept. 22, 2007

Re: Minimal Background Intelligent Transfer Service (bits) implementation

by Stefan Leichter

Am Wednesday 19 September 2007 19:28 schrieb Roy: > Howdy, > > Resubmission of bits skeleton with a DLL_WINE_PREATTACH case added to > DllMain. Thanks for the advice! > > Peace, > -Roy > Hello Roy, you may have more luck to get this patch into the wine tree, if you send it to wine-patches again. Thanks Stefan

Sept. 22, 2007

Re: WineD3D patch submission

by Mirek Slugen(

I tried this patch, everything works like before, can't find any regression in apps like ET: QW, Oblivion, all nvidia D3D SDK tests, 3DMarks and others. Titan Quest looks beter, but there are still some issues in menu, game is not working because of gdi32.dll functionality. I create patch for actual git. Mirek Mitchell Wheeler napsal(a): > Hi all, > > A week or so ago I tried to get a game working in WINE (Titan Quest), > however it seems it really needs a proper DIB engine before it'll be > playable. > > Anyways, in my attempt to get it working I fixed up some issues w/ > "IWineD3DDeviceImpl_UpdateSurface.c" in dlls/wined3d, not entirely sure > how you guys do things around here so I thought i'd just post my changes > to the function in this mailing list and you can do with it what you > want. (Note: it actually has a few different methods of doing one > thing, enclosed in macro blocks to toggle between them. Technically the > first one should work (i think :\) once you guys properly implement > surface locking/unlocking, and it's 'simplest', but the last one is the > only one that actually works properly (using standard OpenGL calls). > > You'll probably have to clean up the code to meet your coding standards > / etc, maybe remove the custom byte size calculation of compressed > images, and some other things - but the functionality is there... i > also fixed the existing code that didn't actually do what it was > supposed to, heh. > > Regards, > Mitchell Wheeler > > static HRESULT WINAPI IWineD3DDeviceImpl_UpdateSurface(IWineD3DDevice > *iface, IWineD3DSurface *pSourceSurface, CONST RECT* pSourceRect, > IWineD3DSurface *pDestinationSurface, CONST POINT* pDestPoint) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface; > /** TODO: remove casts to IWineD3DSurfaceImpl > * NOTE: move code to surface to accomplish this > ****************************************/ > IWineD3DSurfaceImpl *pSrcSurface = (IWineD3DSurfaceImpl > *)pSourceSurface; > IWineD3DSurfaceImpl *pDestSurface = > (IWineD3DSurfaceImpl*)pDestinationSurface; > int srcWidth, srcHeight; > unsigned int srcSurfaceWidth, srcSurfaceHeight, destSurfaceWidth, > destSurfaceHeight; > WINED3DFORMAT destFormat, srcFormat; > int srcLeft, srcTop, destLeft, destTop; > WINED3DPOOL srcPool, destPool; > int offset = 0; > int rowoffset = 0; /* how many bytes to add onto the end of a row to > wraparound to the beginning of the next */ > glDescriptor *glDescription = NULL, *glSrcDescription = NULL; > GLenum dummy; > int bpp; > UINT destByteSize = 0, srcByteSize = 0; > int destPixelByteSize = 0, srcPixelByteSize = 0; > CONVERT_TYPES convert = NO_CONVERSION; > > WINED3DSURFACE_DESC winedesc; > > TRACE("(%p) : Source (%p) Rect (%p) Destination (%p) Point(%p)\n", > This, pSourceSurface, pSourceRect, pDestinationSurface, pDestPoint); > memset(&winedesc, 0, sizeof(winedesc)); > winedesc.Width = &srcSurfaceWidth; > winedesc.Height = &srcSurfaceHeight; > winedesc.Pool = &srcPool; > winedesc.Format = &srcFormat; > winedesc.Size = &srcByteSize; > > IWineD3DSurface_GetDesc(pSourceSurface, &winedesc); > > winedesc.Width = &destSurfaceWidth; > winedesc.Height = &destSurfaceHeight; > winedesc.Pool = &destPool; > winedesc.Format = &destFormat; > winedesc.Size = &destByteSize; > > IWineD3DSurface_GetDesc(pDestinationSurface, &winedesc); > > if(srcPool != WINED3DPOOL_SYSTEMMEM || destPool != > WINED3DPOOL_DEFAULT){ > WARN("source %p must be SYSTEMMEM and dest %p must be DEFAULT, > returning WINED3DERR_INVALIDCALL\n", pSourceSurface, pDestinationSurface); > return WINED3DERR_INVALIDCALL; > } > > /* This call loads the opengl surface directly, instead of copying > the surface to the > * destination's sysmem copy. If surface conversion is needed, use > BltFast instead to > * copy in sysmem and use regular surface loading. > */ > d3dfmt_get_conv((IWineD3DSurfaceImpl *) pDestinationSurface, FALSE, > TRUE, > &dummy, &dummy, &dummy, &convert, &bpp, FALSE); > if(convert != NO_CONVERSION) { > return IWineD3DSurface_BltFast(pDestinationSurface, > pDestPoint ? pDestPoint->x : 0, > pDestPoint ? pDestPoint->y : 0, > pSourceSurface, (RECT *) > pSourceRect, 0); > } > > if (destFormat == WINED3DFMT_UNKNOWN) { > TRACE("(%p) : Converting destination surface from > WINED3DFMT_UNKNOWN to the source format\n", This); > IWineD3DSurface_SetFormat(pDestinationSurface, srcFormat); > > /* Get the update surface description */ > IWineD3DSurface_GetDesc(pDestinationSurface, &winedesc); > } > > ActivateContext(This, This->lastActiveRenderTarget, > CTXUSAGE_RESOURCELOAD); > > ENTER_GL(); > > if (GL_SUPPORT(ARB_MULTITEXTURE)) { > GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB)); > checkGLcall("glActiveTextureARB"); > } > > /* Make sure the surface is loaded and up to date */ > IWineD3DSurface_PreLoad(pDestinationSurface); > IWineD3DSurface_GetGlDesc(pDestinationSurface, &glDescription); > IWineD3DSurface_GetGlDesc(pDestinationSurface, &glSrcDescription); > > /* this needs to be done in lines if the sourceRect != the > sourceWidth */ > srcWidth = pSourceRect ? pSourceRect->right - > pSourceRect->left : srcSurfaceWidth; > srcHeight = pSourceRect ? pSourceRect->bottom - > pSourceRect->top : srcSurfaceHeight; > srcLeft = pSourceRect ? pSourceRect->left > : 0; > srcTop = pSourceRect ? pSourceRect->top > : 0; > destLeft = pDestPoint ? pDestPoint->x > : 0; > destTop = pDestPoint ? pDestPoint->y > : 0; > > // Calculate the rowOffset / offset values, for copying > #define ISDXTFORMAT(format) \ > (format == WINED3DFMT_DXT1 || format == WINED3DFMT_DXT2 || > format == WINED3DFMT_DXT3 || format == WINED3DFMT_DXT4 || format == > WINED3DFMT_DXT5) > > // Calculating this for our selves because I don't have faith in how > surface->bytesPerPixel is calculated... > destPixelByteSize = destByteSize / (int)(destSurfaceWidth * > destSurfaceHeight); > srcPixelByteSize = srcByteSize / (int)(srcSurfaceWidth * > srcSurfaceHeight); > > if(pSourceRect != NULL) > { > // Irregular surface formats > if (destFormat != srcFormat) { > FIXME("Can not convert between surface pixel formats..."); > > // Would require some relatively big code restructuring for > rare occurances (that shouldn't even be supported?) > > return WINED3DERR_INVALIDCALL; > } > // Uniform surface formats > else > { > if(srcWidth != srcSurfaceWidth || srcLeft > 0) > { > rowoffset = srcSurfaceWidth * srcPixelByteSize; > offset += (srcLeft * srcPixelByteSize); > } > > if(srcTop > 0) > offset += srcTop * srcSurfaceWidth * srcPixelByteSize; > } > > } > > /* Sanity check */ > if (IWineD3DSurface_GetData(pSourceSurface) == NULL) { > > /* need to lock the surface to get the data */ > FIXME("Surfaces has no allocated memory, but should be an in > memory only surface\n"); > } > > /* TODO: Cube and volume support */ > if(rowoffset != 0) { > // Compressed texture > if (ISDXTFORMAT(destFormat)) > { > if (GL_SUPPORT(EXT_TEXTURE_COMPRESSION_S3TC)) > { > #if 0 > RECT rect; > rect.left = destLeft; > rect.top = destTop; > rect.right = destLeft + srcWidth; > rect.bottom = destTop + srcHeight; > > // Lock source/destination regions > WINED3DLOCKED_RECT destRect, srcRect; > > printf("Locking surfaces...\n"); > if( > FAILED(IWineD3DSurface_LockRect(pDestinationSurface, &destRect, &rect, > 0)) || > FAILED(IWineD3DSurface_LockRect(pSourceSurface, > &srcRect, pSourceRect, WINED3DLOCK_READONLY))) > { > // How should we handle this case? Just returning > an invalid call for now... > return WINED3DERR_INVALIDCALL; > } > > printf("Surfaces locked, copying contents now... "); > if(destFormat == WINED3DFMT_DXT1) { > printf("DXT1\n"); > //memcpy(destRect.pBits, srcRect.pBits, > srcRect.Pitch * (srcHeight / 2)); > //memcpy(destRect.pBits, srcRect.pBits, > srcRect.Pitch * (srcHeight / 2)); > memcpy(destRect.pBits, srcRect.pBits, > ceil(srcWidth/4) * ceil(srcHeight/4) * 8); > } else { > printf("DXT2-5\n"); > //memcpy(destRect.pBits, srcRect.pBits, > srcRect.Pitch * (srcHeight / 4)); > memcpy(destRect.pBits, srcRect.pBits, > ceil(srcWidth/4) * ceil(srcHeight/4) * 16); > } > > // Unlock source/destination regions > IWineD3DSurface_UnlockRect(pSourceSurface); > IWineD3DSurface_UnlockRect(pDestinationSurface); > printf("Unlocking surfaces...\n"); > #elif 0 > // Get pointers to the source/destination buffers > unsigned char *dest_data = (unsigned > char*)IWineD3DSurface_GetData(pDestinationSurface); > const unsigned char *src_data = (unsigned > char*)IWineD3DSurface_GetData(pSourceSurface); > > // Copy subsection of source buffer, in to destination > buffer. > unsigned char *dest_ptr = dest_data + offset; > const unsigned char *src_ptr = src_data + offset; > > size_t i; > for(i = 0; i < srcHeight; ++i) { > memcpy(dest_ptr, src_ptr, srcWidth * srcPixelByteSize); > > dest_ptr += rowoffset; > src_ptr += rowoffset; > } > > > // Upload destination buffer to server > GL_EXTCALL(glCompressedTexImage2DARB(glDescription->target, > glDescription->level, > > glDescription->glFormatInternal, > srcWidth, > srcHeight, > 0, > destByteSize, > dest_data)); > > checkGLcall("glCompressedTexImage2DARB"); > #elif 1 > int blocksize = 16; > if(destFormat == WINED3DFMT_DXT1) > blocksize = 8; > > #define max(a, b) (a > b? a : b) > srcHeight = max(srcHeight, 4); > srcWidth = max(srcWidth, 4); > #undef max > > int data_size = (srcWidth / 4) * (srcHeight / 4) * > blocksize; > int row_size = data_size / srcHeight; > int pixel_size = row_size / srcWidth; > int stride = srcSurfaceWidth * pixel_size; > > unsigned char *temp_buffer = HeapAlloc(GetProcessHeap(), > 0, data_size); > unsigned char *temp_ptr = temp_buffer; > > // Debug info > //printf(" > BytesTotal: %i | BytesPerPixel: %i | > RowSize: %i\n", data_size, pixel_size, row_size); > //printf(" > Source: %i -> %i, %i -> %i | Dest: %i, > %i\n", srcLeft, srcWidth, srcTop, srcHeight, destLeft, destTop); > //printf(" > Offset: %i\n", (int)((row_size * srcTop) + > srcLeft * pixel_size)); > > // Get pointers to the source buffer > const unsigned char *src_data = (unsigned > char*)IWineD3DSurface_GetData(pSourceSurface); > src_data += (stride * srcTop) + srcLeft * pixel_size; > > size_t i; > for(i = 0; i < srcHeight; ++i) { > memcpy(temp_ptr, src_data, row_size); > temp_ptr += row_size; > src_data += stride; > } > > GL_EXTCALL(glCompressedTexSubImage2DARB( > glDescription->target, > glDescription->level, > destLeft, > destTop, > srcWidth, > srcHeight, > glDescription->glFormatInternal, > data_size, > temp_buffer > )); > //checkGLcall("glCompressedTexSubImage2DARB"); > > HeapFree(GetProcessHeap(), 0, temp_buffer); > #endif > } > else > { > FIXME("TODO: Need to update a DXT compressed texture > without hardware support\n"); > } > } > // Uncompressed texture > else > { > /* not a whole row so we have to do it a line at a time */ > int j; > > /* hopefully using pointer addtion will be quicker than > using a point + j * rowoffset */ > const unsigned char* data =((const unsigned char > *)IWineD3DSurface_GetData(pSourceSurface)) + offset; > > for(j = destTop; j < (srcHeight + destTop); ++j) > { > glTexSubImage2D(glDescription->target > ,glDescription->level > ,destLeft > ,j > ,srcWidth > ,1 > ,glDescription->glFormat > ,glDescription->glType > ,data /* could be quicker using */ > ); > data += rowoffset; > } > } > } else { > // Compressed texture > if (ISDXTFORMAT(destFormat)) > { > if (GL_SUPPORT(EXT_TEXTURE_COMPRESSION_S3TC)) > { > int blocksize = 16; > if(destFormat == WINED3DFMT_DXT1) > blocksize = 8; > > #define max(a, b) (a > b? a : b) > int data_size = (max(srcWidth, 4) / 4) * (max(srcHeight, > 4) / 4) * blocksize; > #undef max > > //printf(" -> S = %i | CompressedTexImage2D(?, %i, %i, > %i, %i, 0, %i, ?)\n", destByteSize, glDescription->level, > glDescription->glFormatInternal, srcWidth, srcHeight, data_size); > > GL_EXTCALL(glCompressedTexSubImage2DARB(glDescription->target, > glDescription->level, > destLeft, > destTop, > srcWidth, > srcHeight, > > glDescription->glFormatInternal, > data_size, > > IWineD3DSurface_GetData(pSourceSurface))); > > checkGLcall("glCompressedTexImage2DARB"); > } > else > { > FIXME("TODO: Need to update a DXT compressed texture > without hardware support\n"); > } > } > // Uncompressed Texture > else > { > glTexSubImage2D( > glDescription->target, > glDescription->level, > destLeft, > destTop, > srcWidth, > srcHeight, > glDescription->glFormat, > glDescription->glType, > IWineD3DSurface_GetData(pSourceSurface) > ); > > checkGLcall("glTexSubImage2D"); > } > } > > LEAVE_GL(); > > ((IWineD3DSurfaceImpl *)pDestinationSurface)->Flags &= ~SFLAG_INSYSMEM; > ((IWineD3DSurfaceImpl *)pDestinationSurface)->Flags |= SFLAG_INTEXTURE; > IWineD3DDeviceImpl_MarkStateDirty(This, STATE_SAMPLER(0)); > > return WINED3D_OK; > } > > > >

Sept. 22, 2007

Re: WineD3D patch submission

by Roderick Colenbrander

> Hi all, > > A week or so ago I tried to get a game working in WINE (Titan Quest), > however it seems it really needs a proper DIB engine before it'll be > playable. > > Anyways, in my attempt to get it working I fixed up some issues w/ > "IWineD3DDeviceImpl_UpdateSurface.c" in dlls/wined3d, not entirely sure > how you guys do things around here so I thought i'd just post my changes > to the function in this mailing list and you can do with it what you > want. (Note: it actually has a few different methods of doing one > thing, enclosed in macro blocks to toggle between them. Technically the > first one should work (i think :\) once you guys properly implement > surface locking/unlocking, and it's 'simplest', but the last one is the > only one that actually works properly (using standard OpenGL calls). > > You'll probably have to clean up the code to meet your coding standards > / etc, maybe remove the custom byte size calculation of compressed > images, and some other things - but the functionality is there... i > also fixed the existing code that didn't actually do what it was > supposed to, heh. > > Regards, > Mitchell Wheeler Hi, Could you submit a patch (the difference between the original file and your changes). That makes it easier to comment on. When it is good you need a patch file anyway as that's what added to wine's git. Regards, Roderick Colenbrander -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Sept. 22, 2007

Re: services.exe[3/3]: start a local RPC server [fixed]

by Robert Shearman

Mikolaj Zalewski wrote: > diff --git a/dlls/advapi32/Makefile.in b/dlls/advapi32/Makefile.in > index 8f6fe33..85e9680 100644 > --- a/dlls/advapi32/Makefile.in > +++ b/dlls/advapi32/Makefile.in > @@ -5,7 +5,7 @@ SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = advapi32.dll > IMPORTLIB = libadvapi32.$(IMPLIBEXT) > -IMPORTS = kernel32 ntdll > +IMPORTS = rpcrt4 kernel32 ntdll I think you should make rpcrt4 a DELAYIMPORT since it should only be needed for program that use services. Also, you have added one or two header files that don't have a copyright and LGPL statement at the top, which should probably be fixed before the final version (the exception is the one-line files to make the generated files appear in the right place). -- Rob Shearman

Sept. 22, 2007

Re: wine.inf: add some four keys in Active Setup\Installed Components [resend]

by Robert Shearman

Mikolaj Zalewski wrote: > +; Some apps wants at least four keys in Installed Components to run correctly > +HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{a2f95861-06e5-4e58-ab61-94cbdde2ff55},Version,2,"1,0,0,0" > +HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{c30a0529-fcef-4b19-8e68-9527b54474ac},Version,2,"1,0,0,0" > +HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{d0b883e4-af5a-45c9-bd44-deb9867c1d94},Version,2,"1,0,0,0" > +HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{e84bb5b4-7fe1-469c-9f24-5a2af3402108},Version,2,"1,0,0,0" You might want to find four real components always present on Windows to add to this key. -- Rob Shearman

Sept. 22, 2007

Re: advapi32: add some more rights constants for ConvertStringSecurityDescriptorToSecurityDescriptor

by Hans Leidekker

On Saturday 22 September 2007 04:19:09 Mikolaj Zalewski wrote: > + > + ADS_RIGHT_DELTE = 0x00010000, You're missing an E there. -Hans

Sept. 22, 2007

WineD3D patch submission

by Mitchell Wheeler

Hi all, A week or so ago I tried to get a game working in WINE (Titan Quest), however it seems it really needs a proper DIB engine before it'll be playable. Anyways, in my attempt to get it working I fixed up some issues w/ "IWineD3DDeviceImpl_UpdateSurface.c" in dlls/wined3d, not entirely sure how you guys do things around here so I thought i'd just post my changes to the function in this mailing list and you can do with it what you want. (Note: it actually has a few different methods of doing one thing, enclosed in macro blocks to toggle between them. Technically the first one should work (i think :\) once you guys properly implement surface locking/unlocking, and it's 'simplest', but the last one is the only one that actually works properly (using standard OpenGL calls). You'll probably have to clean up the code to meet your coding standards / etc, maybe remove the custom byte size calculation of compressed images, and some other things - but the functionality is there... i also fixed the existing code that didn't actually do what it was supposed to, heh. Regards, Mitchell Wheeler static HRESULT WINAPI IWineD3DDeviceImpl_UpdateSurface(IWineD3DDevice *iface, IWineD3DSurface *pSourceSurface, CONST RECT* pSourceRect, IWineD3DSurface *pDestinationSurface, CONST POINT* pDestPoint) { IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface; /** TODO: remove casts to IWineD3DSurfaceImpl * NOTE: move code to surface to accomplish this ****************************************/ IWineD3DSurfaceImpl *pSrcSurface = (IWineD3DSurfaceImpl *)pSourceSurface; IWineD3DSurfaceImpl *pDestSurface = (IWineD3DSurfaceImpl*)pDestinationSurface; int srcWidth, srcHeight; unsigned int srcSurfaceWidth, srcSurfaceHeight, destSurfaceWidth, destSurfaceHeight; WINED3DFORMAT destFormat, srcFormat; int srcLeft, srcTop, destLeft, destTop; WINED3DPOOL srcPool, destPool; int offset = 0; int rowoffset = 0; /* how many bytes to add onto the end of a row to wraparound to the beginning of the next */ glDescriptor *glDescription = NULL, *glSrcDescription = NULL; GLenum dummy; int bpp; UINT destByteSize = 0, srcByteSize = 0; int destPixelByteSize = 0, srcPixelByteSize = 0; CONVERT_TYPES convert = NO_CONVERSION; WINED3DSURFACE_DESC winedesc; TRACE("(%p) : Source (%p) Rect (%p) Destination (%p) Point(%p)\n", This, pSourceSurface, pSourceRect, pDestinationSurface, pDestPoint); memset(&winedesc, 0, sizeof(winedesc)); winedesc.Width = &srcSurfaceWidth; winedesc.Height = &srcSurfaceHeight; winedesc.Pool = &srcPool; winedesc.Format = &srcFormat; winedesc.Size = &srcByteSize; IWineD3DSurface_GetDesc(pSourceSurface, &winedesc); winedesc.Width = &destSurfaceWidth; winedesc.Height = &destSurfaceHeight; winedesc.Pool = &destPool; winedesc.Format = &destFormat; winedesc.Size = &destByteSize; IWineD3DSurface_GetDesc(pDestinationSurface, &winedesc); if(srcPool != WINED3DPOOL_SYSTEMMEM || destPool != WINED3DPOOL_DEFAULT){ WARN("source %p must be SYSTEMMEM and dest %p must be DEFAULT, returning WINED3DERR_INVALIDCALL\n", pSourceSurface, pDestinationSurface); return WINED3DERR_INVALIDCALL; } /* This call loads the opengl surface directly, instead of copying the surface to the * destination's sysmem copy. If surface conversion is needed, use BltFast instead to * copy in sysmem and use regular surface loading. */ d3dfmt_get_conv((IWineD3DSurfaceImpl *) pDestinationSurface, FALSE, TRUE, &dummy, &dummy, &dummy, &convert, &bpp, FALSE); if(convert != NO_CONVERSION) { return IWineD3DSurface_BltFast(pDestinationSurface, pDestPoint ? pDestPoint->x : 0, pDestPoint ? pDestPoint->y : 0, pSourceSurface, (RECT *) pSourceRect, 0); } if (destFormat == WINED3DFMT_UNKNOWN) { TRACE("(%p) : Converting destination surface from WINED3DFMT_UNKNOWN to the source format\n", This); IWineD3DSurface_SetFormat(pDestinationSurface, srcFormat); /* Get the update surface description */ IWineD3DSurface_GetDesc(pDestinationSurface, &winedesc); } ActivateContext(This, This->lastActiveRenderTarget, CTXUSAGE_RESOURCELOAD); ENTER_GL(); if (GL_SUPPORT(ARB_MULTITEXTURE)) { GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB)); checkGLcall("glActiveTextureARB"); } /* Make sure the surface is loaded and up to date */ IWineD3DSurface_PreLoad(pDestinationSurface); IWineD3DSurface_GetGlDesc(pDestinationSurface, &glDescription); IWineD3DSurface_GetGlDesc(pDestinationSurface, &glSrcDescription); /* this needs to be done in lines if the sourceRect != the sourceWidth */ srcWidth = pSourceRect ? pSourceRect->right - pSourceRect->left : srcSurfaceWidth; srcHeight = pSourceRect ? pSourceRect->bottom - pSourceRect->top : srcSurfaceHeight; srcLeft = pSourceRect ? pSourceRect->left : 0; srcTop = pSourceRect ? pSourceRect->top : 0; destLeft = pDestPoint ? pDestPoint->x : 0; destTop = pDestPoint ? pDestPoint->y : 0; // Calculate the rowOffset / offset values, for copying #define ISDXTFORMAT(format) \ (format == WINED3DFMT_DXT1 || format == WINED3DFMT_DXT2 || format == WINED3DFMT_DXT3 || format == WINED3DFMT_DXT4 || format == WINED3DFMT_DXT5) // Calculating this for our selves because I don't have faith in how surface->bytesPerPixel is calculated... destPixelByteSize = destByteSize / (int)(destSurfaceWidth * destSurfaceHeight); srcPixelByteSize = srcByteSize / (int)(srcSurfaceWidth * srcSurfaceHeight); if(pSourceRect != NULL) { // Irregular surface formats if (destFormat != srcFormat) { FIXME("Can not convert between surface pixel formats..."); // Would require some relatively big code restructuring for rare occurances (that shouldn't even be supported?) return WINED3DERR_INVALIDCALL; } // Uniform surface formats else { if(srcWidth != srcSurfaceWidth || srcLeft > 0) { rowoffset = srcSurfaceWidth * srcPixelByteSize; offset += (srcLeft * srcPixelByteSize); } if(srcTop > 0) offset += srcTop * srcSurfaceWidth * srcPixelByteSize; } } /* Sanity check */ if (IWineD3DSurface_GetData(pSourceSurface) == NULL) { /* need to lock the surface to get the data */ FIXME("Surfaces has no allocated memory, but should be an in memory only surface\n"); } /* TODO: Cube and volume support */ if(rowoffset != 0) { // Compressed texture if (ISDXTFORMAT(destFormat)) { if (GL_SUPPORT(EXT_TEXTURE_COMPRESSION_S3TC)) { #if 0 RECT rect; rect.left = destLeft; rect.top = destTop; rect.right = destLeft + srcWidth; rect.bottom = destTop + srcHeight; // Lock source/destination regions WINED3DLOCKED_RECT destRect, srcRect; printf("Locking surfaces...\n"); if( FAILED(IWineD3DSurface_LockRect(pDestinationSurface, &destRect, &rect, 0)) || FAILED(IWineD3DSurface_LockRect(pSourceSurface, &srcRect, pSourceRect, WINED3DLOCK_READONLY))) { // How should we handle this case? Just returning an invalid call for now... return WINED3DERR_INVALIDCALL; } printf("Surfaces locked, copying contents now... "); if(destFormat == WINED3DFMT_DXT1) { printf("DXT1\n"); //memcpy(destRect.pBits, srcRect.pBits, srcRect.Pitch * (srcHeight / 2)); //memcpy(destRect.pBits, srcRect.pBits, srcRect.Pitch * (srcHeight / 2)); memcpy(destRect.pBits, srcRect.pBits, ceil(srcWidth/4) * ceil(srcHeight/4) * 8); } else { printf("DXT2-5\n"); //memcpy(destRect.pBits, srcRect.pBits, srcRect.Pitch * (srcHeight / 4)); memcpy(destRect.pBits, srcRect.pBits, ceil(srcWidth/4) * ceil(srcHeight/4) * 16); } // Unlock source/destination regions IWineD3DSurface_UnlockRect(pSourceSurface); IWineD3DSurface_UnlockRect(pDestinationSurface); printf("Unlocking surfaces...\n"); #elif 0 // Get pointers to the source/destination buffers unsigned char *dest_data = (unsigned char*)IWineD3DSurface_GetData(pDestinationSurface); const unsigned char *src_data = (unsigned char*)IWineD3DSurface_GetData(pSourceSurface); // Copy subsection of source buffer, in to destination buffer. unsigned char *dest_ptr = dest_data + offset; const unsigned char *src_ptr = src_data + offset; size_t i; for(i = 0; i < srcHeight; ++i) { memcpy(dest_ptr, src_ptr, srcWidth * srcPixelByteSize); dest_ptr += rowoffset; src_ptr += rowoffset; } // Upload destination buffer to server GL_EXTCALL(glCompressedTexImage2DARB(glDescription->target, glDescription->level, glDescription->glFormatInternal, srcWidth, srcHeight, 0, destByteSize, dest_data)); checkGLcall("glCompressedTexImage2DARB"); #elif 1 int blocksize = 16; if(destFormat == WINED3DFMT_DXT1) blocksize = 8; #define max(a, b) (a > b? a : b) srcHeight = max(srcHeight, 4); srcWidth = max(srcWidth, 4); #undef max int data_size = (srcWidth / 4) * (srcHeight / 4) * blocksize; int row_size = data_size / srcHeight; int pixel_size = row_size / srcWidth; int stride = srcSurfaceWidth * pixel_size; unsigned char *temp_buffer = HeapAlloc(GetProcessHeap(), 0, data_size); unsigned char *temp_ptr = temp_buffer; // Debug info //printf(" > BytesTotal: %i | BytesPerPixel: %i | RowSize: %i\n", data_size, pixel_size, row_size); //printf(" > Source: %i -> %i, %i -> %i | Dest: %i, %i\n", srcLeft, srcWidth, srcTop, srcHeight, destLeft, destTop); //printf(" > Offset: %i\n", (int)((row_size * srcTop) + srcLeft * pixel_size)); // Get pointers to the source buffer const unsigned char *src_data = (unsigned char*)IWineD3DSurface_GetData(pSourceSurface); src_data += (stride * srcTop) + srcLeft * pixel_size; size_t i; for(i = 0; i < srcHeight; ++i) { memcpy(temp_ptr, src_data, row_size); temp_ptr += row_size; src_data += stride; } GL_EXTCALL(glCompressedTexSubImage2DARB( glDescription->target, glDescription->level, destLeft, destTop, srcWidth, srcHeight, glDescription->glFormatInternal, data_size, temp_buffer )); //checkGLcall("glCompressedTexSubImage2DARB"); HeapFree(GetProcessHeap(), 0, temp_buffer); #endif } else { FIXME("TODO: Need to update a DXT compressed texture without hardware support\n"); } } // Uncompressed texture else { /* not a whole row so we have to do it a line at a time */ int j; /* hopefully using pointer addtion will be quicker than using a point + j * rowoffset */ const unsigned char* data =((const unsigned char *)IWineD3DSurface_GetData(pSourceSurface)) + offset; for(j = destTop; j < (srcHeight + destTop); ++j) { glTexSubImage2D(glDescription->target ,glDescription->level ,destLeft ,j ,srcWidth ,1 ,glDescription->glFormat ,glDescription->glType ,data /* could be quicker using */ ); data += rowoffset; } } } else { // Compressed texture if (ISDXTFORMAT(destFormat)) { if (GL_SUPPORT(EXT_TEXTURE_COMPRESSION_S3TC)) { int blocksize = 16; if(destFormat == WINED3DFMT_DXT1) blocksize = 8; #define max(a, b) (a > b? a : b) int data_size = (max(srcWidth, 4) / 4) * (max(srcHeight, 4) / 4) * blocksize; #undef max //printf(" -> S = %i | CompressedTexImage2D(?, %i, %i, %i, %i, 0, %i, ?)\n", destByteSize, glDescription->level, glDescription->glFormatInternal, srcWidth, srcHeight, data_size); GL_EXTCALL(glCompressedTexSubImage2DARB(glDescription->target, glDescription->level, destLeft, destTop, srcWidth, srcHeight, glDescription->glFormatInternal, data_size, IWineD3DSurface_GetData(pSourceSurface))); checkGLcall("glCompressedTexImage2DARB"); } else { FIXME("TODO: Need to update a DXT compressed texture without hardware support\n"); } } // Uncompressed Texture else { glTexSubImage2D( glDescription->target, glDescription->level, destLeft, destTop, srcWidth, srcHeight, glDescription->glFormat, glDescription->glType, IWineD3DSurface_GetData(pSourceSurface) ); checkGLcall("glTexSubImage2D"); } } LEAVE_GL(); ((IWineD3DSurfaceImpl *)pDestinationSurface)->Flags &= ~SFLAG_INSYSMEM; ((IWineD3DSurfaceImpl *)pDestinationSurface)->Flags |= SFLAG_INTEXTURE; IWineD3DDeviceImpl_MarkStateDirty(This, STATE_SAMPLER(0)); return WINED3D_OK; }

Sept. 21, 2007

Re: Will ROS and WINE still be steady be synchronized ?

by Jeremy White

Dan Kegel wrote: > On 9/21/07, Steven Edwards <winehacker(a)gmail.com> wrote: >> I could go on but I am just ranting and angry because this keeps >> coming up and the solution seems clear enough. Can we at least, while >> the crickets chirp on the audit, get the SFLC to publish some bloody >> standards we should all follow? > > Hear, hear! > I believe this would make an excellent topic at Wineconf. > Jeremy, how about a status report there? Good idea! We'll make that a useful deadline for bringing forward the ideas we've been working with the SFLC for the past year or two. (And yes, I'm painfully aware it's been a long time). I'll post a separate note on the state of the SFLC wrt Wine as I see it as well. Cheers, Jeremy

Sept. 21, 2007

Re: Will ROS and WINE still be steady be synchronized ?

by Dan Kegel

On 9/21/07, Steven Edwards <winehacker(a)gmail.com> wrote: > On 9/21/07, Dan Kegel <dank(a)kegel.com> wrote: > > I'm not trying to make any generalizations here, just > > trying to explain why Wine can't safely accept ReactOS code. > > Sorry about my last post then. I should not have added more statements > that are inflammatory with harsh rhetoric. But it was a good read nonetheless. > I would be happy to write > an FAQ explaining this matter as I understand the clean-room > requirements and that ReactOS does not meet them. My objection to > doing this right now is that I think the SFLC should be the ones to > write the standard and every single time this comes up, members of the > Wine project take it upon themselves to define what is legal and what > is not and accuse the ReactOS team of behaving in a way that is not > legal. The questions certainly do come up frequently. We can't wait forever for the SFLC, so perhaps it would be good for you to draft an FAQ. We could run it by them before posting it. Alexandre? - Dan

Sept. 21, 2007

Re: Will ROS and WINE still be steady be synchronized ?

by Dan Kegel

On 9/21/07, Steven Edwards <winehacker(a)gmail.com> wrote: > I could go on but I am just ranting and angry because this keeps > coming up and the solution seems clear enough. Can we at least, while > the crickets chirp on the audit, get the SFLC to publish some bloody > standards we should all follow? Hear, hear! I believe this would make an excellent topic at Wineconf. Jeremy, how about a status report there? - Dan

Sept. 21, 2007

Re: services.exe[3/3]: start a local RPC server and make advapi32 connect/disconnect to it on service manager handle creation/destruction

by Robert Shearman

Mikolaj Zalewski wrote: > + /* Compatible with Windows function 0x0f */ > + DWORD svcctl_OpenSCManagerW( > + SvcCtlRpcHandle rpc_handle, > + [in,unique,string] LPCWSTR MachineName, > + [in,unique,string] LPCWSTR DatabaseName, > The string attribute should be redundant as LPCWSTR should already be declared as a string type. I also noticed this redundancy in your fourth services patch. > + if ((err = RpcServerInqBindings(&pbindingVector)) != ERROR_SUCCESS) > + { > + WINE_ERR("RpcServerInqBindings failed with error %u\n", err); > + return err; > + } What's the purpose of this? You don't actually use the binding vector anywhere. -- Rob Shearman

Sept. 21, 2007

Re: Patch: ntoskrnl.exe - Added PsCreateSystemThread

by Stefan Dösinger

Am Donnerstag, 20. September 2007 03:49:40 schrieb Carroll Vance: > I have tested this with a driver I made and it seemed to > work fine. I don't know much about ntoskrnl.exe, but if you have a test driver, you may want to include it in the patch. Other libraries have a set of regression tests in dlls/<lib>/tests . ntoskrnl.exe doesn't have any yet, but I don't know if that is a policy or just because no one started it yet.

Sept. 21, 2007

Re: Will ROS and WINE still be steady be synchronized ?

by Steven Edwards

On 9/21/07, Dan Kegel <dank(a)kegel.com> wrote: > I'm not trying to make any generalizations here, just > trying to explain why Wine can't safely accept ReactOS code. Sorry about my last post then. I should not have added more statements that are inflammatory with harsh rhetoric. I would be happy to write an FAQ explaining this matter as I understand the clean-room requirements and that ReactOS does not meet them. My objection to doing this right now is that I think the SFLC should be the ones to write the standard and every single time this comes up, members of the Wine project take it upon themselves to define what is legal and what is not and accuse the ReactOS team of behaving in a way that is not legal. That may very well be, but until our legal team actually says so, all it does is hurt the PR for ReactOS and make the Wine developers look like they have it in for ReactOS Project. -- 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

Sept. 21, 2007

Re: Will ROS and WINE still be steady be synchronized ?

by Steven Edwards

On 9/21/07, Dan Kegel <dank(a)kegel.com> wrote: > (the two projects were the same originally, and split apart > only after the world noticed just how illegal ReactOS's practices were). These broad generalizations or downright libel statements prove more inflammatory that then accusations of developer taint. I take great objection to this as a lot of this crap happened under my watch. 1. Some developers practices might not be legal in the US. The project has an policy statement that most developers followed. Others did not. It happens. It was never taken to court and ultimately those developers left anyway. If you know of a function in ReactOS that looks suspicious feel free to send a note their way. I am sure they will remove it. What happens if I say "Function foo looks like its dirty and it made it in the Wine tree" Is wine forever tainted? Can you point out case-law or a standard ANYWHERE ReactOS needs to follow to make the Wine people happy? I can point to one standard and Julliard already said he did not agree with it. http://www.gnu.org/prep/standards/ They even have a whole page for people that have SEEN proprietary sources http://www.gnu.org/prep/standards/html_node/Reading-Non_002dFree-Code.html#… 2. To Date Wine does not have a clearly identifiable policy statement about what is Kosher and what is not and EVER FREAKING WEEK someone asks a policy related question on wine-devel. Can I use ReactOS code? Do we follow the same rules as the GNU coding standards? What is clean room reverse engineering? What is the Audit thing I keep hearing about? 3. How about, rather than blackballing a whole project or group and causing guilt by association, we use the same standards for everyone when submitting patches, codify them and let that be that. What happens the day Wine gets a patch from a @microsoft.com email? Do we blackball them if their corporate policy changes to allow a contribution. I mean you know they make a compiler right? You know they also submit patches to GCC for Interix right? I hope to God we have a standard in place by then and a webform that allows that person to say "I never had access to windows source that had analogous functionality". 4. Do you think Vlad the Reverser from Russia sending a patch to wine-patches is going to preface his patches saying "I reversed this" or "I copied this"? No hes going to submit it and Julliard is going to have to make a judgment call based upon if he knows the person, the quality of the code and the planarity alignment. I could go on but I am just ranting and angry because this keeps coming up and the solution seems clear enough. Can we at least, while the crickets chirp on the audit, get the SFLC to publish some bloody standards we should all follow? Thanks -- 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

Sept. 21, 2007

Re: Will ROS and WINE still be steady be synchronized ?

by James Hawkins

On 9/21/07, Shachar Shemesh <shachar(a)shemesh.biz> wrote: > Shachar Shemesh wrote: > > Here's the law as I know it. As far as I know, it is quite identical in > > the US and in Israel in that regard: > Just to make it clear, as far as I can see it, even with the above, it > is still illegal to accept code from RoS (you are not allowed to copy > code from the MS source code, or even from your own effort of > translating the assembly to C, without violating copyright). > > All I'm saying is that the rules are not as strict as we sometimes play > them to be. > The article at [1] provides interesting information regarding reverse engineering of all types. More importantly, the author provides a list of cases that provide legal precedence for the legality (or lack thereof) of reverse engineering. The most important thing to keep in mind when considering the legality of reverse engineering is that there is no fine line when it comes to the act, and any new case can overturn all the legal precedence that comes before it. The Wine project has succeeded thus far without using reverse engineering, and will continue to do so, so there's no reason to take the legal risk of accepting code form the ReactOS project, or from anyone that has seen or reverse engineered Microsoft code, clean room or otherwise. [1] http://www.jenkins-ip.com/serv/serv_6.htm -- James Hawkins

Sept. 21, 2007

Re: Will ROS and WINE still be steady be synchronized ?

by Dan Kegel

On 9/20/07, Shachar Shemesh <shachar(a)shemesh.biz> wrote: > Shachar Shemesh wrote: > > Here's the law as I know it. As far as I know, it is quite identical in > > the US and in Israel in that regard: > > Just to make it clear, as far as I can see it, even with the above, it > is still illegal to accept code from RoS (you are not allowed to copy > code from the MS source code, or even from your own effort of > translating the assembly to C, without violating copyright). OK then, we seem to agree. > All I'm saying is that the rules are not as strict as we sometimes play > them to be. I'm not trying to make any generalizations here, just trying to explain why Wine can't safely accept ReactOS code. - Dan

Sept. 21, 2007

Re: Will ROS and WINE still be steady be synchronized ?

by Shachar Shemesh

Shachar Shemesh wrote: > Here's the law as I know it. As far as I know, it is quite identical in > the US and in Israel in that regard: Just to make it clear, as far as I can see it, even with the above, it is still illegal to accept code from RoS (you are not allowed to copy code from the MS source code, or even from your own effort of translating the assembly to C, without violating copyright). All I'm saying is that the rules are not as strict as we sometimes play them to be. Shachar

Sept. 21, 2007

Re: Will ROS and WINE still be steady be synchronized ?

by Shachar Shemesh

Dan Kegel wrote: > We've gone over this about a dozen times. Can we get back to > programming Wine now (cleanly)? > - Dan > Here's the law as I know it. As far as I know, it is quite identical in the US and in Israel in that regard: - Any trade secret (say, algorithm, interface, subbehavior) loses its secret status the moment it is reversed engineered from a legally obtained copy. Once it loses its secret status, it is obviously legal to cleanly reimplemenet it. - Any trade secret loses its status the moment it is public. As far as I understand it, the MS source code that was leaked has no trade secret protection any more, and it is entirely legal for a Wine hacker to look at it in order to find out, for example, why a certain combination of parameters, when sent to a certain function, causes Windows to do something unexpected. It is NOT legal to copy code into Wine from it, as that code is still copyrighted. - Interfaces are not copy protectable. This means that it is, in principle, legal to copy a file that only has interface definitions (say, a header file) into Wine. We don't do it, and for a good reason (why risk it for such a small gain), but it is legal. - A programmer is only tainted if she signed an NDA or a non-compete. Even then, it's a contractual dispute, not a criminal dispute, whether she is allowed to work on Wine. Merely looking at publicly available code does not taint a programmer (this is unlike the IBM BIOS case, where they gave the BIOS source code under NDA, and thus retained trade secret status for it). Shachar

Sept. 21, 2007

Re: Will ROS and WINE still be steady be synchronized ?

by Dan Kegel

On 9/20/07, Shachar Shemesh <shachar(a)shemesh.biz> wrote: > I'm not talking about moving disassembled code into our code. That is a > copyright violation in Israel too. I'm talking about disassembling code > in order to figure out what it does, and then reimplementing that (with > or without going into the extremes of "clean room"). (Again, I am not a lawyer.) I think this is legal in the US *only* when applied to interfaces, not to innards. > Do the RoS guys do the former? For their official policy, see http://www.reactos.org/en/dev_legalreview.html But also see http://www.reactos.org/wiki/index.php/TinyKRNL Here's the problem with accepting code from ReactOS: they share code and developers with the TinyKRNL project (the two projects were the same originally, and split apart only after the world noticed just how illegal ReactOS's practices were). TinyKRNL's official policy is "anything goes", so it wouldn't surprise me if people on that project simply retyped stuff they saw in stolen copies of the real Microsoft Windows source code. ReachOS's official policy says in effect "there's no such thing as a tainted developer, so all TinyKRNL developers are welcome to submit code to ReactOS; and any not-obviously-problematic code in TinyKRNL can be imported into ReactOS." While the above is a crass oversimplification, and I'm sure the ReactOS people will want to correct any errors I made in it, it seems clear to me that the fig leaf ReactOS is standing behind is a bit too small for comfort. Wine does well to steer clear of ReactOS code. We've gone over this about a dozen times. Can we get back to programming Wine now (cleanly)? - Dan

Sept. 21, 2007

Re: Will ROS and WINE still be steady be synchronized ?

by Shachar Shemesh

Dan Kegel wrote: > I am not a lawyer, but I bet you're wrong there. > The disassembled code is probably considered a copy, > I'm not talking about moving disassembled code into our code. That is a copyright violation in Israel too. I'm talking about disassembling code in order to figure out what it does, and then reimplementing that (with or without going into the extremes of "clean room"). Do the RoS guys do the former? Shachar

Sept. 20, 2007

re: Will ROS and WINE still be steady be synchronized ?

by Dan Kegel

Shachar Shemesh wrote: > As far as I understand this, if I disassemble Microsoft binaries (it is > legal in Israel), then the resulting knowledge is legal to use - > anywhere (in other words - the only one who can be sued is me, and the > jurisdiction is Israel, where the action is legal). I am not a lawyer, but I bet you're wrong there. The disassembled code is probably considered a copy, using it could be a copyright violation, and if any such code snuck into Wine, we'd have to go rip it out at great cost. - Dan

Sept. 20, 2007

Re: Patch: ntoskrnl.exe - Added PsCreateSystemThread

by Dmitry Timoshkov

"Carroll Vance" <ovencleaner(a)gmail.com> wrote: > I have implemented PsCreateSystemThread in ntoskrnl.exe. This API i have > found used by programs like nProtect gameguard, and is a pretty commonly > used kernel api. This either ends up calling CreateThread or > CreateRemoteThread depending on if a process handle was provided. You can call CreateRemoteThread without any checks for the process handle. > This is my > first patch, I read over the dev docs and patch format, I hope I did not > miss anything. I have tested this with a driver I made and it seemed to work > fine. Your patch mixes tabs and spaces on the same line, that makes formatting messy. Also if you could add spaces around '!=' and '==' in if statements that would make the code slightly more readable. -- Dmitry.

Sept. 20, 2007

Re: Always set DIOBJECTDATAFORMAT.pguid to GUID_Button for joystick buttons

by John Klehm

On 9/20/07, Antonio Cuni <anto.cuni(a)gmail.com> wrote: > At least one game (Pro Evolution Soccer 6) rely on the pguid field of > the DIOBJECTDATAFORMAT struct to respond to joystick button's events. > Setting pguid to GUID_Button solves the problem. > > 2007-09-20 Antonio Cuni <anto.cuni(a)gmail.com> > > * dlls/dinput/joystick_linux.c, > dlls/dinput/joystick_linuxinput.c > Always set DIOBJECTDATAFORMAT.pguid to GUID_Button for > joystick buttons > > > + df->rgodf[idx].pguid = &GUID_Button; // some games require the GUID to be > + > df->rgodf[idx].pguid = &GUID_Button; // some games require the GUID to be GUID_Button > You need to use C style comments /* */ Regards =), --John Klehm

Sept. 20, 2007