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

Re: Tests for bug 2686
by Alexandre Julliard Feb. 8, 2005

Feb. 8, 2005

"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> writes: > Here's some tests which show the problem reported as bug 2686. I tried to > find a way to fix it but its not simple. (Note I can only confirm that XP > behaves as described). On XP yes, but it will fail on Win9x, the API doesn't guarantee that the returned size will be identical to the allocated size. Unless you have a real app that depends on that I don't think there's much point in doing that test. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: MSIEXEC: fix command line parsing
by Alexandre Julliard Feb. 8, 2005

Feb. 8, 2005

Mike McCormack <mike(a)codeweavers.com> writes: > ChangeLog: > * Fix msiexec's command line parsing. What does msiexec require that the standard command-line parsing cannot support? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: bi-arch on an amd64
by Alex Woods Feb. 8, 2005

Feb. 8, 2005

Hi, I too am trying to compile a working multilib wine. I have got a little further, and actually have a binary that doesn't produce any errors now. Unfortunately, it doesn't seem to do anything at all, and just returns me to the command line with an exit status of 2. I've yet to dig into that one. For reference, I am using gentoo with a multilib gcc, applying the attached patch and then running this sequence of commands: autoconf ./configure --x-libraries=/emul/linux/x86/usr/X11R6/lib make depend && make The small patch I've attached fixes the two problems I came across - one already mentioned by Gabriel de Perthuis. That problem appears to be one of a deprecated? syscall. The other problem is that configure was not detecting x86_64 as being an x86 and hence not building the wine-preloader which is why Gabriel was getting his strange 'wine: could not exec \uffff\uffffmU\uffff\uffffmUp/bin/wine-pthread' message. Should I send the patch to wine-patches also? Or can it make its way into CVS from here? I'm going to see if I can track down which exit(2) I'm hitting now. I'm new to the wine source code, so any suggestions are welcome. -- Alex

1 3

Re: widl: let widl understand typedef enum
by Huw D M Davies Feb. 8, 2005

Feb. 8, 2005

On Sun, Feb 06, 2005 at 09:31:37AM -0500, Vincent Béron wrote: > Le dim 06/02/2005 à 09:01, Mike Hearn a écrit : > > On Sat, 05 Feb 2005 12:37:08 -0600, Rob Shearman wrote: > > > Yeah, it seems strange, but I have a test program here that shows it is > > > 32-bits application-side for proxies/stubs. > > > > There's all kinds of brokenness going on in their variant marshalling, eg > > some types are mapped seemingly at random to others. I have a list with > > some of the details around here somewhere, but I'd totally believe > > whatever Rob says on this no matter how weird. > > VT_I4 it is then. > > This supercedes my widl3.diff patch. > > Changelog: > A RPC_FC_ENUM16 is a VT_I4. Actually this should be VT_USERDEFINED. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Wine for Linux PPC emulate Mac OS
by M-Rick Feb. 8, 2005

Feb. 8, 2005

The Wine http://www.winehq.com/ project has been created to emulate Windows to be able to run windows softwares directly under Linux without to have to emulate Windows. It's very great and wonderful idea ! The Darwine http://darwine.opendarwin.org/ project aims to to the same but under Mac OS X with adding also the emulation of an x86 CPU. But, I wanted to know something, or even to make a proposal. Would it be possible to make a special Wine version for Linux PPC that instead of emulating Windows would emulate Mac OS ? Yes there's already the very great Mac On Linux PPC (MOL) http://www.maconlinux.org/ that can let run Mac OS applications, but you have to run Mac OS in parallel ... It is great, but Mac OS takes rooms and CPU and for some usages, maybe it is not completely useful. Would it be possible to make such a software a WinePPC for exemple that would let run Microsoft Office X 2004 Mac or Adobe CS Mac or Macromedia MX Mac directly under Linux PPC without having to install a Mac OS ? To make simple to run Mac OS softwares directly under the Linux desktop environment.

6 6

Re: dsound: Properly implement DllCanUnloadNow
by Robert Reif Feb. 7, 2005

Feb. 7, 2005

James Hawkins wrote: >Hi, > >Changelog >* Properly implement DllCanUnloadNow ref counting. > > > dsound.dll is a strange dll that doesn't really follow proper COM reference counting rules for buffers. This is intentional by Microsoft (don't know why) and was made common by the example code from "Inside Direct X" . You may want to add a test to the dsound.dll regression tests to verify what Microsoft does.

2 2

[oleaut32/typelib.c] TLB_ReadTypeLib question
by Paul Vriens Feb. 7, 2005

Feb. 7, 2005

Hi, while browsing through typelib.c I saw: 287 */ 288 int TLB_ReadTypeLib(LPCWSTR file, INT index, ITypeLib2 **ppTypelib); 289 290 HRESULT WINAPI LoadTypeLib( Is line 288 supposed to be there ? Cheers, Paul.

2 1

Re: widl: support ATTR_READONLY for interface properties
by Huw D M Davies Feb. 7, 2005

Feb. 7, 2005

On Sun, Feb 06, 2005 at 09:50:31AM -0500, Vincent Béron wrote: > There are probably other easy ones like this one, but for now I only > need this one. > > Huw, am I stepping on your toes? Nope, but I do have some more patches left in my tree that I need to tidy up a bit before submitting - notably support for modules. I've almost got a version of stdole2.tlb too... But feel free to carry on. Cheers, Huw. -- Huw Davies huw(a)codeweavers.com

2 1

Re-examining SetThreadContext
by Mike Hearn Feb. 7, 2005

Feb. 7, 2005

Hi Alexandre, A user recently reported another app that doesn't work due to Armadillo copy protection. This scheme requires SetThreadContext/GetThreadContext to work properly and currently they do not. These two functions require the thread to be suspended, therefore they always return a bogus context (blocking on a wineserver wait pipe). I wrote a patch for this a while ago: http://navi.cx/svn/misc/trunk/winekb/patches/thread-context.patch However you felt it had races in it. There were two possible races I could see: - The race between suspending the thread and the sigcontext being uploaded. This was not a problem with my patch as Get/SetThreadContext loop. - A race where you can call SuspendThread again before the SIGUSR1 handler has completed. I believe this was the sticking point last time, no? But I can't see how this can happen because SIGUSR1 is blocked while it's being handled. So in the following sequence: PROCESS A: SuspendThread() PROCESS A: GetThreadContext() PROCESS B: SIGUSR1 PROCESS B: upload sigcontext PROCESS B: block PROCESS A: GetThreadContext() returns PROCESS A: ResumeThread PROCESS B: unblock, download sigcontext, restore, finish I do not see where the races are. Could you please re-examine this patch and let me know if there are any more problems with it? Dealing with the set/thread context operations in SIGUSR1 makes sense because they are only allowed when the target thread is suspended. thanks -mike

2 5

Re: wine/dlls/dbghelp elf_module.c
by Eric Pouech Feb. 7, 2005

Feb. 7, 2005

Alexandre Julliard a écrit : > ChangeSet ID: 15811 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/01/31 10:24:57 > > Modified files: > dlls/dbghelp : elf_module.c > > Log message: > Silence a noisy FIXME I fear that the issue may be somewhere else than the pure FIXME. Can you describe what actually happened ? A+ -- Eric Pouech

2 1