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

Re: [PATCH 1/3] gdi32: Set current position properly after ArcTo.
by Alexandre Julliard June 20, 2007

June 20, 2007

Misha Koshelev <mk144210(a)bcm.edu> writes: > + if (!PATH_IsPathOpen(dc->path)) > { > - angle = atan2( > - ((yend-ycenter)/height), > - ((xend-xcenter)/width)); > - MoveToEx(hdc, GDI_ROUND(xcenter+(cos(angle)*xradius)), > - GDI_ROUND(ycenter+(sin(angle)*yradius)), NULL); > + if (result && dc->funcs->pMoveTo) result = dc->funcs->pMoveTo(dc->physDev,end.x,end.y); It would be cleaner to add a PATH_ArcTo function instead of having multiple PATH_IsPathOpen checks in the generic function. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: OpenFile16 and similar functions
by Dan Kegel June 20, 2007

June 20, 2007

On 6/20/07, Jakob Eriksson <jakob(a)vmlinux.org> wrote: > Are not the tests still EXE-s called by winetest? Then the current > winetest will work OK. Except that winetest.h might not compile in 16 bit mode, and our build system doesn't handle 16 bit binaries, and gcc/ld can't build 16 bit NE executables, and you can't mix 16 and 32 bit easily so we'd need a winetest16, yes. :-) > Though we would benefit from having a crosscompiler to 8086 Windows EXEs. Yeah, I haven't checked yet whether openwatcom's linux version can build 16 bit NE executables. Sure would be cool! - Dan

2 1

re: OpenFile16 and similar functions
by Dan Kegel June 20, 2007

June 20, 2007

Anatoly asked: > How can I write a test for this function or build program use it? I think writing good win16 tests requires a 16 bit linker. Fortunately, OpenWatcom has one, and works on Wine. It's amazingly easy to install it and build one of its demo apps: $ wget http://ftp.openwatcom.org/ftp/open-watcom-c-win32-1.6.exe $ wine open-watcom-c-win32-1.6.exe $ wineboot $ cd .wine/drive_c/WATCOM/samples/win/alarm/win16 $ wine wmake $ wine alarm This builds an honest-to-goodness win16 binary that works on XP (possibly with one warning dialog you have to ignore). Unfortuately, Wine doesn't currently run these win16 apps properly; they hang with err:ntdll:RtlpWaitForCriticalSection section 0x7b91f300 "syslevel.c: Win16Mutex" wait timed out in thread 000b, blocked by 000c, retrying (60 sec) This is embarassing. These are the "hello, world" of 16 bit windows apps, and current wine (well, wine-0.9.37-g3739b5f) can't run them... I haven't looked to see if older wine runs these 16 bit demo apps properly.

2 3

OpenFile16 and similar functions
by Anatoly Lyutin June 19, 2007

June 19, 2007

Hi all! How can I write a test for this function or build program use it? I do not understand how I can do this uses Wine? Thank you for attention! =) -- Best regards Anatoly Lyutin.

1 0

Re: [4/5] D3D8: Convert FVFs to vertex declarations
by H. Verbeet June 19, 2007

June 19, 2007

On 19/06/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > + if (hr != S_OK) return NULL; Any reason for not simply using FAILED(hr) there? > + object->decls = HeapAlloc(GetProcessHeap(), 0, 0); Is that useful?

3 4

Compiling Wine on Fedora 7 64-bit (opengl fails)
by Paul Vriens June 19, 2007

June 19, 2007

Hi, I'm a total newbie to the 64-bit world (just built a system this weekend) and now I'm trying to get Wine compiled. It fails with (the first failure that is): LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -D__WINESRC__ -foversion.res version.rc ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./opengl32.spec opengl_ext.o opengl_norm.o wgl.o version.res -o opengl32.dll.so -luser32 -lgdi32 -ladvapi32 -lkernel32 -lntdll -L/usr/lib64 -lSM -lICE -lXxf86vm -lXext -lX11 -lGL ../../libs/port/libwine_port.a /usr/bin/ld: skipping incompatible /usr/lib64/libSM.so when searching for -lSM /usr/bin/ld: skipping incompatible /usr/lib64/libICE.so when searching for -lICE /usr/bin/ld: skipping incompatible /usr/lib64/libXxf86vm.so when searching for -lXxf86vm /usr/bin/ld: skipping incompatible /usr/lib64/libXext.so when searching for -lXext /usr/bin/ld: skipping incompatible /usr/lib64/libX11.so when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/lib64/libGL.so when searching for -lGL /usr/bin/ld: skipping incompatible /usr/lib64/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib64/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib64/libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib64/libc.a when searching for -lc wgl.o: In function `wglUseFontOutlines_common': wgl.c:(.text+0xec6): undefined reference to `gluNewTess' wgl.c:(.text+0xeec): undefined reference to `gluTessCallback' wgl.c:(.text+0xf09): undefined reference to `gluTessCallback' wgl.c:(.text+0xf26): undefined reference to `gluTessCallback' wgl.c:(.text+0x13b9): undefined reference to `gluTessBeginPolygon' wgl.c:(.text+0x1432): undefined reference to `gluTessBeginContour' wgl.c:(.text+0x146e): undefined reference to `gluTessVertex' wgl.c:(.text+0x1563): undefined reference to `gluTessVertex' wgl.c:(.text+0x167f): undefined reference to `gluTessVertex' wgl.c:(.text+0x16ca): undefined reference to `gluTessVertex' wgl.c:(.text+0x174b): undefined reference to `gluTessEndContour' wgl.c:(.text+0x178b): undefined reference to `gluTessEndContour' wgl.c:(.text+0x17b9): undefined reference to `gluTessEndPolygon' wgl.c:(.text+0x18a0): undefined reference to `gluDeleteTess' collect2: ld returned 1 exit status winegcc: gcc failed. make: *** [opengl32.dll.so] Error 2 Any suggestions where to start looking or how to approach this. I had a look at the Wiki to no avail. I've tested with and without the NVIDIA drivers. I also have another F7 box, 32-bit, that works fine. Cheers, Paul.

3 3

Re: [2/5] WineD3D: Remove the FVF codepath from drawprim
by H. Verbeet June 19, 2007

June 19, 2007

Not specific to this patch, but will you remove the fvf field from the stateblock as well?

2 3

Re: QUARTZ: Patch 1 - Fix video rendering sizing/positioning bugs
by Alexandre Julliard June 19, 2007

June 19, 2007

a_villacis(a)palosanto.com writes: > + case WM_SIZE: > + TRACE("WM_SIZE %d %d\n", LOWORD(lParam), HIWORD(lParam)); > + SetWindowPos(hwnd, NULL, pVideoRenderer->WindowPos.left, pVideoRenderer->WindowPos.top, LOWORD(lParam), HIWORD(lParam), SWP_NOZORDER); Why do you want to resize a window that has just been resized? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [AppDB] Increase menu text size
by Alex Waite June 19, 2007

June 19, 2007

Alexander Nicolaysen Sørnes wrote: > This should make it easier for people to notice the menu options. From 10px > to 11px. > > > Regards, > > Alexander N. Sørnes > > > ------------------------------------------------------------------------ > > I agree with increasing text size here, but we should keep in mind a few things. Setting text size in pixels is no longer the cool thing to do. W3C feels that it is best to use the "x-small, small, medium, etc" values since they respect user settings and accessibility the most. An alternative which gives more control but isn't quite as proper is to use em instead of px. Either is better than using pixels. Also, this text size should be changed on all pages because the menu text size in the AppDB is now larger than the text in the menu on the front page. I am part of a large project at my work where I have had to learn quite a bit about web accessibility and best practices. Contrary to popular (and lazy) belief, most of it actually makes it easier in the end to write and maintain a large website. Plus the site is accessible to more users. ---Alex

2 1

Re: [4/5] WineD3D: Emulate tracking of multiple material properties
by H. Verbeet June 19, 2007

June 19, 2007

On 19/06/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > + if(!This->stateBlock->vertexShader) { > Testing for a vertex shader like that doesn't take into account the selected vs mode (ie, could be disabled) or transformed vertices. You should probably be using use_vs() instead.

1 0

Re: [3/5] WineD3D: Do not attempt to load texture coords for unsupported stages
by H. Verbeet June 19, 2007

June 19, 2007

I remember discussing this patch, but in retrospect I'm not sure this fix is completely correct. When a pixel shader is used with fixed function vertex processing, more than GL_LIMITS(textures) texture coordinates can be used.

1 0

Re: winex11 - Fix X11DRV_DIB_GetImageBits() when target bitmaps are larger than fetched area
by Alexandre Julliard June 19, 2007

June 19, 2007

Peter Dons Tychsen <donpedro(a)tdcadsl.dk> writes: > #ifdef HAVE_LIBXXSHM > - if (descr->image && descr->useShm) > + > + if(descr->image && descr->useShm) > + { > + XGetGeometry(gdi_display, descr->drawable, &root, &x, &y, &width, > &height, &border_width, &depth); > + TRACE("XGetGeometry(), width=%i, heigth=%i\n", width, height); > + } > + > + /* We must not call XShmGetImage() with a bitmap which is bigger > than the avilable area. > + If we do, XShmGetImage() will fail (X exception), as it checks > for this internally. */ > + if((descr->image && descr->useShm) && (bmpImage->width <= (width - > descr->xSrc)) > + && (bmpImage->height <= (height - descr->ySrc))) > { > int saveRed, saveGreen, saveBlue; The patch is wrapped, and you don't want to use XGetGeometry, this incurs a server round-trip. -- Alexandre Julliard julliard(a)winehq.org

1 0

Adds NET STOP to net.exe
by Kirill K. Smirnov June 19, 2007

June 19, 2007

Hi, Tim. Please, proceed bug #8554. Thanks, -- Kirill

1 0

Re: winex11.drv: send WM_MOUSEACTIVATE before closing a window (try 3)
by Dmitry Timoshkov June 19, 2007

June 19, 2007

"Lei Zhang" <thestig(a)google.com> wrote: > On Windows, clicking the close button of a nonactive window generates > a WM_MOUSEACTIVATE notification. Applications with custom window > procedures can then choose to ignore the close button if they wished > to by returning MA_ACTIVATEANDEAT / MA_NOACTIVATEANDEAT. I'm not sure what you mean by "applications with custom window procedures" because all (even simple ones) window procs in applications are custom, and they are free to handle/ignore any message they like, for instance WM_CLOSE or WM_SYSCOMMAND/SC_CLOSE. We already send WM_MOUSEACTIVATE message on a take focus X11 event, so I don't see a point in duplicating it. On the other hand if a WM doesn't activate a window when a user clicks on window's caption (where the close button usually placed) then it's a WM bug and we can do nothing to fix it. -- Dmitry.

2 4

Remove font set when calling XCreateIC?
by Nigel Liang June 19, 2007

June 19, 2007

Hi, This patch removes a call to XCreateFontSet which was causing wine to be very slow in some Chinese locale settings. The server side font calls are supposed to be deprecated anyway as Dan pointed out in his comment here: http://bugs.winehq.org/show_bug.cgi?id=5309 According to the Xlib programming manual, if a font set is not specified when calling XCreateIC, the default is determined by the input method. But it seems that this used to be a required field, so I am not sure if this will break any old input methods out there. Any ideas on how I could better test this before submitting? Thanks! -Nigel

1 0

Re: msi: Fix the conditions to determine which files to remove
by James Hawkins June 18, 2007

June 18, 2007

On 6/18/07, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > This fixes an error with a test Windows Installer Patch that I'm > trying to get working. > > Changelog: > * Fix the conditions to determine which files to remove. > Ignore this for right now. There's something else that needs to be fixed first. -- James Hawkins

1 0

Re: ntoskrnl.exe: Add a stub implementation of KeInitializeTimer
by James Hawkins June 18, 2007

June 18, 2007

On 6/18/07, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > The Fahrenheit installer calls this function. KTIMER is defined in > ketypes.h in the ddk, but that file doesn't exist for us yet, and I > followed the example of others and defined it in wdm.h (where most of > the types in ketypes.h were defined instead). > Nevermind my comments about the headers. osronline says it's defined in wdm.h, so this patch is still good to go. -- James Hawkins

1 0

Sorry, Opera is not yet supported by Xinha.
by RusH June 18, 2007

June 18, 2007

Bugzilla uses this new toy, but the script loads it even after it detects Opera = it eats the text in edit fields sometimes and I cant process Test Results. Could it load itselfe only when not detecting Opera? -- Who logs in to gdm? Not I, said the duck.

1 0

Winelib should have dir.h and some consts
by Jérôme Gardou June 18, 2007

June 18, 2007

I try to compile a small program which use msvcrt headers, and it appeared that, in winelib there is no dir.h (which may be redirected to dirent.h ?) and that consts like MAXPATH, MAXDRIVE and others are not defined. Should it be done ? Is it planned to be ? ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

2 1

Re: [Wine] Sending changes to winelib ?
by Scott Ritchie June 18, 2007

June 18, 2007

The wine-devel mailing list is best for this type of development question. Thanks, Scott Ritchie On Sun, 2007-06-17 at 12:49 +0200, Jérôme Gardou wrote: > I have a little program coded for windows, and I want to compile it using > winegcc. > > Unfortunately, some functions are not implemented in winelib, and I have to > tweak some files. So, How do I submit those changes ? I found nothing on the > WineHQ site. > > SO, if someone knows where to redirect me, I can do it alone! > > > > > > ___________________________________________________________________________ > Yahoo! Mail rinvente le mail ! Dcouvrez le nouveau Yahoo! Mail et son interface rvolutionnaire. > http://fr.mail.yahoo.com > > > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-users

1 0

Re: cmd.exe: Fix FOR so it works as 'well' as before.
by Detlef Riekenberg June 18, 2007

June 18, 2007

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 June 18, 2007

June 18, 2007

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 June 18, 2007

June 18, 2007

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 June 18, 2007

June 18, 2007

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 June 18, 2007

June 18, 2007

> --- 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 June 17, 2007

June 17, 2007

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 June 17, 2007

June 17, 2007

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 June 17, 2007

June 17, 2007

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 June 16, 2007

June 16, 2007

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 June 16, 2007

June 16, 2007

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

cmd.exe console question
by Ann & Jason Edmeades June 15, 2007

June 15, 2007

Out of interest, is there any way to get (read here 'write code for') the wine's cmd.exe better integrated in the window you launch it from when it is not in wineconsole mode. For example, I would love to see cls clear the screen (I suppose I could just launch 'clear'!), or command retrieval work (and, but by far the lowest priority, colo(u)rs). I *know* you can do it with wineconsole with user and curses backend, but in a 'normal' shell window the shell itself manages it, and is there any programming interface to that? One problem I can perceive is I cant tell between output being redirected to a file, or output being redirected to the shell window (neither query the console attributes) Jason

1 0

Re: [PATCH 2/2] dinput: Handle multiple keyboard and mouse devices.
by Detlef Riekenberg June 15, 2007

June 15, 2007

On So, 2007-06-10 at 19:20 -0600, Vitaliy Margolen wrote: > Should fix 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. > --- > dlls/dinput/dinput_main.c | 82 ++++++++++++++++++++++++++++++++++++++--- > dlls/dinput/dinput_private.h | 4 ++- > dlls/dinput/keyboard.c | 54 ++++++--------------------- > dlls/dinput/mouse.c | 28 ++------------ > 4 files changed, 95 insertions(+), 73 deletions(-) Works the same as native dinput. Thanks a lot. The sensitive high-speed Mouse-Accellerator for the RMB is also present with native dinput. I will add a new bug for that regression. Any Ideas, where to search? ("dlls/" or "dlls/winex11.drv/") As additional hint, the moving direction is most times fixed: When i start moving up/right (45*) while the RMB id pressed, then the app still see 45* when I move the mouse in a different direction (down or left as examples). Looks like a value is not reset. -- By by ... Detlef

1 0

Re: gdiplus: graphics tests [try2]
by Alexandre Julliard June 15, 2007

June 15, 2007

"Evan Stade" <estade(a)gmail.com> writes: > +static const INT drawline_bmp1[192] = > +{0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff, > + 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff, > + 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff, > + 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff, > + 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff, I don't think we want to do that sort of thing. We can't guarantee that the results will be exact pixel for pixel, and we don't really care. And even if we did, hardcoding the image in the source this way is unmaintainable. If you want to check the results, you should write an app that draws various things and check it visually against Windows, but I don't think that's something that can be part of the regression test suite. -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: [3/5] widl: Add tests for encapsulated unions
by Dan Hipschman June 15, 2007

June 15, 2007

On Thu, Jun 14, 2007 at 06:28:41PM -0700, Dan Hipschman wrote: > + if (strcmp(winetest_platform, "wine") != 0) /* crashes wine */ > + { > + eu.t = ENCU_I; > + eu.tagged_union.i = 7; > + ok(square_encu(&eu) == 49.0, "RPC square_encu\n"); > + > + eu.t = ENCU_F; > + eu.tagged_union.f = 3.0; > + ok(square_encu(&eu) == 9.0, "RPC square_encu\n"); > + } Hi. So, I realize the usual way to handle tests that crash wine (besides fixing the bug that causes the crash), is to "if (0)" or comment the test out, as in ntdll/tests/reg.c, or rpcrt4/tests/ndr_marshall.c, but this patch tests more than wine, it also tests widl, and it's therefore not just documentation. If I "if (0)" the test out (or worse, it doesn't get accepted), I'm going to have to edit the test each time I run it on windows to re-add the encapsulated union test so I can verify that the widl output stubs still work on windows. One solution is to do something like this: #ifndef TESTS_THAT_CRASH_WINE # define TESTS_THAT_CRASH_WINE 0 #endif ... if (TESTS_THAT_CRASH_WINE) { eu.t = ENCU_I; eu.tagged_union.i = 7; ok(square_encu(&eu) == 49.0, "RPC square_encu\n"); eu.t = ENCU_F; eu.tagged_union.f = 3.0; ok(square_encu(&eu) == 9.0, "RPC square_encu\n"); } So at least I can just compile with -DTESTS_THAT_CRASH_WINE=1 on windows, which is easy to stick in a batch file or something. Otherwise, I'm stuck maintaining a patch that has to be applied before each compile. Plus, it means I'm the only one who's probably testing encapsulated unions on windows, so it's only getting tested on one platform. Any chance something like the original patch can get into wine?

2 1

Liberation
by Louis. Lenders June 15, 2007

June 15, 2007

Hi, this is mainly a follow up to the thread here http://www.winehq.org/pipermail/wine-devel/2007-May/057092.html , to give it a new boost.... Question is, are there any plans to include Liberation fonts in wine? I gave it a good testing last two weeks, that is, i converted the fonts with Hans' Leidekkers script , from link above, and tested the "Arial-compatible" font quite a bit, with several applications. It all seems to work great, no issues / problems found. Several applications would be very happy , if this were to be included in wine. Any comments? Some of the tested apps: xchat --> just aborts silently without arial font Book worms adventures --> pops up a crash window without arial font d3d9-samples from DirectX 9.0 SDK --> Don't show any text without arial font + a lot more that just look prettier with arial font. --------------------------------- Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your freeaccount today.

7 10

gdiplus no longer available in Vista?
by Paul Vriens June 15, 2007

June 15, 2007

Hi, I had a look but wasn't able to find gdiplus.dll on my Vista box. This most likely means our test has to be re-written. I'll wait with that till the cross-compiling of the gdiplus tests is fixed. Cheers, Paul.

2 1

Problem with the Ubuntu 7.04 (Feisty) package (again)
by Ben Hodgetts (Enverex) June 15, 2007

June 15, 2007

We've had a few people report issues with the Ubuntu Feisty .38 package in the WineHQ repo lately (http://wine.budgetdedicated.com/archive/ubuntu/feisty/wine_0.9.38~winehq0~u…) the specific issue being that the fonts are all missing on most things, in other places only the first few letters may be shown. Originally I thought this was something to do with them lacking fonts but in each case telling them to install the .37 package instead fixed the issue meaning it's more likely to be a problem with the .38 package. Any ideas Scott? Ben H.

1 0

Re: [3/5] widl: Add tests for encapsulated unions
by Dan Hipschman June 15, 2007

June 15, 2007

On Thu, Jun 14, 2007 at 06:28:41PM -0700, Dan Hipschman wrote: > > This adds a test for encapsulated unions, but it crashes wine. The exact Hmm, now that I reread this, I think I said this wrong. The test does crash wine, but I wrote my patch so that it doesn't run on wine. So, doing "make check" in dlls/rpcrt4/tests will *not* crash wine, it just won't run the encapsulated union tests. The encapsulated union tests *will* run, and succeed, on windows, however. I felt this was best because that way all of widl's output can still continue to be tested on windows, and everything that can be tested in wine without crashing still will be.

1 0

Re: Uninstaller
by Misha Koshelev June 14, 2007

June 14, 2007

First of all, of course I am not Alexandre. But I have to say I think I agree with James on this, with regards to submitting just one patch with the correct spacing. I can see how seeing one patch without any spacing changes keeps the diff very simple (I am assuming this is why you submitted your patches in this way), but at the same time I would assume that if Alexandre really wants to see what changed in this way after applying the one patch you will send with correct spacing, he can just type: git-diff -b and see something very similar to your patch #1 (ignores whitespace, same effect). Other than that, I did not see anything obviously wrong with the patch upon a quick look. If you don't hear from anyone else on wine-devel, I would suggest resubmitting as one patch with correct indentation as James suggested. If you don't see it committed after a while (maybe a week or so, maybe longer) I would either get in touch with the list again or try to get in touch with Alexandre to see if he has any specific comments. Hope that helps. Misha

3 4

Re: include/uxtheme.h : enum THEMESIZE
by Michael Stefaniuc June 14, 2007

June 14, 2007

Nicolas (dyalog.com) wrote: > according to MSDN, include/uxtheme.h should define an "enum THEMESIZE", > which is typedefed to "THEME_SIZE", > rather than typedef the enum {} to "THEMESIZE" as it is currently. > http://msdn2.microsoft.com/en-us/library/ms649970.aspx > > note that dlls/uxtheme/draw.c uses this definition so must also be patched. Please merge those 2 changes into one patch as one without the other make the Wine source to not compile anymore. And please use unified diff format; the draw.c.patch isn't a unified diff. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: user32: improve cut/copy/paste behavior of password edit boxes
by Vitaly Lipatov June 14, 2007

June 14, 2007

В сообщении от 14 июня 2007 Lei Zhang написал(a): > Hi, > > This patch prevents cutting/copying text from edit boxes with the > ES_PASSWORD style. It also corrects the paste behavior of password Why we need prevent it? > edit boxes when the clipboard is empty. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

Re: Juan Lang : comdlg32: Initialize file dialog controls before creating dialog.
by Lei Zhang June 14, 2007

June 14, 2007

Hi Juan, With this patch, the bottom of file dialogs are cut off such that the file type dropdown and the cancel button can barely be seen. - Lei On 6/7/07, Alexandre Julliard <julliard(a)wine.codeweavers.com> wrote: > Module: wine > Branch: master > Commit: 13f18ee7593364a2a685fed2bdfa814431906f0c > URL: http://source.winehq.org/git/wine.git/?a=commit;h=13f18ee7593364a2a685fed2b… > > Author: Juan Lang <juan_lang(a)yahoo.com> > Date: Thu Jun 7 12:27:11 2007 -0700 > > comdlg32: Initialize file dialog controls before creating dialog. > > --- > > dlls/comdlg32/filedlg.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/comdlg32/filedlg.c b/dlls/comdlg32/filedlg.c > index f63e64f..5409b91 100644 > --- a/dlls/comdlg32/filedlg.c > +++ b/dlls/comdlg32/filedlg.c > @@ -1037,11 +1037,11 @@ INT_PTR CALLBACK FileOpenDlgProc95(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM l > so it will be easily accessible through a GetPropA(...) */ > SetPropA(hwnd, FileOpenDlgInfosStr, (HANDLE) fodInfos); > > + FILEDLG95_InitControls(hwnd); > + > fodInfos->DlgInfos.hwndCustomDlg = > CreateTemplateDialog((FileOpenDlgInfos *)lParam, hwnd); > > - FILEDLG95_InitControls(hwnd); > - > if (fodInfos->DlgInfos.hwndCustomDlg) > { > RECT rc; > > > >

2 2

Re: [3/5] WineD3D: Present does not clear the depth stencil
by H. Verbeet June 14, 2007

June 14, 2007

On 14/06/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > The patch removes the clearing from Present, except for the DISCARD swap effect if the d3d trace channel is on. It sounds a bit questionable to have different behaviour depending on the debug channel.

2 2

Re: [crypt32/tests 2/2] Vista uses a different error code (RESEND)
by Dmitry Timoshkov June 14, 2007

June 14, 2007

"Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: > ret = CryptSIPRetrieveSubjectGuid(tempfileW, NULL, &subject); > ok ( !ret, "Expected CryptSIPRetrieveSubjectGuid to fail\n"); > ok ( GetLastError() == ERROR_FILE_INVALID || > + GetLastError() == ERROR_INVALID_PARAMETER /* Vista */ || > GetLastError() == S_OK /* Win98 */, > - "Expected ERROR_FILE_INVALID or S_OK, got 0x%08x\n", GetLastError()); > + "Expected ERROR_FILE_INVALID, ERROR_INVALID_PARAMETER or S_OK, got 0x%08x\n", GetLastError()); S_OK is an OLE error, ERROR_SUCCESS is correct name in this case. It's not your fault at all, but since you are fixing this code it would be nice to fix it as well. -- Dmitry.

2 1

Re: Fixed the WriteEnvironmentStrings action [try2]
by Dmitry Timoshkov June 14, 2007

June 14, 2007

"James Hawkins" <truiken(a)gmail.com> wrote: > + while (*cptr && (*cptr == '=' || *cptr == '+' || > + *cptr == '-' || *cptr == '!' || *cptr == '*')) > + { > + switch (*cptr) > + { > + case '=': > + *flags |= ENV_ACT_SETALWAYS; > + break; > + case '+': > + *flags |= ENV_ACT_SETABSENT; > + break; > + case '-': > + *flags |= ENV_ACT_REMOVE; > + break; > + case '!': > + *flags |= ENV_ACT_REMOVEMATCH; > + break; > + case '*': > + *flags |= ENV_MOD_MACHINE; > + break; > + default: > + ERR("Unknown Environment flag: %c\n", *cptr); > + return ERROR_FUNCTION_FAILED; > + } > + > + cptr++; > + (*name)++; > + } A simple 'goto' in the 'default:' case, or using while (*cptr) { if (*cptr == '=') else if (*cptr == '+') { } else if (...) { } else break; } would help to avoid double comparisons and simplify the code. -- Dmitry.

1 0

Re: patch for winefile.
by Dmitry Timoshkov June 14, 2007

June 14, 2007

"Ivan Sinitsin" <ivan(a)etersoft.ru> wrote: > + static const WCHAR sFont[] = {'M','i','c','r','o','s','o','f','t',' ','S','a','n','s',' ','S','e','r','i','f','\0'}; > + HDC hdc = GetDC(0); ... > + if( RegQueryValueEx( hKey, reg_font_facename, NULL, &type, > + (LPBYTE) &logfont.lfFaceName, &sizeW) != ERROR_SUCCESS ) > + strcpyW(logfont.lfFaceName,sFont); It's not very useful to use by default the font that is not available on any Linux installation by default. I'd suggest to use GetStockObject(DEFAULT_GUI_FONT) instead. And you are leaking an hdc. > + LOGFONT logfont; > > wi.cbSize = sizeof( WINDOWINFO ); > GetWindowInfo(Globals.hMainWnd, &wi); > width = wi.rcWindow.right - wi.rcWindow.left; > height = wi.rcWindow.bottom - wi.rcWindow.top; > + GetObject((HGDIOBJ)Globals.hfont, sizeof(logfont), (LPVOID)&logfont); This cast is not needed. -- Dmitry.

1 0

Uninstaller
by Tom Spear June 14, 2007

June 14, 2007

It's been a while since I brought anything up on this, so I figured I'd ask what was wrong with the last set of patches I sent.. The patches are at [1] and [2], the discussion generated by them are at [3], [4], [5], and [6]... Summary, I did everything I was told in private by a developer (who isn't alexandre, i know), and I got told by another developer, who also isn't alexandre, to fix some things that the first developer said didn't need fixing.. So should I fix those things, or is there some other reason it wasn't committed? [1] http://www.winehq.org/pipermail/wine-patches/2007-June/039911.html [2] http://www.winehq.org/pipermail/wine-patches/2007-June/039912.html [3] http://www.winehq.org/pipermail/wine-devel/2007-June/057253.html [4] http://www.winehq.org/pipermail/wine-devel/2007-June/057254.html [5] http://www.winehq.org/pipermail/wine-devel/2007-June/057255.html [6] http://www.winehq.org/pipermail/wine-devel/2007-June/057258.html Someone please let me know what is wrong (I'd love to hear from The Man, if he has time to take a look), but anyone's responses are welcome (hopefully I get more than 2 reponses this time lol).... -- Thanks Tom

1 0

Re: [GDI+: 7/7] implemented GdipDrawImage
by Evan Stade June 14, 2007

June 14, 2007

On 6/13/07, Evan Stade <estade(a)gmail.com> wrote: > Hi, > > changelog: > *implemented GdipDrawImage > > dlls/gdiplus/gdiplus.spec | 2 +- > dlls/gdiplus/graphics.c | 28 ++++++++++++++++++++++++++++ > include/gdiplusflat.h | 1 + > 3 files changed, 30 insertions(+), 1 deletions(-) > > -Evan Stade > > ignore this patch

1 0

msi: Fixed the WriteEnvironmentStrings action
by Misha Koshelev June 14, 2007

June 14, 2007

> + res = RegQueryValueExW(env, name, NULL, &type, NULL, &size); > + if (res != ERROR_FILE_NOT_FOUND || (res == ERROR_SUCCESS && type != REG_SZ)) > + goto done; Hate to point this out but isn't this the exact same error I made in my first (and second) patch from last night? I think it should be: if ((res != ERROR_FILE_NOT_FOUND && res != ERROR_SUCCESS) || (res == ERROR_SUCCESS && type != REG_SZ)) goto done; In your statement, if res is ERROR_SUCCESS it will always goto done no matter what the value of type, because ERROR_SUCCESS != ERROR_FILE_NOT_FOUND. Guess logic errors in if statements are contagious :) Misha

1 0

Re: msi: Do not use type value if call to RegQueryValueEx failed.
by James Hawkins June 13, 2007

June 13, 2007

On 6/12/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > This is necessary (bug not sufficient, see my comment in the bug report that I am about > to post) to fix bug 8678. > > It is also clearly correct, as checking the type "returned" by RegQueryValueEx when it fails > makes no sense. > size = 0; res = RegQueryValueExW(env, var, NULL, &type, NULL, &size); - if ((res != ERROR_MORE_DATA && res != ERROR_FILE_NOT_FOUND) || type != REG_SZ) + if ((res != ERROR_MORE_DATA && res != ERROR_FILE_NOT_FOUND) || + (res == ERROR_SUCCESS && type != REG_SZ)) { RegCloseKey(env); return res; This is wrong. If res == ERROR_SUCCESS, then the first condition evaluates to TRUE and we fall through to exit, but then again, res will never be ERROR_SUCCESS after that particular call. Either way, I have a patch ready to send in that fixes the entire action. -- James Hawkins

3 2

Re: [crypt32/tests 2/2] Vista uses a different error code
by Kai Blin June 13, 2007

June 13, 2007

On Wednesday 13 June 2007 16:13:21 Paul Vriens wrote: > ok ( GetLastError() == ERROR_FILE_INVALID || > + GetLastError() == ERROR_INVALID_PARAMETER /* Vista */ || > GetLastError() == S_OK /* Win98 */, > "Expected ERROR_FILE_INVALID or S_OK, got 0x%08x\n", > GetLastError()); ok ( !memcmp(&subject, &nullSubject, sizeof(GUID)), In that case I think it would make sense to also fix the message. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://us1.samba.org/samba/team/ -- Will code for cotton.

1 0

Re: gdi32: Add some tests for BITMAPINFOHEADER biSize checks.
by Dmitry Timoshkov June 13, 2007

June 13, 2007

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > These tests pass on XP and on Wine with Dimitry's patch applied. > I can also confirm that the patch fixes bug 8674. > > -Hans > > Changelog > Add some tests for BITMAPINFOHEADER biSize checks. Please add DeleteObject calls to delete a DIB section after each succeeding test. -- Dmitry.

1 0

CJK XCreateFontSet performance problem (bug 5309)
by dank＠kegel.com June 13, 2007

June 13, 2007

It turns out bug 5309 affects Picasa; a Chinese user complained that menus were terribly slow. The patch Aric committed here: http://www.winehq.org/pipermail/wine-cvs/2006-October/027272.html seems to have helped. I'm wondering, though, whether this points up a problem in how linux distros configure their asian fonts. I'm sending this via direct telnet to winehq's tsmtp server, since there's no other way to avoid setnding passwords in the clear from where I am at the momment (dang unencrypted wireless in hotel forooms.). Sorry for all the ^H's :-)

1 0

Seeking advice for rewrite of dlls/quartz/videorenderer.c using DirectDraw
by Alex Villacís Lasso June 13, 2007

June 13, 2007

From a time till now, I am using a test application in Visual Basic in order to test progress in quartz. The code for the application (along with a precompiled EXE) can be found at the following address: http://www.palosanto.com/~a_villacis/WMediaTest.tar.bz2 One of the things I dislike about the current quartz implementation is that when a large AVI video file (say, 640x480) is played with the test application, the sound stutters (in both ALSA and OSS) while the frames are being updated. This occurs with the builtin quartz.dll, but not with native (WinXP) quartz. From what I can deduce from WINEDEBUG=+tid,+quartz , it seems that builtin feeds video and audio in the same thread. In addition, dlls/quartz/videorenderer.c uses StretchDIBits() in order to write one frame of video into the output window. Apparently StretchDIBits() is slow enough in my machine that it cannot complete by the next sound sample. Therefore the stuttering. I made a little patch to move the video rendering in videorender.c into a separate thread, in order to allow it to drop frames. However this does not completely eliminate the stuttering audio. I am now thinking about rewriting the video rendering with DirectDraw. It seems that native quartz.dll uses DirectDraw, not GDI, to display video frames into the output window. One thing I am worried about is the pixel format of the surfaces. The video data is 32bpp, but the output window uses my X config at 16bpp. However, nowhere in the ddraw trace of native quartz I can find any reference to a CreateSurface with 32bpp. It seems that native quartz does the depth conversion itself. The question is this: if I create a 32 bpp surface (in order to lock it and write the 32 bpp frame data into it), can I then blit it into a 16 bpp output window and somehow let DirectDraw take care of the depth conversion? If so, can this be any faster than writing the depth conversion myself? Alex Villacís Lasso -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

4 5

Re: [GDI+ implementation: 1/8] GdipDrawLineI
by Evan Stade June 13, 2007

June 13, 2007

On 6/12/07, Evan Stade <estade(a)gmail.com> wrote: > Hi, > > Changelog: > *implemented GdipDrawLineI > > dlls/gdiplus/gdiplus.spec | 2 +- > dlls/gdiplus/graphics.c | 16 ++++++++++++++++ > 2 files changed, 17 insertions(+), 1 deletions(-) > > -Evan Stade > > Sorry, to clarify: this series of patches is a resend of the last without the tests, and with some new patches.

2 1

Re: [GDI+: 2/10] first pen test
by Detlef Riekenberg June 13, 2007

June 13, 2007

On Mo, 2007-06-11 at 11:52 -0700, Evan Stade wrote: > + > + status = GdipCreatePen1((ARGB)0xffff00ff, 10.0f, UnitPixel, > &pen); > + > + todo_wine > + expect(GdiplusNotInitialized, status); > + > + GdipDeletePen(pen); > +} Is pen set to NULL, when GdipCreatePen1 failed? This ist not checked in your test and not done in your implementation, but you pass uninitialized garbage (pen) to GdipDeletePen. You might want to use: - GpPen *pen; + GpPen *pen = NULL; and - GdipDeletePen(pen); + if (status == Ok) then GdipDeletePen(pen); Thanks -- By by ... Detlef

3 2

Re: advapi32: Allow setting CRYPT_VERIFYCONTEXT and CRYPT_NEWKEYSET in CryptAcquireContext
by Mounir IDRASSI June 13, 2007

June 13, 2007

Hi Maarten, You should not modify advapi32 to accommodate this behavior but rsaenh instead. The acceptance of this flags combination is specific to the Microsoft RSA CSP implementation and other vendors don't support it (I tested it with four third party CSPs). Moreover, your patch will clearly introduce unexpected CSP behavior when this combination of flags is specified as you start by acquiring a context using CRYPT_NEWKEYSET only: the returned context will not behave as intended by the CRYPT_VERIFYCONTEXT flag which normally limits many things. The modification to rsaenh is straightforward: in the code of RSAENH_CPAcquireContext, juste add the line "case CRYPT_VERIFYCONTEXT | CRYPT_NEWKEYSET:" above the existing line "case CRYPT_VERIFYCONTEXT:". Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Maarten Lankhorst wrote: > With tests. I think this is the correct way to do this: First try to > Acquire with CRYPT_NEWKEYSET, then CRYPT_VERIFYCONTEXT if it already exists. >

1 0

Re: [7/7] Add ID3D10Device interface and implement it's IUnknown methods
by H. Verbeet June 12, 2007

June 12, 2007

On 13/06/07, Kovács András <andras(a)csevego.net> wrote: > + TRACE("Adapter %p, Driver Type %d, Software Module handle %p, Flags %08x, SDKVersion %d, Device %p\n", > + Adapter, DriverType, Software, Flags, SDKVersion, Device); I think the DriverType should be traces as string there (ie, using something like the debug_d3d*() functions in dlls/wined3d/utils.c). Also, please prefix hexadecimal numbers with 0x. d3d8 and d3d9 are pretty bad wrt producing readable traces, but we might as well do it right when writing a new dll. > + FIXME("ID3D10Device interface is not binary compatible to windows yet\n"); Actually, a void * is binary compatible with IDGXIAdapter * I suppose it's a matter of taste, but personally I think more C like naming (ie, lower case, _ separated) for the parameter names would be easier on the eyes :-) (and you do use those for the ID3D10DeviceImpl functions). Chris already mentioned the initial refcount on IRC.

2 2

Re: Allow GL_ONE on WINED3DRS_EDGEANTIALIAS dstBlend value (try 2)
by H. Verbeet June 12, 2007

June 12, 2007

On 13/06/07, Kovács András <andras(a)csevego.net> wrote: > Hi, > > Allow GL_ONE on WINED3DRS_EDGEANTIALIAS' dstBlend value. This fixes Pirates Of > Caribbean At The Worlds End blending problem. ( black square behind linght > sources) > > -- I think I wasn't very clear wrt what I said on IRC / wrote in my earlier mail. The original patch was fine with me for what it did. What I meant to say was that an additional patch should probably follow that one to remove the code that modifies srcBlend and dstBlend. Personally I think the changes are small enough to go in a single patch, but that would be up to Alexandre. You should remove the line modifying srcBlend a few lines above as well though.

1 0

Re: [7/7] Add ID3D10Device interface and implement it's IUnknown methods
by Stefan Dösinger June 12, 2007

June 12, 2007

Am Mittwoch, 13. Juni 2007 00:17 schrieb Kovács András: > [7/7] Add ID3D10Device interface and implement it's IUnknown methods >+ object->lpVtbl = &D3D10Device_Vtbl; >+ object->ref = 0; Spotted by KittyCat on irc. The ref should be 1. Either set it to 1, or call ID3D10Device_AddRef(*Device) after setting *Device(ms seems to do it the Addref way).

1 0

Re: [PATCH try2 1/3] setupapi/tests: Add rudimentary tests for InstallHinfSectionA/W.
by Detlef Riekenberg June 12, 2007

June 12, 2007

On Mo, 2007-06-11 at 23:29 -0500, Misha Koshelev wrote: > + * - On installation problems, a MessageBox is displayed and there > does not seem to be a way to turn this off. A CBT-Hook (HCBT_CREATEWND) might help -- By by ... Detlef

2 1

Re: [GDI+: 3/10] graphics implementation
by Detlef Riekenberg June 12, 2007

June 12, 2007

On Mo, 2007-06-11 at 11:54 -0700, Evan Stade wrote: > + > + *graphics = (GpGraphics*) HeapAlloc(GetProcessHeap(), > HEAP_ZERO_MEMORY, > + sizeof(GpGraphics)); Have you checked, that the native dll does the same? (WINEDEBUG="+snoop,+relay") Your implementation of GdipCreatePen1 is using GdipAlloc. Thanks -- By by ... Detlef

2 1

Re: [GDI+: 3/10] graphics implementation
by Detlef Riekenberg June 12, 2007

June 12, 2007

On Mo, 2007-06-11 at 11:54 -0700, Evan Stade wrote: > +GpStatus WINGDIPAPI GdipCreateFromHDC(HDC hdc, GpGraphics **graphics) > +{ > + if(hdc == NULL) > + return OutOfMemory; > + > + if(graphics == NULL) > + return InvalidParameter; > + > + *graphics = (GpGraphics*) HeapAlloc(GetProcessHeap(), > HEAP_ZERO_MEMORY, > + sizeof(GpGraphics)); > + (*graphics)->hdc = hdc; > + (*graphics)->hwnd = NULL; There is no need to set a member to NULL, when you use HEAP_ZERO_MEMORY. -- By by ... Detlef

2 1

Re: [GDI+: 6/10] GdipDrawLineI test
by Detlef Riekenberg June 12, 2007

June 12, 2007

On Mo, 2007-06-11 at 12:00 -0700, Evan Stade wrote: > > Changelog: > *Added framework for pixel-by-pixel comparison in tests > *added GdipDrawLineI test > > dlls/gdiplus/tests/graphics.c | 164 > +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 164 insertions(+), 0 deletions(-) > > -Evan Stade The Patch is missing -- By by ... Detlef

1 0

Add new dll mscat32
by Vijay Kiran Kamuju June 12, 2007

June 12, 2007

Hi, I would like to add a stub dll for mscat32.dll in wine. It mostly is a forwarder dll ie, it has forwards for most of the functions to wintrust.dll And it also provides functions for reading catalog files. It is mostly used by microsoft for it installers. I mean for its own products like Winodows Media Player 9, IE, etc. I wanted to inform to get the approval from wine team, for inclusion of this dll. Thanks, VJ

2 4

Re: widl: Add a missing assignment to current_structure before calling write_embedded_types.
by Dan Hipschman June 12, 2007

June 12, 2007

On Tue, Jun 12, 2007 at 10:29:24AM +0100, Robert Shearman wrote: > error("structure size for %s exceeds %d bytes by %d bytes\n", > name, USHRT_MAX, total_size - USHRT_MAX); > > + current_structure = type; > has_pointers = write_embedded_types(file, NULL, type, name, 0, tfsoff); > + current_structure = NULL; > > array = find_array_or_string_in_struct(type); > if (array && !processed(array->type)) That was taken care of by the patch I sent in a little before you. It's like we're reading each other's minds. ;-)

1 0

Re: [GDI+: 3/5] added graphics implementation and tests
by Evan Stade June 12, 2007

June 12, 2007

> On 6/10/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > > "Evan Stade" <estade(a)gmail.com> wrote: > > > > >> Any reason why are you creating a new pen in GdipDrawRectangleI, and while using > > >> an existing one in GdipDrawLineI? > > >> > > >> -- > > >> Dmitry. > > >> > > > > > > Yes, the reason for that is the passed pen can have any endcap style, > > > but to draw the rectangle the pen needs square endcaps. The same does > > > not apply to DrawLine. > > > > Do you have a confirmation that native gdiplus does that as well? +relay,+snoop > > trace, some other test? > > > > -- > > Dmitry. > > Native GDI+ does its own rendering. For example, GDI+ drawline uses repeated stretchblts rather than GDI drawline. However, GDI drawline can be pretty close, if not pixel-for-pixel the same.

1 0

Re: [GDI+: 1/10] first pen implementation
by Detlef Riekenberg June 12, 2007

June 12, 2007

On Mo, 2007-06-11 at 11:51 -0700, Evan Stade wrote: > +GpStatus WINGDIPAPI GdipCreatePen1(ARGB color, FLOAT width, GpUnit > unit, > + GpPen **pen) > +{ > + LOGBRUSH lb; > + GpPen *gp_pen; > + > + gp_pen = (GpPen*) GdipAlloc(sizeof(GpPen)); > + if(!pen) return OutOfMemory; > + > + gp_pen->style = GP_DEFAULT_PENSTYLE; This looks not correct. You returned "OutOfMemory", but you check "pen". I think, you really mean "gp_pen" in that "if". A test with pen==NULL would be nice. > + if((gp_pen->unit == UnitWorld) || (gp_pen->unit == UnitPixel)) { > + > + } else { > + FIXME("UnitWorld, UnitPixel only supported units"); > + return NotImplemented; You leak the allocated memory from gp_pen here. The FIXME does not help very much. You should dump the value for the unsupported unit. > + if(!gp_pen) > + return GenericError; This is dead code in this location. When the allocation for gp_pen failed, you will never reach this line, because gp_pen was accesed before and produced a crash. -- By by ... Detlef

1 0

Re: Allow GL_ONE on WINED3DRS_EDGEANTIALIAS dstBlend value
by H. Verbeet June 12, 2007

June 12, 2007

On 12/06/07, Kovács András <andras(a)csevego.net> wrote: > Hi, > > Allow GL_ONE on WINED3DRS_EDGEANTIALIAS' dstBlend value. This fixes Pirates Of > Caribbean At The Worlds End blending problem. ( black square behind linght > sources) > -- I'm not sure we should be changing srcBlend/dstBlend in the first place over there. The comment at the top of the function claims the red book says GL_LINE_SMOOTH need "special blending parameters", but the copy I've got says no such thing. The closest I could find was "The blending factors you most likely want to use are GL_SRC_ALPHA (source) and GL_ONE_MINUS_SRC_ALPHA (destination)." It also explicitly mentions GL_ONE as a possible alternative for the destination. MSDN also doesn't specify a specific way of antialiasing. Either way, I think we'd rather have correct blending parameters than correctly aliased lines, if we'd have to make a choice between the two.

1 0

Re: [PATCH try2 1/3] setupapi/tests: Add rudimentary tests for InstallHinfSectionA/W.
by James Hawkins June 12, 2007

June 12, 2007

On 6/11/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > Changes from previous version in patch 1: > * Comments to explain why this conformance test cannot be quite standard - see Notes comment @ beginning > * Try A function first - I decided that since the A function works on Win98 but not WinXP it is the one > "broken" (reminder: W works on XP but not 98) > * Added asserts in helper _InstallHinfSection function to verify A/W function pointers to make sure that > in the future useW is not misassigned (currently it is assigned properly in START_TEST(install) section as > it was in previous version). > * Changed test_install to ok_install to make its purpose more clear. Specifically, the idea is that > ok_install does the actual install and checks that everything is installed properly, whereas > test_InstallHinfSection allows us to try using the _InstallHinfSection functions (through ok_install) in > various ways to test effects of parameters on the installation (e.g., see patch 2) > * Use property of the "stub" functions of not changing last error to determine which function is stub instead > of using registry checks > > Hopefully this patchset is clearer. > This would still be clearer and more efficient if you set up a function pointer at the beginning of the tests, and just use that function for the rest of the tests. You make a helper function that tests which version (A or W) works, and assign the working version to the function pointer. This way, you don't have to deal with a useW variable, or any of that mess, and other people can write direct tests without having to use ok_install (which really shouldn't be needed if you use a function pointer). Keep in mind you'll have to use void pointers for the string parameters when declaring the function pointer type. -- James Hawkins

2 3

Can we start/stop services in conformance tests?
by Misha Koshelev June 12, 2007

June 12, 2007

Just wondering. It seems like I can avoid message boxes easily by using a CHT hook, but the Beep() that this particular message box uses can only be disabled with the ControlService/StartService combo. Can I use this in a non-service conformance test, or is it too much to assume that the person running the tests has administrator access (or am I allowed to check for this and simply skip the relevant tests if they don't)? I would assume as long as I am turning the service (beep) back on afterwards if it is on before and check for administrator rights this would be okay? Thanks Misha

1 0

Re: Alexandre Julliard : winecfg: Fix potential null pointer access ( spotted by Yaroslav Skorokhodov).
by Vitaly Lipatov June 12, 2007

June 12, 2007

В сообщении от 12 июня 2007 Alexandre Julliard написал(a): ... > @@ -107,7 +107,7 @@ static void update_comboboxes(HWND dialog) > winver = get_reg_key(config_key, keypath(""), "Version", ""); What wrong with call get_reg_key (,,,NULL) ? Why we need winver as NULL pointer and as empty string? > ver = get_registry_version(); > > - if (*winver == '\0') > + if (!winver || !winver[0]) > { > HeapFree(GetProcessHeap(), 0, winver); -- Lav Виталий Липатов Россия, Санкт-Петербург. www.etersoft.ru GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!

2 1

Re: [GDI+: 4/10] graphics test
by Alexandre Julliard June 12, 2007

June 12, 2007

"Evan Stade" <estade(a)gmail.com> writes: > + wndClass.lpszClassName = TEXT(ClassName); > + > + if(!RegisterClassA(&wndClass)) return FALSE; This is broken, TEXT() doesn't work on a variable name, and it's useless since you call the A function anyway. Please don't use any of the ugly TCHAR macros in tests, there's no need for them. Either A/W doesn't matter and you can simply use plain Ascii strings, or it does matter and then you have to explicitly test both cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

opengl conversation on irc
by Dan Kegel June 11, 2007

June 11, 2007

A bunch of folks just had an interesting discussion about the OpenGL problem on irc. I and Roderick saved a log of the conversation, one per room: http://kegel.com/wine/opengl-wine-chat1.html (the original #winehackers discussion) http://roderick.student.utwente.nl/xorg-devel.log (after it moved to #xorg-devel) Roderick gets back from vacation July 22nd or so, and said he expects not only a nice writeup on WWN but also a full implementation by then :-) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: rsaenh: AcquireContext can have multiple flags defined at the same time
by Mounir IDRASSI June 11, 2007

June 11, 2007

Hi, Your patch is wrong: the flags CRYPT_NEWKEYSET and CRYPT_VERIFYCONTEXT can't be mixed and if they are set together like in your patch AcquireContext should return NTE_BAD_FLAGS. You can check that using the MS implementation under windows. It's also clearly stated in MSDN that CRYPT_VERIFYCONTEXT is reserved for non persistent operations which is not the case when you create a new container. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Maarten Lankhorst wrote: > According to msdn a combination of flags are set, since I'm not sure > which combo's are valid I put up a FIXME. > > ------------------------------------------------------------------------ > >

2 3

Bugzilla is still annoying
by Scott Ritchie June 11, 2007

June 11, 2007

What was the status on the offer to upgrade bugzilla? Lately I've been annoyed by how it sends out emails whenever someone subscribes/unsubscribes from a bug. Is this a simple configuration setting, or do we need to upgrade? Thanks, Scott Ritchie

2 1

Re: [GDI+: 2/5] added Pens implementation, test
by Alexandre Julliard June 11, 2007

June 11, 2007

"Evan Stade" <estade(a)gmail.com> writes: > Hi, > > Changelog: > *added pen implementation > *added just enough memory and startup implementation to support pens > *defined some types > *added pen test You need to send that stuff in smaller chunks, for instance there's no reason to put startup implementation and pens in the same patch. Also things like the GpBrush definition should be part of the brush patch not the pen one. The tests can also be a separate patch. I'll commit the startup code part of the patch, have a look at this to see what a minimal patch should look like. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] setupapi/tests: Add rudimentary tests for InstallHinfSectionA/W.
by James Hawkins June 11, 2007

June 11, 2007

On 6/10/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > Tested on WinXP and Win98 (and of course wine). > --- > dlls/setupapi/tests/Makefile.in | 1 + > dlls/setupapi/tests/install.c | 152 +++++++++++++++++++++++++++++++++++++++ > 2 files changed, 153 insertions(+), 0 deletions(-) > +static void test_install(LPCSTR filename) +{ + char cmdline[MAX_PATH * 2]; + LONG ret; + + sprintf(cmdline, "DefaultInstall 128 %s\\%s", CURR_DIR, filename); + + if (useW == -1) + { + HKEY hkey; + useW = 1; + _InstallHinfSection(NULL, NULL, cmdline, 0); + if (RegOpenKey(HKEY_CURRENT_USER, "Software\\Wine\\setupapitest", &hkey) == ERROR_SUCCESS) + RegCloseKey(hkey); + else + { + skip("InstallHinfSectionW is broken, using InstallHinfSectionA\n"); + useW = 0; + _InstallHinfSection(NULL, NULL, cmdline, 0); + } + } + else _InstallHinfSection(NULL, NULL, cmdline, 0); + + ret = RegDeleteKey(HKEY_CURRENT_USER, "Software\\Wine\\setupapitest"); + ok(ret == ERROR_SUCCESS, "Expected registry key Software\\Wine\\setupapitest to exist, RegDeleteKeyA returned %d\n", ret); +} + +static void test_InstallHinfSection(void) +{ + create_inf_file(inffile); + test_install(inffile); + ok(DeleteFile(inffile), "Expected source inf to exist, last error was %d\n", GetLastError()); +} This would be much simpler if you didn't use the extra test_install function. What is the point of that? Unit test functions should be atomic. Each test function should create the files it needs, and make sure the files it created are cleaned up by the end of the function (replace files with registry keys, etc). You can also look at it like this: you should be able to remove test function x without affecting any other tests, which is not the case here. The check for DeleteFile would obviously fail. Unit tests should be clear and easy to understand what's being tested, and honestly, this code confused me on my first reading. + _InstallHinfSection(NULL, NULL, cmdline, 0); Why aren't you checking the return value, or GetLastError? + skip("InstallHinfSectionW is broken, using InstallHinfSectionA\n"); How is it broken? This needs to be clarified with a comment. You really should just test only the A function in the first place though. + if (pInstallHinfSectionW && !pInstallHinfSectionA) useW = 1; Is there ever a time when InstallHinfSectionA doesn't exist? If it doesn't exist, you're going to crash if InstallHinfSectionW is 'broken': + skip("InstallHinfSectionW is broken, using InstallHinfSectionA\n"); + useW = 0; + _InstallHinfSection(NULL, NULL, cmdline, 0); -- James Hawkins

2 2

Re: [GDI+: 3/5] added graphics implementation and tests
by Dmitry Timoshkov June 11, 2007

June 11, 2007

"Evan Stade" <estade(a)gmail.com> wrote: > +GpStatus WINGDIPAPI GdipDrawLineI(GpGraphics *graphics, GpPen *pen, INT x1, > + INT y1, INT x2, INT y2) > +{ > + HGDIOBJ old_obj; > + > + if(!pen || !graphics) > + return InvalidParameter; > + > + old_obj = SelectObject(graphics->hdc, pen->gdipen); > + MoveToEx(graphics->hdc, x1, y1, NULL); > + LineTo(graphics->hdc, x2, y2); > + SelectObject(graphics->hdc, old_obj); > + > + return Ok; > +} > + > +GpStatus WINGDIPAPI GdipDrawRectangleI(GpGraphics *graphics, GpPen *pen, INT x, > + INT y, INT width, INT height) > +{ > + LOGBRUSH lb; > + HPEN hpen; > + HGDIOBJ old_obj; > + > + if(!pen || !graphics) > + return InvalidParameter; > + > + lb.lbStyle = BS_SOLID; > + lb.lbColor = pen->color; > + lb.lbHatch = 0; > + > + hpen = ExtCreatePen(PS_GEOMETRIC | PS_ENDCAP_SQUARE, (INT) pen->width, > + &lb, 0, NULL); Any reason why are you creating a new pen in GdipDrawRectangleI, and while using an existing one in GdipDrawLineI? -- Dmitry.

2 2

Re: [GDI+: 5/5] Added GdipFillPie
by Dmitry Timoshkov June 11, 2007

June 11, 2007

"Evan Stade" <estade(a)gmail.com> wrote: > +GpStatus WINGDIPAPI GdipFillPie(GpGraphics *graphics, GpBrush *brush, REAL x, > + REAL y, REAL width, REAL height, REAL startAngle, REAL sweepAngle) > +{ > + LOGBRUSH lb; > + HPEN hpen; > + HGDIOBJ old_pen, old_brush; > + REAL x_0, y_0, radStartAngle, radFinishAngle, hypotenuse, > + x_1, y_1, x_2, y_2; > + > + if(!brush || !graphics) > + return InvalidParameter; > + > + lb.lbStyle = BS_SOLID; > + lb.lbColor = brush->color; > + lb.lbHatch = 0; > + > + hpen = ExtCreatePen(PS_GEOMETRIC | PS_ENDCAP_SQUARE, 1, &lb, 0, NULL); > + > + old_pen = SelectObject(graphics->hdc, hpen); > + old_brush = SelectObject(graphics->hdc, brush->gdibrush); GdipFillPie takes only a brush in its parameters, not a pen. Shouldn't you simply select GetStockObject(NULL_PEN) instead of creating a 1 pixel pen with a color of brush? -- Dmitry.

2 1

RE: [PATCH] dinput: Use window subclassing to monitor focus looses away from monitored windows. [try 3]
by Vitaliy Margolen June 10, 2007

June 10, 2007

Please don't apply this and other dinput patches. It doesn't work for multiply acquired windows. This approach does not handle "nesting" - when same window is being acquired several times by different devices. I guess I will have to go back to WINDPROC hook after all. Vitaliy.

1 0

Re: [PATCH 3/3] winex11.drv: Use new mouse grabbing code for ddraw.
by Stefan Dösinger June 10, 2007

June 10, 2007

Am Sonntag, 10. Juni 2007 02:15 schrieb Vitaliy Margolen: > Remove old code that is not thread safe. > --- > dlls/winex11.drv/x11ddraw.c | 50 > +------------------------------------------ 1 files changed, 1 > insertions(+), 49 deletions(-) The ddraw code in winex11.drv isn't called from anywhere afaik, and alexandre doesn't really like it to I planned to remove it somewhen.

1 0

makedep problem on mingw
by Steven Edwards June 9, 2007

June 9, 2007

Hi, I won't have a chance to follow up on this until Wednesday but maybe someone can spot the problem before then. Doing a normal checkout and configure on mingw works fine but the generated makefile in wine/tools/ seems to have a problem with the dependency tracking. Maybe the recent makedep changes and windows don't agree. $ make ../tools/makedep -C. -S.. -T.. bin2res.c fnt2bdf.c fnt2fon.c make_ctests.c make dep.c relpath.c sfnt2fnt.c Makefile:423: *** unterminated variable reference. Stop. Attached is the buggy Makefile Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Re:user32:tests:msg Add test for switch mdi children.[try2] What is wrong with it?
by Anatoly Lyutin June 9, 2007

June 9, 2007

Subject. Thanks for attention. -- Best regards Anatoly Lyutin.

2 1

Re: [5/5] WineD3D: Some render target->texture blit context handling
by H. Verbeet June 9, 2007

June 9, 2007

On 08/06/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > + ActivateContext(This, src_surface, CTXUSAGE_RESOURCELOAD); > + if (GL_SUPPORT(ARB_MULTITEXTURE)) { > + GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB)); > + checkGLcall("glActiveTextureARB"); > + } > + IWineD3DDeviceImpl_MarkStateDirty(This, STATE_SAMPLER(0)); > + IWineD3DSurface_PreLoad(dst_surface); Why do you need this? The surface should be preloaded in attach_surface_fbo as soon as it's attached. Also, although stretch_rect_fbo() is currently only used for onscreen -> texture blits, it should not be limited to that, so I think the ActivateContext should be further down inside both the "if (src_swapchain)" and "if (dst_swapchain)" blocks.

2 4

Using [GS]etWindowLong{Ptr} in tests
by Saulius Krasuckas June 8, 2007

June 8, 2007

Hello. I see some tests call [GS]etWindowLongPtr(..., GWLP_WNDPROC, ...). I think this is somewhat confusing. API offers both A- an W- versions of this function, while at my first glance I cannot firmly decide, what used name does refer to. Shouldn't occurences be renamed to ...WindowLongPtrA() here (or even all occurrences {by not requiring second parameter == GWLP_WNDPROC}) ? Same question stands for [GS]etWindowLong().

4 16

zip folders support
by Alexander Shabanov June 8, 2007

June 8, 2007

Good day, First of all: big thank you for your great wine! Several days ago I made a post on the wine groups: > Does anyone tried to use zip folders support on wine? Is is possible? > I tried to copy zipfldr.dll and register it, but it does not work. > Since I am a developer I would try to do it. Could you please suggest > a point to start? As far as I know the interfaces of zipfldr.dll are > not documented, so it will not be simple task. I would like to ask you about an interfaces of zip folder dynamic library - if they're known I would implement zip folders support. It was suggested to ask someone from wine development team to get more information about that. Please, take a look to the discussion in the wine group about that: http://groups.google.com/group/comp.emulators.ms-windows.wine/browse_thread… If you have an information about zip folders please let me know. btw: maybe an implementation of the such support is prohibited on Linux due to some restrictions with LZW algorithm? Or maybe Microsoft did not care about documenting this library? Unfortunately I am not found any information about this library in MSDN in the topics for developers. Thanks in advance and kind regards, Alexander Shabanov

2 1

Re: zip folders support
by Juan Lang June 8, 2007

June 8, 2007

Hi Alexander, as you say in the quoted thread, > zip filder support is encapsulated within zipfldr.dll which is > standard COM-component (i.e. exposes DllRegisterServer/ > DllCanUnloadNow). > For example in WinXP zip folders support may be switched off by > unregistering zipfldr.dll via regsvr32. > Therefore I may suspect that this support is given on the user (shell > only) level, because CreateFile can't be applied to the files within > zip folder You're correct, zipfldr.dll only register shell extension. As such, it's probably of limited use in Wine, as we really only use the shell for file dialogs - we don't implement an "explorer" that browses the shell namespace. So, may I ask: what app requires such a thing? And you say: > I tried to copy zipfldr.dll and register it, but it does not work. What exactly doesn't work? This probably best captured as a bug, by the way. Enter a bug describing what you expect to happen, what doesn't happen, etc. --Juan ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/

1 0

Re: shell32: conformance tests for unicode filenames and fix a bug forfile deletion (try 2)
by Dmitry Timoshkov June 8, 2007

June 8, 2007

"Nigel Liang" <ncliang(a)gmail.com> wrote: > +static const WCHAR UNICODE_PATH[] = {'c',':','\\','w',0x00ef,0x00f1,0x00eb, > + 't',0x00e8,'s','t','\0','\0'}; /* "c:\winetest" */ The name above is definitely not "c:\winetest", also if you need a double termination '\0' state it specifically. > +static int IsWin9x(void) > +{ > + OSVERSIONINFO winver; > + GetVersionEx(&winver); > + return winver.dwPlatformId==VER_PLATFORM_WIN32_WINDOWS; > +} (GetVersion() & 0x80000000) is much shorter way to detect win9x, but if you need to test whether the platform supports unicode that's wrong, have a look at other tests how it's done there. -- Dmitry.

3 5

Re: [NTDLL] Simple test suite for IO completion APIs
by Alexandre Julliard June 8, 2007

June 8, 2007

Andrey Turkin <andrey.turkin(a)gmail.com> writes: > Depends on previous NTDLL patch ('cause it uses previously stubbed out api) > > --- > dlls/ntdll/tests/Makefile.in | 1 + > dlls/ntdll/tests/completion.c | 212 > +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 213 insertions(+), 0 deletions(-) Please merge that code with the other async I/O tests in file.c. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] wined3d: For ps_2_0 and higher, call shader_get_registers_used() in IWineD3DPixelShaderImpl_SetFunction
by Stefan Dösinger June 8, 2007

June 8, 2007

Am Donnerstag, 7. Juni 2007 23:52 schrieb H. Verbeet: > For pre-2.0 pixel shaders the stateblock is used to determine the > sampler types, so we need to wait until CompileShader to do this. For > ps_2_0 and higher there is no such requirement. > > Changelog: > - For ps_2_0 and higher, call shader_get_registers_used() in > IWineD3DPixelShaderImpl_SetFunction Are you going to compile >= 2.0 shaders in SetFunction? How would that work with other things that may need delayed compilation, like fog or (future) srgb write correction?

2 2

Re: gdiplus: added stub implementation of gdiplus.dll
by Mounir IDRASSI June 8, 2007

June 8, 2007

Hi, You also have to modify other files in order to integrate your stub implementation to the wine build chain: Makefile.in, configure and configure.ac in the wine root directory, Makefile.in in the "dlls" directory. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Evan Stade wrote: > Changelog: > * added stub implementation of gdiplus.dll (3 files) > > dlls/gdiplus/Makefile.in | 16 + > dlls/gdiplus/gdiplus.c | 45 +++ > dlls/gdiplus/gdiplus.spec | 609 > +++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 670 insertions(+), 0 deletions(-)

6 7

FYI: SHELL_ArgifyW and unquoted %1, non-native behavior
by Misha Koshelev June 8, 2007

June 8, 2007

Sorry if I am just filling your inboxes, but I thought I'd at least throw this out there before I forget about it. When I was making my ShellExecute DDE conformance tests to get Vector NTI associated files to open correctly (using DDE and without the fake "%1" that wine was adding to all shell/?/command strings that don't have one at the time), I noticed another non-native behavior in wine. Specifically, when %1 is in a command or a ddeexec string on Windows (XP), the filename is passed as is. However, under wine quotes are added to this argument in SHELL_ArgifyW. Since this did not affect anything Vector NTI related, I decided to just not worry about this behavior at the time and just to change my conformance test so it wouldn't tickle this. However, I am just wondering what the general policy is about something like this? Should it just be left alone until an app is found that somehow depends on this (I am thinking this is the case)? Or do we want to try to correct this when we discover this, that way perhaps preventing this bug in this application from ever even occuring? Thanks Misha

1 0

Re: ole32: Remove stack-based string buffer inFileMonikerImpl_DecomposePath
by Dmitry Timoshkov June 7, 2007

June 7, 2007

"Ulrich Czekalla" <ulrich.czekalla(a)utoronto.ca> wrote: > - WCHAR word[MAX_PATH]; > - int i=0,j,tabIndex=0; > + LPOLESTR word; > + int i=0,j,tabIndex=0, ret=0; > LPOLESTR *strgtable ; > > int len=lstrlenW(str); > > TRACE("%s, %p\n", debugstr_w(str), *stringTable); > > - strgtable =CoTaskMemAlloc(len*sizeof(LPOLESTR)); > + strgtable = CoTaskMemAlloc(len*sizeof(LPOLESTR)); > > if (strgtable==NULL) > return E_OUTOFMEMORY; > > + word = CoTaskMemAlloc((len + 1)*sizeof(LPOLESTR)); Shouldn't it be *sizeof(WCHAR) or *sizeof(OLECHAR)? -- Dmitry.

2 1

Could somebody run the wininet/ftp tests on Wine?
by Paul Vriens June 7, 2007

June 7, 2007

Hi, Some time ago I added some ftp-tests. After I've seen a lot of wininet patches I just tried (current GIT) to run the ftp tests again on Wine. This time I get some failure (or actually successes): [paul(a)LatitudeC600 tests]$ make ftp.ok ../../../tools/runtest -v -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so ftp.c && touch ftp.ok ftp.c:303: Test succeeded inside todo block: Expected ERROR_SUCCESS, got 0 ftp.c:363: Test succeeded inside todo block: Expected ERROR_SUCCESS, got 0 ftp.c:375: Test succeeded inside todo block: Expected ERROR_SUCCESS, got 0 ftp.c:485: Test failed: Expected FtpOpenFileA to succeed ftp.c:858: Test succeeded inside todo block: Expected ERROR_SUCCESS or ERROR_FILE_NOT_FOUND (win98), got 0 ftp: 128 tests executed (14 marked as todo, 5 failures), 0 skipped. make: *** [ftp.ok] Error 5 The strange thing is that the calls fail yet the last error is set to ERROR_SUCCESS. Can somebody confirm? Cheers, Paul.

2 2

Re: cmd:Ru:Update Russian translation.[try2][fixed]
by Kirill K. Smirnov June 7, 2007

June 7, 2007

> >> + WCMD_YES, "Д" > >> + WCMD_NO, "Н" > > > > Answers to "Yes/No" question should not be translated, should they? "All" > > too. > > I think that should translate this answers because in some languages > such as Norwegian,German and Korean it was translated. > I really doesn`t understand why in Russian language this answers should > not to be translated. In windows they are not translated. Moreover, it is inconvenient to switch to Russian, press 'Д' ('Н'), then switch to English. It may be better if we allow to use translated and untranslated answers simultaneously. AFAIK it is allowed to use translated only. -- Kirill

1 0

Re: cmd:Ru:Update Russian translation.[try2][fixed]
by Kirill K. Smirnov June 7, 2007

June 7, 2007

Hi, Anatoly! The translation is still very raw. Please, verify it. >+ WCMD_YES, "Д" >+ WCMD_NO, "Н" Answers to "Yes/No" question should not be translated, should they? "All" too. >+ WCMD_NOASSOC, "Файл, ассоциированный с расширением %s,отсутствует\n" This phrase does not sound Russian. "Отсутствует сопоставление для расширения %s" will be better. and so on... -- Kirill

3 2

Re: wininet: Make the passive mode response check case insensitive.
by Francois Gouget June 7, 2007

June 7, 2007

On Wed, 6 Jun 2007, Hans Leidekker wrote: [...] > Changelog > Make the passive mode response check case insensitive. --- a/dlls/wininet/ftp.c +++ b/dlls/wininet/ftp.c [...] - if (strncmp(p, "Entering Passive Mode", 21)) + if (strncasecmp(p, "Entering Passive Mode", 21)) You should not be using str*casecmp() in Wine (because it's a Unix function, and because it uses the wrong locale). Try CompareString() instead. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

3 2

Re: avifil32: remove 'recursive registry key delete' function
by Detlef Riekenberg June 7, 2007

June 7, 2007

On Do, 2007-06-07 at 00:00 +0200, Stefan Leichter wrote: Replacing recursive_delete_key with RegDeleteTree is not the same. As Example: > - res = recursive_delete_keyA(HKEY_CLASSES_ROOT, > list->progid); > + res = RegDeleteTreeA(HKEY_CLASSES_ROOT, list->progid); > if (res != ERROR_SUCCESS) goto error_close_coclass_key; When the Initial RegOpenKey failed, RegDeleteTree is returning ERROR_FILE_NOT_FOUND and the codepath went to the error-label, but the old recursive_delete_keyA returned ERROR_SUCCESS. See this removed Line from recursive_delete_keyA/W: - if (res == ERROR_FILE_NOT_FOUND) return ERROR_SUCCESS; This additional change should work: if ((res != ERROR_SUCCESS) && (res != ERROR_FILE_NOT_FOUND)) { goto error_close_coclass_key; } Thanks -- By by ... Detlef

1 0

Re: wined3d [1/5]: Add GL_EXT_texture_sRGB constants and corresponding CheckDeviceFormat query
by Phil Costin June 7, 2007

June 7, 2007

Stefan Dösinger wrote: > Am Donnerstag, 7. Juni 2007 01:03 schrieb Phil Costin: >> Adds necessary GL constants and allows the application to query whether a >> particular texture format is compatible with sample-time texture >> linearization. > Ideally you shouldn't enable the srgb formats in this patch already, but > rather in 4/5, but since the current code returns WINED3D_OK this is an > unimportant detail. Well, originally I did but you advised me to move it to patch 1 so I did :) Regards, Phil

2 1