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

Re: user32: Restore old WM_SIZE handler in mdi child
by Peter Oberndorfer Jan. 22, 2007

Jan. 22, 2007

On Monday 08 January 2007 11:31, Dmitry Timoshkov wrote: > Hello, Hi, this patch seems to cause http://bugs.winehq.org/show_bug.cgi?id=7190 Each time a MDI child window gets a WM_SIZE the left most menu entry disapperars. The problem is that MDI_RestoreFrameMenu is called for each WM_SIZE message, that does not maximize the window, instead of only beeing called when window goes from maximized to normal And MDI_RestoreFrameMenu removes the left most menu entry, in belief is the document icon of a maximized child. What is the reason for restoring the old code? Does the new code break some apps? The attached patch, which reverts a part of the revert "fixes" the problem for my test app(ollydbg) But i guess it is totally wrong :-) > > this patch restores (almost completely) an old WM_SIZE handler in mdi child, > including the comment /* do not change */. > > Changelog: > user32: Restore old WM_SIZE handler in mdi child. > Greetings Peter

2 1

Re: comctl32/tests/updown failures on xp?
by Dan Kegel Jan. 21, 2007

Jan. 21, 2007

On 1/19/07, James Hawkins <truiken(a)gmail.com> wrote: > It sounds like your build environment isn't set up correctly. The > easiest way to work on and compile the tests is to run > wine/tools/winapi/msvcmaker under cygwin in Windows. This will create > several project files, one for each dll etc, and a winetest project > that can be opened with Visual C++ (and converted to a solution). Nah, I prefer bare metal commandline. I like knowing what's going on under the hood. > No matter which method you use to compile the tests, you should have the > latest Windows SDK installed (not the Platform SDK, which the Windows > SDK is replacing). OK, I'll try that... > If you run 'make test', you shouldn't see the errors > (because they're wrapped by todo_wine). Whoops, forgot about that! When running without 'make test', you have to set the environment variable WINETEST_PLATFORM=wine on wine for the todo_wine to work. Thanks! - Dan

2 1

WINSPOOL_EnumPrinters Found 0 printers on system with 1 parallel CUPS printer
by Michael [Plouj] Ploujnikov Jan. 21, 2007

Jan. 21, 2007

Hi, I'm sending this message to both wine-users and wine-devel in hopes of getting help from someone with knowledge of Wine's internals. I've had this problem for a while, but only recently have I realized that I better fix it soon! I compile my own Wine out of git. Currently, I'm running wine-0.9.29-g5441536 but this issue appeared long before that. Moreover, I stopped being able to print between Wine updates, so I don't think it is anything to do with changes in Wine's code. The simplest way to reproduce my problem is try printing in notepad. First, I open notepad: $ WINEDEBUG=+winspool wine notepad trace:winspool:WINSPOOL_EnumPrinters Found 0 printers trace:winspool:WINSPOOL_EnumPrinters Found 0 printers Next, I type some text. Then I go to "File -> Printer Setup". Wine outputs this to the console: trace:winspool:WINSPOOL_EnumPrinters Found 0 printers fixme:winspool:WINSPOOL_EnumPrinters We don't handle PRINTER_ENUM_CONNECTIONS and I see a message box saying: "Before you can perform printer-related tasks such as page setup or printing a document, you need to install a printer. Please install one and retry." I've tried deleting and re-creating my ~/.wine multiple times. I know that wine is compiled with CUPS support $ ~/apps/wine-git/configure --x-libraries=/emul/linux/x86/usr/lib/ LDFLAGS="-L/emul/linux/x86/usr/lib -L/emul/linux/x86/lib" --without-libcapi20 --without-libhal --without-libicu --without-libldap --without-libsane > /tmp/wine-config $ grep -i cups /tmp/wine-config checking cups/cups.h usability... yes checking cups/cups.h presence... yes checking for cups/cups.h... yes checking for -lcups soname... libcups.so I have a local CUPS printer installed on my system: $ lpstat -t scheduler is running system default destination: HPDeskjet710c device for HPDeskjet710c: parallel:/dev/lp0 HPDeskjet710c accepting requests since Thu Jan 18 20:26:33 2007 printer HPDeskjet710c is idle. enabled since Thu Jan 18 20:26:33 2007 and I am able to print to it from other Linux applications. I considered tracing the winespool code ot see where it fails to find my printer, but it looks way too cryptic for my uninitiated eyes. Any help would be appreciated. -- Libre Software: http://www.gnu.org/philosophy/free-sw.html

3 2

Re: dbghelp: fix debuglink crash, accessing memory after munmap
by Eric Pouech Jan. 21, 2007

Jan. 21, 2007

Peter Oberndorfer a écrit : > Winedbg would crash on my system when trying to set a breakpoint (loading the debug info from a .debug file) > The problem is that hash_table_elt adds the symbols of the .debug file to the hashtable of the parent file. > But at the time elf_new_public_symbols is run, the sections of the .debug file are already unmapped. > In addition to that the symbols in .debug would be added 2 times (.so and .debug file) > > Changelog: > dbghelp: fix debuglink crash, accessing memory after munmap > I don't think it's the right fix IMO, we shouldn't call elf_new_public_symbols while processing the .gnu_link target, but in the parent call to elf_load_debug_from_map can you provide more information on the crash itself (which reference is lost to an unmapped section) A+

2 1

3DMark2000 regression
by Stefan Dösinger Jan. 21, 2007

Jan. 21, 2007

Hi Dmitry, Your "Do not play with WS_VISIBLE" patch(5ddac44dc2a6637613407fa900d3fafac37e70d8) in wined3d causes a regression with 3DMark2000. The rendering in this game is not visible. Readding the SWP_SHOWWINDOW flag to the SetWindowPos calls fixes the problem. But I have the impression that the main point of your patch was removing this flag, so I don't want to just add it again. What were the reasons for removing the SWP_SHOWWINDOW flag? Stefan

2 3

Questions concering an application I maintain
by Jacob Alberty Jan. 20, 2007

Jan. 20, 2007

I am a delphi developer (not limited to this language, I have done several projects in C, C#, as well as assembly but for the purposes of this email I am a delphi developer). I am experiencing some weirdness in regards to the richedit control in regards to database access (Specifically TDBRichEdit), Since I am a delphi developer using wine this means I have access to A) My programs source code, B) Delphis VCL source code (So i can view how delphi manages the richedit control which in this case is split up among 3 files) and C) The Wine source code. I have two questions 1) Since Delphi does not actually implement any of richedits features, merely wraps around them I should be in the clear to create a patch to wine to correct this functionality correct? and 2) What method is best to watch the api interaction going on in my application so I can see if wine is returning any weirdness that it shouldnt (do normal windows api spy programs work under wine?).

5 8

re: regression from 0.9.28 -> 0.9.29 breaks U.S. tax program
by Dan Kegel Jan. 20, 2007

Jan. 20, 2007

On 1/18/07, Tom Lowe <tomlowe1 at earthlink.net> wrote: > Using ubuntu 6.10 and wine packages from > http://wine.budgetdedicated.com/apt edgy main > > TaxACT 2006 ( free download from http://www.taxact.com ) works > "out-of-the-box" with 0.9.28. Checking for program updates and > electronic filing "hang" with 0.9.29. > > When 0.9.29 hung up on me, I removed it and re-installed 0.9.28 and was > able to connect and file my tax return. We had the same problem with Google Earth, and Rob Shearman kindly provided a fix: http://www.winehq.org/pipermail/wine-cvs/2007-January/029362.html Could be the same problem you hit. If so, it's already fixed in cvs. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 3

array out of bounds checking results
by Marcus Meissner Jan. 20, 2007

Jan. 20, 2007

Hi, Yesterdays TRUNK gcc features array overflow checking... I have run it against WINE and found 3 index overflows. arb_program_shader.c:950: Warnung: array subscript is above array bounds This is the place in C: } else if(GL_SUPPORT(GL_VERTEX_PROGRAM_ARB)) { and in preprocessed: } else if(((*gl_info).supported[0x8620] != 0)) { The supported array is way smaller than that. Likely a typo. winaspi32.c:239: Warnung: array subscript is above array bounds winaspi32.c:239: Warnung: array subscript is above array bounds This is this part: if (rqbuf[15]&0x8) { TRACE("Pointer at %d, bit %d\n",rqbuf[16]*256+rqbuf[17],rqbuf[15]&0x7); } rqbuf points to SenseArea which is only 16 byte. I am unclear what exactly is meant to be done here. We only ever copy 16 Byte into this array anyway. Ciao, Marcus

3 2

java problem with builtin msvcrt.dll (need debugging help)
by Stefan Leichter Jan. 20, 2007

Jan. 20, 2007

Hello, i found a problem with java (1.4.2_05) and builtin msvcrt.dll. The attached java code exhibits the problem. It produces an exception with builtin dll. As difference i identified the call to java._Java_java_io_WinNTFileSystem_getLength, what is basicaly a wrapper around msvcrt._(w)stati64. I have compared the result (dumped struct _stat) from _stati84 running with builtin and native version of msvcrt.dll. The result is the same. I tried winedbg, but i was not able to place a breakpoint neither in _Java_java_io_WinNTFileSystem_getLength nor msvcrt._stati64. Can someone please tell me either - how to place breakpoint in this functions or - suggest anopther way how to find the problem. The problem is independent of the emulated windows version. Thanks for help Stefan

2 1

Re: [Wine] www.winehq.com newsletter dead forever?
by Hiji Jan. 20, 2007

Jan. 20, 2007

The developer's list was talking about this a couple of weeks back. Somebody was going to take over and continue the newsletter, but nothing yet. ----- Original Message ---- From: Michal Seliga <michal.seliga(a)visicom.sk> To: wine-users(a)winehq.org Sent: Tuesday, January 16, 2007 10:14:31 AM Subject: [Wine] www.winehq.com newsletter dead forever? I know its like this for a long time, but i have to ask... what happened with Wine newsletter? it was interesting reading and now its gone there is no update since last wineconf.... _______________________________________________ wine-users mailing list wine-users(a)winehq.org http://www.winehq.org/mailman/listinfo/wine-users ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121

6 7

Greenville Revisited, A new look at FontForge
by Wierd_w Jan. 19, 2007

Jan. 19, 2007

OK, Due to the recent interest in Greenville, and the fact that enough time has passed that my original rage/disgust/contempt at freetype has faded, I decided to grab a recent Cygwin port of FontForge, and take a spin. FontForge is able to import the compiled glyphsets I produce with Fontlab(the expensive font tool) pretty neatly, and also seems to have fairly nice support for SBITs in outputted OTF and TTF files. This means I should be able (with hard work) to convert Greenville into a FontForge project file. However, the generated font will contain bitmaps of the glyphs for PPeM ranges 7-13, as the Type-1 hinting mechanisms inside FontForge are insufficient to cleanly hint the outlines for small point sizes. This will make the font files generated a tad bit 'large'. I will combat this as much as possible by using glyph composites as much as possible. (Basically aliasing to existant glyph outlines with new placement data- This not only improves consistancy of glyph shape, but also reduces the size of the outline glyphset. EG, one can make an "ü" by using the oderesis (The double dot accent) and the "u", and combining aliases of them into a new glyph. The same oderesis glyph can be used on any such accented glyph, and prevents it having to be drawn over and over again, reducing glyphset complexity, and thus filesize. So, pretty much all of Latin-A and Latin-B can be generated using a small set of diacriticals, and Latin-1, if you know what you are doing. :P It's like getting Latin-A and Latin-B for free.) I am comforted to read that FontForge's developer is also "unsatisfied" with the lack of 'quality' truetype instruction generation, and hope that he is able to someday include a real truetype hinter. In the meantime though, SBITs will have to do. (sigh) I still perfer FontLab for my typesetting needs, as it is more responsive on my host platform, and has better Unicode character reordering support (It understands the **FULL** Unicode range.), and a number of other features which I have grown fond of. However, the time I have available to work on it is very limited. I have to be available to assist students all day on Mondays and Wednesdays, and I take classes myself on Tuesdays, Thursdays, and Saturdays. This means that Fridays and Sundays are the only days I have available, and that time is difficult to budget. To try and improve my functional time on this hobby project, I need to get my laptop's battery serviced (as it is an old clunker, but still able to run both FontLab and FontForge+Cygwin) so I can work on it on my downtime at the NIAR building (which admittedly can be several hours a day. In fact, I am idling right now...), which will cost me around 90$. This will have to wait until my next bi-weekly pay deposit, as my disposable income is near 0$ right now, as a result of yet another tuition rate hike. (The university must think I am litterally made out of money....) I just wish there was a win32 native port of Fontforge, but I wont hold my breath. (I really, REALLY REALLY hate cygwin.) Status: I will have to begin re-examining the glyphs that the windows rasterizer returns for Tahoma at various point sizes in order to formulate suitable SBITs, but that will have to wait until after I have completed the glyphset to a degree that I consider at least serviceable. What unicode ranges, and or- codepages, would the WINEHQ community require of a Tahoma replacement? Ideally it would be all of them that MS Tahoma currently supports, but that would require me to draw characters that I have no functional knowledge of-- EG, Arabic, Cyrillic, Greek, and Hebrew characters. Arabic is the one that has me a bit worried, as if done wrong, the ligature substitution will be wonk, and I dont have the functional knowledge of how the language even works to produce such ligature substitution to begin with. Simmilar problem with Hebrew, but fewer glyphs to draw. I am currently shooting to have a full Latin-1, Latin-A, and Latin-B + Greek + Cyrillic glyphset before I start working on FontForge porting, and SBIT generation. I allready have Latin-1 and Latin-A complete (at least the glyphs that Tahoma supports), and am about 75% through Latin-B. I havent really touched Greek or Cyrillic yet. When completed though, it should support the US, Canada, and pretty much all of Europe. CJK ligatures, Arabic Ligatures, and Hebrew Ligatures would need to be done by people who are familiar with those glyphs, know what they mean, and how they are "Supposed" to look, as I consider myself unqualified to do them properly. I hope to have Greenville mostly functional (In North America and Europe) by that time, and to drop the fontforge project into WINEHQ custody, and see how it grows from there. Feedback would be greatly appreciated. ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

3 2

Re: Makefiles: Add a default BISONFLAGS variable for widl, wmc, wrc and wpp.
by Alexandre Julliard Jan. 19, 2007

Jan. 19, 2007

Robert Shearman <rob(a)codeweavers.com> writes: > I disagree. I had a resource file that had an error because I forgot > to define "IDC_STATIC" to a number and all I got from wrc was an > unhelpful "syntax error" that seemed to point to the wrong line. I > ended up using the debugging option to find out what was causing this > error. If you can suggest a better solution, I'd go for it. Well, I don't know, but I have never had to resort to the parser debugging code for that sort of thing. In worst cases looking at the preprocessed file is normally enough to find the problem. It's true that line numbers are sometimes off in wrc errors, and that should clearly be fixed; but the parser debug stuff is not something that should be exposed to users. Do you still have the file that shows an unhelpful error? You should file a bug with it, and I'll have a look. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: COMCTL32: Fix InitCommonControlsEx prototype
by Mike McCormack Jan. 19, 2007

Jan. 19, 2007

Thomas Weidenmueller wrote: > BOOL WINAPI > -InitCommonControlsEx (LPINITCOMMONCONTROLSEX lpInitCtrls) > +InitCommonControlsEx (const INITCOMMONCONTROLSEX *picce) The version of the Windows Platform SDK that I'm looking at agrees with Wine. There is also no reason to make a pointless change to the name of the argument, so this patch looks pointless and wrong to me. Mike

5 4

Re: [3/5] wined3d: Use SetupFullscreenWindow() to make the window fullscreen
by Stefan Dösinger Jan. 19, 2007

Jan. 19, 2007

Am Donnerstag 18 Januar 2007 23:41 schrieb H. Verbeet: > Changelog: > - Use SetupFullscreenWindow() to make the window fullscreen I do not think that SetupFullscreenWindow should stay publically exported from wined3d. I think it would be better if IWineD3DDevice_SetFullscreen calls it, and it is made sure that SetFullscreen is called when needed with a true / false flag. DDraw calls it already, and I think Init3D() calls it too for d3d8 and d3d9. Not sure about IWineD3DDevice_Reset.

2 1

Winelib over Solaris/SPARC
by keyur＠elegantmicroweb.com Jan. 19, 2007

Jan. 19, 2007

Thanks Eric and Mike for your in-sights. Your feedback has been helpful. Regards, Keyur

1 0

comctl32/tests/updown failures on xp?
by Dan Kegel Jan. 19, 2007

Jan. 19, 2007

While getting ready for cs130 (thanks to Lei and James for all the help), I tried building and running comctl32/tests/updown.c standalone on winxp using Visual C++ Express 2005 (the freely downloadable one) and the Platform SDK (also freely downloadable, needed for e.g. user32.lib and .h files). First I tried building it by starting cmd with the visual studio environment vars defined (using the handy Start/Programs/Visual C++/Visual Studio Tools/Visual Studio Command Prompt start menu entry installed by visual C++): cl -DSTANDALONE -D_X86_ -I../../../include updown.c user32.lib gdi32.lib comctl32.lib This failed to compile, complaining about redefinitions in rpc.h. I worked around that as suggested by Lei Zhang by avoiding letting cl see any of the Wine headers but wine/test.h, by doing mkdir wine copy ..\..\..\include\wine\test.h wine cl -DSTANDALONE -D_X86_ updown.c user32.lib gdi32.lib comctl32.lib This failed to compile, complaining about WM_QUERYVISTATE being undefined. I worked around that as suggested by Lei Zhang by defining _WIN32_WINNT to the right value: cl -DSTANDALONE -D_X86_ -D_WIN32_WINNT=0x502 updown.c user32.lib gdi32.lib comctl32.lib That failed to link, complaining it couldn't find user32.lib. I worked around that by doing echo setenv LIB=%LIB% > setenv.bat editing that batch file to append ;C:\Program Files\Microsoft Platform SDK\Lib and running it. That worked (whew), but running the test found two failures: updown.c:509: Test failed: create parent window: the msg 0x0281 was expected, but got msg 0x0007 instead updown.c:522: Test failed: add updown control with edit: in msg 0x0005 expecting lParam 0x4b005b got 0x440065 updown: 133 tests executed (0 marked as todo, 2 failures), 0 skipped. I guess it needs a bit of tweaking. The system I tested it on is running Win XP Professional Version 2002 Service Pack 2. - Dan

2 2

user32/tests: Mysterious WinXP 0xae and 0xef messages.
by Kirill K. Smirnov Jan. 19, 2007

Jan. 19, 2007

Hi! While improving rejected tests for WM_SETICON: http://www.winehq.org/pipermail/wine-patches/2007-January/034949.html I've noticed, that WinXP sends some mysterious message 0xae, that breaks tests. Googling it, I've found few notes indicating to WM_NCUAHDRAWCAPTION [0xae] message and WM_NCUAHDRAWFRAME[0xaf]. [http://www.werkema.com/ blog/index.php?op=Default&Date=200503&blogId=1] As I understood it, these messages are used to paint WINXP-specific fancy borders and captions. But MSDN shows absolutely absence of any knowledge concerning it. AFAIK wine does not support them too. Should these messages be implemented? Or at least add mnemonics to winuser.h? Anyway, how those tests should be modified to pass under XP and other versions? Thanks, Kirill

2 1

regression from 0.9.28 -> 0.9.29 breaks U.S. tax program
by Tom Lowe Jan. 19, 2007

Jan. 19, 2007

Using ubuntu 6.10 and wine packages from http://wine.budgetdedicated.com/apt edgy main TaxACT 2006 ( free download from http://www.taxact.com ) works "out-of-the-box" with 0.9.28. Checking for program updates and electronic filing "hang" with 0.9.29. When 0.9.29 hung up on me, I removed it and re-installed 0.9.28 and was able to connect and file my tax return. It has been accepted by IRS. -- Tom Lowe

2 1

iphlpapi - MacOS / BSD support
by Juan Lang Jan. 18, 2007

Jan. 18, 2007

Hi Gav, > As the iphlpapi DLL is LGPLed, our patches to it are necessarily under > the LGPL as well. In fact that's not true. I added the LGPL headers for inclusion into WineHQ, but I said my patches were MIT/X11 (unless I say otherwise, which I didn't say, but I suppose is implied): http://www.winehq.org/pipermail/wine-patches/2003-May/006174.html Thanks, --Juan ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html

2 1

File buffering
by Teemu Ikonen Jan. 18, 2007

Jan. 18, 2007

Hi, I have a Visual Fortran application which exhibits problems related to concurrency and file buffer flushing when run under wine (it works under all versions of windows). The program does essentially this: opens a file writes to it closes it forks another program to read the file just written deletes the file in the original process Under wine, the forked program does not find the file just written. If I run the program under winedbg and set a breakpoint somewhere between writing and deletion, the buffers are flushed when the breakpoint is reached, and the program works as it does under windows. To my mind this would indicate that windows flushes all open buffers before forking a new process (the api call I see in wine debug output is CreateProcessW). Would it make sense to add flush-calls to the wine implementation as well? I tried to make the program work by adding calls to the Fortran subroutine FLUSH between closing and forking, but somewhat surprisingly, that didn't help. Teemu

3 3

[1/4] D3D9: Implement IDirect3DDevice9::StretchRect
by Christoph Bumiller Jan. 18, 2007

Jan. 18, 2007

This also (partially) fixes the issue with NFS:MW where nothing except the menus appears to be draw when setting the Visual Treatment option to high. The scene is now visible, but its scaled down in the y direction and only covers about the top 2/3 of the screen ...

1 0

Re: wined3d: Synchronize window style correcting code with ddraw
by H. Verbeet Jan. 18, 2007

Jan. 18, 2007

On 18/01/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Hello, > > this patch should fix the regression reported on #wine-hackers. > > Changelog: > wined3d: Synchronize window style correcting code with ddraw. > Although afaik there's nothing wrong with this patch, I do have a patch myself that moves the ddraw code for doing this to wined3d so that both use the same code.

1 0

Re: [PATCH 1/4] ntdll: Implement RtlEncode/DecodePointer
by Alexandre Julliard Jan. 18, 2007

Jan. 18, 2007

Mike McCormack <mike(a)codeweavers.com> writes: > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index 999687a..468e5b6 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -2161,6 +2161,7 @@ void WINAPI LdrInitializeThunk( ULONG unknown1, ULONG unknown2, ULONG unknown3, > > RtlEnterCriticalSection( &loader_section ); > > + rtl_generate_pointer_obfuscator(); > load_path = NtCurrentTeb()->Peb->ProcessParameters->DllPath.Buffer; > if ((status = fixup_imports( wm, load_path )) != STATUS_SUCCESS) goto error; > if ((status = alloc_process_tls()) != STATUS_SUCCESS) goto error; It would be cleaner to initialize this the first time it's needed, instead of having to export a global function and do more work at init time for a rarely used feature. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: invalidate button area instead of painting immediatly
by James Hawkins Jan. 18, 2007

Jan. 18, 2007

On 1/17/07, Clinton Stimpson <cjstimpson(a)utwire.net> wrote: > > WM_SETFONT on a button should invalidate the area so the system can send > a WM_PAINT event, instead of painting the button immediately. > This is a partial fix for bug# 6006. > The other part of the fix is for ShowWindow(button, SW_HIDE) to cause a > WM_PAINT event on the button's parent to paint in the newly exposed region. > > Thanks, > Clinton Stimpson > > ChangeLog: > user32: invalidate button area instead of painting button immediately. > Can you write a message test for this in dlls/user32/tests/msg.c to verify your fix? Thanks, James Hawkins

1 0

Re: [1/4] D3D9: Implement IDirect3DDevice9::StretchRect
by Mirek Jan. 18, 2007

Jan. 18, 2007

Hi, this patch caused big performance regression in some D3D games (Flatout 2, Tomb Raider: Legend, HalfLife 2: Episode One). Mirek Slugen Stefan Dösinger napsal(a): > This time with a FIXME for unsupported filtering options. If we implement > them, it should be done in Blt and private blitting flags used. > > > ------------------------------------------------------------------------ > > From 95f4217d366770b9b05214ae68274ce4ab4b9fb6 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Thu, 11 Jan 2007 22:39:03 +0100 > Subject: [PATCH] D3D9: Implement IDirect3DDevice9::StretchRect > > --- > dlls/d3d9/device.c | 10 +++++++--- > dlls/d3d9/directx.c | 3 +++ > dlls/wined3d/device.c | 9 --------- > include/wine/wined3d_interface.h | 2 -- > 4 files changed, 10 insertions(+), 14 deletions(-) > > diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c > index aa788af..4c27853 100644 > --- a/dlls/d3d9/device.c > +++ b/dlls/d3d9/device.c > @@ -356,9 +356,13 @@ static HRESULT WINAPI IDirect3DDevice9Impl_GetFrontBufferData(LPDIRECT3DDEVICE > } > > static HRESULT WINAPI IDirect3DDevice9Impl_StretchRect(LPDIRECT3DDEVICE9 iface, IDirect3DSurface9* pSourceSurface, CONST RECT* pSourceRect, IDirect3DSurface9* pDestSurface, CONST RECT* pDestRect, D3DTEXTUREFILTERTYPE Filter) { > - IDirect3DDevice9Impl *This = (IDirect3DDevice9Impl *)iface; > - TRACE("(%p) Relay\n" , This); > - return IWineD3DDevice_StretchRect(This->WineD3DDevice, ((IDirect3DSurface9Impl *)pSourceSurface)->wineD3DSurface, pSourceRect, ((IDirect3DSurface9Impl *)pDestSurface)->wineD3DSurface, pDestRect, (WINED3DTEXTUREFILTERTYPE) Filter); > + IDirect3DDevice9Impl *This = (IDirect3DDevice9Impl *)iface; > + IDirect3DSurface9Impl *src = (IDirect3DSurface9Impl *) pSourceSurface; > + IDirect3DSurface9Impl *dst = (IDirect3DSurface9Impl *) pDestSurface; > + > + TRACE("(%p)->(%p,%p,%p,%p,%d)\n" , This, src, pSourceRect, dst, pDestRect, Filter); > + if(Filter != D3DTEXF_NONE) ERR("Texture filters not supported yet\n"); > + return IWineD3DSurface_Blt(dst->wineD3DSurface, (RECT *) pDestRect, src->wineD3DSurface, (RECT *) pSourceRect, 0, NULL); > } > > static HRESULT WINAPI IDirect3DDevice9Impl_ColorFill(LPDIRECT3DDEVICE9 iface, IDirect3DSurface9* pSurface, CONST RECT* pRect, D3DCOLOR color) { > diff --git a/dlls/d3d9/directx.c b/dlls/d3d9/directx.c > index f360b4e..57062b2 100644 > --- a/dlls/d3d9/directx.c > +++ b/dlls/d3d9/directx.c > @@ -170,6 +170,9 @@ static HRESULT WINAPI IDirect3D9Impl_GetDeviceCaps(LPDIRECT3D9 iface, UINT Adapt > D3D9CAPSTOWINECAPS(pCaps, pWineCaps) > hrc = IWineD3D_GetDeviceCaps(This->WineD3D, Adapter, DeviceType, pWineCaps); > HeapFree(GetProcessHeap(), 0, pWineCaps); > + > + /* Some functionality is implemented in d3d9.dll, not wined3d.dll. Add the needed caps */ > + pCaps->Caps2 |= D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES; > TRACE("(%p) returning %p\n", This, pCaps); > return hrc; > } > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 7b81f0e..5f964fb 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4930,14 +4930,6 @@ static HRESULT WINAPI IWineD3DDeviceImpl_UpdateTexture (IWineD3DDevice *iface, I > return hr; > } > > -static HRESULT WINAPI IWineD3DDeviceImpl_StretchRect(IWineD3DDevice *iface, IWineD3DSurface *pSourceSurface, > - CONST RECT* pSourceRect, IWineD3DSurface *pDestinationSurface, > - CONST RECT* pDestRect, WINED3DTEXTUREFILTERTYPE Filter) { > - IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > - > - TRACE("(%p) : stub\n", This); > - return WINED3D_OK; > -} > static HRESULT WINAPI IWineD3DDeviceImpl_GetRenderTargetData(IWineD3DDevice *iface, IWineD3DSurface *pRenderTarget, IWineD3DSurface *pSurface) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > /** TODO: remove remove casts to IWineD3DSurfaceImpl * > @@ -6776,7 +6768,6 @@ const IWineD3DDeviceVtbl IWineD3DDevice_Vtbl = > IWineD3DDeviceImpl_ColorFill, > IWineD3DDeviceImpl_UpdateTexture, > IWineD3DDeviceImpl_UpdateSurface, > - IWineD3DDeviceImpl_StretchRect, > IWineD3DDeviceImpl_GetRenderTargetData, > IWineD3DDeviceImpl_GetFrontBufferData, > /*** object tracking ***/ > diff --git a/include/wine/wined3d_interface.h b/include/wine/wined3d_interface.h > index 8a685f0..4a24636 100644 > --- a/include/wine/wined3d_interface.h > +++ b/include/wine/wined3d_interface.h > @@ -469,7 +469,6 @@ DECLARE_INTERFACE_(IWineD3DDevice,IWineD3DBase) > STDMETHOD(ColorFill)(THIS_ struct IWineD3DSurface* pSurface, CONST WINED3DRECT* pRect, WINED3DCOLOR color) PURE; > STDMETHOD(UpdateTexture)(THIS_ struct IWineD3DBaseTexture *pSourceTexture, struct IWineD3DBaseTexture *pDestinationTexture) PURE; > STDMETHOD(UpdateSurface)(THIS_ struct IWineD3DSurface* pSourceSurface, CONST RECT* pSourceRect, struct IWineD3DSurface* pDestinationSurface, CONST POINT* pDestPoint) PURE; > - STDMETHOD(StretchRect)(THIS_ struct IWineD3DSurface* pSourceSurface, CONST RECT* pSourceRect, struct IWineD3DSurface* pDestinationSurface, CONST RECT* pDestRect, WINED3DTEXTUREFILTERTYPE Filter) PURE; > STDMETHOD(GetRenderTargetData)(THIS_ struct IWineD3DSurface* pRenderTarget, struct IWineD3DSurface* pSurface) PURE; > STDMETHOD(GetFrontBufferData)(THIS_ UINT iSwapChain,struct IWineD3DSurface* pSurface) PURE; > /*** object tracking ***/ > @@ -608,7 +607,6 @@ DECLARE_INTERFACE_(IWineD3DDevice,IWineD3DBase) > #define IWineD3DDevice_ColorFill(p,a,b,c) (p)->lpVtbl->ColorFill(p,a,b,c) > #define IWineD3DDevice_UpdateTexture(p,a,b) (p)->lpVtbl->UpdateTexture(p,a,b) > #define IWineD3DDevice_UpdateSurface(p,a,b,c,d) (p)->lpVtbl->UpdateSurface(p,a,b,c,d) > -#define IWineD3DDevice_StretchRect(p,a,b,c,d,e) (p)->lpVtbl->StretchRect(p,a,b,c,d,e) > #define IWineD3DDevice_GetRenderTargetData(p,a,b) (p)->lpVtbl->GetRenderTargetData(p,a,b) > #define IWineD3DDevice_GetFrontBufferData(p,a,b) (p)->lpVtbl->GetFrontBufferData(p,a,b) > #define IWineD3DDevice_ResourceReleased(p,a) (p)->lpVtbl->ResourceReleased(p,a) > > > ------------------------------------------------------------------------ > >

3 2