August 2006 - Wine-Devel - list.winehq.org

Re: How to use a windows dll in linux

by Troy Rollo

On Friday 01 September 2006 03:52, Jeremy White wrote: > Dan Kegel wrote: > > On 8/30/06, Mark Smith <mesmith.18885136(a)bloglines.com> wrote: > >> I have a windows dll and header files. I want to make a library that I > >> can link to and use on linux. What are the steps required to do this? > > > > Sorry, you can't. Not at the moment, anyway. That's on the to-do list. > > It's not that black and white, is it? > > I believe you can, and it actually works reasonably well. BUT there's > a big catch - you have to make your program into a Winelib application. Actually there's probably an easier way - a scheme I've been considering is one involving a crt0.o designed to load Wine (essentially making the native executable an equivalent of wine-pthread with other stuff), then start a Winelib program whose entry point calls back into a second entry point in the original executable. This scheme ought to work without any modifications to the core of Wine. We also wouldn't need to be reserving any memory areas, so the trimmed down operating system entry point of the Wine executable might be something like this: int __wine_startup( int argc, char **argv, char **envp) { char error[1024]; char winelib_argv[3]; char wine_entry_addr[sizeof(void *) * 2 + 1]; __wine_argc = argc; __wine_argv = argv; __wine_envp = envp; wine_pthread_set_functions( &pthread_functions, sizeof(pthread_functions) ); sprintf(wine_entry_addr, "%p", __wine_entry); winelib_argv[0] = "execallback.exe.so"; winelib_argv[1] 0; wine_init( 2, winelib_argv, error, sizeof(error) ); fprintf( stderr, "wine: failed to initialize: %s\n", error ); exit(1); } A routine "__wine_exe_entry_point" would be exported by the executable. The startup code for "excallback.exe.so" would call that routine as substantially all of its initialisation code, so that the executable calls wine_dll_register providing its own details. I suspect the "difficulty" associated with having a Linux executable that calls Windows DLLs using Wine has been due the assumption that "main()" in the executable would be executed before Wine - by throwing out this assumption the problem may be a whole lot easier to solve. -- Troy Rollo - wine(a)troy.rollo.name

Aug. 31, 2006

Could I get some permissions for Bugzilla?

by Matt Finnicum

Hello, I'm not really sure what levels of permissions Bugzilla has, but could I get the ability to modify bugs? (things like assign them to myself, mark them as fixed, etc). If it's possibile, I suppose only having such access to the "wine-richedit" component would be fine, too. --Matt Finnicum

Aug. 31, 2006

"Bus Error" at thread.c:228 on OS X with Xcode 2.4 and -O2

by dackz

>From what I've heard, there was a bug in the gcc bundled with Xcode 2.3 that caused stack alignment issues when -O2 was used (and maybe -O1?). This is supposed to be fixed in Xcode 2.4, which is what I'm using, yet I'm still getting a "Bus Error" with all default CFLAGS. Adding -O0 into the mix fixes the problem. Here's all I could gleam with gdb: Breakpoint 1, NtAllocateVirtualMemory (process=0x7bc5b6f1, ret=0xbffff949, zero_bits=3221222220, size_ptr=0x10000, type=3221222216, protect=2147352576) at virtual.c:1306 1306 in virtual.c (gdb) bt #0 NtAllocateVirtualMemory (process=0x7bc5b6f1, ret=0xbffff949, zero_bits=3221222220, size_ptr=0x10000, type=3221222216, protect=2147352576) at virtual.c:1306 #1 0x7bc4f428 in thread_init () at thread.c:224 #2 0x7bc2beea in __wine_process_init () at loader.c:2354 #3 0x60a088c1 in wine_init (argc=2, argv=0xbffff8b8, error=0xbffff450 "", error_size=1024) at loader.c:664 #4 0x7bf00f2d in main (argc=2, argv=0xbffff8b8) at main.c:58 [stepping...] (gdb) step NtAllocateVirtualMemory (process=0x2001, ret=0xbffff22c, zero_bits=1048576, size_ptr=0x1000, type=4294967295, protect=10514258) at virtual.c:1379 1379 in virtual.c (gdb) print status $22 = 0 [stepping...] (gdb) step thread_init () at thread.c:226 226 thread.c: No such file or directory. in thread.c (gdb) print addr $23 = (void *) 0x7ffde000 (gdb) print size $24 = 4096 (gdb) step 228 in thread.c (gdb) step Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x7ffde064 thread_init () at thread.c:228 228 in thread.c (gdb) bt #0 thread_init () at thread.c:228 #1 0x7bc2beea in __wine_process_init () at loader.c:2354 #2 0x60a088c1 in wine_init (argc=2, argv=0xbffff8b8, error=0xbffff450 "", error_size=1024) at loader.c:664 #3 0x7bf00f2d in main (argc=2, argv=0xbffff8b8) at main.c:58 (gdb) thread.c:228 being "peb->NumberOfProcessors = 1;", and peb being 0x7ffde000. Here's some environment information: OS: Mac OS X 10.4.7 Xcode: Xcode 2.4 X11: XFree86 Version 4.4.0 / X Window System (protocol Version 11, revision 0, vendor release 6600) gcc -v: Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5363) uname -a: Darwin my-computer 8.7.1 Darwin Kernel Version 8.7.1: Wed Jun 7 16:19:56 PDT 2006; root:xnu-792.9.72.obj~2/RELEASE_I386 i386 i386 I've built Wine with the following DarwinPorts portfile: # $Id: $ PortSystem 1.0 name wine version 0.9.20 description Windows compatibility layer long_description Microsoft Windows compatibility layer for Unix-like systems categories emulators maintainers dackze+darwinports(a)gmail.com platforms darwin freebsd homepage http://www.winehq.org/ master_sites sourceforge:wine use_bzip2 yes depends_lib bin:bison:bison bin:fontforge:fontforge bin:gmake:gmake \ bin:m4:m4 bin:pkg-config:pkgconfig \ lib:libfontconfig:fontconfig lib:libfreetype:freetype \ lib:libintl:gettext lib:libjpeg:jpeg lib:libncurses:ncurses \ lib:libX11:XFree86 lib:liblcms:lcms lib:libglut:glut \ lib:libgphoto2:libgphoto2 lib:libsane:sane-backends \ lib:libssl:openssl lib:libungif:libungif \ lib:libxml2:libxml2 lib:libxslt:libxslt build.type gnu checksums ${distname}${extract.suffix} md5 3e80a07819e4df084becdbbcd4d6cdd3 \ sha1 71b918dcdc54bc32e0b37a63f66891bb7c96b938 \ rmd160 80f1a055674b56ec7cb9231d08b837d1a1a4e883 platform darwin powerpc { ui_msg "Wine is not supported on PowerPC" exit 1 } Which installs the following: fontforge @20060125_0 (active) freetype @2.1.10_1 (active) gettext @0.14.6_0 (active) glut @3.7_0 (active) gmake @3.81_0 (active) jpeg @6b_1 (active) lcms @1.15_0 (active) libgphoto2 @2.1.5_0 (active) libiconv @1.10_1+darwin_8 (active) libpng @1.2.10_2+darwin_8 (active) libungif @4.1.4_0 (active) libuninameslist @20050712_0 (active) libusb @0.1.12_0 (active) pkgconfig @0.21_0 (active) sane-backends @1.0.17_0+local-backends (active) tiff @3.8.2_0+darwin_8 (active) wine @0.9.20_0 (active) zlib @1.2.3_0 (active)

Aug. 31, 2006

Re: [TRY 3] Add support for tooltips for system tray icons

by James Liggett

Hi Kuba, > > What about a static variable right in the function where you call the > initialization function? That'd work fine if you don't call > InitCommonControlsEx from anywhere else: > > if (!list_head(&tray.icons)) > { > static BOOL controls_initialized = FALSE; > INITCOMMONCONTROLSEX init_tooltip; > > init_tooltip.dwSize = sizeof(INITCOMMONCONTROLSEX); > init_tooltip.dwICC = ICC_TAB_CLASSES; > > if (! controls_initialized) { > InitCommonControlsEx(&init_tooltip); > controls_initialized = TRUE; > } > . . . > } Indeed, that's what I ended up doing. Mike committed it to his temporary git tree.

Aug. 31, 2006

Re: [TRY 3] Add support for tooltips for system tray icons

by Kuba Ober

> > Shouldn't you only initialize comctl32 once, rather than every time > > there's no icons and we add one? > > Sure. I did it like this because Alexandre only wanted to have common > controls initialized when we added an icon so we didn't have to do so > much work at explorer startup. Taking a second look I see how we could > end up initializing common controls more than once. My first thought on > this is to add a boolean variable somewhere that would tell us if we've > already initialized comctl32 so we don't do it more than once. What about a static variable right in the function where you call the initialization function? That'd work fine if you don't call InitCommonControlsEx from anywhere else: if (!list_head(&tray.icons)) { static BOOL controls_initialized = FALSE; INITCOMMONCONTROLSEX init_tooltip; init_tooltip.dwSize = sizeof(INITCOMMONCONTROLSEX); init_tooltip.dwICC = ICC_TAB_CLASSES; if (! controls_initialized) { InitCommonControlsEx(&init_tooltip); controls_initialized = TRUE; } . . . } Cheers, Kuba

Aug. 31, 2006

Re: How to use a windows dll in linux

by Jeremy White

Dan Kegel wrote: > On 8/30/06, Mark Smith <mesmith.18885136(a)bloglines.com> wrote: > >> I know this question has been asked many times, but I cannot find enough >> information to solve the problem. >> >> I have a windows dll and header files. I want to make a library that I >> can link to and use on linux. What are the steps required to do this? > > > Sorry, you can't. Not at the moment, anyway. That's on the to-do list. It's not that black and white, is it? I believe you can, and it actually works reasonably well. BUT there's a big catch - you have to make your program into a Winelib application. That is, what you (reasonably) want is just a simple foo.so you can dlopen and then do invoke_my_windows_function(). You can get that, but what you have to do is rename your main to be linux_main, and then write a whole new WinMain which invokes your linux_main. Then, from within your linux app, you can write some glue to make the connectiong. You can get into trouble if you depend heavily on particular IPC mechanisms, threading in particular, but I believe that basic usages should still work. So, basically, if you're willing to stand your application on its head, you can get the functionality you want. Most people don't get over that; to be frank, I think those that don't are largely just stuck on the 'smell' of it; from a practical standpoint, I think it works fine. Cheers, Jeremy

Aug. 31, 2006

Re: How to use a windows dll in linux

by Dan Kegel

On 8/30/06, Mark Smith <mesmith.18885136(a)bloglines.com> wrote: > I know this question has been asked many times, but I cannot find enough > information to solve the problem. > > I have a windows dll and header files. I want to make a library that I > can link to and use on linux. What are the steps required to do this? Sorry, you can't. Not at the moment, anyway. That's on the to-do list. - Dan

Aug. 31, 2006

Re: ole32: Do a QueryInterface for IOleLink in OleLoad, like native does.

by Huw Davies

On Thu, Aug 31, 2006 at 05:18:36PM +0100, Robert Shearman wrote: > --- > dlls/ole32/ole2.c | 25 +++++++++++++++++++------ > 1 files changed, 19 insertions(+), 6 deletions(-) > diff --git a/dlls/ole32/ole2.c b/dlls/ole32/ole2.c > index 8f0629c..c6df7ed 100644 > --- a/dlls/ole32/ole2.c > +++ b/dlls/ole32/ole2.c > @@ -1007,12 +1007,13 @@ HRESULT WINAPI OleLoad( > + if (SUCCEEDED(hres)) > + /* > + * Initialize the object with it's IPersistStorage interface. > + */ > + hres = IOleObject_QueryInterface(pUnk, > + &IID_IPersistStorage, > + (void**)&persistStorage); s/it's/its/ ;-) Huw. -- Huw Davies huw(a)codeweavers.com

Aug. 31, 2006

Re: LOSTWAGES: News : 9.20 release

by Robert Shearman

Tom Wickline wrote: > Hello, > > News Wine 9.20 released > > Tom > >------------------------------------------------------------------------ > >0a1,28 > > Please use "diff -u" for website patches. -- Rob Shearman

Aug. 31, 2006

Re: Can you provide me a help.

by Stefan Dösinger

> wrc: error while loading shared libraries: libwine.so.1: cannot open > shared object file: No such file or directory Did you install wine with "make install"? Is the installation path(usually /usr/local/lib in your ldconfig search path?

Aug. 31, 2006