December 2005 - Wine-Devel - list.winehq.org

Re: ntdll: Implement few Dbg* functions.

by Eric Pouech

Vitaliy Margolen wrote: > ChangeLog: > ntdll: Implement few Dbg* functions. > kernel32: Use new Dbg* functions instead of server calls. > + status = DbgUiDebugActiveProcess( hProc ); > + status = DbgUiStopDebugging( hProc ); > - if (self) DbgBreakPoint(); I wonder if we shouldn't use NtDbgActiveProcess, NtRemoveProcessDebug instead. A+ -- Eric Pouech

Dec. 18, 2005

Re: Alexandre Julliard : Take advantage of the __EXCEPT_PAGE_FAULT macro.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > The idea is that the ole_filter will catch all exceptions other than > page faults so that we don't hide obvious programmer errors. However, > there obviously should be cases for some other exceptions that we don't > want to handle. That doesn't sound right, we should have cases for exceptions that we want to handle, not catching all of them. What sort of exceptions do you expect to get here? -- Alexandre Julliard julliard(a)winehq.org

Dec. 18, 2005

Re: Create new mailing list wine-isv?

by Dan Kegel

On 12/13/05, Dan Kegel <dank(a)kegel.com> wrote: > So I've been thinking about how to attract more Windows ISVs > to test, support, and promote their apps on Linux with Wine. >... > I've made a start at the documentation (http://kegel.com/wine/isv) ... > How about we create a new mailing list, wine-isv, aimed squarely > at ISVs and the Wine community members who want to > help them? I realized I needed a discussion forum for that web page anyway for people who wanted to provide feedback, so I went and created one at google groups and added a link at the bottom of my page to it. Anyone who's interested in testing the idea of a wine-isv mailing list is welcome to join. Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 18, 2005

Re: WLDAP32: link to the reentrant version of libldap

by Hans Leidekker

On Sunday 18 December 2005 15:13, Robert Reif wrote: > Adding this fixes it for me but you may need to check for > ldap_parse_reference also. Yes, strictly speaking we should check all 4 reference handling functions that are absent from your libldap_r, but I'd rather keep the configure checks to an absolute minimum. Since these functions are related I doubt that there are versions of libldap_r around where less than 4 of them are missing. And when that happens we can deal with it ;-) -Hans

Dec. 18, 2005

Re: Create new mailing list wine-isv?

by Robert Shearman

Peter Beutner wrote: > Michael Jung schrieb: > >> On Friday 16 December 2005 10:49, Peter Beutner wrote: >> >>> Wine is _not_ just a different toolkit. Just look at all the "nasty" >>> stuff >>> wine has to do to emulate the windows process environment. >> >> >> I guess in the long term a project like wine, if successfull, doesn't >> have to live with the restrictions put up by the environment. If I >> understand correctly, the reason we have to do this nasty stuff, is >> because the kernel is missing functionality, which the NT kernel >> provides. Linus has stated that he thinks the Wine project is pivotal >> for Linux success as a desktop operation system. The kernel guys have >> been pretty cooperative before and I'm sure if we tell them what we >> need, or even better help out implementing it, Wine could be just >> another toolkit, perfectly well integrated _with_ the Linux environment. > > > Let's just look at the problem with the memory layout. Wine relies on > the possibility to load certain codes at fixed addresses as this is > how it works under windows. > Linux choose exact the opposite direction, i.e. try to ensure that > libraries are loaded at random places in the memory. This is not a > missing feature it is a complete different design decision. And I > seriously doubt that the kernel/or glibc guys will import the security > flaw from windows to always load code at fixed positions. > So wine will have to live forever with it's custom preloader hack to > emulate the windows process environment. You don't seem to realise that you can execute wine-pthread or wine-kthread directly instead of executing wine-preloader. I doubt companies using Wine will care (since the same security flaw will affect Windows and will have to be patched with urgency) and if they do then they can compile their app as a winelib app, which uses the OS's dynamic loader and whatever security benefits come with it. Your arguments seem to centre around complaining about the baggage that Wine brings around with it, yet that we emulate the Windows environment so well is the very reason that a Wine port is so much cheaper for companies than a full port. -- Rob Shearman

Dec. 18, 2005

Re: WLDAP32: link to the reentrant version of libldap

by Robert Reif

Hans Leidekker wrote: >On Thursday 15 December 2005 01:52, Robert Reif wrote: > > > >>>>This patch breaks builds on RH9 and appears to be responsible for the >>>>build breakage on http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php >>>> >>>> > > > >>nm shows that the symbols are in libldap.so but not libldap_r.so. >> >> > >Can you try this patch? > > -Hans > > Adding this fixes it for me but you may need to check for ldap_parse_reference also. Index: parse.c =================================================================== RCS file: /home/wine/wine/dlls/wldap32/parse.c,v retrieving revision 1.2 diff -p -u -r1.2 parse.c --- parse.c 2 Dec 2005 13:15:16 -0000 1.2 +++ parse.c 18 Dec 2005 14:02:35 -0000 @@ -130,7 +130,7 @@ ULONG ldap_parse_referenceW( WLDAP32_LDA PWCHAR **referrals ) { ULONG ret = LDAP_NOT_SUPPORTED; -#ifdef HAVE_LDAP +#if defined(HAVE_LDAP) && defined(HAVE_LDAP_COUNT_REFERENCES) char **referralsU = NULL; TRACE( "(%p, %p, %p)\n", ld, message, referrals );

Dec. 18, 2005

Re: Alexandre Julliard : Take advantage of the __EXCEPT_PAGE_FAULT macro.

by Robert Shearman

Alexandre Julliard wrote: >Module: wine >Branch: refs/heads/master >Commit: ae964ac801b3077f5361559abd6645d21fc35d1f >URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=ae964ac801b3077f5361559… > >Author: Alexandre Julliard <julliard(a)winehq.org> >Date: Fri Dec 16 17:17:57 2005 +0100 > >Take advantage of the __EXCEPT_PAGE_FAULT macro. > > This change is wrong: > --- dlls/ole32/rpc.c > +++ dlls/ole32/rpc.c > @@ -110,13 +110,6 @@ struct dispatch_params > HRESULT hr; /* hresult (out) */ > }; > -static WINE_EXCEPTION_FILTER(ole_filter) > -{ > - if (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION) > - return EXCEPTION_CONTINUE_SEARCH; > - return EXCEPTION_EXECUTE_HANDLER; > -} > - > static HRESULT WINAPI > RpcChannelBuffer_QueryInterface(LPRPCCHANNELBUFFER iface, REFIID riid, > LPVOID *ppv) > { > *ppv = NULL; > @@ -453,7 +446,7 @@ void RPC_ExecuteCall(struct dispatch_par > { > params->hr = IRpcStubBuffer_Invoke(params->stub, params->msg, > params->chan); > } > - __EXCEPT(ole_filter) > + __EXCEPT_PAGE_FAULT > { > params->hr = GetExceptionCode(); > } The idea is that the ole_filter will catch all exceptions other than page faults so that we don't hide obvious programmer errors. However, there obviously should be cases for some other exceptions that we don't want to handle. -- Rob Shearman

Dec. 18, 2005

Re: DirectDraw over Direct3D

by Aric Cyr

Roderick Colenbrander <thunderbird2k <at> gmx.net> writes: > > > > Second the required 3d functionality is VERY limited. Basicly the > only > > > thing the videocard needs support is texturing which all cards do. > > > > But that's obviously wrong - the video *driver* also needs to support > it. > > And the current 3D video driver situation in Linux is horrible. > > > > about which I talked already has a fillrate of 60MPixels so it can > already do it fast enough. (one of the bottlenecks is the uploading of > textures which happens through PCI / AGP / PCI-Express but this > bottleneck appears for all drawing operations) Textures might even be faster than a direct DGA mode since textures are sent over the bus at AGP/PCIe speeds, where DGA is (I believe) limited to PCI memory mapped I/O speeds. Granted there is a bit more configuration overhead for using OpenGL but all that state can (and should) be set up front and then never touched again. I haven't checked out this patch in much detail yet, but I hope it is implemented in such a way to avoid changing OpenGL states once the program has started. I think the code would reduce to something like: one_time_init: <create and setup the texture object to be compatible with framebuffer> <set up vertex and texture coordinate arrays (only 4 unchangin vertices)> render_frame: glTexSubImage2D(...) // update texture object from the 'framebuffer' glDrawArrays(...); // uses the currently active vertex and texture coords There should be no reason that ddraw needs to change any state or vertex info between render operations. The only thing that changes should be the pixel data for used for the texture. We could go even one better and replace my example glDrawArrays with a display list so then the only data we are sending to the GPU on a render is the pixel data and a glCallList(). Also, for memory savings, we don't need a depth buffer, an accum buffer or stencil buffer for ddraw. A straight framebuffer-only visual would be cheapest in terms of video card memory and glClear costs. Of course, since ddraw is going to eventually end up using wined3d, we should make sure that this fast-path is possible, or create a ddraw inside wined3d, as some have mentioned. - Aric

Dec. 18, 2005

Re: Comparing a complicated program startup to windows

by Dmitry Timoshkov

Corey McClymonds <galeru(a)gmail.com> wrote: > There is a game, known as Continuum, that has a very complicated setup > before it actually starts the game, to prevent cheating. Due to this, the > relay is very large, about 4MB, before it starts to repeat itself. I have > gotten the +loaddll and the +seh logs at the bottom. I was just wondering, > would it be possible to do the same startup on a Windows machine, and > compare its relay to the relay from Wine. If this is possible, how would I > go about this? Get Debugging Tools for Windows and use logger.exe to get a log similar to Wine relay log. Use +relay,+seh debug switches to create a log under Wine, +loaddll is not useful at all for your purposes. -- Dmitry.

Dec. 18, 2005

Re: [wined3d] Converting Wined3d to use WGL instead of GLX

by Gregory M. Turner

On Friday 16 December 2005 23:07, Aric Cyr wrote: > Last time I checked gcc doesn't enable optimizations unless a -O option is > specified explicitly (don't know if this has changed though). I realize it is a moot point wrt the topic, but as you may know, there's an easy way to check. Running sh$ echo 'main () {}' > bloated.c sh$ gcc -v -Q $CFLAGS bloated.c will, amongst other things, dump exactly what optimizations (in terms of atomic gcc command-line optimizations) are used given the current setup and CFLAGS environment variable. My 3.4.4 does indeed do exactly the same thing with "-g" and "-g -O0". -- gmt

Dec. 17, 2005