October 2006 - Wine-Devel - list.winehq.org

Re: Copy protection

by Martin Owens

> Re Copy Protection. > > be quite hard to make this work I think? It would be quite dangerous to make this work. What about creating a file say with a fake data map, wine thinks it's the direct access to the hard drive where all this information is held. all we do is add the place where the data starts and the data thats stored. it would be slower but it would get around the dangers while keeping the interface the same.

Oct. 2, 2006

Re: Copy protection

by Willie Sippel

Am Montag, 2. Oktober 2006 04:49 schrieb Vitaliy Margolen: > EA Durbin wrote: > >> So the short story is that copy protection support is the > >> gating issue here, and it's a serious PITA. > > > > What specifically keeps most copy protection from working with wine? > > Why does it work in some applications, such as Star Wars Jedi Academy > > and not others? > > There are several types of copy protection. Those that use kernel > drivers do not work on Wine because ... Wine has no kernel to load those > drivers into. We will need at least ntoskrnl.exe implemented because > it's more of a "dll" then exe and all drivers import number of functions > from it. > > Of course we can only emulate "kernel" to some point. But even that > would be enough for drivers that only check for debugger presence and > nothing else. > As far as I know, the Flex copy protection scheme used by, for example, Photoshop and ZBrush also writes a key somewhere on the harddisk. Not on the file system, but somewhere in the unused space after the MBR IIRC. It should be quite hard to make this work I think? Ciao, Willie -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

Oct. 2, 2006

Full A and W implementations for registry functions in shlwapi

by Paul Vriens

Hi, is there any reason that some of the registry functions in shlwapi have a full implementation for both the A and the W calls, instead of calling W from A? (other then nobody bothered). Is it worthwhile to be done? (Could be another janitorial task). Cheers, Paul.

Oct. 2, 2006

Re: compiling wine for amd64 on ubuntu dapper 6.06

by Gerald Britton

Ah. Well on the wiki there's a note about symlinks for those libs. I have these: $ ls -l /usr/lib32/libG* lrwxrwxrwx 1 root root 21 2006-09-18 22:22 /usr/lib32/libGLcore.so.1 -> libGLcore.so.1.0.8762 -rw-r--r-- 1 root root 8113728 2006-09-18 03:28 /usr/lib32/libGLcore.so.1.0.8762 -rw-r--r-- 1 root root 662 2006-09-18 03:28 /usr/lib32/libGL.la lrwxrwxrwx 1 root root 17 2006-09-18 22:22 /usr/lib32/libGL.so.1 -> libGL.so.1.0.8762 -rw-r--r-- 1 root root 540136 2006-09-18 03:28 /usr/lib32/libGL.so.1.0.8762 lrwxrwxrwx 1 root root 20 2006-08-28 23:21 /usr/lib32/libGLU.so.1 -> libGLU.so.1.3.060401 -rw-r--r-- 1 root root 479244 2006-05-05 11:05 /usr/lib32/libGLU.so.1.3.060401 Is there a command to verify if the libs are 32- or 64-bit? On 10/2/06, Robert Shearman <rob(a)codeweavers.com> wrote: > Gerald Britton wrote: > > Looking at config.log, I see these messages: > > > > configure:9418: checking for glXCreateContext in -lGL > > configure:9453: gcc -m32 -o conftest -g -O2 conftest.c -lGL > > -L/usr/X11R6/lib -lXext -lX11 -lm >&5 > > /usr/bin/ld: skipping incompatible > > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libGL.so when searching > > for -lGL > > /usr/bin/ld: skipping incompatible /usr/bin/../lib/libGL.so when > > searching for -lGL > > /usr/bin/ld: skipping incompatible /usr/lib/libGL.so when searching > > for -lGL > > /usr/bin/ld: cannot find -lGL > > > > > > How does .configure determine that libGL is incompatible? > > > > When it's a 64-bit library, whereas wine is 32-bit. > > -- > Rob Shearman > >

Oct. 2, 2006

Re: compiling wine for amd64 on ubuntu dapper 6.06

by Robert Shearman

Gerald Britton wrote: > Looking at config.log, I see these messages: > > configure:9418: checking for glXCreateContext in -lGL > configure:9453: gcc -m32 -o conftest -g -O2 conftest.c -lGL > -L/usr/X11R6/lib -lXext -lX11 -lm >&5 > /usr/bin/ld: skipping incompatible > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libGL.so when searching > for -lGL > /usr/bin/ld: skipping incompatible /usr/bin/../lib/libGL.so when > searching for -lGL > /usr/bin/ld: skipping incompatible /usr/lib/libGL.so when searching > for -lGL > /usr/bin/ld: cannot find -lGL > > > How does .configure determine that libGL is incompatible? > When it's a 64-bit library, whereas wine is 32-bit. -- Rob Shearman

Oct. 2, 2006

Re: compiling wine for amd64 on ubuntu dapper 6.06

by Gerald Britton

Looking at config.log, I see these messages: configure:9418: checking for glXCreateContext in -lGL configure:9453: gcc -m32 -o conftest -g -O2 conftest.c -lGL -L/usr/X11R6/lib -lXext -lX11 -lm >&5 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libGL.so when searching for -lGL /usr/bin/ld: skipping incompatible /usr/bin/../lib/libGL.so when searching for -lGL /usr/bin/ld: skipping incompatible /usr/lib/libGL.so when searching for -lGL /usr/bin/ld: cannot find -lGL How does .configure determine that libGL is incompatible? Also the second problem is much worse as it stops the make altogether: > > Relocatable linking with relocations from format elf64-x86-64 > > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.ArPHdq.o) > > is not supported On 10/2/06, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > On 9/29/06, Gerald Britton <gerald.britton(a)gmail.com> wrote: > > Hi -- I'm trying to get wine going on my ubuntu dapper installation on > > an amd 64 box. I have followed the wiki instructions in > > http://wiki.winehq.org/WineOn64bit for ubuntu and rechecked my work. > > Two things go wrong: > > > > 1. /configure can't find opengl, and produces these messages: > > > > configure: WARNING: Wine will be build without OpenGL or Direct3D support > > configure: WARNING: because something is wrong with the OpenGL setup: > > configure: WARNING: No OpenGL library found on this system. > > It's been a while since I compiled wine on my Ubuntu Dapper (32-bit) > box, but I had to install (too) many packages, among others > nvidia-glx-dev and maybe even some mesa ones, to get wine to detect > OpenGL. Are you sure you've got everything? Try building and running > some OpenGL samples. > > Start by looking at config.log to see why wine didn't detect it. > > > 2. make depend works, but make all fails with this: > > > > LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc > > --nostdinc -I. -I. -I../../include -I../../include > > -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -foversion.res > > version.rc > > ../../tools/winegcc/winegcc -B../../tools/winebuild -shared > > ./gdi32.spec dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o > > dispdib.o env.o gdi16.o metafile16.o wing.o bidi.o bitblt.o bitmap.o > > brush.o clipping.o dc.o dib.o driver.o enhmetafile.o enhmfdrv/bitblt.o > > enhmfdrv/dc.o enhmfdrv/graphics.o enhmfdrv/init.o enhmfdrv/mapping.o > > enhmfdrv/objects.o font.o freetype.o gdi_main.o gdiobj.o icm.o > > mapping.o metafile.o mfdrv/bitblt.o mfdrv/dc.o mfdrv/graphics.o > > mfdrv/init.o mfdrv/mapping.o mfdrv/objects.o mfdrv/text.o painting.o > > palette.o path.o pen.o printdrv.o region.o version.res -o > > gdi32.dll.so -ladvapi32 -lkernel32 -lntdll /usr/lib/libsicuuc.a > > /usr/lib/libsicudata.a -lstdc++ -lgcc_s ../../libs/port/libwine_port.a > > -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 > > ld: Relocatable linking with relocations from format elf64-x86-64 > > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.ArPHdq.o) > > is not supported > > winebuild: ld -m elf_i386 -r failed with status 256 > > winegcc: ../../tools/winebuild/winebuild failed. > > make[2]: *** [gdi32.dll.so] Error 2 > > make[2]: Leaving directory `/tmp/wine-0.9.22/dlls/gdi' > > make[1]: *** [gdi] Error 2 > > make[1]: Leaving directory `/tmp/wine-0.9.22/dlls' > > make: *** [dlls] Error 2 > > > > > > > > I'm not sure what to do now. Any feedback/suggestions would be appreciated. > > > > > > >

Oct. 2, 2006

Re: building outside of source tree fails - making wrong makedep

by Alexandre Julliard

"Michael [Plouj] Ploujnikov" <ploujj(a)gmail.com> writes: > What this looks like to me is make trying to build > ../../wine-git/tools/makedep which already exists, but it's trying to > use ../tools/makedep, which doesn't exist, to actually build other > stuff. There should be no makedep in the source tree. You probably ran make there, you can't do that, you should either build in the source dir or in the build dir but not both. -- Alexandre Julliard julliard(a)winehq.org

Oct. 2, 2006

Re: compiling wine for amd64 on ubuntu dapper 6.06

by Damjan Jovanovic

On 9/29/06, Gerald Britton <gerald.britton(a)gmail.com> wrote: > Hi -- I'm trying to get wine going on my ubuntu dapper installation on > an amd 64 box. I have followed the wiki instructions in > http://wiki.winehq.org/WineOn64bit for ubuntu and rechecked my work. > Two things go wrong: > > 1. /configure can't find opengl, and produces these messages: > > configure: WARNING: Wine will be build without OpenGL or Direct3D support > configure: WARNING: because something is wrong with the OpenGL setup: > configure: WARNING: No OpenGL library found on this system. It's been a while since I compiled wine on my Ubuntu Dapper (32-bit) box, but I had to install (too) many packages, among others nvidia-glx-dev and maybe even some mesa ones, to get wine to detect OpenGL. Are you sure you've got everything? Try building and running some OpenGL samples. Start by looking at config.log to see why wine didn't detect it. > 2. make depend works, but make all fails with this: > > LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc > --nostdinc -I. -I. -I../../include -I../../include > -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -foversion.res > version.rc > ../../tools/winegcc/winegcc -B../../tools/winebuild -shared > ./gdi32.spec dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o > dispdib.o env.o gdi16.o metafile16.o wing.o bidi.o bitblt.o bitmap.o > brush.o clipping.o dc.o dib.o driver.o enhmetafile.o enhmfdrv/bitblt.o > enhmfdrv/dc.o enhmfdrv/graphics.o enhmfdrv/init.o enhmfdrv/mapping.o > enhmfdrv/objects.o font.o freetype.o gdi_main.o gdiobj.o icm.o > mapping.o metafile.o mfdrv/bitblt.o mfdrv/dc.o mfdrv/graphics.o > mfdrv/init.o mfdrv/mapping.o mfdrv/objects.o mfdrv/text.o painting.o > palette.o path.o pen.o printdrv.o region.o version.res -o > gdi32.dll.so -ladvapi32 -lkernel32 -lntdll /usr/lib/libsicuuc.a > /usr/lib/libsicudata.a -lstdc++ -lgcc_s ../../libs/port/libwine_port.a > -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 > ld: Relocatable linking with relocations from format elf64-x86-64 > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.ArPHdq.o) > is not supported > winebuild: ld -m elf_i386 -r failed with status 256 > winegcc: ../../tools/winebuild/winebuild failed. > make[2]: *** [gdi32.dll.so] Error 2 > make[2]: Leaving directory `/tmp/wine-0.9.22/dlls/gdi' > make[1]: *** [gdi] Error 2 > make[1]: Leaving directory `/tmp/wine-0.9.22/dlls' > make: *** [dlls] Error 2 > > > > I'm not sure what to do now. Any feedback/suggestions would be appreciated. > > >

Oct. 2, 2006

Re: Mem usage in Mac OSX

by Stefan Dösinger

Am Sonntag 01 Oktober 2006 13:30 schrieb Nick Burns: > Im seeing some very odd behaviour in Mac OSX using wine -- and wondered if > anyone could enlighten me > > When I run any application -- I see it start with ~4GB of VM then > depending on the app -- it goes upwards of 5.7GB in VM usage (>4GB?) in > Activity Monitor (usually because of texture loading or other context > loading -- so this is seen in games where you start moving around a map and > it starts loading textures into OGL/D3D(->OGL)) > Usually when it gets this high -- bad things happen -- basically mallocs > start to fail, and the app crashes. I can confirm the crashes and the vm oddness, but I haven't tracked them down as much as you did. I have seen Half-Life 2 crashing with shaders enabled(dxlevel 80 and 70), as well as Half-Life 1 with the OpenGL renderer. HL1 takes some time, approximately 1 hour. Even the simplest D3D apps seem to use a vm size of > 4GB, even the small D3D SDK demos. The sdk examples seem to run stable and as fine as on Linux. (http://stud4.tuwien.ac.at/~e0526822/dx8demos-mac.png for a bunch of screenshots. That was CrossOver Mac actually, but shouldn't make any difference) My first suspicion was a memory leak in the OpenGL libraries, but I haven't done any further investigation to back that up. All the apps that crash on MacOS seem to run fine on Linux. My brother played Half-Life 2 for 6 hours in one go without issues on my Linux machine.

Oct. 2, 2006

Re: gdi32: Improve get_nearest_charset().

by Huw Davies

On Mon, Oct 02, 2006 at 06:42:50AM +0900, Byeong-Sik Jeon wrote: > Use the font linking information at get_nearest_charset(). > MS-Windows do it(equal behavior). Looks good to me. Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

Oct. 2, 2006