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

Re: MAPI32.dll.so - how to use in linux programs?

by Robert van Herk

Boaz Harrosh wrote: > Luke Kenneth Casson Leighton wrote: > >> ... i am kinda looking for something with a Makefile, compiles and >> links against Wine directly - under linux not windows. >> >> i am inclined to rip bits of code out of Wine (parts of header >> files so far) until i can get to grips with it. > > So Just look at the Winelib programmer's guide (On Winehq) > documentation on how to make a Winelib application. for inspiration, you could look at the makefiles of the various winelib programs in the /programs directory in the wine source code.

Feb. 1, 2005

DLL Load Question: Please Help!

by Sergey Efimoff

Hi, I have windows binary-only, third-party .DLL library without any source files. I would like to use it in my unix-based project, which is compiled with usual GNU C compiler. Wine documentation says Wine is able to load external .DLLs, but does not explain how to implement such ability in userland program using Wine API. I've discovered LoadLibrary() and GetProcAddr() functions compiled into built-in DLL (kernel32.dll.so), so in order to load my DLL I use the function LoadLibrary("somelib.dll"), linking my project with -lwine and -lkernel32. The problem is that when my application calls LoadLibrary(), it causes Bus Error. Back tracing using gdb shows that the crash appears under such sequence: in main() in LoadLibraryA() at module.c:745 in LoadLibraryExA() at module.c:706 in FILE_name_AtoW() at file.c:198 in ?? () from kernel32.dll.so The function call at file.c:198 is RtlInitAnsiString() and (as I understand) is unreferenced in kernel32 and uses ntdll.dll.so. What things should I do before calling LoadLibrary()? By the way: If I call RtlInitAnsiString() directly from main(), linking my project with ntdll.dll.so, it is called correctly, works and returns some result. I tried to define -lntdll within LDFLAGS, in this case compile finishes cleanly, but the Bus Error still appears. Also I tried to find any examples showing how to load external .DLL. I've found no examples. Note: there is no ability to obtain library sources. Bye.

Feb. 1, 2005

wine

by te0543＠giga.net.tw

I use x86 solaris. I got these messages compiling wine-20050111. configure: WARNING: sys/reg.h: present but cannot be compiled configure: WARNING: sys/lwp.h: present but cannot be compiled configure: WARNING: pthread.h: present but cannot be compiled configure: WARNING: arpa/nameser.h: present but cannot be compiled configure: WARNING: GL/glx.h: present but cannot be compiled checking for assembler keyword for word values... configure: error: could not discover how to specify word values with assembler.

Feb. 1, 2005

Re: RESEND: Enable GCOV Code Coverage

by Robert Shearman

Aaron Arvey wrote: >This is the third or fourth resend... anything I'm unaware of? > > > >We're using gcov and lcov to measure how well the Wine test suite >covers the wine source tree. Here's our first cut at making it easy >to run wine compiled for coverage testing, and view the results >using the simple text interface of gcov. A seperate patch for >lcov will be released soon. > > I think the issue with this patch is that it isn't it doesn't appear to be useful for a significant number of people and could be maintained as an external patch by the people who do think it's useful. Maybe you could try to persuade us as to why everyone should be using gcov? Rob

Feb. 1, 2005

Re: NPTL and Wine threads

by Luke Kenneth Casson Leighton

On Tue, Feb 01, 2005 at 06:56:57AM -0800, Dan Kegel wrote: > Luke Kenneth Casson Leighton wrote: > >>>there is some code in FreeDCE which expects to be able to jump out > >>>of a cancellation handler > >> > >>Then FreeDCE should be fixed to be POSIX-compliant, I think. > >>Or is there something subtle going on here? > > > > > > the behaviour of LinuxThreads is different from NPTL. > > > > therefore, given that this cancellation thing matters for dce > > applications (the runtime relies on it being possible) i thought > > you might wish to be aware of this subtle difference in case > > Wine MSRPC or other applications also rely on it. > > > > that's all - nothing more. > > Right. Nothing subtle, then. I guess FreeDCE needs some > work to run on NPTL or other POSIX-compliant threads packages, *sigh*. yes. depends on your version of POSIX (final or draft 4). loic is working on keeping dcethreads "current", at least. there are approx 350 occurrences of pthread_somethingorother in FreeDCE, so it's not a trivial task, more's the pity. > as it's using Linuxthreads behavior that is an extension of POSIX threads. > (Surely FreeDCE doesn't *need* to longjmp out of a cancellation handler; it's the dcethreads (posix draft 4) emulation library that handles that, from what i can gather. > it can't be that hard to fix.) Thanks for the heads up. ack.

Feb. 1, 2005

Re: NPTL and Wine threads

by Robert Shearman

Luke Kenneth Casson Leighton wrote: >On Mon, Jan 31, 2005 at 08:28:53PM -0800, Dan Kegel wrote: > > > >>Luke wrote: >> >> >>>it's come to my attention that NPTL cannot cope with jumping out >>>of a cancellation handler. >>> >>> >>Tough noogies, as it were. See >> >> > > it'll bother me later but for now it doesn't :) > > > >>>there is some code in FreeDCE which expects to be able to jump out >>>of a cancellation handler >>> >>> >>Then FreeDCE should be fixed to be POSIX-compliant, I think. >>Or is there something subtle going on here? >> >> > > the behaviour of LinuxThreads is different from NPTL. > > therefore, given that this cancellation thing matters for dce > applications (the runtime relies on it being possible) i thought > you might wish to be aware of this subtle difference in case > Wine MSRPC or other applications also rely on it. > > If I understand it correctly, "cancellation handlers" are used for cleaning up when a thread is terminated. Windows doesn't have an eqivalent feature so if you forcefully terminate a thread then you leak resources and could have terminated with a lock held. However, in kernel designers seem to have thought about this problem and have added features to the one of the locking primitives (the NT mutant, or Win32 mutex, also used by Win32 critical sections) so that if the owning thread was terminated then calls to wait on the lock will return with a error code signaling that the owning thread was terminated so that they can clean up. For more details see here: http://blogs.msdn.com/larryosterman/archive/2004/09/24/233969.aspx It doesn't look like cancellation handlers are called by the pthread emulation code, but I can't see why it would be necessary at the moment. Rob P.S. Because of the reasons above, using the Win32 TerminateThread function is a sign of bad programming, except when used by a debugger. Similarly, SuspendThread has the problem above that it could suspend a thread whilst inside the heap critical section and similarly, should not be used, except in a debugger.

Feb. 1, 2005

Re: Update: olepicture.c compile failure : `UserData' / `DGifOpen'

by Dan Kegel

Rizwan Kassim wrote: > It seems that configure approves of vesrion 3.0.0 of libungif.so / > gif_lib.h, but compile fails using 3.0.0. DGifOpen > gif_lib.h 4.0.0 compiles correctly (even without updating libungif.so, > but afaik thats pretty poor practice) > > The gif_lib.h that configure approves of is labeled version 3.0 by > Eric S Raymond. > > (from gif_lib.h - 4.0.0 : > GifFileType *DGifOpen(void *userPtr, InputFunc readFunc); /* new one > > Interestingly, it seems that configure DOES show the failure during > the test compile: > ... > configure:15599: checking for -lungif soname > configure:15629: gcc -o conftest -g -O2 conftest.c -lungif >&5 > /tmp/ccdg49tg.o: In function `main': > /home/rizwank/wine/conftest.c:155: undefined reference to `DGifOpen' > collect2: ld returned 1 exit status > configure:15635: $? = 1 > configure: failed program was: > <snip confdefs.h and a few more lines> > configure:15738: result: libgif.so Look in configure.ac for references to DGifOpen. You'll find WINE_GET_SONAME(ungif,DGifOpen) WINE_GET_SONAME(gif,DGifOpen) So Wine is looking in two places for DGifOpen, which explains perhaps why you're seeing the failure in the output of configure; one of the places it's looking doesn't have it. (Just a guess.) As to who would know what's going on, try searching wine-patches for those lines, and you'll see two fairly recent patches, http://www.winehq.com/hypermail/wine-patches/2004/08/0045.html http://www.winehq.com/hypermail/wine-patches/2004/09/0252.html by Huy and Marcus. Since they've been playing with the code, maybe they can comment on the real problem you're having. > So, whats the next step? Should it be a critical error for configure? > Should configure report the incorrect gif_lib.h (and old libungif)? > I'm new enough to OSS projects that I'm not sure if I should : > a) attempt to patch configure to report the error and stop the configure process Yes, once you understand that section completely. We do want it to fail in configure rather than while compiling wine. > b) patch olepicture.c to stop using DGifOpen I doubt it, but I haven't looked at those libraries > c) submit gif_lib.h to the tree in dlls/oleaut32 No, that would break encapsulation of the library. > This has been (partially) reported as Bug 1730 and 2437. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Feb. 1, 2005

Re: x11drv regression?

by Oliver Stieber

--- Alexandre Julliard <julliard(a)winehq.org> wrote: > Oliver Stieber <oliver_stieber(a)yahoo.co.uk> writes: > > > Hi, > > I've just synced with CVS and the following > code > > and I can no longer get an x11 window ID using > > > > (Window)GetPropA(HWND,"__wine_x11_client_window" > ); > > > > > > I've had a look at X11DRV and there have been a > few > > changes reciently, should I be using something > else? > > The client window is gone, but > "__wine_x11_whole_window" still works > (though only for top-level windows). > > -- > Alexandre Julliard > julliard(a)winehq.org I've got that working now thanks. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

Feb. 1, 2005

Re: my trouble

by Robert Shearman

pyd wrote: >hello all: >I download one Game http://www.qf.com.cn/software/qfweiqi.exe >run in WINE >but It show me like this. >------------------------------------------------ >pyd(a)linux:~/.wine/drive_c/qf> wine GoStoneClient.exe >fixme:ole:CoRegisterMessageFilter stub >wine: Unhandled exception (thread 002c), starting debugger... >WineDbg starting on pid 0x2b >In 32 bit mode. >0x404719c4 DebugBreak+0x4 in kernel32: popl %ebp >Wine-dbg> >------------------------------------------------ >I have allready install win98 dll store in wine.my system is SuSe8.2 > > Type 'bt' to get a backtrace which will give us more clue as to what is wrong. Note that if you are not a developer and don't want to do any debugging, then the wine-users list may be more appropriate for getting help. Rob

Feb. 1, 2005

Re: MAPI32.dll.so - how to use in linux programs?

by Boaz Harrosh

Luke Kenneth Casson Leighton wrote: > ... i am kinda looking for something with a Makefile, compiles and > links against Wine directly - under linux not windows. > > i am inclined to rip bits of code out of Wine (parts of header > files so far) until i can get to grips with it. > > > It looks like what you are looking for is a vanilla Winelib application. It compiles on Linux with a Makefile it can freely be linked to any Linux resource/Library and in turn also use Wine or native windows DLLs. Only thing is that it is executed under the Wine loader and must keep some linking and structure rules special for wine. Once it works it is easy to take code from a Winelib App and make it a Winelib DLL. So Just look at the Winelib programmer's guide (On Winehq) documentation on how to make a Winelib application. Hope that helps Free Life Boaz

Feb. 1, 2005