April 2003 - Wine-devel - list.winehq.org

Is it possible to call DLL functions from a Linux program?
by Eloy A. Paris 14 Apr '03

14 Apr '03

Hi! Sorry if this has been covered before, but I could not find any answers in the archives or by Googling... Here's the situation: I have a Windows DLL and a small Windows program that calls functions from this DLL. The Windows program does not have a GUI (it's command-line based.) I have the C source code for this program, but don't have the source code for the DLL. I built the program with Visual C and was able to run it under WINE just fine with wcmd. Now, I want to run this program natively under Linux - I mean, I don't want to run wcmd because that requires an X server. The first question is: is this possible? (have a Unix program that calls functions from a native Windows DLL). I started experimenting with winelib, but am not sure if this is the correct way... If this is possible, how should I do it? I ran winemaker, configure, make, but am getting errors from winbebuild. Summarizing: I have the C source code. This C program calls function foo() that is in a Windows DLL. I want to run this program under Linux without the need for an X server. The program calls gets(), printf(), etc. I want these functions to be from my Linux's libc, not Windows'. Any help will be greatly appreciated. Thanks in advance! Eloy.- P.S. I read the winelib user guide, but couldn't find the answer there. If it is there, it's not clear to me :(

4 4

Re: Implement proxies in wininet
by Steven Edwards 14 Apr '03

14 Apr '03

--- Dominik Strasser <Dominik.Strasser(a)t-online.de> wrote: > The attached patch implements proxies in wininet to an extent that at > least IE6 install works behind a firewall. > > ChangeLog: > partially implement proxy support in wininet > > This is the third time I am sending this patch. Is anything wrong with it ? I think we are starting to see we need a patch tracking system =) Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

1 0

Latest wine tarball not compiling with egcs and --disable-debug
by Gabriele 14 Apr '03

14 Apr '03

Hi all, I'm trying to compile wine 20030408 with a pretty old compiler which is gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) If I run the configure scipt without passing --disable-debug and --disable-trace and then make depend && make everything builds just fine. If I disable debug and trace and then run make I get some errors. The first problem is with some defines in debug.c ../../include/wine/debug.h:84: warning: invalid character in macro parameter name ../../include/wine/debug.h:84: badly punctuated parameter list in `#define' I had to add a string before the '...' to bypass the error: #ifdef NO_DEBUG_MSGS #define WINE_WARN(arg...) do { } while(0) #define WINE_WARN_(ch) WINE_WARN #define WINE_FIXME(arg...) do { } while(0) #define WINE_FIXME_(ch) WINE_FIXME #endif The other error is the following : make[2]: Entering directory `/home/gabriele/wine-20030408/dlls/oleaut32' gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -gstabs+ -fPIC -D__WINESRC__ -D_OLEAUT32_ -DCOM_NO_WINDOWS_H -D_REENTRANT -o typelib.o typelib.c typelib.c: In function `ITypeLib2_fnGetTypeComp': typelib.c:3393: warning: unused variable `This' typelib.c: In function `ITypeLib2_fnReleaseTLibAttr': typelib.c:3584: warning: unused variable `This' typelib.c: In function `ITypeLib2_fnGetLibStatistics': typelib.c:3629: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnGetTypeComp': typelib.c:3870: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnAddressOfMember': typelib.c:4765: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnCreateInstance': typelib.c:4778: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnGetMops': typelib.c:4790: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseTypeAttr': typelib.c:4828: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseFuncDesc': typelib.c:4840: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseVarDesc': typelib.c:4851: warning: unused variable `This' gcc: Internal compiler error: program cc1 got fatal signal 11 make[2]: *** [typelib.o] Error 1 make[2]: Leaving directory `/home/gabriele/wine-20030408/dlls/oleaut32' make[1]: *** [oleaut32] Error 2 make[1]: Leaving directory `/home/gabriele/wine-20030408/dlls' make: *** [dlls] Error 2

1 0

keyboard mapping with XFree86 4.3.0
by Tim Ruehsen 14 Apr '03

14 Apr '03

With XFree86 4.3.0 I experience the message fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (German keyboard layout without dead keys) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. This is very annoying, I can't use the right alt key any more to reach characters like {,} or [. Very bad for C programming... (I use EditPlus together with wine). The Problem can be found with older versions (20020812) as with newer version (20030317). Here is my keyboard layout from XF86Config: Section "InputDevice" Driver "Keyboard" Identifier "Keyboard[0]" Option "MapName" "Standard Keyboard [ pc105 ]" Option "Protocol" "Standard" Option "XkbLayout" "de" Option "XkbModel" "pc105" Option "XkbRules" "xfree86" Option "XkbVariant" "nodeadkeys" EndSection wine -debugmsh +key,+keyboard application outputs: trace:key:X11DRV_InitKeyboard NumLockMask is 10 trace:keyboard:X11DRV_KEYBOARD_DetectLayout Attempting to match against "United States keyboard layout" trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff1b trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff1b trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 11, character 2 ... Any idea? Regards, Tim

4 11

Re: Fall Back to ttydrv when DISPLAY is not set
by Andreas Mohr 13 Apr '03

13 Apr '03

On Sun, Apr 13, 2003 at 08:41:04PM +0200, Uwe Bonnes wrote: > > Changelog > wine/dlls/user/user_main.c: load_driver > wine/dlls/gdi/driver.c: load_display_driver > Fall back to the ttydrv when the DIPLAY variable is not set What about falling back to including a patch? ;-) BTW, do you print a SUFFICIENTLY LARGE warning message when doing so? Users should be aware that something "isn't ok" when this happens... (otherwise they'll keep running Wine with ttydrv and not be aware of the real reason for this behaviour, namely the missing DISPLAY variable) Anyway, since this is going towards error handling, you should make sure that people *know* what's going on instead of them confusedly deleting Wine again ;-) Andreas Mohr -- Help prevent Information Technology Fascism! - before it's too late... http://www.againsttcpa.com

4 3

Re: Fall back to ttydrv when DISPLA variable not set(with patch)
by Dimitrie O. Paun 13 Apr '03

13 Apr '03

On April 13, 2003 04:35 pm, Uwe Bonnes wrote: > + { > + MESSAGE( "Falling back to ttydrv\n"); > + strcpy( buffer, "ttydrv" ); /* default value */ > + } I'm not sure this message is a good idea. What about if you don't run X, are we gonna spam people into running it? -- Dimi.

1 0

Re: UPDATED: video mode changes
by Dimitrie O. Paun 13 Apr '03

13 Apr '03

On April 12, 2003 09:34 pm, Alex Pasadyn wrote: > +#define _X_FIELD(prefix, bits) if ((fields) & prefix##_##bits) TRACE(""#bits ","); +static void _dump_CDS_flags(DWORD fields) { > + _X_FIELD(CDS,UPDATEREGISTRY);_X_FIELD(CDS,TEST);_X_FIELD(CDS,FULLSCREEN); > + _X_FIELD(CDS,GLOBAL);_X_FIELD(CDS,SET_PRIMARY);_X_FIELD(CDS,RESET); > + _X_FIELD(CDS,SETRECT);_X_FIELD(CDS,NORESET); > +} > +static void _dump_DM_fields(DWORD fields) { > + _X_FIELD(DM,BITSPERPEL);_X_FIELD(DM,PELSWIDTH);_X_FIELD(DM,PELSHEIGHT); > + _X_FIELD(DM,DISPLAYFLAGS);_X_FIELD(DM,DISPLAYFREQUENCY);_X_FIELD(DM,POSITION); > +} > +#undef _X_FIELD I still think these should return a string as I described in my previous email... Also, there is no need for such tests: > + if (TRACE_ON(x11drv)) The TRACE will take care of things nicely. -- Dimi.

1 0

Re: ALTGR Problem
by Dmitry Timoshkov 13 Apr '03

13 Apr '03

<duncan(a)semanticedge.de> wrote: > When ever I press the AltGr Key, I get the ^ sign and nothin happend > concerning the email "at" sign, the special brackets and so on. I have > a Toshiba notebook, 2430-101 with a qwertz keyboard, german layout. > Under RH everything works fine concerning the keyboard! > I'm not really familiar with keyboard settings, so editing the > keyboard.c will fail ;-) If I gonna try it with no idea what to do. Let's wait for a merge of keyboard patches from CX Office and see whether it works any better. -- Dmitry.

1 0

Re: Fall Back to ttydrv when DISPLAY is not set
by Vincent Béron 13 Apr '03

13 Apr '03

Le dim 13/04/2003 à 14:41, Uwe Bonnes a écrit : > > Changelog > wine/dlls/user/user_main.c: load_driver > wine/dlls/gdi/driver.c: load_display_driver > Fall back to the ttydrv when the DIPLAY variable is not set You forgot the patch this time. Vincent

1 0

Re: OLE storage SetFilePointer fix
by Mike Hearn 13 Apr '03

13 Apr '03

> P.S.: Alexandre, I'd REALLY like you to finally put a patch status > tracking system in place. The number of people submitting patches > for the second, third, bazillionth time is astonishing (I speak > from my very own experience, too!). I really don't know how many very > valuable Wine patches got lost due to not getting applied without any > status reply whatsoever... The main problem as far as I'm concerned isn't so much the lack of a patch "tracker", I'm usually capable of keeping track of whether my patches have been applied or not by watching wine-cvs (though i've found once or twice i've missed the commit), it's more an issue of if a patch is rejected, you have to ask why. That means I'm often left thinking, is my patch simply in the queue, or is something wrong with it? Or, like my last pkgconfig patch, is there another reason it didn't go in? The way gnome/mozilla do it is to have patches put in bugzilla, but for the sheer volume of patches Wine gets with only Alexandre committing (which is fine by me), that wouldn't work. I'd be perfectly happy with the current arrangement if when a patch was dropped, a reason would normally appear on wine-devel - but then I'm not the one doing the work, Alexandre is, so it's easy for me to ask for him to do more work :/ thanks -mike

2 2