December 2004 - Wine-devel - list.winehq.org

Bug Busters
by James Hawkins 01 Dec '04

01 Dec '04

I have a totally non-original idea for sessions called Bug Busters where, at a designated time, a group of wine developers would get together on #winehackers (or some other channel). We would pick a bug (or maybe more) from wine's bug tracker and work together to fix the bug(s). This would serve several good purposed. First, we would be giving more attention to wine's bugzilla and getting rid of a lot of those bugs. Second, many newcomers can witness and take part in the wine development process. I'm sure everyone can remember how daunting it is to jump into wine development. Anyway, if anyone has any ideas or would like to take part in this, let me know and we'll get this started. -- James Hawkins

7 18

which classes support aggregation?
by James Hawkins 01 Dec '04

01 Dec '04

IClassFactory->CreateInstance aggregation check: "The CreateInstance method of IClassFactory takes pUnkOuter as the second member. This parameter must be null unless the class supports aggregation, which many don't." Where can I find out which classes support aggregation? -- James Hawkins

3 2

implementing DllCanUnloadNow questions
by James Hawkins 01 Dec '04

01 Dec '04

I sent this message a couple months ago, but I got no response so I'll try again. I would like to work on the DllCanUnloadNow janitorial task, but I was wondering if there are any patches or examples of dll's that correctly implement this so that I can do it right. Is LockServer(TRUE/FALSE) the same as this example? static HRESULT WINAPI SFCF_LockServer(LPCLASSFACTORY iface,BOOL dolock) { IClassFactoryImpl *This = (IClassFactoryImpl *)iface; FIXME("(%p)->(%d),stub!\n",This,dolock); return S_OK; } If they are the same, what is needed to complete this stub? I would think that there would be a refCount variable that is incremented if dolock is true and decremented if dolock is false. Also, should the LockServer functions be listed in the spec files of the dlls? After implementing LockServer, it should be an easy matter to do a check for refCount == 0 to see if the dll can be unloaded or not. Am I heading in the right direction? -- James Hawkins

3 4

Re: Always create a suspended thread in CreateThread and resume it if CREATE_SUSPENDED flag is not set as Windows does
by Robert Shearman 01 Dec '04

01 Dec '04

Dmitry Timoshkov wrote: >Hello, > >there is at least one application which crashes in CreateThread due >to a race between a creating thread and a newly created one. The problem >is that the tid address passed to CreateThread resides in the memory >block allocated with VirtualAlloc which gets freed once the newly created >thread starts running, and when CreateThread code attempts to store thread >id it crashes. > >It appears that Windows always creates suspended threads in CreateThread >and a created thread gets resumed later. Here is a snippet of the log >running a simple test program under NT strace (the test app just creates >a thread): > >hThread = CreateThread(NULL, 0, thread_proc, NULL, 0, &tid); >CloseHandle(hThread); > >... >117 796 792 NtCreateThread (0x1f03ff, 0x0, -1, 1243704, 1244568, 1, ... 60, {796, 800}, ) == 0x0 >118 796 792 NtRequestWaitReplyPort (40, {28, 52, new_msg, 0, 2013529912, 2147348480, 902, 2086471576} "\0\0\0\0\1\0\1\0x\1\23\0\320<\23\0<\0\0\0\34\3\0\0 \3\0\0" ... {28, 52, reply, 0, 796, 792, 2138, 0} "\0\0\0\0\1\0\1\0\0\0\0\0\320<\23\0<\0\0\0\34\3\0\0 \3\0\0" ) == 0x0 >119 796 792 NtResumeThread (60, ... 1, ) == 0x0 >120 796 792 NtClose (60, ... ) == 0x0 >... > >Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Always create a suspended thread in CreateThread and resume it > if CREATE_SUSPENDED flag is not set as Windows does. > >--- cvs/hq/wine/dlls/kernel/thread.c 2004-09-22 16:48:59.000000000 +0900 >+++ wine/dlls/kernel/thread.c 2004-12-01 18:04:52.000000000 +0800 >@@ -164,7 +164,7 @@ HANDLE WINAPI CreateRemoteThread( HANDLE > if (flags & STACK_SIZE_PARAM_IS_A_RESERVATION) stack_reserve = stack; > else stack_commit = stack; > >- status = RtlCreateUserThread( hProcess, NULL, (flags & CREATE_SUSPENDED) != 0, >+ status = RtlCreateUserThread( hProcess, NULL, TRUE, > NULL, stack_reserve, stack_commit, > THREAD_Start, info, &handle, &client_id ); > if (status == STATUS_SUCCESS) >@@ -172,6 +172,19 @@ HANDLE WINAPI CreateRemoteThread( HANDLE > if (id) *id = (DWORD)client_id.UniqueThread; > if (sa && (sa->nLength >= sizeof(*sa)) && sa->bInheritHandle) > SetHandleInformation( handle, HANDLE_FLAG_INHERIT, HANDLE_FLAG_INHERIT ); >+ if (!(flags & CREATE_SUSPENDED)) >+ { >+ DWORD ret; >+ >+ status = NtResumeThread( handle, &ret ); >+ if (status) >+ { >+ NtTerminateThread( handle, -1 ); >+ RtlFreeHeap( GetProcessHeap(), 0, info ); >+ SetLastError( RtlNtStatusToDosError(status) ); >+ handle = 0; >+ } >+ } > } > else > > I think you should close the thread handle in the error case, otherwise it will be leaked. Rob

1 0

Debian Packages Almost Ready
by Scott Ritchie 01 Dec '04

01 Dec '04

Debian packages are almost done. I have them up for testing. Add the following to /etc/apt/sources.list deb http://tuzakey.com/~scott/ binary/ deb-src http://tuzakey.com/~scott/ source/ My friend's webserver can't handle the huge bandwidth permanent hosting of packages like this will require, so if there's a way we could put them up on winehq it would be nice. I'd like to have an apt repository here, so installing the latest debian wine package would be as simple as adding something like the above line to sources.list and then doing things as normal. What would be ideal, of course, is if the package could be included in the Debian distribution itself. I've yet to hear back from Ove (the current maintainer of the package), and unless he's disappeared entirely there's really nothing that can be done until he decides to update the package or orphan it, as Debian maintainers have total control over their packages. Ubuntu is a different matter, however, and I may be able to get an Ubuntu version included much quicker. If you're a Debian/Ubuntu user, test out the packages and tell me if I left anything out. Thanks, Scott Ritchie

1 0

Small WinMM janitorial project
by Steven Edwards 01 Dec '04

01 Dec '04

Hi, With this patch it is possible to use a few Windows sound drivers under ReactOS but I have only submitted patches for one small part of this because its going to require a bit of rework of the existing WinMM code. This should fix 2 of the existing W->A CrossCall issues # dlls/winmm/winmm.c: winmm: waveInGetDevCapsW: illegal call to waveInGetDevCapsA # dlls/winmm/winmm.c: winmm: waveOutGetDevCapsW: illegal call to waveOutGetDevCapsA but before it can be merged we have to rewrite the Wine drivers to accept Unicode. I am planing on adding this as a subproject to the Janitorial page. Thanks Steven __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

1 0