wine-devel January 2005

wine-devel@winehq.org

149 participants
343 discussions

Re: olepicture.c compile failure : "structure has no member named `UserData', implicit declaration of function `DGifOpen'"
by Marcus Meissner 23 Jan '05

23 Jan '05

On Fri, Jan 21, 2005 at 06:45:11PM -0800, Rizwan Kassim wrote: > Oh, I see what you mean. > > I've found that getting the latest version of libgif and copying > gif_lib.h into the local directory (and including it in > LD_LIBRARY_PATH) seems to at least halt compile errors. > > Reason I'm asking about what to do now, is that if this is a problem > that might be encountered, it makes sense that the configure or make > script should detect and "fix" it... > > Updated script at http://www.geekymedia.com/twiki/bin/view.cgi/WineDev/LugWine > > Any thoughts? No, it should work better with the installed system itself. I am building RPMs with defined chroots and have no problems. This script is just a major hack. If you have problems it should have been checked and/or found by the configure script. Ciao, Marcus

1 0

Re: [LOSTWAGES] Update howto and downloads page
by Mike Hearn 23 Jan '05

23 Jan '05

On Sat, 22 Jan 2005 17:32:24 -0800, Scott Ritchie wrote: > +<<<<<<< download.template > +======= Whoops, a merge conflict marker sneaked in there!

1 0

More DCOM notes
by Mike Hearn 23 Jan '05

23 Jan '05

Here are some more notes in a convenient to read form. I'll turn these into a documentation patch later. Rob, can you double-check this? This document assumes you are familiar with the basics of DCOM. If you aren't read this first: http://winehq.com/site/docs/wine-devel/dcom-1 This is not suitable study material for beginners. Don't say I didn't warn you. * Apartments Before a thread can use COM it must enter an apartment. Apartments are an abstraction of a COM objects thread safety level. There are many types of apartment but the only two we care about right now are single threaded apartments (STAs) and the multi-threaded apartment (MTA). Any given process may contain at most one MTA and potentially many STAs. You enter an apartment by calling CoInitializeEx and passing the desired thread model in as a parameter. The default if you use the deprecated CoInitialize is a STA, and this is the most common type of apartment used in COM. An object in the multi-threaded apartment may be accessed concurrently by multiple threads: eg, it's supposed to be entirely thread safe. It must also not care about thread-affinity, the object should react the same way no matter which thread is calling it. An object inside a STA does not have to be thread safe, and all calls upon it should come from the same thread - the thread that entered the apartment in the first place. The apartment system was originally designed to deal with the disparity between the Windows NT/C++ world in which threading was given a strong emphasis, and the Visual Basic world in which threading was barely supported and even if it had been fully supported most developers would not have used it. Visual Basic code is not truly multi-threaded, instead if you start a new thread you get an entirely new VM, with separate sets of global variables. Changes made in one thread do NOT reflect in another, which pretty much violates the expected semantics of multi- threading entirely but this is Visual Basic, so what did you expect? If you access a VB object concurrently from multiple threads, behind the scenes each VM runs in a STA and the calls are marshaled between the threads using DCOM. In the Windows 2000 release of COM, several new types of apartment were added, the most important of which are RTAs (the rental threaded apartment) in which concurrent access are serialised by COM using an apartment-wide lock but thread affinity is not guaranteed. * Structure of a marshaled interface pointer When an interface is marshaled using CoMarshalInterface, the result is a serialized OBJREF structure. An OBJREF actually contains a union, but we'll be assuming the variant that embeds a STDOBJREF here which is what's used by the system provided standard marshaling. A STDOBJREF (standard object reference) consists of the magic signature 'MEOW', then some flags, then the IID of the marshaled interface. Quite what MEOW stands for is a mystery, but it's definitely not "Microsoft Extended Object Wire". Next comes the STDOBJREF flags, identified by their SORF_ prefix. Most of these are reserved, and their purpose (if any) is unknown, but a few are defined. After the SORF flags comes a count of the references represented by this marshaled interface. Typically this will 1 in the case of a normal marshal, but may be 5 for table-strong marshals and 0 for table-weak marshals (the difference between these is explained below). The most interesting part of a STDOBJREF is the OXID, OID, IPID triple. This triple identifies any given marshaled interface pointer in the network. OXIDs are apartment identifiers, and are supposed to be unique network-wide. How this is guaranteed is currently unknown: the original algorithm Windows used was something like the current UNIX time and a local counter. OXIDs are generated and registered with the OXID resolver by performing local RPCs to the RPC subsystem (rpcss.exe). In a fully security-patched Windows system they appear to be randomly generated. This registration is done using the ILocalOxidResolver interface, however the exact structure of this interface is currently unknown. OIDs are object identifiers, and identify a stub manager. The stub manager manages interface stubs. For each exported COM object there are multiple interfaces and therefore multiple interface stubs (IRpcStubBuffer implementations). OIDs are apartment scoped. Each ifstub is identified by an IPID, which identifies a marshaled interface pointer. IPIDs are apartment scoped. Unmarshaling one of these streams therefore means setting up a connection to the object exporter (the apartment holding the marshaled interface pointer) and being able to send RPCs to the right ifstub. Each apartment has its own RPC endpoint and calls can be routed to the correct interface pointer by embedding the IPID into the call using RpcBindingSetObject. IRemUnknown, discussed below, uses a reserved IPID. Both standard and handler marshaled OBJREFs contains an OXID resolver endpoint which is an RPC string binding in a DUALSTRINGARRAY. This is necessary because an OXID alone is not enough to contact the host, as it doesn't contain any network address data. Instead, the combination of the remote OXID resolver RPC endpoint and the OXID itself are passed to the local OXID resolver. It then returns the apartment string binding. This step is an optimisation: technically the OBJREF itself could contain the string binding of the apartment endpoint and the OXID resolver could be bypassed, but by using this DCOM can optimise out a server round-trip by having the local OXID resolver cache the query results. The OXID resolver is a service in the RPC subsystem (rpcss.exe) which implements a raw (non object-oriented) RPC interface called IOXIDResolver. Despite the identical naming convention this is not a COM interface. Unmarshaling an interface pointer stream therefore consists of reading the OXID, OID and IPID from the STDOBJREF, then reading one or more RPC string bindings for the remote OXID resolver. Then RpcBindingFromStringBinding is used to convert this remote string binding into an RPC binding handle which can be passed to the local IOXIDResolver::ResolveOxid implementation along with the OXID. The local OXID resolver consults its list of same-machine OXIDs, then its cache of remote OXIDs, and if not found does an RPC to the remote OXID resolver using the binding handle passed in earlier. The result of the query is stored for future reference in the cache, and finally the unmarshaling application gets back the apartment string binding, the IPID of that apartments IRemUnknown implementation, and a security hint (let's ignore this for now). Once the remote apartments string binding has been located the unmarshalling process constructs an RPC Channel Buffer implementation with the connection handle and the IPID of the needed interface, loads and constructs the IRpcProxyBuffer implementation for that IID and connects it to the channel. Finally the proxy is passed back to the application. * Handling IUnknown There are some subtleties here with respect to IUnknown. IUnknown itself is never marshaled directly: instead a version of it optimised for network usage is used. IRemUnknown is similar in concept to IUnknown except that it allows you to add and release arbitrary numbers of references at once, and it also allows you to query for multiple interfaces at once. IRemUnknown is used for lifecycle management, and for marshaling new interfaces on an object back to the client. Its definition can be seen in dcom.idl - basically the IRemUnknown::RemQueryInterface method takes an IPID and a list of IIDs, then returns STDOBJREFs of each new marshaled interface pointer. There is one IRemUnknown implementation per apartment, not per stub manager as you might expect. This is OK because IPIDs are apartment not object scoped. * Table marshaling Normally once you have unmarshaled a marshaled interface pointer that stream is dead, you can't unmarshal it again. Sometimes this isn't what you want. In this case, table marshaling can be used. There are two types: strong and weak. In table-strong marshaling, selected by a specific flag to CoMarshalInterface, a stream can be unmarshaled as many times as you like. Even if all the proxies are released, the marshaled object reference is still valid. Effectively the stream itself holds a ref on the object. To release the object entirely so its server can shut down, you must use CoReleaseMarshalData on the stream. In table-weak marshaling the stream can be unmarshaled many times, however the stream does not hold a ref. If you unmarshal the stream twice, once those two proxies have been released remote object will also be released. Attempting to unmarshal the stream at this point will yield CO_E_DISCONNECTED. * RPC dispatch Exactly how RPC dispatch occurs depends on whether the exported object is in a STA or the MTA. If it's in the MTA then all is simple: the RPC dispatch thread can temporarily enter the MTA, perform the remote call, and then leave it again. If it's in a STA things get more complex, because of the requirement that only one thread can ever access the object. Instead, when entering a STA a hidden window is created implicitly by COM, and the user must manually pump the message loop in order to service incoming RPCs. The RPC dispatch thread performs the context switch into the STA by sending a message to the apartments window, which then proceeds to invoke the remote call in the right thread. RPC dispatch threads are pooled by the RPC runtime. When an incoming RPC needs to be serviced, a thread is pulled from the pool and invokes the call. The main RPC thread then goes back to listening for new calls. It's quite likely for objects in the MTA to therefore be servicing more than one call at once. * Message filtering and re-entrancy When an outgoing call is made from a STA, it's possible that the remote server will re-enter the client, for instance to perform a callback. Because of this potential re-entrancy, when waiting for the reply to an RPC made inside a STA, COM will pump the message loop. That's because while this thread is blocked, the incoming callback will be dispatched by a thread from the RPC dispatch pool, so it must be processing messages. While COM is pumping the message loop, all incoming messages from the operating system are filtered through one or more message filters. These filters are themselves COM objects which can choose to discard, hold or forward window messages. The default message filter drops all input messages and forwards the rest. This is so that if the user chooses a menu option which triggers an RPC, they then cannot choose that menu option *again* and restart the function from the beginning. That type of unexpected re-entrancy is extremely difficult to debug, so it's disallowed. Unfortunately other window messages are allowed through, meaning that it's possible your UI will be required to repaint itself during an outgoing RPC. This makes programming with STAs more complex than it may appear, as you must be prepared to run all kinds of code any time an outgoing call is made. In turn this breaks the idea that COM should abstract object location from the programmer, because an object that was originally free-threaded and is then run from a STA could trigger new and untested codepaths in a program. Oh well, it was nice in theory. thanks -mike

2 2

WineConf 2005: hotel info
by Brian Vincent 23 Jan '05

23 Jan '05

Earlier I added hotel info to the WineConf pages: http://www.winehq.com/site/wineconf/travel Here's what you need to know: - we have 50 rooms reserved for Fri and Sat night, we have some on Thursday and Monday night too. I'll drink bier with anyone arriving early or staying late. - 81 EUR for 2 nights - you have to send an email to the address on the web page to reserve a room, note the "keyword" - first come, first served, reservations must be made by March 29th - did I mention RSVP'ing on WineHQ as well? Link: http://www.winehq.com/site/wineconf/rsvp Thanks goes out to Hans-Ulrich Schmid (WRS) and Ulrich Gemkow (University of Stuttgart) for getting together and figuring this out. -Brian

1 0

where does windows define RTL_RWLOCK?
by Robert Reif 23 Jan '05

23 Jan '05

I'm trying to compile wine's direct sound dll on windows and I can't get past this problem. I can't find a windows file that defines RTL_RWLOCK in the PSDK or DDK. Is the structure wine uses compatible with windows?

2 1

Re: [DSOUND] fix memory leak in mixer code
by Robert Reif 22 Jan '05

22 Jan '05

Robert Reif wrote: > Fix memory leak in mixer code. > > > Revised to remove unnecessary test before HeapFree. Index: dlls/dsound/dsound.c =================================================================== RCS file: /home/wine/wine/dlls/dsound/dsound.c,v retrieving revision 1.24 diff -u -p -r1.24 dsound.c --- dlls/dsound/dsound.c 7 Dec 2004 14:23:46 -0000 1.24 +++ dlls/dsound/dsound.c 22 Jan 2005 20:52:27 -0000 @@ -301,6 +301,7 @@ static ULONG WINAPI IDirectSoundImpl_Rel if (This->driver) IDsDriver_Release(This->driver); + HeapFree(GetProcessHeap(),0,This->tmp_buffer); RtlDeleteResource(&This->buffer_list_lock); This->mixlock.DebugInfo->Spare[1] = 0; DeleteCriticalSection(&This->mixlock); @@ -809,6 +810,8 @@ HRESULT WINAPI IDirectSoundImpl_Create( pDS->primary = NULL; pDS->speaker_config = DSSPEAKER_STEREO | (DSSPEAKER_GEOMETRY_NARROW << 16); pDS->initialized = FALSE; + pDS->tmp_buffer = NULL; + pDS->tmp_buffer_len = 0; /* 3D listener initial parameters */ pDS->listener = NULL; Index: dlls/dsound/dsound_private.h =================================================================== RCS file: /home/wine/wine/dlls/dsound/dsound_private.h,v retrieving revision 1.24 diff -u -p -r1.24 dsound_private.h --- dlls/dsound/dsound_private.h 7 Sep 2004 19:32:21 -0000 1.24 +++ dlls/dsound/dsound_private.h 22 Jan 2005 20:52:27 -0000 @@ -95,6 +95,8 @@ struct IDirectSoundImpl DSBUFFERDESC dsbd; DWORD speaker_config; BOOL initialized; + LPBYTE tmp_buffer; + DWORD tmp_buffer_len; /* DirectSound3DListener fields */ IDirectSound3DListenerImpl* listener; Index: dlls/dsound/mixer.c =================================================================== RCS file: /home/wine/wine/dlls/dsound/mixer.c,v retrieving revision 1.26 diff -u -p -r1.26 mixer.c --- dlls/dsound/mixer.c 8 Sep 2004 01:37:25 -0000 1.26 +++ dlls/dsound/mixer.c 22 Jan 2005 20:52:27 -0000 @@ -368,20 +368,20 @@ static void DSOUND_MixerVol(IDirectSound } } -static void *tmp_buffer; -static size_t tmp_buffer_len = 0; - -static void *DSOUND_tmpbuffer(size_t len) +static LPBYTE DSOUND_tmpbuffer(IDirectSoundImpl *dsound, DWORD len) { - if (len>tmp_buffer_len) { - void *new_buffer = realloc(tmp_buffer, len); - if (new_buffer) { - tmp_buffer = new_buffer; - tmp_buffer_len = len; + TRACE("(%p,%ld)\n",dsound,len); + + if (len > dsound->tmp_buffer_len) { + if (dsound->tmp_buffer) + dsound->tmp_buffer = HeapReAlloc(GetProcessHeap(), 0, dsound->tmp_buffer, len); + else + dsound->tmp_buffer = HeapAlloc(GetProcessHeap(), 0, len); + + dsound->tmp_buffer_len = len; } - return new_buffer; - } - return tmp_buffer; + + return dsound->tmp_buffer; } static DWORD DSOUND_MixInBuffer(IDirectSoundBufferImpl *dsb, DWORD writepos, DWORD fraglen) @@ -407,9 +407,7 @@ static DWORD DSOUND_MixInBuffer(IDirectS return 0; } - /* Been seeing segfaults in malloc() for some reason... */ - TRACE("allocating buffer (size = %d)\n", len); - if ((buf = ibuf = (BYTE *) DSOUND_tmpbuffer(len)) == NULL) + if ((buf = ibuf = DSOUND_tmpbuffer(dsb->dsound, len)) == NULL) return 0; TRACE("MixInBuffer (%p) len = %d, dest = %ld\n", dsb, len, writepos); @@ -518,8 +516,7 @@ static void DSOUND_PhaseCancel(IDirectSo nBlockAlign = dsb->dsound->pwfx->nBlockAlign; len = len / nBlockAlign * nBlockAlign; /* data alignment */ - TRACE("allocating buffer (size = %ld)\n", len); - if ((buf = ibuf = (BYTE *) DSOUND_tmpbuffer(len)) == NULL) + if ((buf = ibuf = DSOUND_tmpbuffer(dsb->dsound, len)) == NULL) return; TRACE("PhaseCancel (%p) len = %ld, dest = %ld\n", dsb, len, writepos);

1 0

Re: [DSOUND] fix memory leak in mixer code
by Mike Hearn 22 Jan '05

22 Jan '05

On Sat, 22 Jan 2005 14:46:04 -0500, Robert Reif wrote: > + if (This->tmp_buffer) > + HeapFree(GetProcessHeap(),0,This->tmp_buffer); There's no need for the test here, it's duplicated inside HeapFree. There was a janitorial task to clean this up not that long ago. thanks -mike

1 0

Howto process X11 events async'ly
by Peter Quiring 22 Jan '05

22 Jan '05

I'm developing my own library and I'm in the process of porting it over in Linux. I can get X11 to display the graphics and process events, but the only problem I have is with processing events without wasting CPU power. How do you process events without constantly polling? What I've done is create a new thread that will call XNextEvent() which will block if there are no events waiting and this seems to work fine. Except if the main thread wants to use the Window it too will deadlock until XNextEvent() returns an event. I've even tried using XPutBackEvent() to wake-up the other thread, but it looks like X11 is not smart enough to handle this. Looking at Wine source it looks like they too have given up on X11 and do sync themselves. But then how do you know when new events are waiting without constantly polling ????? I've looked thru wine source but can't follow it. Thanks in advance. I've asked this question many times @ linuxforum.com but no one there understands the problem. Peter Quiring

3 2

Wine/Winelib for Visual Basic 6.0 Users?
by Ira Krakow 22 Jan '05

22 Jan '05

I'm writing the Winelib part of the book. The main audience is Microsoft Visual C++ 6.0 users. I can define a development environment for both MFC and non-MFC users, since it is well documented already. I was wondering - I'd like to include a section for Visual Basic 6.0 users. Beyond running the .EXEs in Wine, is it possible to use Winelib to convert VB6.0 apps? How does it differ from the VC++ environment? There's a _lot_ of VB6 code out there. Attracting these developers will help the Wine project (and sales of our book) tremendously. Thanks for your input. Ira

3 2

Re: [d3drm] Adds a header, and corrects a typo
by Tom 22 Jan '05

22 Jan '05

Ivan Leo Puoti wrote: > Peter Berg Larsen wrote: > >> + * Copyright (C) the Wine project > > > Please use your own name here, Wine is not a legal entity and cat' own > copyright, > just as it can't own a building or a car, so this copyright notice > doesn't make much sense. > If you don't want to use your name use something like "The wine project > authors" Why not just - the line you don't have to give copyright notice if you don't want to. Tom > > Ivan. > > > >

3 2

← Newer
1
...
9
10
11
12
13
14
15
...
35
Older →

Jump to page:

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 January 2005