November 2005 - Wine-Devel - list.winehq.org

Re: Compiling wine on Ubuntu amd64

by Peter Beutner

James Trotter schrieb: > I also encountered another quirk, and needed to install libxt-dev, because > the header file /usr/include/X11/Intrinsic.h was missing. The Wine package > should probably depend on libxt-dev. I think we should rather get rid of including /usr/include/X11/Intrinsic.h. The code in x11drv which include this header doesn't even link against libXt. (and afaik no other part of wine does it) > Then, the compilation failed with: > > ../../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 > 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.ogdi_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 -L../../dlls -L../../dlls/advapi32 -L../../dlls/kernel32 > -L../../dlls/ntdll -ladvapi32 -lkernel32 -lntdll -L../../libs/wine -lwine > -L../../libs/unicode -lwine_unicode /usr/lib/libsicuuc.a > /usr/lib/libsicudata.a -lstdc++ -lgcc_s -L../../libs/port -lwine_port > ld: Relocatable linking with relocations from format elf64-x86-64 > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.Q3Qz7R.o) is > not supported winebuild: ld -m elf_i386 -r failed with status 256 As the error message says: linking a 32bit object against a 64bit library(libsicuuc.a) doesn't work. I don't know where the /usr/lib/libsicuuc.a library comes from( I don't have it on my system), but you need a ia32 version of the package the library belongs to.

Nov. 29, 2005

Re: Latest CVS download opensolaris, AMD 64, build errors

by Robert Lunnon

On Mon, 28 Nov 2005 01:56 pm, Mike McCormack wrote: > David Clack wrote: > > I'm on OpenSolaris B27, on an AMD 64 system, I'm getting these errors > > from the build. > > I guess not alot of people use that configuration ... > Did you apply the patches from http://www.blastwave.org/wine

Nov. 29, 2005

RFC: Presentation for Desktop Architecture meeting, take two

by Dan Kegel

The presentation has to be really short. Essentially, everything we want to say has to fit in just two slides! Here's my attempt: http://kegel.com/wine/wine-osdl-da05.pdf Can the folks who posted issues have a look at the X.org and/or Mesa categories in https://bugs.freedesktop.org/ and send me links to the appropriate enhancement requests? (And if they're not there already, can you add them?) Dmitry Timoshkov wrote: > How about inability of X server to handle pixmaps larger > than 32767 x 32767 and an ugly workaround introduced by > the following patch: > ftp://ftp.x.org/pub/X11R6.8.2/patches/xorg-CAN-2005-2495.patch Lionel Ulmer wrote: > OK, here is my wish list from the X.org guys: > * relative mouse movement reporting. ... > * full support for resolution / depth switching. ... > * GL (GLX ?) extension which would remove the 'thread-affinity' from GL. > * GLX extension that would export the 'clip-list' functionalities of cards > * same point as before but for Xv the day we will re-add this code for > accelerated YUV display. > * have 'connection-level' configuration. ... > * have a non-connection limited mouse-grab. ... Thanks, Dan -- Why can't Johnny run Linux? See http://kegel.com/linux/comfort

Nov. 29, 2005

Re: Missing WGL function declarations in wingdi.h

by Aric Cyr

Lionel Ulmer <lionel.ulmer <at> free.fr> writes: > > > Anyone have problems with me > > submitting a patch which would move the relevant (i.e. not all) parts of > > dlls/opengl32/wgl.h into include/wingdi.h? > > Not from me. It simply that when I did the OpenGL work, 'winelib' was not > really a priority and so I did not think about putting the 'wgl.h' headers > somewhere usable for something else than the GL library itself. Okay, I'm submit a patch for wgl headers then. I should be able to just move the relevant declarations from dlls/opengl32/wgl.h to include/wingdi.h without any problems I think. Please let me know if there are any gotchas I should watch out for. > Anyway, about your D3D over WGL project, I am still wondering how you are > going to link 'wined3d' against OpenGL32.DLL. Direct linking or > 'GetProcAddress' linking ? If it's the former, will you PE-link against > OpenGL32.DLL or ELF-link against libGL.so ? > > Just wondering because if it's the former, you also need a complete set of > 'GL' headers in Wine to have the stdcall version of all GL calls (and pay > the price of thunking on each GL call). Well I am only working on removing glX calls from wined3d and replacing them with wgl calls so I'd rather not impact the GL code if possible. At first I didn't quite understand your question, so let me see if I got this right. Currently wined3d directly links to libGL.so (via EXTRALIBS in the Makefile). So if I wanted to use opengl32.dll (for wgl), and I added it to IMPORTS it would override the libGL.so calls? Currently that is what I am doing, but if that is causing all GL calls to go through opengl32.dll then that is not good... Since there are not too many wgl calls, it would probably be best to GetProcAddress them. In fact, I am doing this for a few wgl extensions anyways, so I might as well just do it for all of wgl. I'm not that familiar with the wine linking issues, so please let me know if I am off here. Cheers, Aric

Nov. 29, 2005

REG_EXPAND_SZ not parsed correctly

by Cihan Altinay

Hi, I have a .reg file exported from Windows that contains the following entry: "HelpLink"=hex(2):68,00,74,00,74,00,70,00,3a,00,2f,00,2f,00,77,00,77,00,77,00,\ 2e,00,6d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,2e,00,63,00,6f,\ 00,6d,00,2f,00,73,00,75,00,70,00,70,00,6f,00,72,00,74,00,00,00 When I run "regedit regfile.reg" this value is written into system.reg as follows: "HelpLink"=str(2):"h\0t\0t\0p\0:\0/\0/\0w\0w\0w\0.\0m\0i\0c\0r\0o\0s\0o\0f\0t\0. \0c\0o\0m\0/\0s\0u\0p\0p\0o\0r\0t\0\0" Looking at this key with wine's regedit I just see an "h", ie. the first character, because the next one is treated as end of string. I don't know if this is a bug in regedit or in the way the value gets read/written by advapi. Any suggestions? Cheers, Cihan

Nov. 29, 2005

Re: resend: http.c: redirect corrections.

by Robert Shearman

Aric Stewart wrote: >Index: dlls/wininet/http.c >=================================================================== >RCS file: /home/wine/wine/dlls/wininet/http.c,v >retrieving revision 1.113 >diff -u -r1.113 http.c >--- dlls/wininet/http.c 22 Nov 2005 14:53:30 -0000 1.113 >+++ dlls/wininet/http.c 22 Nov 2005 15:35:24 -0000 >@@ -629,6 +634,26 @@ > > /* We appear to do nothing with the buffer.. is that correct? */ > >+ if(!(lpwhr->hdr.dwFlags & INTERNET_FLAG_NO_AUTO_REDIRECT)) >+ { >+ DWORD dwCode,dwCodeLength=sizeof(DWORD),dwIndex=0; >+ if(HTTP_HttpQueryInfoW(lpwhr,HTTP_QUERY_FLAG_NUMBER|HTTP_QUERY_STATUS_CODE,&dwCode,&dwCodeLength,&dwIndex) && >+ (dwCode==302 || dwCode==301)) >+ { >+ WCHAR szNewLocation[2048]; >+ DWORD dwBufferSize=2048; >+ dwIndex=0; >+ if(HTTP_HttpQueryInfoW(lpwhr,HTTP_QUERY_LOCATION,szNewLocation,&dwBufferSize,&dwIndex)) >+ { >+ static const WCHAR szGET[] = { 'G','E','T', 0 }; >+ /* redirects are always GETs */ >+ HeapFree(GetProcessHeap(),0,lpwhr->lpszVerb); >+ lpwhr->lpszVerb = WININET_strdupW(szGET); >+ return HTTP_HandleRedirect(lpwhr, szNewLocation, NULL, 0, NULL, 0); >+ } >+ } >+ } >+ > TRACE("%i <--\n",rc); > return rc; > } > > This proves that HttpSendRequestEx and HttpSendRequest need to share more code. >@@ -1849,13 +1885,26 @@ > #endif > > HeapFree(GetProcessHeap(), 0, lpwhs->lpszServerName); >- lpwhs->lpszServerName = WININET_strdupW(hostName); >+ if (urlComponents.nPort != INTERNET_DEFAULT_HTTP_PORT && >+ urlComponents.nPort != INTERNET_DEFAULT_HTTPS_PORT) >+ { >+ int len; >+ static WCHAR fmt[] = {'%','s',':','%','i',0}; >+ len = lstrlenW(hostName); >+ len+=6; >+ lpwhs->lpszServerName = HeapAlloc(GetProcessHeap(),0,len*sizeof(WCHAR)); > > I submitted a patch to unbreak the Host header for proxies that means you should be changing lpwhs->lpszHostName now. >+ sprintfW(lpwhs->lpszServerName,fmt,hostName,urlComponents.nPort); >+ } >+ else >+ lpwhs->lpszServerName = WININET_strdupW(hostName); >+ >+ HTTP_ProcessHeader(lpwhr, g_szHost, lpwhs->lpszServerName, HTTP_ADDREQ_FLAG_ADD | HTTP_ADDREQ_FLAG_REPLACE | HTTP_ADDHDR_FLAG_REQ); >+ >+ > > And you should be sending lpwhs->lpszHostName. >@@ -1868,6 +1917,9 @@ > return FALSE; > } > >+ if (lstrlenW(extra)>0) >+ StrCatW(path,extra); > Why are you using a shlwapi string function? What's wrong with strcatW or lstrcatW? Also, this could easily cause a buffer overflow by a server sending a redirect with a large query. You need to check that there is enough space before blinding copying into the buffer. - Rob Shearman

Nov. 29, 2005

Re: msvcrt incompatibility in Origin 6.0 when saving documents

by Olaf Leidinger

Hello again! > Try running the application with the debugger and builtin msvcrt. Perhaps > you get a backtrace of the crash. Otherwise try in the relay trace (builtin > msvcrt, showing the messagebox but not the crash) to find where the > messagebox is called. You can seach for the message text. Now work up the > log and try to find why the program decides to emit the messagebox. > Well, the debugger doesn't tell me anything, as the backtrace is only one line long and it doesn't contain any information. I digged a bit deeper in the relay-log. After the save-file dialog I found this: 0009:Call ntdll.RtlLeaveCriticalSection(6c300220) ret=6c2317dd 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=6c2317dd 0009:Call msvcrt._mbscmp(7fe7c6d0 "",7d8aa353 "Saving project UNTITLED to i:\\mnt\\privat\\Origin6\\UNTITLED.opj...") ret=4c0608e6 0009:Ret msvcrt._mbscmp() retval=ffffffff ret=4c0608e6 0009:Call kernel32.GetLastError() ret=6c23429b 0009:Ret kernel32.GetLastError() retval=00000000 ret=6c23429b 0009:Call kernel32.TlsGetValue(00000003) ret=6c231018 0009:Ret kernel32.TlsGetValue() retval=7fdd4bb0 ret=6c231018 0009:Call kernel32.SetLastError(00000000) ret=6c2342b5 0009:Ret kernel32.SetLastError() retval=00000000 ret=6c2342b5 0009:Call kernel32.lstrlenA(7d8aa353 "Saving project UNTITLED to i:\\mnt\\privat\\Origin6\\UNTITLED.opj...") ret=6c2338d7 0009:Ret kernel32.lstrlenA() retval=00000040 ret=6c2338d7 0009:Call msvcrt.memcpy(7fe7c6d0,7d8aa353,00000040) ret=6c233905 0009:Ret msvcrt.memcpy() retval=7fe7c6d0 ret=6c233905 0009:Call kernel32.GetLastError() ret=6c23429b 0009:Ret kernel32.GetLastError() retval=00000000 ret=6c23429b 0009:Call kernel32.TlsGetValue(00000003) ret=6c231018 0009:Ret kernel32.TlsGetValue() retval=7fdd4bb0 ret=6c231018 0009:Call kernel32.SetLastError(00000000) ret=6c2342b5 0009:Ret kernel32.SetLastError() retval=00000000 ret=6c2342b5 0009:Call user32.CallWindowProcA(7f72ffe2,0001003e,00000401,00000100,7fe7c6d0) ret=6c2320f2 The GetLastError and SetLastError calls look a bit strange to me... Then there is A LOT OF gui-stuff... ... some _mbsinc calls ... some putc calls And finally ... 0009:Call msvcrt.fclose(7fe8fa90) ret=7f81ecf0 0009:Call kernel32.WriteFile(00000018,7fe60478,00000004,7fadef00,00000000) ret=7e876aa7 0009:Call ntdll.NtWriteFile(00000018,00000000,00000000,00000000,7fadee08,7fe60478,00000004,00000000,00000000) ret=7fcc4389 0009:Ret ntdll.NtWriteFile() retval=00000000 ret=7fcc4389 0009:Ret kernel32.WriteFile() retval=00000001 ret=7e876aa7 0009:Call ntdll.RtlFreeHeap(7fd80000,00000000,7fe60478) ret=7e87a5e5 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e87a5e5 0009:Call ntdll.RtlEnterCriticalSection(7e899fc8) ret=7e877bb5 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7e877bb5 0009:Call kernel32.CloseHandle(00000018) ret=7e877bd6 0009:Call ntdll.NtClose(00000018) ret=7fceb271 0009:Ret ntdll.NtClose() retval=00000000 ret=7fceb271 0009:Ret kernel32.CloseHandle() retval=00000001 ret=7e877bd6 0009:Call ntdll.RtlEnterCriticalSection(7e899fc8) ret=7e877be7 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7e877be7 0009:Call ntdll.RtlLeaveCriticalSection(7e899fc8) ret=7e877d1f 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7e877d1f 0009:Call ntdll.RtlLeaveCriticalSection(7e899fc8) ret=7e877c40 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7e877c40 0009:Ret msvcrt.fclose() retval=00000000 ret=7f81ecf0 0009:Call kernel32.OpenFile(7fe60252 "i:\\mnt\\privat\\Origin6\\UNTITLED.opj",7fadf040,00000200) ret=7f81ed08 0009:Call ntdll.RtlInitAnsiString(7fadecb4,7fe60252 "i:\\mnt\\privat\\Origin6\\UNTITLED.opj") ret=7fcc2d75 0009:Ret ntdll.RtlInitAnsiString() retval=00000023 ret=7fcc2d75 0009:Call ntdll.RtlAnsiStringToUnicodeString(7fffcbf8,7fadecb4,00000000) ret=7fcc2dda 0009:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=7fcc2dda 0009:Call ntdll.RtlGetFullPathName_U(7fffcc00 L"i:\\mnt\\privat\\Origin6\\UNTITLED.opj",00000208,7fadecd8,00000000) ret=7fce6be7 0009:Ret ntdll.RtlGetFullPathName_U() retval=00000044 ret=7fce6be7 0009:Call ntdll.RtlInitUnicodeString(7fadecbc,7fadecd8 L"I:\\mnt\\privat\\Origin6\\UNTITLED.opj") ret=7fce6b4e 0009:Ret ntdll.RtlInitUnicodeString() retval=00000046 ret=7fce6b4e 0009:Call ntdll.RtlUnicodeStringToAnsiSize(7fadecbc) ret=7fce6b58 0009:Ret ntdll.RtlUnicodeStringToAnsiSize() retval=00000023 ret=7fce6b58 0009:Call ntdll.RtlUnicodeStringToAnsiString(7fadecb4,7fadecbc,00000000) ret=7fce6b81 0009:Ret ntdll.RtlUnicodeStringToAnsiString() retval=00000000 ret=7fce6b81 0009:Call ntdll.RtlInitAnsiString(7fadeca0,7fe60252 "i:\\mnt\\privat\\Origin6\\UNTITLED.opj") ret=7fcc2d75 0009:Ret ntdll.RtlInitAnsiString() retval=00000023 ret=7fcc2d75 0009:Call ntdll.RtlAnsiStringToUnicodeString(7fffcbf8,7fadeca0,00000000) ret=7fcc2dda 0009:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=7fcc2dda 0009:Call ntdll.RtlInitAnsiString(7fadeca0,00000000) ret=7fcc2d75 0009:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=7fcc2d75 0009:Call ntdll.RtlAnsiStringToUnicodeString(7fadec98,7fadeca0,00000001) ret=7fcc2dda 0009:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=7fcc2dda 0009:Call ntdll.RtlDetermineDosPathNameType_U(7fffcc00 L"i:\\mnt\\privat\\Origin6\\UNTITLED.opj") ret=7fce8811 0009:Ret ntdll.RtlDetermineDosPathNameType_U() retval=00000002 ret=7fce8811 0009:Call ntdll.RtlDoesFileExists_U(7fffcc00 L"i:\\mnt\\privat\\Origin6\\UNTITLED.opj") ret=7fce8820 0009:Ret ntdll.RtlDoesFileExists_U() retval=00000001 ret=7fce8820 0009:Call ntdll.RtlGetFullPathName_U(7fffcc00 L"i:\\mnt\\privat\\Origin6\\UNTITLED.opj",00000208,7fadecd0,00000000) ret=7fce6be7 0009:Ret ntdll.RtlGetFullPathName_U() retval=00000044 ret=7fce6be7 0009:Call ntdll.RtlFreeHeap(7fd80000,00000000,7fdcd6a8) ret=7fccb881 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7fccb881 0009:Call ntdll.RtlFreeHeap(7fd80000,00000000,00000000) ret=7fccb881 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7fccb881 0009:Call ntdll.RtlInitUnicodeString(7fadeca8,7fadecd0 L"I:\\mnt\\privat\\Origin6\\UNTITLED.opj") ret=7fce6b4e 0009:Ret ntdll.RtlInitUnicodeString() retval=00000046 ret=7fce6b4e 0009:Call ntdll.RtlUnicodeStringToAnsiSize(7fadeca8) ret=7fce6b58 0009:Ret ntdll.RtlUnicodeStringToAnsiSize() retval=00000023 ret=7fce6b58 0009:Call ntdll.RtlUnicodeStringToAnsiString(7fadeca0,7fadeca8,00000000) ret=7fce6b81 0009:Ret ntdll.RtlUnicodeStringToAnsiString() retval=00000000 ret=7fce6b81 0009:Call ntdll.RtlInitAnsiString(7fadeed0,7fadf048 "I:\\mnt\\privat\\Origin6\\UNTITLED.opj") ret=7fcc2d75 0009:Ret ntdll.RtlInitAnsiString() retval=00000023 ret=7fcc2d75 0009:Call ntdll.RtlAnsiStringToUnicodeString(7fffcbf8,7fadeed0,00000000) ret=7fcc2dda 0009:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=7fcc2dda 0009:Call ntdll.RtlDosPathNameToNtPathName_U(7fffcc00 L"I:\\mnt\\privat\\Origin6\\UNTITLED.opj",7fadeed4,00000000,00000000) ret=7fcc4e4f 0009:Ret ntdll.RtlDosPathNameToNtPathName_U() retval=00000001 ret=7fcc4e4f 0009:Call ntdll.NtDeleteFile(7fadeebc) ret=7fcc4edf 0009:Ret ntdll.NtDeleteFile() retval=00000000 ret=7fcc4edf 0009:Call ntdll.RtlFreeUnicodeString(7fadeed4) ret=7fcc4ee7 0009:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=7fcc4ee7 0009:Ret kernel32.OpenFile() retval=00000001 ret=7f81ed08 0009:Call kernel32.TlsGetValue(00000003) ret=6c231018 0009:Ret kernel32.TlsGetValue() retval=7fdd4bb0 ret=6c231018 0009:Call kernel32.TlsGetValue(00000003) ret=6c231018 0009:Ret kernel32.TlsGetValue() retval=7fdd4bb0 ret=6c231018 I think here (at the latest) it starts building the error dialog... 0009:Call kernel32.FindResourceA(00400000,000003f1,00000006) ret=6c233a4e 0009:Call ntdll.LdrFindResource_U(00400000,7faded74,00000003,7faded90) ret=7fcf69c3 0009:Ret ntdll.LdrFindResource_U() retval=c000008b ret=7fcf69c3 0009:Call ntdll.RtlNtStatusToDosError(c000008b) ret=7fcf6968 0009:Ret ntdll.RtlNtStatusToDosError() retval=00000716 ret=7fcf6968 0009:Ret kernel32.FindResourceA() retval=00000000 ret=6c233a4e 0009:Call ntdll.RtlEnterCriticalSection(6c300178) ret=6c23178e 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=6c23178e 0009:Call kernel32.FindResourceA(7d4f0000,000003f1,00000006) ret=6c292bb9 0009:Call ntdll.LdrFindResource_U(7d4f0000,7faded74,00000003,7faded90) ret=7fcf69c3 0009:Ret ntdll.LdrFindResource_U() retval=c000008a ret=7fcf69c3 0009:Call ntdll.RtlNtStatusToDosError(c000008a) ret=7fcf6968 0009:Ret ntdll.RtlNtStatusToDosError() retval=00000715 ret=7fcf6968 0009:Ret kernel32.FindResourceA() retval=00000000 ret=6c292bb9 0009:Call kernel32.FindResourceA(10000000,000003f1,00000006) ret=6c292bb9 0009:Call ntdll.LdrFindResource_U(10000000,7faded74,00000003,7faded90) ret=7fcf69c3 0009:Ret ntdll.LdrFindResource_U() retval=c000008b ret=7fcf69c3 0009:Call ntdll.RtlNtStatusToDosError(c000008b) ret=7fcf6968 0009:Ret ntdll.RtlNtStatusToDosError() retval=00000716 ret=7fcf6968 0009:Ret kernel32.FindResourceA() retval=00000000 ret=6c292bb9 0009:Call kernel32.FindResourceA(4c000000,000003f1,00000006) ret=6c292bb9 0009:Call ntdll.LdrFindResource_U(4c000000,7faded74,00000003,7faded90) ret=7fcf69c3 0009:Ret ntdll.LdrFindResource_U() retval=c000008b ret=7fcf69c3 0009:Call ntdll.RtlNtStatusToDosError(c000008b) ret=7fcf6968 0009:Ret ntdll.RtlNtStatusToDosError() retval=00000716 ret=7fcf6968 0009:Ret kernel32.FindResourceA() retval=00000000 ret=6c292bb9 0009:Call kernel32.FindResourceA(44000000,000003f1,00000006) ret=6c292bb9 0009:Call ntdll.LdrFindResource_U(44000000,7faded74,00000003,7faded90) ret=7fcf69c3 0009:Ret ntdll.LdrFindResource_U() retval=c000008a ret=7fcf69c3 0009:Call ntdll.RtlNtStatusToDosError(c000008a) ret=7fcf6968 0009:Ret ntdll.RtlNtStatusToDosError() retval=00000715 ret=7fcf6968 0009:Ret kernel32.FindResourceA() retval=00000000 ret=6c292bb9 0009:Call kernel32.FindResourceA(7f770000,000003f1,00000006) ret=6c292bb9 0009:Call ntdll.LdrFindResource_U(7f770000,7faded74,00000003,7faded90) ret=7fcf69c3 0009:Ret ntdll.LdrFindResource_U() retval=00000000 ret=7fcf69c3 0009:Ret kernel32.FindResourceA() retval=7f98d968 ret=6c292bb9 0009:Call user32.LoadStringA(7f770000,00003f0e,7fadeebc,00000100) ret=6c292bcf 0009:Call ntdll.RtlAllocateHeap(7fd80000,00000000,00000200) ret=7f6b448f 0009:Ret ntdll.RtlAllocateHeap() retval=7fe60478 ret=7f6b448f 0009:Call kernel32.FindResourceW(7f770000,000003f1,00000006) ret=7f6b3dd5 0009:Call ntdll.LdrFindResource_U(7f770000,7fadec78,00000003,7fadec94) ret=7fcf6b33 0009:Ret ntdll.LdrFindResource_U() retval=00000000 ret=7fcf6b33 0009:Ret kernel32.FindResourceW() retval=7f98d968 ret=7f6b3dd5 0009:Call kernel32.LoadResource(7f770000,7f98d968) ret=7f6b3de4 0009:Call ntdll.LdrAccessResource(7f770000,7f98d968,7fadecd4,00000000) ret=7fcf5f94 0009:Ret ntdll.LdrAccessResource() retval=00000000 ret=7fcf5f94 0009:Ret kernel32.LoadResource() retval=7f9aea58 ret=7f6b3de4 0009:Call kernel32.LockResource(7f9aea58) ret=7f6b3df2 0009:Ret kernel32.LockResource() retval=7f9aea58 ret=7f6b3df2 0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7fe60478 L"Achtung !",00000009,7fadeebc,000000ff,00000000,00000000) ret=7f6b4557 "Achtung !" is the caption of the dialog. It seems as if the file is written normally, but in fact no file is created (or it is deleted again). But I can't say what's wrong... Ciao, Olaf Leidinger

Nov. 29, 2005

Re: Wine benchmarks

by Tom Wickline

On 11/28/05, James Hawkins <truiken(a)gmail.com> wrote: > > > > Quake 3 > > > > Gentoo native the FPS is 400.7 demo 1 > > Wine 0.9.1 FPS 339.6 demo 1 > > > > By native do you mean the linux client for Quake 3? Yes. If so then that's > not a very accurate benchmark comparison. The linux client is written > specifically for linux and the calls are directly into the system, > whereas with wine the calls go through the wine layer and then to the > system. The best comparison would be the fps from running quake 3 on > windows and the fps from the same executable run in wine. So true, when I first posted the benchmarks a couple people ask me what the difference between the native linux port, wine & xp were. So I thought I would add this info this time around as well. http://www.winehq.org/pipermail/wine-devel/2005-July/038874.html Cheers, Tom > > -- > James Hawkins >

Nov. 29, 2005

Re: Wine benchmarks

by James Hawkins

> > Quake 3 > > Gentoo native the FPS is 400.7 demo 1 > Wine 0.9.1 FPS 339.6 demo 1 > By native do you mean the linux client for Quake 3? If so then that's not a very accurate benchmark comparison. The linux client is written specifically for linux and the calls are directly into the system, whereas with wine the calls go through the wine layer and then to the system. The best comparison would be the fps from running quake 3 on windows and the fps from the same executable run in wine. -- James Hawkins

Nov. 29, 2005

Re: [Bug 3002] problems writting to serial ports on 2005-05-24 release

by James Hawkins

On 11/25/05, Fernando Chmielewsky <ferchimi(a)gmail.com> wrote: > sorry I ask you this in this way... > I once tracked a bug in wine using CVS, but now I can't even get to > download the cvs tree, doing exactly the sama I did in the past: > creating ~/.cvspass with the single line > :pserver:cvs(a)cvs.winehq.com:/home/wine Ah<Z > and ~/cvsrc file containing: > cvs -z 3 > update -PAd > diff -up > > and running: > cvs checkout wine > > and this just throws the following: > cvs checkout: No CVSROOT specified! Please use the `-d' option > cvs [checkout aborted]: or set the CVSROOT environment variable. > > and then, after setting export CVSROOT=~/wine, and creating ~wine/CVSROOT > says the following: > cvs checkout: cannot find module `wine' - ignored > > I know there's something wrong I am doing, only I do not know yet, > after all this time, what this things mean... > hope you can help me > You should check out the docs on winehq.org, they'll give better details then the folowing: your CVSROOT wasn't set up correctly: CVSROOT=:pserver:cvs(a)winehq.org:/home/wine -- James Hawkins

Nov. 29, 2005