video4linux - wine
Question: Is there support for video4linux devices with wine? Is there some support for webcams? What are the settings (config)? I couldn't find anything useful on google concerning this issue -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org MediaHost™ at www.mediahost.org Skype: startcom Phone: +1.213.341.0390
Re: Debugging mingw applications using wine
Eric Pouech wrote: Bryce McKinlay a écrit : I'm trying to debug a windows .exe built with mingw using wine, but winedbg seems to have problems reading stabs from the mingw-built binary. My goal is to be able to debug a cross-compiled, native Java (GCJ) application, but even a simple C "hello world" seems to cause problems. winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support you can either: - use bare winedbg (without gdb support) - recompile gdb with 'stabs in PE' support (ie the settings used when compiling gdb under windows) Could you give any hints as to how to configure GDB with 'stabs in PE' support? The only reference I could find in the GDB documentation is: "6.4.5 PE Windows 95 and NT use the PE (/Portable Executable/) format for their executables. PE is basically COFF with additional headers. While BFD includes special PE support, GDB needs only the basic COFF reader." Is there a configure option to enable this support in the standard BFD/GDB code? (I'm using GDB from CVS head) - or are special patches required? How did you get/build the GDB you use? Thanks! Bryce
questions for safedisc implementation (AJ pleas read)
Chances are I'll be quite busy during the next week, but Laurent Pinchart, the guy who originally reverse engineered safedisc, asked a few questions on IRC about implementing support for the native safedisc driver, feedback, particularly from AJ, would be very appreciated, here is the IRC log. peter_pan is Laurent. < peter_pan> I'm trying to figure out how to implement "kernel services" in wine. a kernel service is a device driver which is loaded by StartService and runs in kernel space. the driver has a DriverEntry entry point, which, unlike regular services, seem to return immediately after registering callbacks. this might not always be the case though 23:41 < peter_pan> after DriverEntry returns, the process started by StartService currently exits. how should I handle calls to the callbacks registered by IoCreateDevice inside DriverEntry ? should they run in the calling process space, the wine server space or the service process space ? 23:41 < peter_pan> in the first case, I have to map the kernel service in all wine processes space, as the service can make use of global data (in windows the kernel service only exists once inside the kernel) 23:41 < peter_pan> in the third case, I will have to find a way to keep the service process alive (in a stopped state) after DriverEntry returns, and use wineserver and ptrace to call the callbacks from the user processes. this will imply inter process communication and inter process synchronization. or maybe I could just use IPC and keep the kernel space process waiting on a pipe or something. this wouldn't work for a kernel service which doesn't return from DriverEntry immediately, but I don't know if those exist. 23:41 < peter_pan> does anyone have any thought to share ? 23:47 <@Thunderbird> hi 23:47 <@Thunderbird> guess it needs to happen in wineserver 23:47 <@Thunderbird> better ask julliard about it 23:47 <@Thunderbird> if he is still awake 23:48 < peter_pan> he's been idling for 1 hour and 45 minutes 23:49 < peter_pan> are you there alexandre ? 23:50 <@Thunderbird> td might be online too .. 23:51 * TD is gone to a film, like NOW 23:51 <@TD> bye 23:51 < peter_pan> no luck either 23:51 < peter_pan> lol 23:52 <@Thunderbird> isn't there some function in wineserver that runs all the time? 23:53 < peter_pan> my opinion is that DriverEntry should be called in a separate process like it is now, as it can block, and that IoCreateDevice should map the image in the wineserver process space and update the callback table. the problem is that the changes to data sections made in DriverEntry must be somehow shared with wineserver. 23:55 < peter_pan> StartService will have to be modified to handle kernel services. it uses CreateProcess now, which calls DriverEntry (the entry point) with wrong parameters. we would need a way to mark a process as being a kernel process or a user process 23:57 <@Thunderbird> I guess that is good but I'm not qualified enough to say something about that 23:58 < peter_pan> using wineserver to host the driver callbacks would serialize the calls, which might not be a good thing to do. in windows, syscalls are executed in kernel space, but in the context of the calling process. it might be a good idea to do that here too. is the windows kernel interruptible ? can a process call a driver function while another process sleeps in the same functions, or while another process executes inside that function on another CPU ? 23:59 <@Thunderbird> how is this stuff handled in reactos? 23:59 < peter_pan> I have no idea 23:59 < peter_pan> maybe I should ask them
Re: video4linux - wine
There's currently no support, but you could add it via the Still Image
(STI) API. It's meant for scanners and webcams. There's probably a way
to add VFW (Video For Windows drivers) too.
I have written an IDL file for IStillImage, which I haven't gotten round
to submitting as yet. I've attached it incase you're interested... I
think it still needs some fixing up.
Mike
MediaHost (TM) wrote:
Question: Is there support for video4linux devices with wine? Is there
some support for webcams? What are the settings (config)? I couldn't
find anything useful on google concerning this issue
/*
* Copyright (C) 2004 Mike McCormack
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
import "oaidl.idl";
/* encoding neutral interfaces */
/*struct STIDEVICE;
typedef struct STIDEVICE* PSTIDEVICE ;
struct IStillImage;
struct STI;
typedef struct STI *PSTI;
struct STI_DEVICE_INFORMATIONW;
struct STIDEVICEW;
typedef struct IStillImageW IStillImageW,*PSTIW;
typedef struct STIDEVICEW* PSTIDEVICEW;
typedef struct STI_DEVICE_INFORMATIONW *PSTI_DEVICE_INFORMATIONW;
struct STIDEVICEA;
typedef struct IStillImageA IStillImageA,*PSTIA;
typedef struct STIDEVICEA* PSTIDEVICEA;
typedef struct STI_DEVICE_INFORMATIONA *PSTI_DEVICE_INFORMATIONA;
HRESULT WINAPI StiCreateInstanceA(HINSTANCE hinst, DWORD ver, PSTIA *ppSti,
void **punk);
HRESULT WINAPI StiCreateInstanceW(HINSTANCE hinst, DWORD ver, PSTIW *ppSti,
void **punk);
*/
typedef struct _STI_DEV_CAPS {
DWORD dwGeneric;
} STI_DEV_CAPS, *PSTI_DEV_CAPS;
typedef struct _STI_DEVICE_STATUS {
DWORD dwSize;
DWORD StatusMask;
DWORD dwOnlineState;
DWORD dwHardwareStatusCode;
DWORD dwEventHandlingState;
DWORD dwPollingInterval;
} STI_DEVICE_STATUS, *PSTI_DEVICE_STATUS;
typedef struct _ERROR_INFOA {
DWORD dwSize;
DWORD dwGenericError;
DWORD dwVendorError;
CHAR szExtendedErrorText[255];
} STI_ERROR_INFOA, *PSTI_ERROR_INFOA;
typedef struct _ERROR_INFOW {
DWORD dwSize;
DWORD dwGenericError;
DWORD dwVendorError;
WCHAR szExtendedErrorText[255];
} STI_ERROR_INFOW, *PSTI_ERROR_INFOW;
typedef struct _STI_DIAGA {
DWORD dwSize;
DWORD dwBasicDiagCode;
DWORD dwVendorDiagCode;
DWORD dwStatusMask;
STI_ERROR_INFOA sErrorInfo;
} STI_DIAGA, *LPSTI_DIAGA;
typedef struct _STI_DIAGW {
DWORD dwSize;
DWORD dwBasicDiagCode;
DWORD dwVendorDiagCode;
DWORD dwStatusMask;
STI_ERROR_INFOW sErrorInfo;
} STI_DIAGW, *LPSTI_DIAGW;
[
object,
uuid(6CFA5A80-2DC8-11D0-90EA-00AA0060F86C),
pointer_default(unique)
]
interface IStiDevice : IUnknown
{
HRESULT Initialize(HINSTANCE hinst, LPCWSTR pwszDeviceName, DWORD
dwVersion, DWORD dwMode);
HRESULT GetCapabilities(PSTI_DEV_CAPS pDevCaps);
HRESULT GetStatus(PSTI_DEVICE_STATUS pDevStatus);
HRESULT DeviceReset();
HRESULT Diagnostic(LPSTI_DIAG pBuffer);
HRESULT Escape(STI_RAW_CONTROL EscapeFunction, LPVOID lpInData, DWORD
cbInDataSize, LPVOID pOutData, DWORD dwOutDataSize, LPDWORD pdwActualData);
HRESULT GetLastError(LPDWORD pdwLastDeviceError);
HRESULT LockDevice(DWORD dwTimeOut);
HRESULT UnLockDevice();
HRESULT RawReadData(LPVOID lpBuffer, LPDWORD lpdwNumberOfBytes,
LPOVERLAPPED lpOverlapped);
HRESULT RawWriteData(LPVOID lpBuffer, DWORD nNumberOfBytes, LPOVERLAPPED
lpOverlapped);
HRESULT RawReadCommand(LPVOID lpBuffer, LPDWORD lpdwNumberOfBytes,
LPOVERLAPPED lpOverlapped);
HRESULT RawWriteCommand(LPVOID lpBuffer, DWORD nNumberOfBytes, LPOVERLAPPED
lpOverlapped);
HRESULT Subscribe(LPSTISUBSCRIBE lpSubscribe);
HRESULT GetLastNotificationData(LPSTINOTIFY lpNotify);
HRESULT UnSubscribe();
HRESULT GetLastErrorInfo(STI_ERROR_INFO *pLastErrorInfo);
}
/*
* IStillImageW
*/
[
object,
uuid(641BD880-2DC8-11D0-90EA-00AA0060F86C),
pointer_default(unique)
]
interface IStillImageW : IUnknown
{
HRESULT Initialize(HINSTANCE hinst, DWORD dwVersion);
HRESULT GetDeviceList(DWORD dwType, DWORD dwFlags, DWORD *pdwItemsReturned,
LPVOID* ppBuffer);
HRESULT GetDeviceInfo(LPWSTR pwszDeviceName, LPVOID* ppBuffer);
HRESULT CreateDevice(LPWSTR pwszDeviceName, DWORD dwMode, PSTIDEVICE*
pDevice, LPUNKNOWN* punkOuter);
HRESULT GetDeviceV
RC file translation via winehq?
Hey All you web programmers out there! How hard to you think it would be to rig up a web page for people to do translations for wine on? Have a web page (translate.winehq.org?) into which we feed in all the .rc files and maybe even parts of WineHQ, and show the translations for each language and bits that are missing ... then accumulate all the bits of translation somehow so they can be sumbitted back to wine-patches. I think there's plenty of people who'd do translation work for us if they didn't have to bother learning about how to submit patches or understand how .rc files work. Mike
video4linux - wine
Question: Is there support for video4linux devices with wine? Is there some support for webcams? What are the settings (config)? I couldn't find anything useful on google concerning this issue -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org MediaHost™ at www.mediahost.org Skype: startcom Phone: +1.213.341.0390
wineserver: fix get_update_region for desktop window
Calling SetSysColor in the current cvs version of wine causes an infinite loop
in update_now in dlls/user/painting.c. As I understand it, the problem is the
following: get_update_flags will promote it's child window argument to the
next child window (via a wineserver call to get_update_region), if the
current child doesn't need any repaint. Calling get_update_flags on the
desktop window will always return a repaint flag, so it never gets ahead. The
attached patch automatically promotes the child window argument to the first
child, if called on the desktop window. I don't know if this really is the
desired behaviour. Another fix would be to not return any repaint flags for
the desktop window.
Ciao,
Michael
Index: server/window.c
===
RCS file: /home/wine/wine/server/window.c,v
retrieving revision 1.36
diff -u -r1.36 window.c
--- server/window.c 7 Dec 2004 17:31:53 - 1.36
+++ server/window.c 4 Jan 2005 23:16:12 -
@@ -1632,7 +1632,7 @@
}
}
-if (!(reply->flags = get_update_flags( win, flags )))
+if (win == top_window || !(reply->flags = get_update_flags( win, flags )))
{
/* if window doesn't need any repaint, check the children */
if (!(flags & UPDATE_NOCHILDREN) &&
Re: [OLE #21] Make apartment access thread safe, rework OLE TLS management (take 2)
Mike Hearn wrote: On Tue, 04 Jan 2005 16:35:15 -0600, Robert Shearman wrote: and obviously increment COM_CurrentInfo()->inits in CoInitializeEx. And we should only add a reference to the apartment once in CoInitializeEx. What does that buy us that a 1:1 mapping between CoInitializeEx and apartment refs doesn't? I'm not sure why refcounting the OLETLS structure is useful. If you refcount the apartment then you could get the following situation: Thread1: CoInitialize(MTA) Thread2: CoInitialize(MTA) - note both threads now have a pointer to the same apt Thread1: CoUninitialize() - still has pointer to MTA Thread2: CoUninitialize() - detects apartment being destroyed and removes pointer to MTA Thread1: Some marshalling function - BOOM! using free'd memory. If you remove the pointer to the apartment on every CoUninitialize then you will break applications depending on it not separating from the apartment until the last CoUninitialize. Rob
Re: [OLE #21] Make apartment access thread safe, rework OLE TLS management (take 2)
On Tue, 04 Jan 2005 16:35:15 -0600, Robert Shearman wrote: > and obviously increment COM_CurrentInfo()->inits in CoInitializeEx. And > we should only add a reference to the apartment once in CoInitializeEx. What does that buy us that a 1:1 mapping between CoInitializeEx and apartment refs doesn't? I'm not sure why refcounting the OLETLS structure is useful.
Re: [OLE #21] Make apartment access thread safe, rework OLE TLS management (take 2)
Mike Hearn wrote:
On Tue, 2005-01-04 at 15:27 -0600, Robert Shearman wrote:
Because inits should be thread-local, not apartment scoped.
NtCurrentTeb()->ReservedForOle should be set to NULL when the matching
CoUninitialize is called, not when the apartment is destroyed.
I was under the impression that CoSetState/*ErrorInfo weren't tied to
apartments at all, hence the whole uninitialised apartments thing. So
it's not right to set ReservedForOle to NULL when CoUninitialise is
called with this patch because ReservedForOle now points to a struct
oletls not an apartment (which should be refcounted so CoUninitialise in
the MTA doesn't trigger its destruction).
You are right. My tests show that the TLS state struct isn't be freed
when the final CoUninitialize is called. However, it should still detach
from the apartment. I believe we should do something like this in
CoUninitialize:
if (!--COM_CurrentInfo()->inits)
{
COM_ApartmentRelease(COM_CurrentInfo()->apt);
COM_CurrentInfo()->apt = NULL;
}
and obviously increment COM_CurrentInfo()->inits in CoInitializeEx. And
we should only add a reference to the apartment once in CoInitializeEx.
That does leave the question of how to free the OLE TLS data though.
Presumably in a THREAD_DETACH notification.
That sounds like the best plan, otherwise we will leak a small amount of
memory for each thread that uses COM functions.
Rob
Re: ptrace single-stepping change breaks Wine
Mike Hearn <[EMAIL PROTECTED]> wrote: > > Also a precise description of what flex-mmap does would be good. Google > wasn't too informative, best I could get was that it means mmap > allocates from the "top" of the address space down. But where is the top > exactly? Ingo has described it thus: before: 0x0800 ... binary code 0x08xx ... brk area 0x4000 ... start of mmap, new mmaps go after old ones 0xbfxx ... stack after: 0x0800 ... binary code 0x08xx ... brk area 0xbfxx ... _end_ of all mmaps, new mmaps go below old ones 0xbfyy ... stack the 'after' layout guarantees that brk area (malloc()) can grow unlimited and mmap() can grow unlimited - they will meet somewhere inbetween when almost all of the VM is used up. [the 'top' of the mmaps in the 'after' layout is constrained by the stack ulimit - the stack must still fit and we never allocate into the stack's yet unallocated and growable hole.] with the 'before' layout we've got 900 MB for brk() and 1.9GB for mmaps() - a rigid limit.
Re: [OLE #21] Make apartment access thread safe, rework OLE TLS management (take 2)
On Tue, 2005-01-04 at 15:27 -0600, Robert Shearman wrote: > Because inits should be thread-local, not apartment scoped. > NtCurrentTeb()->ReservedForOle should be set to NULL when the matching > CoUninitialize is called, not when the apartment is destroyed. I was under the impression that CoSetState/*ErrorInfo weren't tied to apartments at all, hence the whole uninitialised apartments thing. So it's not right to set ReservedForOle to NULL when CoUninitialise is called with this patch because ReservedForOle now points to a struct oletls not an apartment (which should be refcounted so CoUninitialise in the MTA doesn't trigger its destruction). That does leave the question of how to free the OLE TLS data though. Presumably in a THREAD_DETACH notification.
Re: dcom95.exe removed from sf.net
Ivan Leo Puoti wrote: Hem, Mike I did ask about this on wine-devel and got no answers. I am *not* the sort of person that would take decisions like that one without discussing it first, but as nobody answered I thought nobody cared, it is not my intent to interfere with anything. I was puzzled by this, because I shared Mike's concern that you unilaterally removed this file, and it seemed abrupt and unannounced to me as well. So I searched around, and I see that you brought this up in April, and then nicely followed through by submitting patches to change Wine to not point to SF, but instead to Microsoft. So, I guess that the only thing we could have asked is if you had posted a note saying something to the effect 'okay, guys, now that I cleaned up the code to not point to SF, I'm removing the file now...', which would have wacked us with the clue bat. And it's a bit tough to ask us to remember things 8 months out of context... But it is clear to me that you did try to do 'the right thing', and we jumped down your throat a bit too quickly. Sorry about that. I just don't think it's nice to violate the sf.net rules, and I beleive it's disrispectful to other projects. Closed source files can be useful to linux users, but thins is no excuse. If the wine community thinks this the sf TOS isn't important, fine, but I disassociate myself from such a decision. I think we all agree that we want to respect their wishes. Jer tells me it's deleted now; anyone still pointing to SF needs to update ASAP. Cheers, Jeremy
Re: [OLE #21] Make apartment access thread safe, rework OLE TLS management (take 2)
Mike Hearn wrote:
On Tue, 2005-01-04 at 12:21 -0600, Robert Shearman wrote:
HRESULT WINAPI CoGetState(IUnknown ** ppv)
{
- APARTMENT * apt = COM_CurrentInfo();
+HRESULThr = E_FAIL;
- FIXME("\n");
+FIXME("possible stub\n");
I believe the function does everything that is required of it - the only
problem is that we don't currently do anything with the state. I'm not
sure if we should though.
Do we actually have any docs on this function? I agree the "possible
stub" fixme is annoying though so I'll remove it.
No. All I know is that native oleaut32 uses it for some purpose.
This should be moved into the TLS struct, not removed entirely.
inits has been subsumed into the refcount, each CoInitialize adds a ref.
Why is it still needed?
Because inits should be thread-local, not apartment scoped.
NtCurrentTeb()->ReservedForOle should be set to NULL when the matching
CoUninitialize is called, not when the apartment is destroyed.
Here's the updated patch.
Mike Hearn <[EMAIL PROTECTED]>
- Make apartment access thread-safe by introducing refcounting and wider
usage of the apartment lock
- Rework OLE TLS management to eliminate uninitialised apartments and
parent chaining
Rob
Re: ptrace single-stepping change breaks Wine
Context: this is not about ptrace stuff, but rather Thomas Sailors original problem which seems to be flex-mmap related. On Fri, 2004-12-31 at 16:51 +0100, Thomas Sailer wrote: > On Freitag 31 Dezember 2004 14.31, Mike Hearn wrote: > > > What about this patch? > > This works now. Happy new year... I'm afraid Alexandre has decided not to apply this patch (the ABI personality syscall). His reasoning is as follows: - There are a million kernel patches out there which use the ABI personality system to break stuff, which means that realistically we have no idea what it does - Therefore, using it would be a big support problem as it may even switch off stuff (new features etc) we want, so this system doesn't really scale - It'd be a lot better to provide a "disable this mmap feature/behaviour" flag for each thing that changes it, or *even* better to make it opt-in as having to change the sources to make old apps work again kind of defeats the point of backwards compatibility (ie, old apps should continue to work as-is) - Another possibility would be to create a new mmap API that lets us ask for exactly what we want, instead of second-guessing the kernel. I don't know exactly what sort of an API Alexandre has in mind here, perhaps he could describe it. - So rather than apply the patch, we have to figure out why flex-mmap is breaking this program and add yet more magic VM code to stop it from happening :( Could you upload a +relay,+tid,+seh,+msgbox trace somewhere please? Of course if you could investigate it yourself that'd be the best thing. I wasn't sure whether to CC some kernel people or not, but it seems from previous threads that the ABI personality syscall system is meant for people like us who are trying to keep "legacy" binaries working. Unfortunately this sort of unbreak-me-please flag isn't really what we need/want from the kernel. Also a precise description of what flex-mmap does would be good. Google wasn't too informative, best I could get was that it means mmap allocates from the "top" of the address space down. But where is the top exactly? thanks -mike
Re: [QUARTZ] Use Interlocked* functions in AddRef and Release (RESEND)
On Tue, 2005-01-04 at 21:48, Alexandre Julliard wrote:
> Paul Vriens <[EMAIL PROTECTED]> writes:
>
> > TRACE("(%p)->()\n", iface);
> > -if (!--This->refCount)
> > +if (!InterlockedDecrement(&This->refCount))
> > {
> > CoTaskMemFree(This->ppFilters);
> > CoTaskMemFree(This);
>
> You also need to store the result of the decrement and have the
> function return that value instead of This->refCount, otherwise it's
> still not thread-safe.
OK. This will also mean fixing up 13 occurences of
if (!InterlockedDecrement(&This->
for QUARTZ alone.
I will fix them as well and resend ASAP.
Cheers,
Paul.
Re: [QUARTZ] Use Interlocked* functions in AddRef and Release (RESEND)
Paul Vriens <[EMAIL PROTECTED]> writes:
> TRACE("(%p)->()\n", iface);
> -if (!--This->refCount)
> +if (!InterlockedDecrement(&This->refCount))
> {
> CoTaskMemFree(This->ppFilters);
> CoTaskMemFree(This);
You also need to store the result of the decrement and have the
function return that value instead of This->refCount, otherwise it's
still not thread-safe.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Mandrake packages
Mike Hearn wrote: Hi, The downloads page advertises support for 10.1, 10.0 and 9.2 Mandrake packages but it seems only 10.1 RPMs are provided. Should the download page be updated to say only 10.1 is available? I'd rather actually it was built on an older Mandrake and then fixed to work on later versions too if that was necessary, as I suspect the only real difference is glibc symvers. It works on Mandrake 9.2, I don't know why it won't run on 10.0 correctly, I'm looking into this. Ivan.
Re: dcom95.exe removed from sf.net
Do you mean you changed SourceForge, or that the new file you posted is a different installer somehow? I'm confused ... I'm not touching sourceforge Ivan.
Re: dcom95.exe removed from sf.net
On Tue, 04 Jan 2005 20:44:44 +0100, Ivan Leo Puoti wrote: > Hello, I replaced the sdk redistributable installer with the actualy > installer, as the licence > allows redistribution of the installer for end users only. It also makes > the installation easier. Do you mean you changed SourceForge, or that the new file you posted is a different installer somehow? I'm confused ...
Re: dcom95.exe removed from sf.net
Hem, Mike I did ask about this on wine-devel and got no answers. I am *not* the sort of person that would take decisions like that one without discussing it first, but as nobody answered I thought nobody cared, it is not my intent to interfere with anything. I just don't think it's nice to violate the sf.net rules, and I beleive it's disrispectful to other projects. Closed source files can be useful to linux users, but thins is no excuse. If the wine community thinks this the sf TOS isn't important, fine, but I disassociate myself from such a decision. Ivan.
Re: dcom95.exe removed from sf.net
Oh well, might be good to do that then... I just provided (in case it's needed) http://lisas.de/~andi/wine_files/dcom95.exe http://lisas.de/~andi/wine_files/dcom95.exe.md5 (a copy of the nonsolomicrosoft/ file) which is on the rhlx01 server, MASSIVE bandwidth... Hello, I replaced the sdk redistributable installer with the actualy installer, as the licence allows redistribution of the installer for end users only. It also makes the installation easier. The file contains a Microsoft digital signature. The new url is http://spazioinwind.libero.it/nonsolomicrosoft/DCom95.Exe the md5sum is b5b69ccd1691fbc43e87a719c1546dcd Ivan.
Mandrake packages
Hi, The downloads page advertises support for 10.1, 10.0 and 9.2 Mandrake packages but it seems only 10.1 RPMs are provided. Should the download page be updated to say only 10.1 is available? I'd rather actually it was built on an older Mandrake and then fixed to work on later versions too if that was necessary, as I suspect the only real difference is glibc symvers. thanks -mike
[OLE #21] Make apartment access thread safe, rework OLE TLS management (take 2)
On Tue, 2005-01-04 at 12:21 -0600, Robert Shearman wrote:
> I can't see the need to make this non-static at the moment.
Right, I made it non-static when the lock was taken inside an inlined
function earlier, but I got rid of that at the end. It can go back to
being static.
> I don't really like functions like this doing special things on certain
> input values. I don't think it is that big a deal to require the few
> callers of this function to go to the effort of getting the apartment
> themselves.
It was done that way so it's inside the lock, ie the TEB apt field
should be cleared before the apartment is freed, otherwise there's a
time when it's pointing to garbage.
But thinking about it, as that's TLS it probably doesn't matter. So I'll
remove this feature.
> I think it would be cleaner to put the ref-count increment inside the
> apartment creation function. That way, no callers of the
> COM_CreateApartment function can make the mistake of creating an
> apartment without incrementing its refcount.
OK, done.
> > HRESULT WINAPI CoGetState(IUnknown ** ppv)
> > {
> >-APARTMENT * apt = COM_CurrentInfo();
> >+HRESULThr = E_FAIL;
> >
> >-FIXME("\n");
> >+FIXME("possible stub\n");
> >
> >
> >
>
> I believe the function does everything that is required of it - the only
> problem is that we don't currently do anything with the state. I'm not
> sure if we should though.
Do we actually have any docs on this function? I agree the "possible
stub" fixme is annoying though so I'll remove it.
> This should be moved into the TLS struct, not removed entirely.
inits has been subsumed into the refcount, each CoInitialize adds a ref.
Why is it still needed?
> > LPVOID ErrorInfo;/* thread error info */
> >
> >
>
> You can remove this - it should no longer be needed.
Right, done.
> >+if (!NtCurrentTeb()->ReservedForOle)
> >+NtCurrentTeb()->ReservedForOle = HeapAlloc(GetProcessHeap(),
> >HEAP_ZERO_MEMORY, sizeof(struct oletls));
> >
> >
>
> I guess are ignoring failures from HeapAlloc then. There isn't really
> much we can do about it anyway though.
Indeed, we're a bit hosed in this situation. I guess the relevant parts
of the code should return an appropriate error code for that specific
API though.
> Nothing should reference it directly as the offset is OS dependent.
Hehe, whatever :) I've seen too many "neat tricks" based on referencing
stuff at that offset. Still I took the comment out as we don't know the
format of that object anyway, so it's a bit useless
Here's the updated patch.
Mike Hearn <[EMAIL PROTECTED]>
- Make apartment access thread-safe by introducing refcounting and wider
usage of the apartment lock
- Rework OLE TLS management to eliminate uninitialised apartments and
parent chaining
--- dlls/ole32/compobj.c (revision 67)
+++ dlls/ole32/compobj.c (local)
@@ -30,6 +30,8 @@
* - Rewrite the CoLockObjectExternal code, it does totally the wrong
* thing currently (should be controlling the stub manager)
*
+ * - Make the MTA dynamically allocated and refcounted
+ *
* - Implement the service control manager (in rpcss) to keep track
* of registered class objects: ISCM::ServerRegisterClsid et al
* - Implement the OXID resolver so we don't need magic pipe names for
@@ -99,7 +101,8 @@ static void COM_ExternalLockFreeList(voi
const CLSID CLSID_StdGlobalInterfaceTable = { 0x0323, 0, 0, {0xc0, 0, 0,
0, 0, 0, 0, 0x46} };
-APARTMENT MTA, *apts;
+APARTMENT MTA;
+struct list apts = LIST_INIT( apts );
static CRITICAL_SECTION csApartment;
static CRITICAL_SECTION_DEBUG critsect_debug =
@@ -236,6 +239,7 @@ static void COM_UninitMTA(void)
MTA.oxid = 0;
}
+
/* creates an apartment structure which stores OLE thread-local
* information. Call with COINIT_UNINITIALIZED to create an apartment
* that will be initialized with a model later. Note: do not call
@@ -243,100 +247,134 @@ static void COM_UninitMTA(void)
* with a different COINIT value */
APARTMENT* COM_CreateApartment(DWORD model)
{
-APARTMENT *apt;
-BOOL create = (NtCurrentTeb()->ReservedForOle == NULL);
+APARTMENT *apt = COM_CurrentApt();
-if (create)
+if (!apt)
{
+if (model & COINIT_MULTITHREADED)
+{
+TRACE("thread 0x%lx is entering the multithreaded apartment\n",
GetCurrentThreadId());
+COM_CurrentInfo()->apt = &MTA;
+return apt;
+}
+
+TRACE("creating new apartment, model=%ld\n", model);
+
apt = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(APARTMENT));
apt->tid = GetCurrentThreadId();
DuplicateHandle(GetCurrentProcess(), GetCurrentThread(),
GetCurrentProcess(), &apt->thread,
THREAD_ALL_ACCESS, FALSE, 0);
-}
-else
-apt = NtCurrentTeb()->ReservedForOle;
-list_init(&apt->proxies);
-list_init(&apt->stubmgrs);
-apt->oidc =
Re: [OLE #21] Make apartment access thread safe, rework OLE TLS management
Mike Hearn wrote:
On Mon, 2005-01-03 at 11:47 -0600, Robert Shearman wrote:
Also, it may be best to split up the apartment structure into the stuff
that really is apartment-local and the stuff that is thread-local, and
then we have NtCurrentTeb()->ReservedForOle point to the thread-local
structure, which has a member that points to the apartment struct.
That makes sense. I'll implement it now.
One other thing: we also need the MTA to be dynamically allocated and
destroyed and so therefore also ref counted.
Rob
OK, I implemented the new OLE TLS management, and it clears up the code
a lot, no more confusing apt->parent business.
I didn't make the MTA dynamically allocated because this patch already
contains two changes that could really have been one given enough pain,
so I added it to the todo list instead.
I think this patch is pretty much ready to go, the OLE TLS changes are
straightforward enough, so I'm CCing wine-patches. Any comments on the
last changes are welcome as usual.
Alexandre: this patch is against the previous patches sent, so they must
be applied in order.
Mike Hearn <[EMAIL PROTECTED]>
- Make apartment access thread-safe by introducing refcounting and wider
usage of the apartment lock
- Rework OLE TLS management to eliminate uninitialised apartments and
parent chaining
--- dlls/ole32/compobj.c (revision 67)
+++ dlls/ole32/compobj.c (local)
@@ -30,6 +30,8 @@
* - Rewrite the CoLockObjectExternal code, it does totally the wrong
* thing currently (should be controlling the stub manager)
*
+ * - Make the MTA dynamically allocated and refcounted
+ *
* - Implement the service control manager (in rpcss) to keep track
* of registered class objects: ISCM::ServerRegisterClsid et al
* - Implement the OXID resolver so we don't need magic pipe names for
@@ -99,16 +101,17 @@ static void COM_ExternalLockFreeList(voi
const CLSID CLSID_StdGlobalInterfaceTable = { 0x0323, 0, 0, {0xc0, 0, 0, 0,
0, 0, 0, 0x46} };
-APARTMENT MTA, *apts;
+APARTMENT MTA;
+struct list apts = LIST_INIT( apts );
-static CRITICAL_SECTION csApartment;
+CRITICAL_SECTION csApartment;
static CRITICAL_SECTION_DEBUG critsect_debug =
{
0, 0, &csApartment,
{ &critsect_debug.ProcessLocksList, &critsect_debug.ProcessLocksList },
0, 0, { 0, (DWORD)(__FILE__ ": csApartment") }
};
-static CRITICAL_SECTION csApartment = { &critsect_debug, -1, 0, 0, 0, 0 };
+CRITICAL_SECTION csApartment = { &critsect_debug, -1, 0, 0, 0, 0 };
I can't see the need to make this non-static at the moment.
/*
* This lock count counts the number of times CoInitialize is called. It is
@@ -236,6 +239,7 @@ static void COM_UninitMTA(void)
MTA.oxid = 0;
}
+
/* creates an apartment structure which stores OLE thread-local
* information. Call with COINIT_UNINITIALIZED to create an apartment
* that will be initialized with a model later. Note: do not call
@@ -243,100 +247,138 @@ static void COM_UninitMTA(void)
* with a different COINIT value */
APARTMENT* COM_CreateApartment(DWORD model)
{
-APARTMENT *apt;
-BOOL create = (NtCurrentTeb()->ReservedForOle == NULL);
+APARTMENT *apt = COM_CurrentApt();
-if (create)
+if (!apt)
{
+if (model & COINIT_MULTITHREADED)
+{
+TRACE("thread 0x%lx is entering the multithreaded apartment\n",
GetCurrentThreadId());
+COM_CurrentInfo()->apt = &MTA;
+return apt;
+}
+
+TRACE("creating new apartment, model=%ld\n", model);
+
apt = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(APARTMENT));
apt->tid = GetCurrentThreadId();
DuplicateHandle(GetCurrentProcess(), GetCurrentThread(),
GetCurrentProcess(), &apt->thread,
THREAD_ALL_ACCESS, FALSE, 0);
-}
-else
-apt = NtCurrentTeb()->ReservedForOle;
-list_init(&apt->proxies);
-list_init(&apt->stubmgrs);
-apt->oidc = 1;
-
-apt->model = model;
-if (model & COINIT_APARTMENTTHREADED) {
- /* FIXME: how does windoze create OXIDs? */
- apt->oxid = MTA.oxid | GetCurrentThreadId();
- apt->win = CreateWindowA(aptWinClass, NULL, 0,
- 0, 0, 0, 0,
- 0, 0, OLE32_hInstance, NULL);
- InitializeCriticalSection(&apt->cs);
-}
-else if (!(model & COINIT_UNINITIALIZED)) {
- apt->parent = &MTA;
- apt->oxid = MTA.oxid;
-}
-EnterCriticalSection(&csApartment);
-if (create)
-{
-if (apts) apts->prev = apt;
-apt->next = apts;
-apts = apt;
+list_init(&apt->stubmgrs);
+apt->oidc = 1;
+InitializeCriticalSection(&apt->cs);
+
+apt->model = model;
+
+/* we don't ref the apartment as CoInitializeEx will do it for us */
+
+if (model & COINIT_APARTMENTTHREADED)
+{
+/* FIXME: how does windoze create OXIDs? */
+apt
Re: Change some d3d9 RACE( "stub ") into FIXME ("stub")
On Tue, Jan 04, 2005 at 05:21:41PM +, Mike Hearn wrote: > One thing to be aware of when doing this is that some of these calls may > be used very frequently, and the cost of outputting a fixme for each one > is high. Because TRACEs are not output by default making a stub a TRACE is > often used in this situation. Not to mention the users who will generate bug reports saying 'look it does not work because of this FIXME' whereas this FIXME is just for an obscure function which does not do anything important and can be let as a stub for ages. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Native unix style paths in wine common dialogs
Mike Hearn wrote: > On Tue, 04 Jan 2005 11:22:00 -0500, Dan Notestein wrote: >>Btw, if anyone is interested we also have another module which >>can be used to convert the windows-style drive letters returned >>by the common dialogs into unix-style paths (if you want to use >>these paths will "normal" file i/o functions such as C++ stream i/o). > > Isn't that what wine_get_unix_file_name does? I was responsible for this bit of hackery, so I'll try to explain. The patch Dan sent in before only changes how the common dialogs display the filenames, it doesn't change how they deal with them internally. The GetOpenFileName() function returns a structure containing the filenames the user selected. Since the patch only changed the appearance of the dialog, GetOpenFileName() would still report that the user had opened the file "e:\\foo\\bar" instead of "/tmp/foo/bar". This may or may not be what you want. If you're porting a windows application that passes these filenames to Win32 functions like OpenFile(), it will work. But if you're passing those filenames to native unix functions like fopen() (or to c++ iostreams, which in turn call fopen()), you'll have problems. The module Dan was referring to above implements wrappers around the common dialog box routines that return filenames. It just converts the filenames that the real routine returns to us to unix-style names by calling wine_get_unix_file_name, and properly modifying the structure that gets returned. It was non-invasive, and works independently of the patch that affects the appearance of the dialogs. You could make a case that the appearance of the dialogs should be controlled by a registry key, but the type of filenames they return must be known by the application for it to function properly. Eric
Re: Native unix style paths in wine common dialogs
On Tue, Jan 04, 2005 at 05:29:10PM +, Mike Hearn wrote: > On Tue, 2005-01-04 at 12:11 -0500, Dimitrie O. Paun wrote: > > Actually, there are two independent issues here: > > 1. How paths are presented to the user > > This is user preference, and should be a registry setting > > Yeah. It'd be nice to improve this, but we're limited by the dumb design > of the open dialog API. We can't change its UI design very much and we > can't use native file dialogs because apps can customise them. Unless > we're OK with apps having a mix of native and win32 dialogs of course. > > There's also the confusion from selecting /home/mike/Foo.doc in the open > dialog but having the title bar say X:\foo.doc or whatever. This is why it's a user preference. But this, mind you, has nothing to do with a native dialog. This preference would control the behaviour of *our* dialog. Our vs. native dialog is a completely different setting, and it's a app-specific one, as noted below. > > 2. How paths are presented to the app > > This is something that needs to be per app. One way to do it > > would be to follow Miscrosoft and ornate apps somehow (the > > same they do for themable apps) via some sort of manifest > > that would request Unix paths instead of DOS ones. Same > > mechanism could be used for other things, like requesting > > native open dialogs instead of ours, etc. > > Mmmm, the manifest thing seems horribly complicated to me. Seems like a > use of XML just for the sake of it. When extending win32 we don't have > to follow their dubious design decisions (one reason why I'm not keen > on magic PIDLs and such). I have no idea how their manifest looks like, be it XML or not, but I find the idea OK. Being an app specific setting, it should be bound to the application somehow. And being able to "stamp" the app with ceratin settings sounds better then inveting all sorts of apps, for things that are truly app global. -- Dimi.
Re: Native unix style paths in wine common dialogs
On Tue, 2005-01-04 at 12:11 -0500, Dimitrie O. Paun wrote: > Actually, there are two independent issues here: > 1. How paths are presented to the user > This is user preference, and should be a registry setting Yeah. It'd be nice to improve this, but we're limited by the dumb design of the open dialog API. We can't change its UI design very much and we can't use native file dialogs because apps can customise them. Unless we're OK with apps having a mix of native and win32 dialogs of course. There's also the confusion from selecting /home/mike/Foo.doc in the open dialog but having the title bar say X:\foo.doc or whatever. > 2. How paths are presented to the app > This is something that needs to be per app. One way to do it > would be to follow Miscrosoft and ornate apps somehow (the > same they do for themable apps) via some sort of manifest > that would request Unix paths instead of DOS ones. Same > mechanism could be used for other things, like requesting > native open dialogs instead of ours, etc. Mmmm, the manifest thing seems horribly complicated to me. Seems like a use of XML just for the sake of it. When extending win32 we don't have to follow their dubious design decisions (one reason why I'm not keen on magic PIDLs and such). thanks -mike
Re: keybd_event patch and default combobox height patch
Peter Hercek wrote:
server/queue.c
Fixes an error in keybd_event function. This function sends events even
between different processes on win32. This was not handled in wine.
dlls/user/combo.c
The default size for comboxes was 2 pixels bigger in wine at the
standard dpi.
The patches are against wine 20041019.
Index: server/queue.c
===
--- server/queue.c (revision 29655)
+++ server/queue.c (working copy)
@@ -1073,6 +1073,8 @@
*msg_code = msg->msg;
if (is_keyboard_msg( msg ))
{
+if (!input || !(input->focus) || !(input->active))
+input = foreground_input;
if (input && !(win = input->focus))
{
win = input->active;
Index: dlls/user/combo.c
===
--- dlls/user/combo.c (revision 29655)
+++ dlls/user/combo.c (working copy)
@@ -207,8 +207,10 @@
* The height of the text area is set in two ways.
* It can be set explicitly through a combobox message or through a
* WM_MEASUREITEM callback.
- * If this is not the case, the height is set to 13 dialog units.
- * This height was determined through experimentation.
+ * If this is not the case, the height is set to 12 dialog units.
+ * This height was determined through experimentation. It was
+ * set to 13 originally but this led to higher comboboxes than
+ * in windows.
*/
static INT CBGetTextAreaHeight(
HWNDhwnd,
@@ -239,7 +241,7 @@
ReleaseDC(hwnd, hDC);
-iTextItemHeight = ((13 * baseUnitY) / 8);
+iTextItemHeight = ((12 * baseUnitY) / 8);
/*
* This "formula" calculates the height of the complete control.
These should have been sent as two separate patches. since they address two
different issues.
--
Tony Lambregts
Re: Native unix style paths in wine common dialogs
On Tue, Jan 04, 2005 at 04:57:15PM +, Mike Hearn wrote: > It needs to be an API switch really as it's a per-app thing, only programs > written to expect it should get UNIX names. But this is similar to the > discussion we had before and what form the API should take (no firm > decision made). Actually, there are two independent issues here: 1. How paths are presented to the user This is user preference, and should be a registry setting 2. How paths are presented to the app This is something that needs to be per app. One way to do it would be to follow Miscrosoft and ornate apps somehow (the same they do for themable apps) via some sort of manifest that would request Unix paths instead of DOS ones. Same mechanism could be used for other things, like requesting native open dialogs instead of ours, etc. -- Dimi.
Re: Native unix style paths in wine common dialogs
On Tue, 04 Jan 2005 11:30:32 -0500, Dimitrie O. Paun wrote: > This would be much better as a registry setting, not a compile > time option. It needs to be an API switch really as it's a per-app thing, only programs written to expect it should get UNIX names. But this is similar to the discussion we had before and what form the API should take (no firm decision made).
Re: Native unix style paths in wine common dialogs
On Tue, 04 Jan 2005 11:22:00 -0500, Dan Notestein wrote: > This patch allows winelib to be conditionally compiled with > USE_NATIVE_UNIX_PATHS macro. Enabling this will cause > the common dialogs to display using unix paths instead of drive > letters. Fantastic! What would rule even more is if this was not a conditional compilation flag, but something that could be toggled at runtime. That way you can have a single Wine installation that has both half-native winelib apps and regular win32 binaries run at once. As it is, this patch is only really useful for when you are distributing your own app-specific copy of Wine, no? > Btw, if anyone is interested we also have another module which > can be used to convert the windows-style drive letters returned > by the common dialogs into unix-style paths (if you want to use > these paths will "normal" file i/o functions such as C++ stream i/o). Isn't that what wine_get_unix_file_name does? thanks -mike
Re: Native unix style paths in wine common dialogs
On Tue, Jan 04, 2005 at 11:22:00AM -0500, Dan Notestein wrote: > This patch allows winelib to be conditionally compiled with > USE_NATIVE_UNIX_PATHS macro. Enabling this will cause > the common dialogs to display using unix paths instead of drive > letters. This would be much better as a registry setting, not a compile time option. -- Dimi.
Re: gdi/tests/metafile.c NT 4 fix
Dmitry Timoshkov wrote: "Jakob Eriksson" <[EMAIL PROTECTED]> wrote: --- dlls/gdi/tests/metafile.c 27 Dec 2004 17:46:36 - 1.4 +++ dlls/gdi/tests/metafile.c 3 Jan 2005 14:27:55 - @@ -185,8 +185,6 @@ ret = EnumEnhMetaFile(hdcDisplay, hMetafile, emf_enum_proc, dx, &rc); ok( ret, "EnumEnhMetaFile error %ld\n", GetLastError()); -ok(emr_processed, "EnumEnhMetaFile couldn't find EMR_EXTTEXTOUTA or EMR_EXTTEXTOUTW record\n"); - This defeats the whole purpose of the test, could you investigate what is going on? I'll try some other day. regards, Jakob
Re: dcom95.exe removed from sf.net
Hi, On Tue, Jan 04, 2005 at 03:21:10PM +0100, Ivan Leo Puoti wrote: > Jeremy, we got this reply from the sourceforge staff, please remove the > file. Oh well, might be good to do that then... I just provided (in case it's needed) http://lisas.de/~andi/wine_files/dcom95.exe http://lisas.de/~andi/wine_files/dcom95.exe.md5 (a copy of the nonsolomicrosoft/ file) which is on the rhlx01 server, MASSIVE bandwidth... Andreas Mohr
Re: dcom95.exe removed from sf.net
On Tue, 04 Jan 2005 15:21:10 +0100, Ivan Leo Puoti wrote: > Jeremy, we got this reply from the sourceforge staff, please remove the file. Why don't you ask them why they're hosting the core fonts which are not open source licensed then? Actually don't bother, we don't want to cause the font guys hassle too. The policy is quite clearly there to stop proprietary software companies using the SF mirror network to distribute their own products, not to stop open source projects hosting downloads that will be useful to the Linux community. Really Ivan, you may be technically in the right here, but the fact is you should absolutely have discussed this on wine-devel first. That file is referenced by various third party scripts/howtos and such, I know this because I've written these things before. By taking this matter into your own hands and not discussing it first you went behind the backs of the community and broke a lot of code and documentation by doing so. My IE installer script is one example iirc, but I'm sure there are others. Your admin access on Sourceforge is so you can upload the Mandrake RPMs, it is *not* so you can interfere with decisions that were made a long time ago at will. Please remember that in future. thanks -mike
Re: dcom95.exe removed from sf.net
Jeremy, we got this reply from the sourceforge staff, please remove the file. Message: Logged In: YES user_id=597273 Greetings, Only software licensed under an Open Source license may be hosted on SourceForge.net resources. As such, no, it may not. Thank you, David Burley Second Level Support Technician, SourceForge.net [EMAIL PROTECTED]
Re: Changed files to use interlocked functions
On Tue, Jan 04, 2005 at 02:59:45PM +0100, Paul Vriens wrote: > Are there AddRef's or Releases that don't need the modification? Or is it > OK to modify all of them? I think it's OK to modify them all. > What's the best way to generate mail/patches for this bulk. One email for > each file/dll? Inline or attached? One email per patch, one patch per dll, inlined. -- Dimi.
Re: Changed files to use interlocked functions
Paul Vriens wrote: Hi Mike, Are there AddRef's or Releases that don't need the modification? Or is it OK to modify all of them? Theoretically, COM classes that are registered with "ThreadingModel"="Apartment" do not need to use the atomic increment/decrement functions as they shouldn't be accessed by more than one thread at a time, but it shouldn't hurt to change them anyway. What's the best way to generate mail/patches for this bulk. One email for each file/dll? One patch for each DLL should be a good balance of reviewability and amount of work for Alexandre. Inline or attached? Whatever is easiest for you. Rob
Re: Changed files to use interlocked functions
Paul Vriens wrote: Are there AddRef's or Releases that don't need the modification? Or is it OK to modify all of them? I think it should be safe to do all of them. InterlockedIncrement is inline, so it shouldn't have any performance penalty. It may not strictly be necessary for objects in single threaded apartments, but at least nobody will copy thread unsafe code into an object that lives in a multi threaded apartment. What's the best way to generate mail/patches for this bulk. One email for each file/dll? Inline or attached? I'd do one per dll. Mike
Re: Changed files to use interlocked functions
Hi Mike, > > > Paul Vriens wrote: > >> the Janitorial page shows that the "Use Interlocked functions in AddRef >> and Release methods" project is finished. >> >> There are however several files (at least 135) that still use the >> non-interlocked method. Especially ddraw, d3*, dm*, avifil32 and some >> ole/oleaut32. >> >> Do they still need to be changed ? > > Sure. I probably didn't catch all occurences of AddRef and Release that > needed modification. You can update the Janitorial page yourself by > submitting a patch against the LostWages CVS which holds the WineHQ > website. > > Mike > Are there AddRef's or Releases that don't need the modification? Or is it OK to modify all of them? What's the best way to generate mail/patches for this bulk. One email for each file/dll? Inline or attached? Cheers, Paul.
Re: Changed files to use interlocked functions
Paul Vriens wrote: the Janitorial page shows that the "Use Interlocked functions in AddRef and Release methods" project is finished. There are however several files (at least 135) that still use the non-interlocked method. Especially ddraw, d3*, dm*, avifil32 and some ole/oleaut32. Do they still need to be changed ? Sure. I probably didn't catch all occurences of AddRef and Release that needed modification. You can update the Janitorial page yourself by submitting a patch against the LostWages CVS which holds the WineHQ website. Mike
Changed files to use interlocked functions
Hi, the Janitorial page shows that the "Use Interlocked functions in AddRef and Release methods" project is finished. There are however several files (at least 135) that still use the non-interlocked method. Especially ddraw, d3*, dm*, avifil32 and some ole/oleaut32. Do they still need to be changed ? Cheers, Paul.
Re: gdi/tests/metafile.c NT 4 fix
"Jakob Eriksson" <[EMAIL PROTECTED]> wrote: > --- dlls/gdi/tests/metafile.c 27 Dec 2004 17:46:36 - 1.4 > +++ dlls/gdi/tests/metafile.c 3 Jan 2005 14:27:55 - > @@ -185,8 +185,6 @@ > ret = EnumEnhMetaFile(hdcDisplay, hMetafile, emf_enum_proc, dx, &rc); > ok( ret, "EnumEnhMetaFile error %ld\n", GetLastError()); > > -ok(emr_processed, "EnumEnhMetaFile couldn't find EMR_EXTTEXTOUTA or > EMR_EXTTEXTOUTW record\n"); > - This defeats the whole purpose of the test, could you investigate what is going on? -- Dmitry.
Re: [LOSTWAGES] Add a short blurb about what Wine is on the About page
Mike McCormack wrote: Index: templates/en/about.template === RCS file: /home/wine/lostwages/templates/en/about.template,v retrieving revision 1.15 diff -u -r1.15 about.template --- templates/en/about.template 1 Dec 2004 22:15:11 - 1.15 +++ templates/en/about.template 4 Jan 2005 07:32:05 - @@ -4,6 +4,12 @@ About Wine +Wine is a translation layer (a program loader) capable of running +Windows applications on Linux and other POSIX compatible operating +systems. Windows programs running in Wine act as native programs would, +running without the performance or memory usage penalties of an emulator, +with a similar look and feel as other your desktop. What about: with a similar look and feel as other applications on your desktop. Tom
Re: build problem on current cvs [fixed]
Jack wrote in http://www.winehq.org/hypermail/wine-devel/2004/12/0720.html : Program received signal SIGSEGV, Segmentation fault. 0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 (gdb) bt #0 0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 #1 0x4009d06c in malloc () from /lib/i686/libc.so.6 #2 0x080525a0 in pp_xmalloc (size=11) at ../../../wine/libs/wpp/preproc.c:80 #3 0x0805264a in pp_xstrdup (str=0xbfffec68 "\"11:25:54\"") at ../../../wine/libs/wpp/preproc.c:108 It is probably caused by overwritting the allocated memory. The last changes of widl look well so I think it is some old hidden problem. Lookng at code I found a potential bug, but I'm not sure if it a bug. In parsers, both widl's and wpp's, strings are not duplicated whie adding to structures. If it helps, I'll see if it is correct at all. This is included in diffs: wy.diff and widl.diff. Could you try it? I also found another small bug in wpp, but it's not what we're looking for. I included it with some code cleanup in wpppreproc.diff. I swear I found this same error several months ago, but never submitted a patch (and can't find my old patch now). Your three patches solved the widl crash in current cvs for me. Alexandre, can you review / apply them? Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
