April 2004 - Wine-Devel - list.winehq.org

winehq & 20040408
by Rein Klazes April 10, 2004

April 10, 2004

Hi, winehq still shows: Latest Release: Wine 20040309 (diff:s) released: 2004/03/09 Nothing under "Latest News" either. Can somebody fix this? Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

wine native linux executable /
by Arne Gellhaus April 10, 2004

April 10, 2004

Hi, I am new to wine and i am trying to get some things done. 1. Is it possible to compile a native linux executable with winelib and use winapi functions like LoadLibrary() and GetProcAddress()? I made my buildsystem with winemaker. 2. I tried to use Common C++ [1] in my winelib application. But because of winelib/wineg++ (?) it assumes that it is running on windows and so the compilation failed. Is it possible to use such portable frameworks in a winelib application like in any other linux application? Thanks for helping me out, Arne Gellhaus [1] http://www.gnu.org/software/commoncpp/

6 9

Re: Security bug in ShellExecuteEx()
by Michael Stefaniuc April 9, 2004

April 9, 2004

Hello, On Fri, Apr 09, 2004 at 02:14:10AM +0200, Francois Gouget wrote: > Index: dlls/shell32/shlexec.c > =================================================================== > RCS file: /var/cvs/wine/dlls/shell32/shlexec.c,v > retrieving revision 1.40 > diff -u -r1.40 shlexec.c > --- a/dlls/shell32/shlexec.c 7 Apr 2004 03:49:51 -0000 1.40 > +++ b/dlls/shell32/shlexec.c 8 Apr 2004 23:12:53 -0000 > @@ -1114,10 +1126,6 @@ > strcatW(wszApplicationName, wszCommandline); > } > > - retval = execfunc(wszApplicationName, NULL, FALSE, &sei_tmp, sei); > - if (retval > 32) > - return TRUE; > - > /* Else, try to find the executable */ ^^^^^ You may want to remove this because it refers to the just removed if. > wcmd[0] = '\0'; > retval = SHELL_FindExecutable(sei_tmp.lpDirectory, lpFile, sei_tmp.lpVerb, wcmd, 1024, lpstrProtocol, &env, sei_tmp.lpIDList, sei_tmp.lpParameters); bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

3 2

Wine-20040408 Compile Bug
by greensh＠knology.net April 9, 2004

April 9, 2004

Had a problem compiling this latest version on my Dell Latitude laptop... here is the exact make error; gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -DBINDIR="\"/usr/local/bin\"" -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o keyboard.o keyboard.c keyboard.c: In function `X11DRV_ToUnicodeEx': keyboard.c:2128: error: `XK_EuroSign' undeclared (first use in this function) keyboard.c:2128: error: (Each undeclared identifier is reported only once keyboard.c:2128: error: for each function it appears in.) make[2]: *** [keyboard.o] Error 1 make[2]: Leaving directory `/data/0MD2/wine-20040408/dlls/x11drv' make[1]: *** [x11drv] Error 2 make[1]: Leaving directory `/data/0MD2/wine-20040408/dlls' make: *** [dlls] Error 2 Compilation failed, aborting install. Looks like it's wrong in detecting the keyboard. A fix was to comment out the if statement entirely; < if (keysym == XK_EuroSign) < { < bufW[0] = 0x20AC; < ret = 1; < goto found; < } --- > /* > if (keysym == XK_EuroSign) > { > bufW[0] = 0x20AC; > ret = 1; > goto found; > } > /* Then it compiled/installed fine. Shaun

1 0

Serial Port Problem
by TN April 9, 2004

April 9, 2004

Hi I already posted this on gmane.comp.emulators.wine.user but didn't get a response, maybe I have more luck here. I'm running wine-20040309 on a SuSE 8.2 system and trying to get Keil µVision2 Evaluation Version (Integrated Development Environment for Microcontrollers) working. So far, I've been pretty successful - most of it works. However, connecting a µC-Board at the serial port fails. The traces I get are as follows: fixme:comm:GetCommProperties (0xa0 0x408bf6f0 ) trace:comm:SetCommTimeouts (0xa0,0x42be02f8) trace:comm:SetCommMask handle 0xa0, mask 1 trace:comm:GetCommState handle 0xa0, ptr 0x42be02d8 trace:comm:GetCommState OK trace:comm:GetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:GetCommState IXON ~IXOFF trace:comm:GetCommState CRTSCTS trace:comm:SetCommState handle 0xa0, ptr 0x42be02d8 trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState IXON ~IXOFF trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:WaitCommEvent (0xa0 0x42f00180 0x42be0328 ) trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x42be0328 trace:comm:GetCommMask handle 0xa0, mask 0x42f00184 trace:comm:ClearCommError handle 0xa0 cbInQue = 1 cbOutQue = 0 err:file:GetOverlappedResult PENDING status after waiting! trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:WaitCommEvent (0xa0 0x42f00180 0x42be0328 ) Any help would be greatly appreciated. Thanks. Regards, Thomas

2 1

inheriting exec-shield avoidance
by Peter Riocreux April 9, 2004

April 9, 2004

I am intermittently trying to get Wine to play nicely with a big EDA tool, and it is doing not too badly today with the 20040309 snapshot on Fedora Core 1. The thing that I think is stopping it working is that whatever is done to stack-shield by the prepending "setarch i386" on invocation is not inherited by the .exe that the program calls. Net result is that I get the "..... security-patched kernel ?" error message from the child process instead of the parent. Progress of a sort. Is there anything, short of turning off exec-shield entirely, that can be done about this? The full set of messages it emits (with program identities obscured to avoid identifying the much-cheaper-when-bought-as-windows-binary application) is below. The printer message mentions an extant queue. ----8<--------8<--------8<--------8<--------8<--------8<---- err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report fixme:console:SetConsoleCtrlHandler (0x41a8af,1) - no error checking or testing yet err:comm:GetCommState tcgetattr error 'Invalid argument' fixme:commdlg:PRINTDLG_OpenDefaultPrinter Could not open printer pica_duplex?! fixme:console:SetConsoleCtrlHandler (0x7800f03e,1) - no error checking or testing yet err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load L"G:\\path\\to\\my\\child.exe" as Win32 binary ----8<--------8<--------8<--------8<--------8<--------8<---- Peter

4 8

Re: CryptoAPI
by dataphile April 9, 2004

April 9, 2004

I read in one of the list archives that someone was working on implementing CryptoAPI functionality via libgcrypt on the backend. Anyone have any more info on this?

1 0

Re: wine/dlls/msvcrt math.c
by Hans Leidekker April 9, 2004

April 9, 2004

On Thursday 08 April 2004 21:49, Alexandre Julliard wrote: > Modified files: > dlls/msvcrt : math.c > > Log message: > Portability fix. > > Patch: http://cvs.winehq.org/patch.py?id=11915 This isn't needed anymore. MinGW has accepted my patch that adds the defines to their header. I think that's the proper fix: they export fpclass() so they should export the corresponding defines for it's return values too. -Hans

1 0

Re: ShellExecute IE compatibility problems
by Martin Fuchs April 9, 2004

April 9, 2004

On 09.04.2004 02:03:37 Francois Gouget wrote: > > This patch fixes two IE compatibility problems. > > The first one is a mundane issue. IE calls ShellExecuteEx with a NULL > verb. Our implementation fails when it should use some sophisticated > algorithm described in the MSDN to choose a default verb. Well most of > the time we just want 'open' anyway so that's what this patch does. I've > left it as an exercise to the reader to head over to the MSDN and > implement the series of fallbacks we're supposed to implement. This is what SHELL_FindExecutable() tries to do when enumerating the registry keys. What is wrong with that - doesn't this work for you? I don't think we should go back and use "open" again if the verb parameter is NULL. Please correct the current algorithm, if it's not fully compliant. Regards, Martin

1 0

Re: Workaround a SoundBlaster 16 OSS bug
by Andreas Mohr April 9, 2004

April 9, 2004

Hi, On Fri, Apr 09, 2004 at 02:27:19AM +0200, Francois Gouget wrote: > Note: AFAIK Andreas' kernel patch has never been applied :-( In fact it has been, fortunately, just about two weeks ago... By Andreas Kies in 2.4.26-pre3. He'd already patched 2.6.x a bit earlier. I've been trying to get the slightest bit of attention about that DoS at that time, but after two very detailed fruitless mails to LKML, I just gave up: http://www.uwsg.iu.edu/hypermail/linux/kernel/0206.0/0087.html http://www.uwsg.iu.edu/hypermail/linux/kernel/0206.2/0033.html Andreas Kies told me that it seemed that they now cared a slight wee bit more about small fringe problems such as DoSes in 2.4.x... </sarcasm> > (now you know how to mount a DOS on these systems!) Ow, watch your words! This can be VERY easily misinterpreted as mounting a DOS partition somewhere!? (in fact I did fall for it the first couple of seconds) > Patch the fragment size if it does not match the current sound > format. This saves us from trigerring a kernel freeze on some OSS 2.4 + > SounBlaster 16 systems. Crap, I thought I'd sent a Wine patch at that time; it would have been the easiest thing to do. Anyway, glad to see it fixed now. Greetings, Andi (been finishing my wireless driver any single day for about 5 months now :))

2 1