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

Re: [PATCH 1/3] gdi32: Set current position properly after ArcTo.
by Alexandre Julliard 20 Jun '07

20 Jun '07

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 20 Jun '07

20 Jun '07

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 20 Jun '07

20 Jun '07

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 19 Jun '07

19 Jun '07

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 19 Jun '07

19 Jun '07

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 19 Jun '07

19 Jun '07

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 19 Jun '07

19 Jun '07

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 19 Jun '07

19 Jun '07

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 19 Jun '07

19 Jun '07

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 19 Jun '07

19 Jun '07

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