Re: Work legalities
Jeremy White wrote: If you are employed to do programming (even at a university), or have made an agreement with your employer, school or anyone else saying it owns software you write, then you and we need a signed document from them disclaiming any rights they may have to the software. Wouldn't a paper saying they keep their rights, but approve the LGPL distribution also work? Would that still require us to have a written statement? After all, we do not require written from other people. Shachar
Re: Work legalities
I asked today and was told there shouldn't be a problem and my boss is going to check it over for me with the powers that be. In the meantime I think I'll just start coding and not submit anything until I eventually get it in writing. On 3/9/07, Shachar Shemesh [EMAIL PROTECTED] wrote: Jeremy White wrote: If you are employed to do programming (even at a university), or have made an agreement with your employer, school or anyone else saying it owns software you write, then you and we need a signed document from them disclaiming any rights they may have to the software. Wouldn't a paper saying they keep their rights, but approve the LGPL distribution also work? Would that still require us to have a written statement? After all, we do not require written from other people. Shachar -- Nathan
Re: wined3d: Update cursor position on ShowCursor
I'm not sure why, but it looks like this was commited as part of http://source.winehq.org/git/wine.git/?a=commitdiff;h=7126b63645747fe035aaa1167f0dcda8cb38be01 On 08/03/07, Erich Hoover [EMAIL PROTECTED] wrote: Request for comments, as per http://www.winehq.com/site/sending_patches. For details on the need for this patch please see Bug #7542. Thanks! Erich Hoover [EMAIL PROTECTED]
Re: Alexandre Julliard : advapi32: Fixed registry test that failed because of a buffer overflow.
James Hawkins [EMAIL PROTECTED] writes: The test passes in Windows, so isn't this hiding a bug in our implementation of RegSetValueW? No, it's because the Windows build stores the variables differently in memory. The test was buggy. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wined3d: Update cursor position on ShowCursor
H. Verbeet [EMAIL PROTECTED] writes: I'm not sure why, but it looks like this was commited as part of http://source.winehq.org/git/wine.git/?a=commitdiff;h=7126b63645747fe035aaa1167f0dcda8cb38be01 Yes, I screwed up the commit, but the patch is in. Sorry about the confusion. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [2/2] wined3d: IWineD3DDeviceImpl_UpdateSurface: return D3DERR_INVALIDCALL if source and dest format do not match
On 09/03/07, Fabian Bieler [EMAIL PROTECTED] wrote:
+if (destFormat != srcFormat) {
+WARN(source %p and dest %p must match, returning
WINED3DERR_INVALIDCALL\n, pSourceSurface, pDestinationSurface);
+return WINED3DERR_INVALIDCALL;
+}
You should probably print the actual formats there, using
debug_d3dformat(). Also, a test wouldn't hurt.
Re: quartz: Check allocation failure and clear memory in DSound Renderer
Chris Robinson wrote: return CLASS_E_NOAGGREGATION; pDSoundRender = CoTaskMemAlloc(sizeof(DSoundRenderImpl)); +if (!pDSoundRender) +return E_OUTOFMEMORY; +ZeroMemory(pDSoundRender, sizeof(DSoundRenderImpl)); pDSoundRender-lpVtbl = DSoundRender_Vtbl; pDSoundRender-IBasicAudio_vtbl = IBasicAudio_Vtbl; @@ -325,9 +328,15 @@ HRESULT DSoundRender_create(IUnknown * pUnkOuter, LPVOID * ppv) pDSoundRender-pClock = NULL; pDSoundRender-init = FALSE; pDSoundRender-started = FALSE; -ZeroMemory(pDSoundRender-filterInfo, sizeof(FILTER_INFO)); The check for allocation failure is good, but clearing the memory that is going to be initialised anyway is inefficient and unnecessary. -- Rob Shearman
Re: quartz: Check allocation failure and clear memory in DSound Renderer
On Friday 09 March 2007 03:26:31 am you wrote: The check for allocation failure is good, but clearing the memory that is going to be initialised anyway is inefficient and unnecessary. Not all of it is initialized, which is what led me to create the patch (if the object is created then released without ever being used, it may crash trying to delete the dsound buffer and device, since those pointers are never initialized when the filter isn't processed). As fields are added or changed to the struct, it becomes cumbersome to keep track and make sure each field is initialized to 0. I suppose I could've removed the lines that set fields to 0/FALSE/NULL, but I didn't think to. It doesn't hurt anything to keep them (reduntantly setting a few extra fields to 0 when creating the filter object is the least of the speed concerns), but if you really want me to remove them I can send an updated patch.
Re: quartz: Check allocation failure and clear memory in DSound Renderer
On Fr, 2007-03-09 at 03:02 -0800, Chris Robinson wrote: +ZeroMemory(pDSoundRender, sizeof(DSoundRenderImpl)); Since you clear the whole struct, ... pDSoundRender-lpVtbl = DSoundRender_Vtbl; pDSoundRender-IBasicAudio_vtbl = IBasicAudio_Vtbl; @@ -325,9 +328,15 @@ HRESULT DSoundRender_create(IUnknown * pUnkOuter, LPVOID * ppv) pDSoundRender-pClock = NULL; pDSoundRender-init = FALSE; pDSoundRender-started = FALSE; ... there is no need to clear it again. -- By by ... Detlef
Re: Tackling gdiplus?
So what would be the overall of the project? I'm interested in participating in this Google SoC, so this project sound interesting to me for this SoC 2007. Regards, Ivan On 3/9/07, Dan Kegel [EMAIL PROTECTED] wrote: An increasing number of apps need gdiplus.dll. Seems like it's time for Wine to include it. Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways. Any objections? I'm thinking of asking a summer intern to try this. - Dan
Re: Writing a winelib plugin
Dan Kegel wrote: What application did you have in mind? I honestly don't know, yet. I'm meeting a prospective client on Sunday that is currently doing some browser plugin via ActiveX, and wants to support Linux and Mac OSX, as well as Firefox. They were thinking about using Wine for some of the stuff, and converting code for other. Obviously, I've heard the usual we'll use winelib as we don't want to bundle the whole of Wine, and had to break it to them that that is not how things work. At worst, I believe we can run the actual plugin code in a separate process (started by Wine), and have a stub as the actual plugin, and have the two communicate via some IPC. I was just asking in case the problem was miraculously solved by someone while I was away from Wine. What you describe sounds awfully similar to what I remembered, however. Shachar
Re: Tackling gdiplus?
On Thu, Mar 08, 2007 at 10:50:30PM -0800, Dan Kegel wrote: An increasing number of apps need gdiplus.dll. Seems like it's time for Wine to include it. Yes, absolutely. Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways. Except that's based on top of Cairo, whereas ours should be based on gdi32. Huw. -- Huw Davies [EMAIL PROTECTED]
Is there someone working on dxdiag?
Hi, I would like to start some applications like Carmageddon TDR 2000 in HW mode, Neverwinter Nights 2 or just GetGPUAndSystemInfo.exe from Nvidia SDK demos and maybe 3DMark with HW info, but there are problems with detecting video card, I assume the main problem is in dxdiag library. So I would like to ask if there is someone working on this library, or if was there some code which was not accepted in wine tree to fix that? I am trying to hack this library, but with only small success. Mirek Slugen
Re: user32: avoid NULL pointer access in DefWindowProcA WM_NCCREATE
Jan Zerebecki wrote: cs is never NULL at that point. Where should it be checked for NULL, then? Or what does it prevent to be NULL? cs == lParam. And this code is inside if (lParam != NULL).
Re: quartz: Check allocation failure and clear memory in DSound Renderer
Detlef Riekenberg wrote: @@ -325,9 +328,15 @@ HRESULT DSoundRender_create(IUnknown * pUnkOuter, LPVOID * ppv) pDSoundRender-pClock = NULL; pDSoundRender-init = FALSE; pDSoundRender-started = FALSE; ... there is no need to clear it again. However, note that NULL is not always all binary zero in memory. :)
Re: Is there someone working on dxdiag?
have you tried plopping in a native dxdiag app. to see if it does enough for the application to think the environment is alright? It would be pretty cool to have a native Wine dxdiag though... Having a standardized set of tests would be very helpful, not to mention for the log output function, would simplify a lot of things for when d3d is good enough for the mainstream. On 3/9/07, Mirek [EMAIL PROTECTED] wrote: Hi, I would like to start some applications like Carmageddon TDR 2000 in HW mode, Neverwinter Nights 2 or just GetGPUAndSystemInfo.exe from Nvidia SDK demos and maybe 3DMark with HW info, but there are problems with detecting video card, I assume the main problem is in dxdiag library. So I would like to ask if there is someone working on this library, or if was there some code which was not accepted in wine tree to fix that? I am trying to hack this library, but with only small success. Mirek Slugen -- Cheers, Bryan
Re: quartz: Check allocation failure and clear memory inDSound Renderer
Felix Nawothnig [EMAIL PROTECTED] wrote: However, note that NULL is not always all binary zero in memory. :) I don't believe it's true since NULL is defined as (void *)0. -- Dmitry.
Re: Is there someone working on dxdiag?
WW, it is working, with native dxdiagn.dll I can start Neverwinter Nights 2 without any problems, coool :) Mirek Bryan Haskins napsal(a): have you tried plopping in a native dxdiag app. to see if it does enough for the application to think the environment is alright? It would be pretty cool to have a native Wine dxdiag though... Having a standardized set of tests would be very helpful, not to mention for the log output function, would simplify a lot of things for when d3d is good enough for the mainstream. On 3/9/07, *Mirek* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I would like to start some applications like Carmageddon TDR 2000 in HW mode, Neverwinter Nights 2 or just GetGPUAndSystemInfo.exe from Nvidia SDK demos and maybe 3DMark with HW info, but there are problems with detecting video card, I assume the main problem is in dxdiag library. So I would like to ask if there is someone working on this library, or if was there some code which was not accepted in wine tree to fix that? I am trying to hack this library, but with only small success. Mirek Slugen -- Cheers, Bryan
Re: quartz: Check allocation failure and clear memory inDSound Renderer
Dmitry Timoshkov wrote: However, note that NULL is not always all binary zero in memory. :) I don't believe it's true since NULL is defined as (void *)0. Actually it may aswell be just 0 in C. Just in C++ it's defined to be (void *)0. But even with just 0 an assignment/compare/whatever will get you an implicit typecast which makes the compiler generate any necessary conversion. See http://c-faq.com/null/ Felix
Re: Tackling gdiplus?
On 3/9/07, Huw Davies [EMAIL PROTECTED] wrote: On Thu, Mar 08, 2007 at 10:50:30PM -0800, Dan Kegel wrote: An increasing number of apps need gdiplus.dll. Seems like it's time for Wine to include it. Yes, absolutely. Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways. Except that's based on top of Cairo, whereas ours should be based on gdi32. But cairo has a win32 backend. So I think we can use mono-libgdiplus. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: quartz: Check allocation failure and clear memoryinDSound Renderer
Felix Nawothnig [EMAIL PROTECTED] wrote: Dmitry Timoshkov wrote: However, note that NULL is not always all binary zero in memory. :) I don't believe it's true since NULL is defined as (void *)0. Actually it may aswell be just 0 in C. Just in C++ it's defined to be (void *)0. But even with just 0 an assignment/compare/whatever will get you an implicit typecast which makes the compiler generate any necessary conversion. See http://c-faq.com/null/ Have you read it at all? NULL is guaranteed to be 0 in all contexts. If some C++ compiler decides to generate not 0 data while converting/casting a NULL pointer, it should be declared broken. -- Dmitry.
Re: Tackling gdiplus?
Ivan de Jesus Deras Tabora [EMAIL PROTECTED] wrote: Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways. Except that's based on top of Cairo, whereas ours should be based on gdi32. But cairo has a win32 backend. So I think we can use mono-libgdiplus. Considering that gdiplus has a very poor performance under Windows because it doesn't have a dedicated DDI (device driver interface), adding gdiplus that uses a completely different backend into Wine would have even more performance related problems. How is that possible to mention gdiplus at all, if even so basic functionality as a DIB engine still is not implemented? Besides, my personal opinion is that implementing gdiplus is out of scope of the Wine project, just like MFC and similar libraries. -- Dmitry.
Re: Is there someone working on dxdiag?
Am Freitag 09 März 2007 15:50 schrieb Mirek: Hi, I would like to start some applications like Carmageddon TDR 2000 in HW mode, Neverwinter Nights 2 or just GetGPUAndSystemInfo.exe from Nvidia SDK demos and maybe 3DMark with HW info, but there are problems with detecting video card, I assume the main problem is in dxdiag library. So I would like to ask if there is someone working on this library, or if was there some code which was not accepted in wine tree to fix that? I am trying to hack this library, but with only small success. No, no one is working on that DLL. As Bryan Haskins has said, you can use native dxdiagn.dll, but maybe this does more harm than good because no one will implement it in wine. The native DLL comes with all sorts of licensing issues. Even though there are more important parts of DirectX that need improvement, like dsound, dplay, dmusic or a start of a d3d10 implementation. pgpuXaaA18p09.pgp Description: PGP signature
Re: quartz: Check allocation failure and clear memoryinDSound Renderer
Dmitry Timoshkov [EMAIL PROTECTED] writes: Have you read it at all? NULL is guaranteed to be 0 in all contexts. If some C++ compiler decides to generate not 0 data while converting/casting a NULL pointer, it should be declared broken. The point is that (void*)0 isn't guaranteed to be represented by an all-zero bit pattern; but that's the case on any platform worth worrying about. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [2/2] wined3d: IWineD3DDeviceImpl_UpdateSurface: return D3DERR_INVALIDCALL if source and dest format do not match
Please ignore this patch.
Re: quartz: Check allocation failure and clear memory in DSound Renderer
On Fri, 9 Mar 2007, Felix Nawothnig wrote: Detlef Riekenberg wrote: @@ -325,9 +328,15 @@ HRESULT DSoundRender_create(IUnknown * pUnkOuter, LPVOID * ppv) pDSoundRender-pClock = NULL; pDSoundRender-init = FALSE; pDSoundRender-started = FALSE; ... there is no need to clear it again. However, note that NULL is not always all binary zero in memory. :) Isn't it zero on all sane systems, i.e. all systems we care about and even more? -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner
Re: New opengl thread context selection patches for testing
Stefan Dösinger napsal(a): Am Dienstag 06 März 2007 20:48 schrieb Mirek: Stefan Dösinger napsal(a): Am Sonntag 04 März 2007 23:04 schrieb Mirek: Ok, i tried it with current CVS. + Oblivion is still broken (same as with previous patchset) Which offscreen rendering method did you use? Backbuffer What happens with fbos? Last I knew this game works better with fbos With fbo game crashed after loading game. Mirek
Re: Work legalities
Shachar Shemesh wrote: Jeremy White wrote: If you are employed to do programming (even at a university), or have made an agreement with your employer, school or anyone else saying it owns software you write, then you and we need a signed document from them disclaiming any rights they may have to the software. Wouldn't a paper saying they keep their rights, but approve the LGPL distribution also work? Would that still require us to have a written statement? After all, we do not require written from other people. Sample text for LGPL release To the extent ACME Corporation (Company) has any copyright interest in the contribution written by Jane Doe for the program Wine, including original Wine code and documentation and support files, changes and enhancements to Wine and files, and any future modifications of Wine and files, Company hereby licenses that contribution under the GNU Lesser General Public License. Company affirms that it has no other obligation or interest that would undermine this license, or the use of the Wine, and will do nothing to undermine it in the future. [signature of John Smith], 30 March 2006 John Smith, Vice President, ACME Corp. And, yes, a writing is still needed. Documentation of the right to release code is important. Employers are usually different from authors, both in their interaction with the copyrights and their interaction with the project, hence the different treatment. -- GPG Fingerprint: 1571 BD1F 0EF3 B7DC 949E D6FC F70D A43C 6835 2635 [EMAIL PROTECTED] 212-461-1906
How does wine determine to draw non-client area according to managed mode setting?
Hello, When wine runs on managed mode, it delegate drawing non-client area(caption, frame-border) to window manager. I found NC_DrawCaption function is not invoked on managed mode. On non-managed mode, that function is invoked. I tried to find routine which determine to draw non-client area according to managed mode setting, but I can't. please give me some hints about that. Thank you.
Re: New opengl thread context selection patches for testing
Without patch 10 I can run Rainbow Six Vegas, even the game, but it is realy slow and graphic is very ugly. Mirek Slugen Mirek napsal(a): Ok, i tried it with current CVS. + There are many improvments in some games like Tomb Raider Legends, GTA San Andreas, HalfLife Episode One and 3DMark 2005 or 2006 + Oblivion is still broken (same as with previous patchset) + With your previous Thread patchset Rainbow Six Vegas can even run into menu, but now it hang while loading menu. + I can't find any other regressions :) Tested with: - 3DMark 2003 - 3DMark 2005 - 3DMark 2006 - Alpine Sky Racing 2007 - Battlefield 2142 Demo - Call of Duty 2 - Flatout 2 - GTA San Andreas - Half-Life 2 EO - NFS: MW - NFS: Carbon (can't run it before and after) - All NVidia SDK Direct3D Demos - Neverwinter Nights 2 (can't run it before and after) - Polda 5 (czech game) - Rayman 3 - Rayman Raving Rabbids (can't run it before and after) - Rainbow Six: Vegas - TES IV: Oblivion - Titan Quest (still hangs in menu) - Tomb Raider: Legend Mirek Stefan Dösinger napsal(a): Hi, Here is a new patchset for testing which implements duplicating gl contexts for new threads in wined3d. Again, it does not implement any synchronisation measures(except ENTER_GL and glFinish), so running multithreaded games is still kinda a lottery. This patchset also contains a patch for offscreen rendering, which may fix the problems introduced with TES: Oblivion before. This is just a format-patch of my git tree, the first 3 patches are unrelated. One of them is a clone of Henri's already sent patch, and the other 2 patches were sent by me already. Happy testing, Stefan
Re: Don't compare file handles to NULL
Francois Gouget wrote: On Wed, 7 Mar 2007, Michael Stefaniuc wrote: [...] You mean something like http://people.redhat.com/mstefani/wine/smatch/scripts/file_handles.pl ? Cool, thanks. [...] Most are false positives (non NULL check before CloseHandle()). These are not false positives. Any file handle that is not INVALID_HANDLE_VALUE must be closed with CloseHandle(). So these checks should be against INVALID_HANDLE_VALUE, not NULL. In fact they may possibly be removed altogether. Ok, as there are no false positives i have improved the script a little; documented it on my Smatch page and added it to my daily Smatch run. If you know more functions that return a file_handle i can search for those too. At the moment i'm looking only for the regexp CreateFile[AW]?. [...] dlls/rpcrt4/rpcss_np_client.c 92 RPCRT4_RpcssNPConnect(58) Comparision of the file handle 'the_pipe' with 0. programs/rpcss/np_server.c 393 RPCSS_NPConnect(57) Comparision of the file handle 'the_pipe' with 0. These two combine with what looks like a very bad file handle leak (especially in rpcrt4). Sending patches... Send a patch too for the additional occurence that the improved script has found. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Don't compare file handles to NULL
Michael Stefaniuc wrote: Francois Gouget wrote: On Wed, 7 Mar 2007, Michael Stefaniuc wrote: [...] Sending patches... Send a patch too for the additional occurence that the improved script has found. Duh ... I mean I have sent a patch already for the additional bug found by the improved script. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Question about OpenGL/D3D
Has anyone tested using standard window objects in a window that also had an opengl/d3d context? I believe Terragen 2 is attempting to do this. If this hasn't been tested, than it might be the cause of all of the static that appears non opengl area, making the program nearly unusable. No messages get printed to the console from wine(Terragen 2 prints out a fair bit of debug info there, but nothing from wine that would cause the problem, just a few warnings that shouldn't be related). Any thoughts?
Re: [Bug 7503] Eve Online pasword box on login screen doesn't work
On 2/20/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Lei Zhang [EMAIL PROTECTED] wrote: Can we change wineprefixcreate to copy the truetype fonts (if any) from /usr/X11R6/lib/X11/fonts/TTF or /usr/share/X11/fonts/TTF or [insert distro specific X11/fonts/TTF directory] to $WINEPREFIX/drive_c/windows/fonts/ ? No. It's the distribution's duty to put ttf fonts in the path available through the fontconfig APIs. -- Dmitry. While testing GetTextMetric, I noticed on my Slackware machine fontconfig/fontconfig.h is in the wrong location and as a result Wine does not load any fonts through fontconfig. I'll submit a patch shortly so that ./configure warns about this.
Re: Writing a winelib plugin
On Friday 09 March 2007 14:21 +0100, Shachar Shemesh wrote: Dan Kegel wrote: What application did you have in mind? I honestly don't know, yet. I'm meeting a prospective client on Sunday that is currently doing some browser plugin via ActiveX, and wants to support Linux and Mac OSX, as well as Firefox. They were thinking about using Wine for some of the stuff, and converting code for other. A couple of years ago two KDE developers were working on something like this as a fun project: http://dot.kde.org/994747675/ At worst, I believe we can run the actual plugin code in a separate process (started by Wine), and have a stub as the actual plugin, and have the two communicate via some IPC. I was just asking in case the problem was miraculously solved by someone while I was away from Wine. What you describe sounds awfully similar to what I remembered, however. That shouldn't be a problem, Konqueror is doing this for all Netscape plugins and I think there is a Firefox plugin which does this with MPlayer Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgp6kkWsb0xQS.pgp Description: PGP signature
Re: Don't compare file handles to NULL
Michael Stefaniuc [EMAIL PROTECTED] writes: Ok, as there are no false positives i have improved the script a little; documented it on my Smatch page and added it to my daily Smatch run. If you know more functions that return a file_handle i can search for those too. At the moment i'm looking only for the regexp CreateFile[AW]?. Probably at least CreateNamedPipe, CreateMailslot and FindFirstFile would be interesting to check. The opposite check would be nice too, there are probably cases where a call that returns a NULL handle on error is tested against INVALID_HANDLE_VALUE. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Question about OpenGL/D3D
Am Freitag 09 März 2007 19:47 schrieb Mike Schaadt: Has anyone tested using standard window objects in a window that also had an opengl/d3d context? This is known not to work. It was a regression due to the window management rewrite. The problem is that since the window management rewrite all window elements except the main window are not X11 windows. So the clipping done by X11 on opengl contexts does not work for subwindows in wine. The current plan for fixing this is, I believe, to create an overlay window which is used for opengl drawing. The other idea was to set up the opengl scissor test, but that turned out not to work correctly, and we need a seperate window for antialiasing support too. pgpcGlLa7esNm.pgp Description: PGP signature
Re: Tackling gdiplus?
Huw wrote: Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways. Except that's based on top of Cairo, whereas ours should be based on gdi32. But cairo has a win32 backend. So I think we can use mono-libgdiplus. Even if we wanted to do it that way, it wouldn't work; gdiplus exposes gdi32 handles, so we'd somehow have to get these through Cairo. Well, I heard libgdiplus already has a bundled version of Cairo, we could replace that with a win32-cairo, then hack it up to let the gdi32 handles shine through, maybe... (For those looking for a pointer to cairo-win32, see http://mces.blogspot.com/2007/02/cairo-and-winelib-adventures.html Maybe we could start by just getting it building?) Whether or not gdiplus is in scope for wine is really a function of whether it's practical to implement, and whether doing so would solve important problems for us. Maybe it would help to list the problems we have with using native gdiplus. I think it's just two: some apps don't bundle it, and it might be slow. The speed problem might be solvable by doing a DIB engine instead, as Dmitry implied. So Huw, you sounded like you thought doing our own gdiplus was a good idea. How strongly do you feel about it? Think I should have somebody try to tackle a DIB engine instead? - Dan - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Patches in bugzilla
Hi, There are some patches that are attached in the bugzilla. They havent sent to wine-patches mailing list. Can I mail them to the mailing list on their behalf? I have asked them to submit to the mailing list. The patches are submitted about 2 months back. Thanks, VJ
Re: comctl32: treeview: Message sequencing tests
Chris Peterson escreveu:
This is another patch for my CS130 assignment. It adds message
sequencing tests. Other changes include: I updated one of my previous
tests which was not testing the implied message; I changed a
SendMessageW to SendMessageA call in DoFocusTest to fix a problem on
Windows 98 due to a lack of default unicode support. Any
comments/suggestions are welcome.
Thanks!
-Chris
Hi!
@@ -166,7 +315,8 @@ static void DoFocusTest(void)
assert(hChild2);
ShowWindow(hMainWnd,SW_SHOW);
-SendMessageW(hTree, TVM_SELECTITEM, TVGN_CARET, (LPARAM)hChild);
+/* Using SendMessageA since Win98 doesn't have default unicode support */
+SendMessageA(hTree, TVM_SELECTITEM, TVGN_CARET, (LPARAM)hChild);
Use SendMessage() instead.
static void TestGetSetInsertMarkColor(void)
{
COLORREF crColor = RGB(0,0,0);
-SendMessage( hTree, TVM_SETBKCOLOR, 0, crColor );
-crColor = (COLORREF)SendMessage( hTree, TVM_GETBKCOLOR, 0, 0 );
+SendMessage( hTree, TVM_SETINSERTMARKCOLOR, 0, crColor );
+crColor = (COLORREF)SendMessage( hTree, TVM_GETINSERTMARKCOLOR, 0, 0 );
ok(crColor == RGB(0,0,0), Insert mark color reported as 0x%.8x, expected
0x\n, crColor);
Re: comctl32: treeview: Message sequencing tests
On 3/9/07, Marcelo Duarte [EMAIL PROTECTED] wrote: Chris Peterson escreveu: This is another patch for my CS130 assignment. It adds message sequencing tests. Other changes include: I updated one of my previous tests which was not testing the implied message; I changed a SendMessageW to SendMessageA call in DoFocusTest to fix a problem on Windows 98 due to a lack of default unicode support. Any comments/suggestions are welcome. Thanks! -Chris Hi! @@ -166,7 +315,8 @@ static void DoFocusTest(void) assert(hChild2); ShowWindow(hMainWnd,SW_SHOW); -SendMessageW(hTree, TVM_SELECTITEM, TVGN_CARET, (LPARAM)hChild); +/* Using SendMessageA since Win98 doesn't have default unicode support */ +SendMessageA(hTree, TVM_SELECTITEM, TVGN_CARET, (LPARAM)hChild); Use SendMessage() instead. There's nothing wrong with using SendMessageA. -- James Hawkins
Re: Don't compare file handles to NULL
Alexandre Julliard wrote: Michael Stefaniuc [EMAIL PROTECTED] writes: Ok, as there are no false positives i have improved the script a little; documented it on my Smatch page and added it to my daily Smatch run. If you know more functions that return a file_handle i can search for those too. At the moment i'm looking only for the regexp CreateFile[AW]?. Probably at least CreateNamedPipe, CreateMailslot and FindFirstFile would be interesting to check. Done! Added also FindFirstFileEx(); no new bug was found. The opposite check would be nice too, there are probably cases where a call that returns a NULL handle on error is tested against INVALID_HANDLE_VALUE. Can be done but i'll need a list of functions that return HANDLEs. The problem is Smatch looses a lot of type informations and a HANDLE is only an unsigned long pointer_type. And INVALID_HANDLE_VALUE is just -1. I have to see if i can automatically generate the list of HANDLE returning functions by other means. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Don't compare file handles to NULL
On Fri, 9 Mar 2007, Michael Stefaniuc wrote: [...] Ok, as there are no false positives i have improved the script a little; documented it on my Smatch page and added it to my daily Smatch run. Thanks a lot for the Smatch script. It has proven pretty useful already. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Utilisateur (nom commun) : Mot utilisé par les informaticiens en lieu et place d'idiot.
Re: user32: avoid NULL pointer access in DefWindowProcA WM_NCCREATE
On Fri, Mar 09, 2007 at 03:53:17PM +0100, Felix Nawothnig wrote: Jan Zerebecki wrote: cs is never NULL at that point. Where should it be checked for NULL, then? Or what does it prevent to be NULL? cs == lParam. And this code is inside if (lParam != NULL). Sorry, I missed that, because it was only recently added. Jan
Re: Question about OpenGL/D3D
Ah so that was the infamous problem with things like the WC3 Map editor, and such? Thinking about that not it makes sense. On 3/9/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Freitag 09 März 2007 19:47 schrieb Mike Schaadt: Has anyone tested using standard window objects in a window that also had an opengl/d3d context? This is known not to work. It was a regression due to the window management rewrite. The problem is that since the window management rewrite all window elements except the main window are not X11 windows. So the clipping done by X11 on opengl contexts does not work for subwindows in wine. The current plan for fixing this is, I believe, to create an overlay window which is used for opengl drawing. The other idea was to set up the opengl scissor test, but that turned out not to work correctly, and we need a seperate window for antialiasing support too. -- Cheers, Bryan
Re: Shader instruction table whitespace cleanup
Kevin Wallerbos wrote: This formatting patch cleans up the spacing in the pixel/vertexshader instruction table, making it somewhat nicer on the eyes. The lines have become a bit longer than practical on standard resolutions, but that shouldn't be a problem as most lines were already too long. A better thing to do is to remove the useless GLNAME_REQUIRE_GLSL, and undefined instruction names. In fact, it may be nice to break out the instruction names out of this table completely, since they are only necessary for some instructions, required by the map2gl function. This table is also organized poorly, you have to search through the whole thing, and then do version comparisons to find anything. If possible, it would be great to make it O(1) accessible. = Also, as you point out: Before patch : most lines were already too long [ I'd say some lines were too long ] After patch:all lines are too long Not sure what is gained... please don't force others to your resolution preferences. [ looking at this on a widescreen at 1680 x 1050 and it still wraps! ]
Re: WineD3D: Blit the offscreen texture into the drawable if needed
This time cube texture support is added. Hopefully the coords are right, I had no test app for them. If not it should be easy to spot the very characteristic flipping of the image. I'm confused - you replaced a patch which had no support for cube maps, with one that has untested support for cube maps?
Quick, how do you install native dcom? Or the visual C++ runtimes? Or...
OK, I've been doing bug triage on and off for years, but just recently I've gotten to the point where I'm tired of going to the NativeDCOM wiki page to remember how to try an app with native dcom just to see if the bug in question is a COM bug. So I wrote a trivial script to automate installing that plus a bunch of other redistributables. A draft is at http://kegel.com/wine/winetricks Usage: winetricks [dcom98|fakeie6|mdac26|mfc40|mono|vbrun60|vcrun6|wsh51|wsh56jscript] ... It's a bit like a programmer's version of winetools: it's so commandline-crufty that normal users won't go near it, but it's simple enough to extend that it will probably end up being pretty handy for anyone working on triaging bugs that appear to be due to missing redistributable libraries. Oh, or commonly-needed registry entries. - Dan
Re: Add Xcursor support
This patch makes the Guild Wars show up in all its glory.
