September 2009 - wine-devel

Re: ddraw: complete recognition of pixelformat 19: X8L8V8U8
by Stefan Dösinger 14 Sep '09

14 Sep '09

Am Monday 14 September 2009 17:28:13 schrieb Joerg-Cyril.Hoehle(a)t-systems.com: > Hi, > > the argument for including this code is based on symmetry: Every place in > the Wine source tree (incl. ddraw, d3d9, wined3d) that handles L6V5U5 also > handles X8L8V8U8 -- except for these two places. So I closed the gap. > > This fixes > err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 19 > Please see bug #16559 for further discussion. > > Being based on the symmetry argument means this patch is completely > independent on possible missing conversions between D3DFMT and WINED3DFMT > codes somewhere in Wine. I would not eliminate that possibility. The above > error message that used to mention Pixelformats 62/63/64 nowadays mentions > 19/64/69/70. > > Regards, > Jörg Höhle The patch seems ok to me

1 0

Re: ntdll: Do not accept device control requests with invalid and/or incompatible handles
by Alexandre Julliard 14 Sep '09

14 Sep '09

Peter Dons Tychsen <donpedro(a)tdcadsl.dk> writes: > +static void test_device_control(void) > +{ > + IO_STATUS_BLOCK io; > + NTSTATUS status; > + > + /* Try using a bugus handle for I/O control */ > + HANDLE handle = (HANDLE)0xdeadbeef; > + status = pNtDeviceIoControlFile(handle, NULL, NULL, NULL, &io, IOCTL_SERIAL_SET_BAUD_RATE, NULL, 0, NULL, 0); > + ok(status == STATUS_INVALID_HANDLE, "Expected %08X, got %08X\n", STATUS_INVALID_HANDLE, status); > + > + /* Try using an valid (but wrong) handle for I/O control */ > + handle = GetStdHandle(STD_INPUT_HANDLE); > + status = pNtDeviceIoControlFile(handle, NULL, NULL, NULL, &io, IOCTL_SERIAL_SET_BAUD_RATE, NULL, 0, NULL, 0); > + ok(status == STATUS_INVALID_HANDLE, "Expected %08X, got %08X\n", STATUS_INVALID_HANDLE, status); GetStdHandle returns a console handle which is not a valid ntdll handle, so you are not testing what you think. -- Alexandre Julliard julliard(a)winehq.org

3 5

Re: Is Wine printing on MacOSX?
by Joerg-Cyril.Hoehle＠t-systems.com 14 Sep '09

14 Sep '09

Hi, Stefan Dösinger wrote: >>All that happened [with notepad] is that the printer ejected a blank page. >Printing from notepad works fine for me on both Linux and OSX, fwiw Saving to file instead of printing, notepad generated a .ps file. Reading this into Apple's preview shows the text. Converting to pdf, then viewing also shows the text. Printing this prints a blank page! So either Apple does not like the PS generated by Wine, or only the printer, or that's a problem with fonts or whatever else. I'm using a PPC driver for an old Lexmark Z33 printer that prints documents from TextEdit and Safari perfectly. I still need to test a wine application other than notepad. BTW, the page footer says "Page &p": &p is not substituted by notepad. Is this a known bug in notepad or Wine's printer driver? Regards, Jörg Höhle.

1 0

Re: [3/5] comctl32/dpa: Implement DPA_SaveStream() with tests
by Vitaliy Margolen 14 Sep '09

14 Sep '09

Nikolay Sivov wrote: > Changelog: > - Implement DPA_SaveStream() with tests > > + streamData.dwSize = curr_pos.QuadPart - initial_pos.QuadPart; > + streamData.dwData2 = 1; > + streamData.dwItems = streamInfo.iPos;// + 1; c++ comment. > +#if 0 > + /* crashes on XP */ > + hRes = pDPA_SaveStream(NULL, CB_Save, pStm, NULL); > + expect(E_INVALIDARG, hRes); > + > + hRes = pDPA_SaveStream(dpa, CB_Save, NULL, NULL); > + expect(E_INVALIDARG, hRes); > +#endif Don't use #if 0 / #endif in tests. Use if (0){} instead. This will guarantee that code will still compile. Vitaliy.

2 1

Re: include: Add missing definitions in af_irda.h. (try 2)
by Alexandre Julliard 13 Sep '09

13 Sep '09

Thomas Trummer <th.trummer(a)gmail.com> writes: > @@ -97,4 +100,159 @@ typedef struct _SOCKADDR_IRDA > #define LmCharSetISO_8859_9 0x09 > #define LmCharSetUNICODE 0xff > > +#define SIO_LAZY_DISCOVERY _IOR('t', 127, ULONG) > + > +#define WINDOWS_AF_IRDA 26 > +#define WINDOWS_PF_IRDA WINDOWS_AF_IRDA > + > +#define WCE_AF_IRDA 22 > +#define WCE_PF_IRDA WCE_AF_IRDA > + > +#ifndef AF_IRDA > +#define AF_IRDA WINDOWS_AF_IRDA > +#endif > + > +#ifndef PF_IRDA > +#define PF_IRDA AF_IRDA > +#endif > + > +#define IRDA_PROTO_SOCK_STREAM 1 You need a WS prefix on all definitions that can conflict with Unix. -- Alexandre Julliard julliard(a)winehq.org

4 4

Sept 11 with tools and tests removed
by chris ahrendt 13 Sep '09

13 Sep '09

Here is the run for Friday Sept. 11 with the tools and the tests directory results removed. [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 Chris

6 11

Re: wined3d: Add Intel GMA 4500MHD
by Stefan Dösinger 13 Sep '09

13 Sep '09

Am Sunday 13 September 2009 08:15:19 schrieb Jaime Rave: > More information about Intel cards: > http://en.wikipedia.org/wiki/Intel_GMA#Table_of_GMA_graphics_cores_and_chip >sets + || strstr(gl_renderer, "Intel®")) I don't know if it is safe check for the ®. I think its not part of the standard ASCII character set, so there might be codepage issues. I don't think its necessary to check for it anyway, I think "Intel" is good enough. (In which case we might change the "Intel(R)" and "Intel Inc." checks as well) + if (strstr(gl_renderer, "GM45")) + { + /* GMA 4500MHD. These can take up to 2048MB */ + *vidmem = 512; + return CARD_INTEL_GM45; + } + You are adding trailing whitespace in the last line(I think Alexandre's commit scripts fiter that out though)

1 0

Re: wined3d: Add Intel GMA 4500MHD
by Roderick Colenbrander 13 Sep '09

13 Sep '09

Just one minor thing make sure the right email address is configured in your git repository, so that the correct email address is set in the patch Roderick On Sun, Sep 13, 2009 at 8:15 AM, Jaime Rave <jaimerave(a)ubuntu-co.com> wrote: > More information about Intel > cards: http://en.wikipedia.org/wiki/Intel_GMA#Table_of_GMA_graphics_cores_and_chip… > > > >

1 0

Re: [ntdll] Add test for NtQueryDirectoryFile [try 2]
by James McKenzie 13 Sep '09

13 Sep '09

Dan Kegel wrote: > Here's the next broken-out test patch from the series that > implements support for hidden and system attributes. > This one just adds a test for NtQueryDirectoryFile(). > It passes for me on Wine and Vista Home Basic. > > Changes since first try: > 1) fixed issues Paul found (wasn't setting hidden attribute, wasn't > cleaning up on failure) > 2) actually test reported file attributes > Dan: It looks like your original patch was approved by AJ in commit 398a8ea1fec599cfd6442e3b8bba620431cf53b7 You might want to run a diff against the current git. James McKenzie

2 1

Re: DDraw: Add a few missing WINAPIs
by Henri Verbeet 12 Sep '09

12 Sep '09

2009/9/12 Stefan Dösinger <stefan(a)codeweavers.com>: > I wonder how this worked in the past, and why the compiler didn't complain. It's pretty simple really, these functions don't need WINAPI because they're ddraw internal functions "cleverly" disguised as vtable methods. IIRC it's actually harmful to add WINAPI to these on OS X due to some obscure compiler bug.

2 1

re: fixing ReadDirectoryChangesW()
by Dan Kegel 12 Sep '09

12 Sep '09

Michael Pujos wrote: > I'm willing to resubmit this patch with updated tests > against current Wine, but before I procceed > I need to be sure it won't be rejected simply because it changes the protocol. Server changes are tricky to get in. You have to be patient and persistent. I think your best next move is to file a bug describing the problem (and give the URL for the app it affects for you, if possible), and submit just the tests first (with appropriate todo_wine lines where wine gets it wrong currently). All that is useful, and a good first step towards getting the bug fixed. Thanks! - Dan

3 2

Re: DDraw: Add a few missing WINAPIs
by Stefan Dösinger 12 Sep '09

12 Sep '09

Am Saturday 12 September 2009 23:41:00 schrieb Stefan Dösinger: > Am Saturday 12 September 2009 23:25:56 schrieb Stefan Dösinger: > > Oops: forgot the patch: Er, never mind that patch - those functions aren't used directly in the vtable. There are the FPUSetup and FPUPreserve wrappers around them, so the default calling convention is ok.

1 0

RE: Help with a native Windows test program needed (CreateFileW).
by Markus Stockhausen 12 Sep '09

12 Sep '09

Sorry for the the wrong feedback. As I have limited possibilites creating executables on Windows I relied on Thomas executable for the tests. Maybe you can post a corrected version. It is not my intention to confuse someone. Im just trying to narrow down my initial analysis. The last write access to the malicous memory address before the application dump comes from CreateFileW. Best regards. -------- Weitergeleitete Nachricht -------- Von: wine-bugs(a)winehq.org An: mst(a)collogia.de Betreff: [Bug 9575] IBExpert need windows native ole32.dll to run Datum: Sat, 12 Sep 2009 05:18:49 -0500 http://bugs.winehq.org/show_bug.cgi?id=9575 --- Comment #15 from Alexandre Julliard <julliard(a)winehq.org> 2009-09-12 05:18:42 --- There's no such behavior. The test is broken.

2 5

Re: [ntdll] Add test for NtQueryDirectoryFile
by Paul Vriens 12 Sep '09

12 Sep '09

On 09/12/2009 02:18 AM, Dan Kegel wrote: > Here's the next broken-out test patch from the series that > implements support for hidden and system attributes. > This one just adds a test for NtQueryDirectoryFile(). > It passes for me on Wine and Vista Home Basic. > > [Paul, could you test it on your box to make sure it's ok there?] Hi Dan, No failures on my NT4+ boxes (32bit). One thing I noticed is that you don't cleanup in some of the failure cases which would leave that temporary directory around. -- Cheers, Paul.

1 2

Help with a native Windows test program needed (CreateFileW).
by Markus Stockhausen 12 Sep '09

12 Sep '09

Hi, as I have no Windows machine and cannot test this. I'm in need for someone who can build a small exe that gives further hints to my observations in bug #9575. The following is needed: call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) Return the result of second call. I expect it to be a valid handle on Windows whereas Wine will return an invalid handle. Thanks in advance. Markus

2 3

RE: Help with a native Windows test program needed (CreateFileW)
by Greg Geldorp 11 Sep '09

11 Sep '09

Hi Markus, > From: Markus Stockhausen <markus.stockhausen(a)collogia.de> > > as I have no Windows machine and cannot test this: I'm in need for > someone who can build a small exe that gives further hints to my > observations in bug #9575. The following is needed: > > call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) > call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) > > Return the result of second call. I expect it to be a valid handle on > Windows whereas Wine will return an invalid handle. This test program: int main(int argc, char *argv[]) { HANDLE File1, File2; File1 = CreateFileW(L"test.dat", GENERIC_READ, 0, NULL, CREATE_ALWAYS, 0, NULL); File2 = CreateFileW(L"test.dat", GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL); printf("File1 0x%x File2 0x%x error %u\n", File1, File2, GetLastError()); return 0; } returns this result on Windows 2008: File1 0x10 File2 0xffffffff error 32 so the second CreateFile fails on Windows too, with ERROR_SHARING_VIOLATION. Ge.

1 0

RFC: registry keys of serial ports
by Stefan Leichter 11 Sep '09

11 Sep '09

Hi, i like to know what modifikations the attached patch needs to go into git. More things need to be done in this area. I know of: - more registry keys [1] - remove the registry keys when a serial port disappears (USB) - the links in the dosdevice directory needs to be created Patches for the items above will be created, when the current patch went into git References: 1 http://www.winehq.org/pipermail/wine-patches/2009-April/071999.html - http://www.winehq.org/pipermail/wine-devel/2009-April/074476.html -- Stefan

3 5

Help with a native Windows test program needed (CreateFileW)
by Markus Stockhausen 11 Sep '09

11 Sep '09

Hi, as I have no Windows machine and cannot test this: I'm in need for someone who can build a small exe that gives further hints to my observations in bug #9575. The following is needed: call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) Return the result of second call. I expect it to be a valid handle on Windows whereas Wine will return an invalid handle. Thanks in advance. Markus

2 1

fixing ReadDirectoryChangesW()
by Michael Pujos 11 Sep '09

11 Sep '09

A few months ago I wrote a patch that addressed the following issues with ReadDirectoryChangesW(): "1. move and rename of files and directories in a monitored directory are not notified 2. the current implementation allow to only get one change (FILE_NOTIFY_INFORMATION structure) at a time. No change is actually lost but the calling application using ReadDirectoryChangesW() expect to retrieve all changes since the last call. With the current implementation it would only get the first and would have to call ReadDirectoryChangesW() again to get the other. With this patch , it gets all notification (as many consecutive FILE_NOTIFY_INFORMATION structs) since the last call to ReadDirectoryChangesW(). These move operations are implemented by this patch and conform to what win32 does: - Moving a directory or a file inside the monitored directory. A FILE_NOTIFY_INFORMATION structure with action FILE_ACTION_ADDED is returned - Moving a directory or a file out of the monitored directory. A FILE_NOTIFY_INFORMATION structure with action FILE_ACTION_REMOVED is returned - Renaming a directory or a file in the monitored directory. Two consecutive FILE_NOTIFY_INFORMATION structures with actions FILE_ACTION_RENAMED_OLD_NAME and FILE_ACTION_RENAMED_NEW_NAME are returned within the same reply. This can actually be done because issue 2 above is corrected." This old patch can be found here: http://bubbleguuum.free.fr/0001-server-implement-move-rename-change-notific… This patch modify the server protocol in server_protocol.h from struct read_change_reply { struct reply_header __header; int action; /* VARARG(name,string); */ }; to: struct read_change_reply { struct reply_header __header; int action_count; /* VARARG(name,string); */ }; I'm willing to resubmit this patch with updated tests against current Wine, but before I procceed I need to be sure it won't be rejected simply because it changes the protocol.

1 0

Re: [PATCH 2/4] mshtml: Added http loading test.
by Paul Vriens 11 Sep '09

11 Sep '09

On 09/02/2009 12:27 PM, Jacek Caban wrote: > --- > dlls/mshtml/tests/htmldoc.c | 270 > +++++++++++++++++++++++++++++-------------- > 1 files changed, 182 insertions(+), 88 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi Jacek, Looks like this one introduced 2 test failures on some boxes, I couldn't find a common denominator though. The failures happen on IE6, IE7 and IE8 on different platforms (NT4 and higher). There are however also IE8 boxes without failures. The failures seem to be triggered by the "test_download(FALSE, FALSE, FALSE);" on line 4026. Could you have a look? (Some other failures happen on ME and lower but I'll investigate those). -- Cheers, Paul.

2 1

Re: [ntdll] Add tests for NtQueryInformationFile
by Paul Vriens 11 Sep '09

11 Sep '09

On 09/09/2009 02:41 PM, Dan Kegel wrote: > Alexandre said I should break up the big xattr patch, > so here are just the NtQueryInformationFile tests, > improved a bit. Once these are in I'll submit the > NtQueryDirectoryFile tests. > > Passes on both Wine and Vista. > > > ------------------------------------------------------------------------ > > Hi Dan, This patch introduces some issues on NT4 and higher. Attached patch fixes it but I'm not sure if you are already chasing these failures. Weird that it doesn't fail on your Vista box. That remark "whoops, vista doesn't implement this one?\n" should probably be changed. It also looks like Vista/Win7 has either 2 or 4 failures (most likely related to indexing being disabled, if so that could also happen on other platforms). Not sure if we should explicitly check for attributes being 2020, ignore FILE_ATTRIBUTE_NOT_CONTENT_INDEXED or just check as I did. -- Cheers, Paul.

2 4

Mirror Space
by Marty Cannon 11 Sep '09

11 Sep '09

Hey guys, Since the wine.budgetdedicated.com server was down all weekend, I thought I'd offer an additional mirror location. I currently mirror several major linux distributions, and would love to contribute to something as valuable to the community as the wine project is. My site currently runs around 3500GB per month, so a few hundred GB worth of transfer shouldn't make much difference. I've never set up an apt mirror, but with some instruction and googling, I bet I can do it. At the very least, I can mirror the package archive just incase the main site goes down. Let me know how I can help. -Marty Cannon amarillolinux.com

6 12

Fixing the user32/dde tests on Win9x/WinMe
by Paul Vriens 11 Sep '09

11 Sep '09

Hi, DdeInitializeW is not implemented on the mentioned platforms but it's not just a matter of skipping some tests when that W-function is found to be not implemented. Any idea what the best way would be to fix these tests? -- Cheers, Paul.

1 0

Re: bitblt.c - GdiAlphaBlend : Check for NULL Pointer
by Roderick Colenbrander 11 Sep '09

11 Sep '09

Recently Nikolay Sivov wrote some tests for this call. His tests didn't make it in yet but I think those should enter and then based on those results changes should be made. Roderick On Thu, Sep 10, 2009 at 10:56 PM, Markus Stockhausen <markus.stockhausen(a)collogia.de> wrote: > Hi, > > http://bugs.winehq.org/show_bug.cgi?id=18041 reveals a bug where > GdiAlphaBlend will crash in Teamviewer application when a NULL pointer > is handed over. The attached check fixes that behaviour. > > Tanks in advance. > > Markus > > > > >

4 7

Status of LoadLibrary and .so
by Joe Dluzen 11 Sep '09

11 Sep '09

Hi all, back a few years ago it didn't: http://www.winehq.org/pipermail/wine-devel/2003-July/018498.html Does anyone know of the status of LoadLibrary and a .so? Can it load directly or is there a workaround that does not involve multiple processes and some sort of IPC? thanks, Joe

3 2

Wineconf drumbeat - don't sleep on the streets!
by Jeremy White 11 Sep '09

11 Sep '09

Hi Folks, It's now close enough to November that you can't blow this email off <grin>. We've got all the info here: http://wiki.winehq.org/WineConf2009 Our challenge this year is that we're managing the booking, so we need a firm head count ahead of time. Again, if money is an issue, and you haven't already, please contact me privately. So if you're thinking of coming, email Hans. Now. Please. Failure to do so may result in your sleeping on the streets of Enschede *grin*. Cheers, Jeremy

2 2

Re: [2/4] WineD3D: Make context_attach_surface_fbo srgb aware
by Henri Verbeet 10 Sep '09

10 Sep '09

2009/9/10 Stefan Dösinger <stefan(a)codeweavers.com>: > @@ -402,7 +433,7 @@ static void context_apply_fbo_entry(struct wined3d_context *context, struct fbo_ > for (i = 0; i < GL_LIMITS(buffers); ++i) > { > IWineD3DSurface *render_target = device->render_targets[i]; > - context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, i, render_target); > + context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, i, render_target, SRGB_ANY); > } > > /* Apply depth targets */ I don't think SRGB_ANY is correct here. context_apply_fbo_entry() very much cares about which texture is attached to the FBO. If rendering to sRGB textures was supported properly this would depend on the sRGB write state, but since it isn't this should aways be SRGB_RGB. > @@ -2041,7 +2072,7 @@ struct wined3d_context *ActivateContext(IWineD3DDeviceImpl *This, IWineD3DSurfac > FIXME("Activating for CTXUSAGE_BLIT for an offscreen target with ORM_FBO. This should be avoided.\n"); > ENTER_GL(); > context_bind_fbo(context, GL_FRAMEBUFFER_EXT, &context->dst_fbo); > - context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, target); > + context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, target, SRGB_ANY); > context_attach_depth_stencil_fbo(context, GL_FRAMEBUFFER_EXT, NULL, FALSE); > LEAVE_GL(); > } else { Similar to above. > @@ -6045,7 +6045,7 @@ static void color_fill_fbo(IWineD3DDevice *iface, IWineD3DSurface *surface, > context = ActivateContext(This, NULL, CTXUSAGE_RESOURCELOAD); > ENTER_GL(); > context_bind_fbo(context, GL_FRAMEBUFFER_EXT, &context->dst_fbo); > - context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, surface); > + context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, surface, SRGB_ANY); > context_attach_depth_stencil_fbo(context, GL_FRAMEBUFFER_EXT, NULL, FALSE); > } Afaik color fill colors are specified in RGB space. Unless you have a test that shows otherwise, this should be SRGB_RGB. > @@ -6463,7 +6463,7 @@ void stretch_rect_fbo(IWineD3DDevice *iface, IWineD3DSurface *src_surface, WINED > TRACE("Source surface %p is offscreen\n", src_surface); > ENTER_GL(); > context_bind_fbo(context, GL_READ_FRAMEBUFFER_EXT, &context->src_fbo); > - context_attach_surface_fbo(context, GL_READ_FRAMEBUFFER_EXT, 0, src_surface); > + context_attach_surface_fbo(context, GL_READ_FRAMEBUFFER_EXT, 0, src_surface, SRGB_ANY); > glReadBuffer(GL_COLOR_ATTACHMENT0_EXT); > checkGLcall("glReadBuffer()"); > context_attach_depth_stencil_fbo(context, GL_READ_FRAMEBUFFER_EXT, NULL, FALSE); > @@ -6503,7 +6503,7 @@ void stretch_rect_fbo(IWineD3DDevice *iface, IWineD3DSurface *src_surface, WINED > > ENTER_GL(); > context_bind_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, &context->dst_fbo); > - context_attach_surface_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, 0, dst_surface); > + context_attach_surface_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, 0, dst_surface, SRGB_ANY); > glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT); > checkGLcall("glDrawBuffer()"); > context_attach_depth_stencil_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, NULL, FALSE); This doesn't work either. While it probably doesn't matter if the blit is done in RGB or sRGB space, it still needs to be the same color space for both surfaces (and one of those can be onscreen). On a higher level, I'm not really happy with how sRGB textures currently fit in and how that's starting to spread to everything that has to deal with surfaces.

2 1

Re: [3/4] WineD3D: Perform the srgb copy with fbo_blit if possible
by Henri Verbeet 10 Sep '09

10 Sep '09

2009/9/10 Stefan Dösinger <stefan(a)codeweavers.com>: > + if (context->current_fbo) { > + context_bind_fbo(context, GL_FRAMEBUFFER_EXT, &context->current_fbo->id); > + } else { > + context_bind_fbo(context, GL_FRAMEBUFFER_EXT, NULL); > + } This shouldn't be needed. > + /* Need FBOs obviously */ > + if(wined3d_settings.offscreen_rendering_mode != ORM_FBO) return FALSE; > + /* Need framebuffer blit */ > + if(!GL_SUPPORT(EXT_FRAMEBUFFER_BLIT)) return FALSE; > + /* Need to be able to attach both RGB and sRGB copy */ > + if((fmt_flags & attach_flags) != attach_flags) return FALSE; > + /* Need to be able to blit from and to my format */ > + if(!surface_can_stretch_rect(This, This)) return FALSE; > + /* Need either RGB or sRGB copy up to date */ > + if((This->Flags & (SFLAG_INSRGBTEX | SFLAG_INTEXTURE)) == 0) return FALSE;That's redundant, Some of those are redundant. A format is never FBO attachable if FBOs are disabled, surface_can_stretch_rect() will already check for regular attachment.

1 0

Re: bitblt.c - GdiAlphaBlend : Check for NULL Pointer
by Paul Vriens 10 Sep '09

10 Sep '09

On 09/10/2009 10:56 PM, Markus Stockhausen wrote: > Hi, > > http://bugs.winehq.org/show_bug.cgi?id=18041 reveals a bug where > GdiAlphaBlend will crash in Teamviewer application when a NULL pointer > is handed over. The attached check fixes that behaviour. > > Tanks in advance. > > Markus > > > > ------------------------------------------------------------------------ > > No comments on the validity of the patch but you should add a test for this to the conformance tests. If you are bailing out when dcSrc == NULL then the other checks in that function for dcSrc are not necessary anymore. -- Cheers, Paul.

1 0

Re: winehq: Fix some HTML markup
by Jeremy Newman 10 Sep '09

10 Sep '09

The reason I left the XHTML markup in was eventually the goal was to convert the entire website to XHTML. The only issue with leaving them in while still in HTML4/Transitional is that the pages do not pass W3C validation. I am still willing to live with non-valid working HTML to save some work down the road. -N André Hentschel wrote: > --- > templates/de/about.template | 2 +- > templates/de/contributing.template | 8 +++--- > templates/de/download.template | 10 +++--- > templates/de/help.template | 16 ++++++------ > templates/en/about.template | 2 +- > templates/en/contributing.template | 8 +++--- > templates/en/documentation.template | 48 +++++++++++++++++----------------- > templates/en/download.template | 10 +++--- > templates/en/help.template | 16 ++++++------ > templates/fr/about.template | 2 +- > templates/pl/about.template | 2 +- > templates/pl/download.template | 10 +++--- > templates/pl/help.template | 16 ++++++------ > templates/pt/about.template | 2 +- > templates/pt/contributing.template | 8 +++--- > 15 files changed, 80 insertions(+), 80 deletions(-) > > > > > > ------------------------------------------------------------------------ > >

3 3

Asynchronus serial port
by Fenixk19 10 Sep '09

10 Sep '09

Hello! I've already post the bug(http://bugs.winehq.org/show_bug.cgi?id=19713) on this subject, but i need more help. So I've decided to write here. There is a problem in wine. When I use asynchronous serial port read, data never comes. Event, caused by select comes. But operation status stays pending, and i can't do anything to this serial port anymore. In windows it never get pending, and port can be accessed just after data arrival. Seems to be wineserver problem, but i don't know, where to look at. What code respond for asynchronous serial port in wineserver? Alexander. P.S. Test program attached.

4 4

Re: [PATCH 12/12] openal32: fixed ctx null ptr debug (Coverity)
by Chris Robinson 10 Sep '09

10 Sep '09

I have a different patch that will fix this, that also fixes a problem with error states.

1 0

Re: server: Use kernel support for thread affinity when available
by Chris Robinson 10 Sep '09

10 Sep '09

On Thursday 10 September 2009 9:43:02 am Juan Lang wrote: > +/* Define to 1 if you have the `sched_getaffinity' function. */ > +#undef HAVE_SCHED_GETAFFINITY > + ... > +#ifdef HAVE_SCHED_GET_AFFINITY > +#define __USE_GNU > +#include <sched.h> > +#endif Looks like a typo there.

1 0

Re: winex11: Make X11DRV_PALETTE_ComputeColorShifts() static.
by Roderick Colenbrander 10 Sep '09

10 Sep '09

In a next patch ComputeChannelShift will be called from outside palette.c and for this reason I made it non-static. Roderick On Thu, Sep 10, 2009 at 5:58 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > dlls/winex11.drv/palette.c | 115 ++++++++++++++++++++++---------------------- > dlls/winex11.drv/x11drv.h | 1 - > 2 files changed, 57 insertions(+), 59 deletions(-) > > diff --git a/dlls/winex11.drv/palette.c b/dlls/winex11.drv/palette.c > index 81bb73b..cdbfb21 100644 > --- a/dlls/winex11.drv/palette.c > +++ b/dlls/winex11.drv/palette.c > @@ -131,6 +131,63 @@ static void palette_set_mapping( HPALETTE hpal, int *mapping ) > wine_tsx11_unlock(); > } > > +/*********************************************************************** > + * X11DRV_PALETTE_ComputeChannelShift > + * > + * Calculate conversion parameters for a given color mask > + */ > +static void X11DRV_PALETTE_ComputeChannelShift(unsigned long maskbits, ChannelShift *physical, ChannelShift *to_logical) > +{ > + int i; > + > + if (maskbits==0) > + { > + physical->shift=0; > + physical->scale=0; > + physical->max=0; > + to_logical->shift=0; > + to_logical->scale=0; > + to_logical->max=0; > + return; > + } > + > + for(i=0;!(maskbits&1);i++) > + maskbits >>= 1; > + > + physical->shift = i; > + physical->max = maskbits; > + > + for(i=0;maskbits!=0;i++) > + maskbits >>= 1; > + physical->scale = i; > + > + if (physical->scale>8) > + { > + /* On FreeBSD, VNC's default 32bpp mode is bgrabb (ffc00000,3ff800,7ff)! > + * So we adjust the shifts to also normalize the color fields to > + * the Win32 standard of 8 bits per color. > + */ > + to_logical->shift=physical->shift+(physical->scale-8); > + to_logical->scale=8; > + to_logical->max=0xff; > + } else { > + to_logical->shift=physical->shift; > + to_logical->scale=physical->scale; > + to_logical->max=physical->max; > + } > +} > + > +/*********************************************************************** > + * X11DRV_PALETTE_ComputeColorShifts > + * > + * Calculate conversion parameters for a given color > + */ > +static void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask) > +{ > + X11DRV_PALETTE_ComputeChannelShift(redMask, &shifts->physicalRed, &shifts->logicalRed); > + X11DRV_PALETTE_ComputeChannelShift(greenMask, &shifts->physicalGreen, &shifts->logicalGreen); > + X11DRV_PALETTE_ComputeChannelShift(blueMask, &shifts->physicalBlue, &shifts->logicalBlue); > +} > > /*********************************************************************** > * COLOR_Init > @@ -278,64 +335,6 @@ void X11DRV_PALETTE_Cleanup(void) > } > > /*********************************************************************** > - * X11DRV_PALETTE_ComputeChannelShift > - * > - * Calculate conversion parameters for a given color mask > - */ > -static void X11DRV_PALETTE_ComputeChannelShift(unsigned long maskbits, ChannelShift *physical, ChannelShift *to_logical) > -{ > - int i; > - > - if (maskbits==0) > - { > - physical->shift=0; > - physical->scale=0; > - physical->max=0; > - to_logical->shift=0; > - to_logical->scale=0; > - to_logical->max=0; > - return; > - } > - > - for(i=0;!(maskbits&1);i++) > - maskbits >>= 1; > - > - physical->shift = i; > - physical->max = maskbits; > - > - for(i=0;maskbits!=0;i++) > - maskbits >>= 1; > - physical->scale = i; > - > - if (physical->scale>8) > - { > - /* On FreeBSD, VNC's default 32bpp mode is bgrabb (ffc00000,3ff800,7ff)! > - * So we adjust the shifts to also normalize the color fields to > - * the Win32 standard of 8 bits per color. > - */ > - to_logical->shift=physical->shift+(physical->scale-8); > - to_logical->scale=8; > - to_logical->max=0xff; > - } else { > - to_logical->shift=physical->shift; > - to_logical->scale=physical->scale; > - to_logical->max=physical->max; > - } > -} > - > -/*********************************************************************** > - * X11DRV_PALETTE_ComputeColorShifts > - * > - * Calculate conversion parameters for a given color > - */ > -void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask) > -{ > - X11DRV_PALETTE_ComputeChannelShift(redMask, &shifts->physicalRed, &shifts->logicalRed); > - X11DRV_PALETTE_ComputeChannelShift(greenMask, &shifts->physicalGreen, &shifts->logicalGreen); > - X11DRV_PALETTE_ComputeChannelShift(blueMask, &shifts->physicalBlue, &shifts->logicalBlue); > -} > - > -/*********************************************************************** > * X11DRV_PALETTE_BuildPrivateMap > * > * Allocate colorcells and initialize mapping tables. > diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h > index 62b0d63..844af31 100644 > --- a/dlls/winex11.drv/x11drv.h > +++ b/dlls/winex11.drv/x11drv.h > @@ -494,7 +494,6 @@ extern BOOL X11DRV_IsSolidColor(COLORREF color); > extern COLORREF X11DRV_PALETTE_ToLogical(X11DRV_PDEVICE *physDev, int pixel); > extern int X11DRV_PALETTE_ToPhysical(X11DRV_PDEVICE *physDev, COLORREF color); > extern int X11DRV_PALETTE_LookupPixel(COLORREF color); > -extern void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask); > > extern unsigned int depth_to_bpp( unsigned int depth ); > > -- > 1.6.3.3 > > >

1 0

Re: mshtml: Add support for Reference BSTR when setting styles.
by Paul Vriens 10 Sep '09

10 Sep '09

On 09/10/2009 12:00 PM, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > mshtml: Add support for Reference BSTR when setting styles. > > Best Regards > Alistair Leslie-Hughes > > > ------------------------------------------------------------------------ > > Hi Alistair, Now VT_BSTR is used in two case-statements. -- Cheers, Paul.

1 1

Re: msi: Ignore CoInitialize failure in ACTION_CreateShortcuts.
by Hans Leidekker 10 Sep '09

10 Sep '09

> Fixes http://bugs.winehq.org/show_bug.cgi?id=19636 Or it doesn't: err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded err:shell:ShellLink_QueryInterface -- Interface: E_NOINTERFACE Because IShellLink is apartment-threaded only? -Hans

1 0

Performance tag for Bugzilla?
by Scott Ritchie 10 Sep '09

10 Sep '09

We have a wiki page functioning as sort of a wannabe performance tag here: http://wiki.winehq.org/Performance-related_bugs Is this a reasonable tag to have? Thanks, Scott Ritchie

1 0

http://bugs.winehq.org/show_bug.cgi?id=18337
by Frank Gruman 10 Sep '09

10 Sep '09

I have been using wine for various tools and utilities at work and home for some time now. Recently I tried to use wine to run the VMware Infrastructure Client and ran into bug 18337 (http://bugs.winehq.org/show_bug.cgi?id=18337). I am pasting my comments on that bug here to avoid repetition (http://bugs.winehq.org/show_bug.cgi?id=18337#c4). <paste> So - I looked through the code (current git @1.1.29) and compared to the 1.0 release (because of comment 1) and did not see that CERT_CHAIN_POLICY_SSL was ever implemented. Looking at chain.c, line 1886-1902 I can see the switch-case statement where this would have been handled. The problem I ran into while trying to keep up with the code was figuring out what the verify_* methods are trying to do. I'd really like to see this work and may have some spare cycles to help out. The problem is that I don't understand everything happening in these methods - can I get some pointers to what is happening or what should happen in the yet to be created verify_ssl_policy() method? </paste> Regards, Frank

2 3

ddraw: Added support for WINED3DFMT_X8L8V8U8, WINED3DFMT_R8G8B8A8_SNORM and WINED3DFMT_R16G16_SNORM to PixelFormat_WineD3DtoDD
by Joerg-Cyril.Hoehle＠t-systems.com 10 Sep '09

10 Sep '09

Stephan, All the patches proposed to bug #16559 forget one thing: it cannot be right to patch only PixelFormat_WineD3DtoDD without patching its converse function in the same file, PixelFormat_DD2WineD3D. There's no gain in silencing a fixme by introducing internal inconsistency in the source code. I had my own patch which changed both but for X8L8V8U8 only, but never published it because I observed no visual difference in the one app I tested, and had no time for 3 other ones I own, nor the other formats. I'm left wondering which of the pixelformats actually produces a visual difference as e.g. in comment #27. BTW, I suggest you submit individual patches, one per format. Regards, Jörg Höhle

2 1

Re: CPPCheck for Sept 8th
by chris ahrendt 09 Sep '09

09 Sep '09

Nicolas Le Cam wrote: > 2009/9/9 Alexandre Julliard <julliard(a)winehq.org>: >> chris ahrendt <celticht32(a)yahoo.com> writes: >> >>> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd >> This is the only one that looks a real bug, all the rest are false >> positives. Please filter them out from future reports. >> >> -- >> Alexandre Julliard >> julliard(a)winehq.org >> >> >> > > Not necessary false positives. Errors in dlls/msvcrt/tests/file.c, for > example, are real but expected errors, as it's the purpose of the test > to see how it behaves on Windows in such situation. > So continue to send everything then? Since I have been running them the size has not really been that large... just let me know what you want me to send and I will send it in... Chris

2 1

CPPCheck for Sept 8th
by chris ahrendt 09 Sep '09

09 Sep '09

[/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:146]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:208]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:387]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/makedep.c:953]: (error) Resource leak: file [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/msmangle.c:164]: (error) Memory leak: function_name [/home/cahrendt/wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map This is using thursdays git tree of CPPCheck.. please let me know if there are FP's so I can report them. Chris p.s. Thanks stephan for pointing out I sent it to the wrong list =D

3 2

Re: CPPCheck for Sept 8th
by chris ahrendt 09 Sep '09

09 Sep '09

Alexandre Julliard wrote: > chris ahrendt <celticht32(a)yahoo.com> writes: > >> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd > > This is the only one that looks a real bug, all the rest are false > positives. Please filter them out from future reports. > Is there any others? So ignore the tests findings and the tools findings? Are These the ones that may be a bug then : [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:146]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:208]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 These Ignore correct? [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:387]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/makedep.c:953]: (error) Resource leak: file [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/msmangle.c:164]: (error) Memory leak: function_name [/home/cahrendt/wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map Chris

1 0

Re: CPPCheck for Sept 8th
by chris ahrendt 09 Sep '09

09 Sep '09

Alexandre Julliard wrote: > chris ahrendt <celticht32(a)yahoo.com> writes: > >> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd > > This is the only one that looks a real bug, all the rest are false > positives. Please filter them out from future reports. > Alexandre, I will filter them as best I can going forward... Chris

1 0

Re: CPP Run for Sept 8
by Stefan Dösinger 09 Sep '09

09 Sep '09

hi, I think its better to send these reports to wine-devel instead of wine-patches

1 0

Re: gdi32/tests: Some GdiAlphaBlend tests
by Roderick Colenbrander 09 Sep '09

09 Sep '09

Regarding the zero source DC, what happens visually? On Wed, Sep 9, 2009 at 1:30 PM, Nikolay Sivov<bunglehead(a)gmail.com> wrote: > Bug http://bugs.winehq.org/show_bug.cgi?id=18041 shows this commented crash. > I'm not sure how to fix it, but I think this call can't do anything > without source context. > > Another question is where to place such check - in gdi32 or winex11...any > advices are welcome. > > Changelog: > - Some GdiAlphaBlend tests > > >From a59cadcf03edeefff95c340230a47c9c3c60727f Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Wed, 9 Sep 2009 15:20:34 +0400 > Subject: Some GdiAlphaBlend tests > > --- > dlls/gdi32/tests/bitmap.c | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdi32/tests/bitmap.c b/dlls/gdi32/tests/bitmap.c > index 8666da2..38acd09 100644 > --- a/dlls/gdi32/tests/bitmap.c > +++ b/dlls/gdi32/tests/bitmap.c > @@ -2376,6 +2376,25 @@ static void test_GdiAlphaBlend(void) > blend.SourceConstantAlpha = 128; > blend.AlphaFormat = 0; > > + /* zero dimensions */ > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 0, 0, hdcSrc, 0, 0, 20, 20, blend), TRUE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, 0, 0, 0, 0, blend), TRUE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > + > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 0, 0, hdcSrc, 0, 0, 0, 0, blend), TRUE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > + > +#if 0 > + /* zero source HDC - crashes on wine, works on native */ > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, NULL, 0, 0, 20, 20, blend), FALSE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > +#endif > + > expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, 0, 0, 20, 20, blend), TRUE, BOOL, "%d"); > SetLastError(0xdeadbeef); > expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, -1, 0, 10, 10, blend), FALSE, BOOL, "%d"); > -- > 1.5.6.5 > > > > >

2 1

Re: mfc42: Stub implementation with the message where to get it from
by Alexandre Julliard 09 Sep '09

09 Sep '09

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > This is more of the testing waters type of patch. If this approach is > fine then we can do the same for all other dlls that are shipped with > Windows but not really a part of an O/S. I don't think you can put up a message box on attach, that could potentially become very annoying since it will trigger also for version checks etc. That sort of thing should be done at the loader level. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: gdi32: Handle OEM_CHARSET
by Dmitry Timoshkov 09 Sep '09

09 Sep '09

"Vladimir Pankratov" <scriptkid(a)mail.ru> wrote: > --- a/dlls/gdi32/freetype.c 2009-08-08 13:27:23.000000000 +0500 > +++ b/dlls/gdi32/freetype.c 2009-09-07 19:58:58.000000000 +0500 > @@ -3576,6 +3576,7 @@ > if(!TranslateCharsetInfo((DWORD*)(INT_PTR)lf.lfCharSet, &csi, TCI_SRCCHARSET)) { > switch(lf.lfCharSet) { > case DEFAULT_CHARSET: > + case OEM_CHARSET: > csi.fs.fsCsb[0] = 0; > break; > default: How is this different from the default case? -- Dmitry.

2 1

Re: [PATCH 02/10] d3d10: Implement annotation parsing.
by Henri Verbeet 09 Sep '09

09 Sep '09

2009/9/9 Rico Schüller <kgbricola(a)web.de>: > -static void parse_fx10_annotation(const char **ptr) > +static HRESULT parse_fx10_annotation(struct d3d10_effect_variable *a, const char **ptr, const char *data) > { > - skip_dword_unknown(ptr, 3); > + DWORD offset; > + > + read_dword(ptr, &offset); > + TRACE("Annotation name at offset %#x.\n", offset); > + > + a->name = copy_name(data + offset); > + if (!a->name) > + { > + ERR("Failed to copy name.\n"); > + return E_OUTOFMEMORY; > + } > + TRACE("Annotation name: %s.\n", a->name); > + > + read_dword(ptr, &offset); > + TRACE("Annotation type info at offset %#x.\n", offset); > + > + a->type = get_fx10_type(a->effect, data, offset); > + if (!a->type) > + { > + ERR("Failed to get variable type.\n"); > + return E_FAIL; > + } > + > + skip_dword_unknown(ptr, 1); > + > + return S_OK; > } It seems to me that this is just the same code for parsing variables (that has implications for 1/10 as well).

2 1

Re: msxml3: Add IDispatchEx support to IXMLDOMElement (resend 2)
by Alexandre Julliard 09 Sep '09

09 Sep '09

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi, > Feedback if something is wrong would be great. domdoc.c:601: warning: ISO C90 forbids mixed declarations and code -- Alexandre Julliard julliard(a)winehq.org

1 0

Google Summer of Code mentor summit Oct 24th-25th
by Kai Blin 09 Sep '09

09 Sep '09

Hi folks, Wine gets to send two delegates to the Google Summer of Code mentor summit in Mountain View, CA, this October. Is anybody who mentored interested in going? 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.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel September 2009