June 2007 - Wine-devel - list.winehq.org

Re: cmd.exe: Fix FOR so it works as 'well' as before.
by Detlef Riekenberg 18 Jun '07

18 Jun '07

Hi Jason. The Patch is already in the tree, but I have a question: + * + * Execute a command, and any && or bracketed follow on to the command. The + * first command to be executed may not be at the front of the + * commands->thiscommand string (eg. it may point after a DO or ELSE + * Returns TRUE if something like exit or goto has aborted all processing + */ +void WCMD_part_execute(CMD_LIST **cmdList, WCHAR *firstcmd, WCHAR *variable, + WCHAR *value, BOOL isIF, BOOL conditionTRUE) { + The comment missed a closing bracked somewhere. How does the "Returns TRUE" match the declaration ("void")? Thanks -- By by ... Detlef

1 0

Building Wine with the lsb sdk, take 2
by Dan Kegel 18 Jun '07

18 Jun '07

At the Linux Summit, a bunch of us decided it'd be a good idea to try out lsbcc on more real-world packages, so I tried wine again tonight. My previous try was described here: http://www.winehq.org/pipermail/wine-devel/2006-August/050554.html This time I used Feisty Fawn's lsb build env packages: sudo apt-get install lsb-build-cc3 This installed lsbcc (well, lsbcc3, anyway; looks like that's a debianism that isn't mentioned in the official lsb doc). And instead of making configure aware of lsbcc3, I created the file ~/bin/gcc containing #!/bin/sh exec lsbcc3 "$@" (Yes, the first line is needed, make fails without it.) and did chmod +x ~/bin/gcc and added ~/bin early in my PATH. Then I did configure etc. Finally, I still had to use a few of the same magic incantations explained in my last message on the subject when building: LSBCC_SHAREDLIBS=wine export LSBCC_SHAREDLIBS make LDFLAGS=-ldl CFLAGS="-g -O2 \"-DRTLD_DEFAULT=((void *)0)\" -DMAP_FILE=0" The first real problem I ran into was that freetype wasn't found. This turned out to be http://bugs.linuxbase.org/show_bug.cgi?id=1577 and I just ignored it for now. The second real problem I ran into was /home/dank/wine-git/server/ptrace.c:103: undefined reference to `ptrace' Last mention I've seen of ptrace in lsb was http://lists.debian.org/lsb-spec/2001/02/msg00038.html and I guess it never made it in. I've filed this as http://bugs.linuxbase.org/show_bug.cgi?id=1664 - Dan

3 2

Re: hnetcfg: Resend Stub implementation of the dll
by Alexandre Julliard 18 Jun '07

18 Jun '07

Jeff Latimer <lats(a)yless4u.com.au> writes: > --- /dev/null > +++ b/dlls/hnetcfg/Makefile.in > @@ -0,0 +1,14 @@ > +TOPSRCDIR = ../.. > +TOPOBJDIR = ../.. > +SRCDIR = . > + > +MODULE = hnetcfg.dll > +IMPORTS = kernel32 > +IMPORTLIB = libhnetcfg.$(IMPLIBEXT) > + > +C_SRCS = \ > + hnetcfg.c > + > +(a)MAKE_DLL_RULES@ > + > +(a)DEPENDENCIES@ # everything below this line is overwritten by make depend That's not a valid Makefile.in. -- Alexandre Julliard julliard(a)winehq.org

1 0

debugging help
by Damjan Jovanovic 18 Jun '07

18 Jun '07

Hi I've been looking at bug 4437, where a game demo works perfectly with the native MSVCRT.DLL but dies on startup with the builtin due to a division by zero. The builtin doesn't have any fixmes, warnings or errors. Comparing builtin +relay and native +snoop traces shows the divide by zero doesn't happen with the native, everything else looks the same. A +msvcrt log is 200000 lines long but there is nothing obviously wrong either, a +all,+relay log shows nothing useful before the crash - the last function called before the crash is a simple printf without any %'s, which produces the same results on native and builtin. Disassembling around the crash shows a long chain of calculations that dies on the fated idivl. So it looks like a nasty delayed-effect bug. I'd welcome any new ideas, and I also have a few questions. Does +relay catch all function calls? Because some functions like sscanf only appear in +snoop, not in +relay. And is there a way for a builtin DLL to LoadLibrary() the native DLL of the same name and call functions in it? It would be very useful in narrowing down the bug. Thank you Damjan

2 1

Re: QUARTZ: Patch 1 - Fix video rendering sizing/positioning bugs
by Stefan Dösinger 17 Jun '07

17 Jun '07

> --- wine-0.9.39-cvs/dlls/quartz/videorenderer.c 2007-05-17 10:25:02.000000000 -0500 > +++ wine-0.9.39-cvs-patch/dlls/quartz/videorenderer.c 2007-06-17 00:47:15.000000000 -0500 You should really use git. It may be some effort to learn, but it makes your life, and Alexandre's much easier in the long run.

1 0

Re: QUARTZ: Patch 2 - Move blitting operation to message thread and handle WM_PAINT
by Chris Robinson 17 Jun '07

17 Jun '07

I have no direct comment on the patch (it's not really my area), but there's something I'd like to bring up. On Sunday 17 June 2007 01:51:56 pm a_villacis(a)palosanto.com wrote: > This patch moves the blitting code into the message thread. This is a setup > patch for the DirectDraw rewrite, but can be applied on its own after the > first patch. I'm all for changing the video renderer away from GDI, however I think it'd be better to move it to Direct3D or WGL instead of DDraw. I'm quite sure native quartz uses Direct3D when available, given that DDraw has been deprecated ever since DX7. Also, using native quartz's video renderer causes wined3d debug output for me, and as Stefan says, DDraw currently defaults to GDI so it wouldn't have come from that.

1 0

Re: dinput: Handle multiple keyboard and mouse devices. Get rid of the message window. [resend]
by Vitaliy Margolen 17 Jun '07

17 Jun '07

Please don't apply this patch. I will need to change few more things that will affect parts of this patch. Vitaliy. Vitaliy Margolen wrote: > Please use this one instead. The other patch had accidentally escaped debug > statements. > > Fixes bug 7129. > > The whole idea here is to set/release hook only once for keyboard/mouse. > Then if we have more then one device, just call their hook handlers from > the single > top level handler. > > Also, since we don't really check the return status from setting the > hook itself > get rid of the message window. Just notify the thread it needs to > recheck device > lists and set/remove hooks. > > --- > dlls/dinput/dinput_main.c | 234 > +++++++++++++++++++++++++----------------- > dlls/dinput/dinput_private.h | 3 +- > dlls/dinput/keyboard.c | 54 ++-------- > dlls/dinput/mouse.c | 28 +----- > 4 files changed, 156 insertions(+), 163 deletions(-) > > > ------------------------------------------------------------------------ > >

1 0

re: vxd loading is broken last months
by Dan Kegel 17 Jun '07

17 Jun '07

Vitaly Lipatov wrote: > INT21_CreateMagicDeviceHandle in winedos/int21.c uses the same dummy file > magic with open file with unix path from wine_get_server_dir(). > I guess we could use NtCreateFile on unix path before. > Now we need select correct place for such dummy files inside wine disk tree... Yeah. Evan has been sitting on a patch to fix this for a week now. Evan, I'd say it's time to post your minimal test and the fix, even if things are broken. - Dan

4 3

GDI+ programs
by Evan Stade 16 Jun '07

16 Jun '07

Hi, I want to make some real applications work with the built-in wine GDI+. Does anyone know of some programs that use GDI+ that would be good for guiding my development? thanks, Evan Stade

5 4

vxd loading is broken last months
by Vitaly Lipatov 16 Jun '07

16 Jun '07

CreateFile is not success with somename.vxd (somename.vxd.so exists in /usr/lib/wine) As known open_vxd_handle( LPCWSTR name ) in kernel32/vxd.c have to open dummy file in the wineserver directory. It try use NtCreateFile for open Unix path /tmp/.wine/... and get failure. What part have to be fixed? NtCreateFile or open_vxd_handle? -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

2 2