wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Re: unicows update and PE memory format
by Rolf Kalbermatter 25 Nov '03

25 Nov '03

Message: 4 Subject: Re: PE stack trick not working on lowmem machines From: Mike Hearn <mike(a)theoretic.com> To: Alexandre Julliard <julliard(a)winehq.org> Cc: Marcus Meissner <meissner(a)suse.de>, wine-devel(a)winehq.com Date: Mon, 24 Nov 2003 21:00:33 +0000 On Mon, 2003-11-24 at 20:38, Alexandre Julliard wrote: > > Btw, why don't we use -Wa,--noexecstack ? > > It doesn't help with prelink AFAICT. Is it really too late to get some kind of hook into prelink to stop it interfering with Wine? It seems daft that we need such a big hack when surely a flag in the elf headers would work just as well with co-operation from the rtld. --__--__-- >Shachar Shemesh <wine-devel(a)shemesh.biz> writes: >Now here's the puzzle - GetProcAddress is never called. Neither are >these functions imported from the DLL in the PE header. In fact, >unicows.dll does not even appear in the PE header (which makes sense - >on NT you don't even want to install it). This means that unicows.lib >manages to call GetProcAddress, without actually calling GetProcAddress. > >Some tracing leads me to suspect (I have not done enough research to >determine yet) that it accesses the PE header of kernel32 directly. It >appears that unicows.dll enountered the exact same problem we have vis a >vis GetProcAddress, and have happily hacked their way around it using >direct memory access. What I see them do is call "GetModuleHandle" on >"kernel32.dll", and then use the resulting handle as a struct/array >pointer, and access offsets into it. This is not exactly very nice but it is also not to surprising. The PE header is actually documented on MSDN including the import and export tables. GetModuleHandle actually also just returns the HMODULE which at least for Win32 is the same as the HINSTANCE returned by LoadLibrary. The difference is if I'm not mistaken, that GetModuleHandle will usually not try to load the module if it isn't already loaded, but for kernel32 you can safely assume that a process has it already loaded implicitedly or even explicitedly. An HMODULE on Win32 is nothing else than the base address of a loaded module image, and with some offset calculations using Macros from winnt.h you can get at anything in that image including the export table and from there you can then search GetProcAddress. One possible problem is that the unicows GetProcAddress implementation might not search the function in the export table by name but rather by ordinal and our ordinal or ordinal base is different from what Unicows expects. Rolf Kalbermatter

2 1

Re: Small fontdlg fix.
by Shachar Shemesh 25 Nov '03

25 Nov '03

Rein Klazes wrote: > HPEN hOrigPen; > HFONT hOrigFont; > COLORREF rgbPrev; >- WCHAR sample[SAMPLE_EXTLEN+5]={'A','a','B','b'}; >+ WCHAR sample[SAMPLE_EXTLEN+9]={'A','a','B','b','Y','y','Z','z'}; > > This is wrong. "YyZz" are only added if it's a western encoding. This already happens (a patch I submitted earlier this year, and forgot to add my copyright to the file). With this patch, if you view a font in it's Western encoding, you get a sample that says "AaBbYyZzYyZz". If you view a font in another encoding (say, Hebrew, because that's the only one that was fed in), you get "AaBbYyZz��", instead of "AaBb��", like it is on Windows 2000, and like it makes sense (we want to spare some space). Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

2 3

Re: [PATCH] wininet.dll compile time defines
by Vincent Béron 25 Nov '03

25 Nov '03

Le mar 25/11/2003 à 00:37, Alex Tribble a écrit : > Hi, > When upgrading to Fedora Core 1 (the new RedHat release, sort of), > wine stopped compiling for me. I was getting errors while parsing > <openssl/ssl.h>, et al. -DOPENSSL_NO_KRB5 makes these go away. > > Any thoughts? Please CC me, as I'm not subscribed to the devel list. The patch http://cvs.winehq.com/patch.py?id=10182 (applied yesterday in CVS) fixes the issue. Vincent

1 0

Re: Mach-O Support for imageSize in NtHeader
by Alexandre Julliard 25 Nov '03

25 Nov '03

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > Here is my second try for a replacement of the _end symbol. I think > that since there is no support of it we need a kind of emulation > function, which I thought should be located in the wine_port lib. So I > add a mach-o.c port file, with the needed function. But should it be > done this way? No, the static char _end[] thing should be enough, you don't have to store anything in there (which won't do what you want anyway). The only thing that matters is the address of the _end symbol. -- Alexandre Julliard julliard(a)winehq.com

2 1

unicows update and PE memory format
by Shachar Shemesh 25 Nov '03

25 Nov '03

Hi list, Here is a quick update. It seems that I won't be able to use the forwarding inside the spec file. I'm not sure exactly why that is, but I think the unicows.lib link time library tries to load stuff by doing "GetModuleHandle", and then fetching relative values from that place. Is there a plausable assumption about PE memory layout? Is this something that Win32 properly defines? Do we have such a format for winelib dlls? Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

3 5

RFH: *ReAlloc* mess
by Dimitrie O. Paun 25 Nov '03

25 Nov '03

Hi folks, I need some help to figure out how the following realloc functions behave: GlobalReAlloc LocalReAlloc Local32ReAlloc16 NetApiBufferReallocate SysReAllocStringLen So, I need to know: -- do they allocate memory when a NULL is passed in? -- do they free memory when the size is passed in as 0? Help with this matter is much appreciated! -- Dimi.

1 0

Re: Update comctl spec
by Alexandre Julliard 24 Nov '03

24 Nov '03

Hans Leidekker <hans(a)it.vu.nl> writes: > Changelog: > - Export more functions by name. This will break the import libraries. Why do you want to do that? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Compile Bug: dlls/wininet/cookie.c .. and its cause
by Alexandre Julliard 24 Nov '03

24 Nov '03

Ivan Gyurdiev <ivg2(a)cornell.edu> writes: > I have no clue what the FAR macro does, but wouldn't it be better to > just rename the wine FAR macro to something different if you dont want > it to conflict w/ the other FAR macro? It's a Windows thing, we can't change it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: heap: fix RtlHeapReAllocate()
by Dimitrie O. Paun 24 Nov '03

24 Nov '03

On November 21, 2003 03:21 pm, Eric Pouech wrote: > this will not compile on Win9x. You have to take care of: Good point, sorry about that, I was being lazy. To force people to do the dyn load, we shouldn't import ntdll, no? ChangeLog RtlHeapReAllocate() should not allocate memory. Add small test to make sure it doesn't return. Don't import ntdll for tests, we need to load it dynamically. Index: dlls/ntdll/heap.c =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/heap.c,v retrieving revision 1.25 diff -u -r1.25 heap.c --- dlls/ntdll/heap.c 10 Oct 2003 00:12:17 -0000 1.25 +++ dlls/ntdll/heap.c 20 Nov 2003 21:00:39 -0000 @@ -1231,11 +1231,11 @@ HEAP *heapPtr; SUBHEAP *subheap; - if (!ptr) return RtlAllocateHeap( heap, flags, size ); /* FIXME: correct? */ + if (!ptr) return NULL; if (!(heapPtr = HEAP_GetPtr( heap ))) { set_status( STATUS_INVALID_HANDLE ); - return FALSE; + return NULL; } /* Validate the parameters */ Index: dlls/ntdll/tests/Makefile.in =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/tests/Makefile.in,v retrieving revision 1.9 diff -u -r1.9 Makefile.in --- dlls/ntdll/tests/Makefile.in 8 May 2003 03:47:24 -0000 1.9 +++ dlls/ntdll/tests/Makefile.in 24 Nov 2003 07:19:04 -0000 @@ -3,12 +3,12 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ TESTDLL = ntdll.dll -IMPORTS = ntdll CTESTS = \ env.c \ error.c \ generated.c \ + heap.c \ large_int.c \ path.c \ rtl.c \ --- /dev/null 2003-01-30 05:24:37.000000000 -0500 +++ dlls/ntdll/tests/heap.c 2003-11-24 02:17:07.000000000 -0500 @@ -0,0 +1,49 @@ +/* + * Unit test suite for heap functions + * + * Copyright 2003 Dimitrie O. Paun + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <stdarg.h> +#include <stdlib.h> + +#include "ntstatus.h" +#include "windef.h" +#include "winbase.h" +#include "wine/test.h" +#include "winnt.h" +#include "winnls.h" +#include "winreg.h" +#include "winternl.h" + +PVOID (WINAPI *pRtlReAllocateHeap)(HANDLE,ULONG,PVOID,ULONG); + +static void test_realloc( void ) +{ + void *mem = NULL; + + mem = pRtlReAllocateHeap(GetProcessHeap(), 0, mem, 10); + ok(mem == NULL, "memory allocated"); +} + +START_TEST(heap) +{ + HMODULE mod = GetModuleHandle("ntdll.dll"); + if (!mod) return; + pRtlReAllocateHeap = (void *)GetProcAddress(mod, "RtlReAllocateHeap"); + if (pRtlReAllocateHeap) test_realloc(); +} -- Dimi.

3 3

Compile Bug: dlls/wininet/cookie.c .. and its cause
by Ivan Gyurdiev 24 Nov '03

24 Nov '03

Macro __WINESRC__ is defined for dlls/wininet/cookie.c in the Makefile. The file cookie.c includes wine/debug.h. wine/debug.h includes windef.h. windef.h defines the macro FAR to __ONLY_IN_WINELIB() __ONLY_IN_WINELIB() defines to do_not_use_this_in_wine if __WINESRC__ The file dlls/wininet/cookie.c also includes dlls/wininet/internet.h dlls/wininet/internet.h includes openssl/ssl.h for my machine openssl/ssl.h includes openssl/kssl.h openssl/kssl.h has the following code using the FAR macro: #ifdef KRB5_HEIMDAL typedef unsigned char krb5_octet; #endif #ifndef FAR #define FAR #endif ... Line 136: krb5_octet FAR *key; This is on a Fedora core system, which applies a patch to openssl that changes the original openssl-devel regarding this, but I think the issue's with wine, and is still there. The original openssl-devel looks like this: #ifdef KRB5_HEIMDAL typedef unsigned char krb5_octet; define FAR #endif Either way, the point is the FAR macro is being used in kssl.h, and it's defined in windef.h, as do_not_use_this_in_wine, resulting in this: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_WINX32_ -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o cookie.o cookie.c In file included from /usr/include/openssl/ssl.h:179, from internet.h:36, from cookie.c:39: /usr/include/openssl/kssl.h:136: error: syntax error before '*' token /usr/include/openssl/kssl.h:149: error: syntax error before '*' token /usr/include/openssl/kssl.h:150: error: syntax error before '*' token /usr/include/openssl/kssl.h:151: error: syntax error before '*' token /usr/include/openssl/kssl.h:151: error: syntax error before '*' token /usr/include/openssl/kssl.h:152: error: syntax error before '*' token /usr/include/openssl/kssl.h:153: error: syntax error before '*' token /usr/include/openssl/kssl.h:155: error: syntax error before '*' token /usr/include/openssl/kssl.h:157: error: syntax error before '*' token /usr/include/openssl/kssl.h:159: error: syntax error before '*' token /usr/include/openssl/kssl.h:167: error: syntax error before '*' token In file included from internet.h:36, from cookie.c:39: /usr/include/openssl/ssl.h:909: error: syntax error before "KSSL_CTX" /usr/include/openssl/ssl.h:931: error: syntax error before '}' token make[2]: *** [cookie.o] Error 1 make[2]: Leaving directory `/home/phantom/tmp/firebird-downloads/wine-20031118/dlls/wininet' make[1]: *** [wininet] Error 2 make[1]: Leaving directory `/home/phantom/tmp/firebird-downloads/wine-20031118/dlls' make: *** [dlls] Error 2 ===================================================================== I am not subscribed to this list. If you'd like to email back write to ivg2(a)cornell.edu. Also, some unrelated questions: does anyone know what causes this: err:module:NE_LoadBuiltinModule loaded .so but dll winealsa.drv still not found (the file is there... oss is there too, and works great) ....or why keyboard focus is always lost (characters appear in the console, kb doesn't work in application) when playing most games under a window manager like gnome or kde, but not under twm? This bug has been there forever and is really annoying.

3 2

Re: winmm: move MCI settings from system.ini to the registry
by Andreas Mohr 24 Nov '03

24 Nov '03

Hi, On Mon, Nov 24, 2003 at 12:10:20PM -0500, Dimitrie O. Paun wrote: > On November 22, 2003 03:02 am, Eric Pouech wrote: > > I won't have too much time to look at this in details right now, so if > > someone wants to jump in, I'll be happy to give him (her ?) a hand. > > To be honest, > My interest in doing this work is to get rid of system.ini from the > Wine tree. While I agree that there's more to do, it's just not up > my alley :) So, this version of the patch still maintains support > for system.ini, just like the old code does, but it also adds support > for registry, which should allow us to move stuff there. To be honest, I'm not sure why one would want that. After all the system.ini settings are an essential part of a Windows environment, and removing the whole file will break many (admittedly older) programs, if I'm not mistaken... (nevermind the duplication of the parameters, which does exist) Andreas Mohr

1 0

Re: documentation/samples/generic.ppd
by Marcus Meissner 24 Nov '03

24 Nov '03

On Mon, Nov 24, 2003 at 02:32:49AM -0500, Dimitrie O. Paun wrote: > > I can't help but feel that this file does not belong in the > Wine tree, but in the print system packages (cups, etc.). > > cvs rm -f documentation/samples/generic.ppd > > ChangeLog > Remove generic.ppd, it does not belong in the Wine tree. This is the generic fallback PPD file which can be used LPR style printing, where we do not get access to a PPD easily. Ciao, Marcus

2 1

IS_STRING_ITEM( lpitem->fType ) but no lpitem->text
by Uwe Bonnes 24 Nov '03

24 Nov '03

Hallo, Peter Heckert <ph_newsalias(a)arcor.de> posted on c.e.m.w a problem with Sigma Photo Pro 2. Sigma Photo Pro 2 can be downloaded at http://www.sigma-photo.co.jp/english/downloads/downloads.html It seems that IS_STRING_ITEM( lpitem->fType ) is set while there is no lpitem->text. Appended hack lets Sigma Photo Pro 2 run until exit, where it crashes again. Can anybody look at that problem? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.169 diff -u -r1.169 menu.c --- wine/controls/menu.c 18 Nov 2003 19:42:31 -0000 1.169 +++ wine/controls/menu.c 23 Nov 2003 21:52:38 -0000 @@ -936,7 +936,7 @@ /* it must be a text item - unless it's the system menu */ - if (!(lpitem->fType & MF_SYSMENU) && IS_STRING_ITEM( lpitem->fType )) + if (!(lpitem->fType & MF_SYSMENU) && IS_STRING_ITEM( lpitem->fType )&& lpitem->text) { SIZE size; GetTextExtentPoint32W(hdc, lpitem->text, strlenW(lpitem->text), &size); @@ -1361,7 +1361,7 @@ } /* No bitmap - process text if present */ - else if (IS_STRING_ITEM(lpitem->fType)) + else if (IS_STRING_ITEM(lpitem->fType) && lpitem->text) { register int i; HFONT hfontOld = 0;

2 2

Re: wine/dlls/kernel process.c
by Marcelo Duarte 24 Nov '03

24 Nov '03

Em Seg 17 Nov 2003 17:18, Alexandre Julliard escreveu: > ChangeSet ID: 10093 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/11/17 14:18:19 > > Modified files: > dlls/kernel : process.c > > Log message: > Fixed regression in loading of builtin apps from the system dir when > the native doesn't exist. > > Patch: http://cvs.winehq.com/patch.py?id=10093 > > Old revision New revision Changes Path > 1.34 1.35 +1 -1 wine/dlls/kernel/process.c This patch do not work for me. I run: wine --debugmsg +file -- c:\\windows\\system\\vfp300.esl c:\\modullus.300\\modullus.exe See, the file is searched in all directories of the PATH, and not found: trace:file:CreateFileW L"C:\\windows\\system\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\windows\\system\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L".\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L".\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"C:\\WINDOWS\\SYSTEM\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\WINDOWS\\SYSTEM\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"C:\\WINDOWS\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\WINDOWS\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"c:\\windows\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"c:\\windows\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"c:\\windows\\system\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"c:\\windows\\system\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"e:\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"e:\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"e:\\test\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"e:\\test\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"f:\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"f:\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"C:\\windows\\system\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\windows\\system\\kernel32.dll" (GLE 2) trace:file:CreateFileW L".\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L".\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"C:\\WINDOWS\\SYSTEM\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\WINDOWS\\SYSTEM\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"C:\\WINDOWS\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\WINDOWS\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"c:\\windows\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"c:\\windows\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"c:\\windows\\system\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"c:\\windows\\system\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"e:\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"e:\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"e:\\test\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"e:\\test\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"f:\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"f:\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"C:\\windows\\system\\ntdll.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\windows\\system\\ntdll.dll" (GLE 2) trace:file:CreateFileW L".\\ntdll.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L".\\ntdll.dll" (GLE 2) -- Marcelo Duarte

1 0

Re: Compiler problems
by Ivan Leo Murray-Smith 24 Nov '03

24 Nov '03

Current code builds on my system.

2 1

Re: Regressions....
by Marcelo Duarte 24 Nov '03

24 Nov '03

Em Sáb 15 Nov 2003 13:28, você escreveu: Hi, Recently I found plus a regression when trying to install my application, using the installer of the M$, with updated cvs. See the error: [mduarte@mduarte setup]$ wine config Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Could not stat /cdrom (No such file or directory), ignoring drive D: Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Could not stat /cdrom (No such file or directory), ignoring drive D: err:seh:setup_exception stack overflow 304 bytes in thread 000c eip 4045ec30 esp 405c0ed0 stack 0x405c0000-0x405c4000 [mduarte@mduarte setup]$ Somebody can give tips to discover the problem to me? Running +relay is too slow in my machine, but I hava a 1.2MB log. I have little time that I can dedicate to the Wine, but go to try to make this today and tomorrow. Here is the part of +relay where the error occurs and system hangs: 000c:Call ntdll.RtlInitAnsiString(405c3c6c,406867c0 "Software\\Wine\\Wine\\Config\\Tweak.Fonts") ret=405e32a4 000c:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=405e32a4 000c:Call ntdll.RtlAnsiStringToUnicodeString(40018bf8,405c3c6c,00000000) ret=405e32ad 000c:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=405e32ad 000c:Call ntdll.NtOpenKey(405c3d78,000f003f,405c3c74) ret=405e32d3 000c:Ret ntdll.NtOpenKey() retval=c0000034 ret=405e32d3 000c:Call ntdll.RtlNtStatusToDosError(c0000034) ret=405e32b7 000c:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=405e32b7 000c:Ret advapi32.RegOpenKeyA() retval=00000002 ret=4066f28c 000c:Call kernel32.LoadLibrary16(40686903 "GDI.EXE") ret=4066f2a3 err:seh:setup_exception stack overflow 460 bytes in thread 000c eip 4045ec30 esp 405c0e34 stack 0x405c0000-0x405c4000 Thanks in advance. > Em Qua 05 Nov 2003 22:30, Marcelo Duarte escreveu: > > Hi all, > > > > Some days ago, I have some problems with my application developed in > > Visual Foxpro 3, that before the end of separation of kernel, runs with > > some issues, but runs. The problems resides in a call to dlls and > > library (in VFP, the comand SET LIBRARY calls a especial type of DLL) and > > the 3 forms is accepted: 1) SET LIBRARY TO FOXTOOLS > > 2) SET LIBRARY TO FOXTOOLS.FLL > > 3) SET LIBRARY TO "FOXTOOLS.FLL" > > In wine, after the end of separation fase, in the new wine-20031016, only > > the (3) is accepted, and accutually (the last CVS) the forms 1, 2 and 3, > > appear to be running, and I will investigate.... > > But, the usage of external DLLs is broken. > > Exist the comand DECLARE, wich declares a function in a dll, and as > > example, I use this: > > DECLARE INTEGER GetLogicalDriveStrings IN WIN32API; > > INTEGER nLen, STRING @sBuf > > > > and call: > > nLen = GetLogicalDriveStrings(MAX_DRIVES, @sBuf) > > > > When the calls fire, the programs terminates, a messagebox appear with > > text "Invalid indentifier" and some others erros and wine returns the > > following errors: > > > > [mduarte@mduarte MODULLUS.300]$ wine modullus > > fixme:font:WineEngAddFontResourceEx :stub > > fixme:font:WineEngAddFontResourceEx :stub > > [mduarte@mduarte MODULLUS.300]$ wine: Unhandled exception (thread 000b), > > starting debugger... > > WineDbg starting on pid a > > Loaded debug information from ELF 'wine' ((nil)) > > Breakpoint 1 at 0x4000d484 (_end+0x400a660) > > Loaded debug information from ELF '/usr/local/lib/libwine.so.1' > > (0x40028000) No debug information in ELF '/lib/libc.so.6' (0x4003f000) > > No debug information in ELF '/lib/libdl.so.2' (0x40184000) > > No debug information in ELF '/lib/libm.so.6' (0x40187000) > > Loaded debug information from ELF '/lib/ld-linux.so.2' (0x40000000) > > Loaded debug information from ELF '/usr/local/lib/wine/ntdll.dll.so' > > (0x401aa000) > > Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so.1' > > (0x40216000) > > No debug information in ELF '/lib/libnss_files.so.2' (0x4001a000) > > Loaded debug information from ELF '/usr/local/lib/wine/kernel32.dll.so' > > (0x40420000) > > Loaded debug information from ELF '/usr/local/lib/wine/user32.dll.so' > > (0x40680000) > > Loaded debug information from ELF '/usr/local/lib/wine/gdi32.dll.so' > > (0x407ab000) > > Loaded debug information from ELF '/usr/local/lib/wine/advapi32.dll.so' > > (0x4081b000) > > Loaded debug information from ELF '/usr/local/lib/wine/winspool.drv.so' > > (0x40847000) > > Loaded debug information from ELF '/usr/local/lib/wine/comdlg32.dll.so' > > (0x40869000) > > Loaded debug information from ELF '/usr/local/lib/wine/shell32.dll.so' > > (0x408e1000) > > Loaded debug information from ELF '/usr/local/lib/wine/ole32.dll.so' > > (0x4095d000) > > Loaded debug information from ELF '/usr/local/lib/wine/rpcrt4.dll.so' > > (0x409cc000) > > Loaded debug information from ELF '/usr/local/lib/wine/shlwapi.dll.so' > > (0x40a11000) > > Loaded debug information from ELF '/usr/local/lib/wine/comctl32.dll.so' > > (0x40a64000) > > Loaded debug information from ELF '/usr/local/lib/wine/version.dll.so' > > (0x40af9000) > > Loaded debug information from ELF '/usr/local/lib/wine/lz32.dll.so' > > (0x40b12000) > > Loaded debug information from ELF '/usr/local/lib/wine/mpr.dll.so' > > (0x40b28000) > > Loaded debug information from ELF '/usr/local/lib/wine/winmm.dll.so' > > (0x40b41000) > > Loaded debug information from ELF '/usr/local/lib/wine/x11drv.dll.so' > > (0x40ba6000) > > No debug information in ELF '/usr/X11R6/lib/libSM.so.6' (0x40561000) > > No debug information in ELF '/usr/X11R6/lib/libICE.so.6' (0x40c21000) > > No debug information in ELF '/usr/X11R6/lib/libXrandr.so.2' (0x4030b000) > > No debug information in ELF '/usr/X11R6/lib/libXrender.so.1' (0x40571000) > > No debug information in ELF '/usr/X11R6/lib/libXext.so.6' (0x40c38000) > > No debug information in ELF '/usr/X11R6/lib/libX11.so.6' (0x40c46000) > > No debug information in ELF '/usr/lib/libGL.so.1' (0x40d0e000) > > No debug information in ELF '/usr/X11R6/lib/libXmu.so.6' (0x40ebb000) > > No debug information in ELF '/usr/X11R6/lib/libXt.so.6' (0x40ed1000) > > No debug information in ELF '/usr/X11R6/lib/libXi.so.6' (0x40f23000) > > No debug information in ELF '/lib/libpthread.so.0' (0x40f2b000) > > No debug information in ELF '/usr/X11R6/lib/libXcursor.so.1' (0x40f7c000) > > No debug information in ELF > > '/usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2' (0x4056a000) > > No debug information in ELF > > '/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2' (0x40f85000) > > Loaded debug information from ELF '/usr/local/lib/wine/wineoss.drv.so' > > (0x410c0000) > > Loaded debug information from ELF '/usr/local/lib/wine/msacm.drv.so' > > (0x410fb000) > > Loaded debug information from ELF '/usr/local/lib/wine/msacm32.dll.so' > > (0x41112000) > > Loaded debug information from ELF '/usr/local/lib/wine/midimap.drv.so' > > (0x41250000) > > Loaded debug information from ELF '/usr/local/lib/wine/ctl3d32.dll.so' > > (0x41371000) > > No debug information in 32bit DLL 'C:\windows\system\VFP300.ESL' > > (0x400000) No debug information in 32bit DLL 'NTDLL.DLL' (0x401c0000) > > No debug information in 32bit DLL 'KERNEL32.DLL' (0x40450000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' > > (0x40830000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' > > (0x407c0000) No debug information in 32bit DLL > > 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x406a0000) No debug information in 32bit > > DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x40850000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' > > (0x409e0000) No debug information in 32bit DLL > > 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x40980000) No debug information in 32bit > > DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x40a30000) No debug information in > > 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x40a70000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' > > (0x40900000) No debug information in 32bit DLL > > 'C:\WINDOWS\SYSTEM\COMDLG32.DLL' (0x40880000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\LZ32.DLL' > > (0x40b20000) No debug information in 32bit DLL > > 'C:\WINDOWS\SYSTEM\VERSION.DLL' (0x40b00000) No debug information in > > 32bit DLL 'C:\WINDOWS\SYSTEM\MPR.DLL' (0x40b30000) No debug information > > in 32bit DLL > > 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x40b50000) No debug information in 32bit > > DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40bc0000) No debug information in > > 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x410d0000) No debug > > information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x41120000) No > > debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x41100000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' > > (0x41260000) No debug information in 32bit DLL > > 'C:\WINDOWS\SYSTEM\CTL3D32.DLL' (0x41380000) Unhandled exception: page > > fault on write access to 0x55bd0565 in 32-bit code (0x00405732). > > In 32-bit mode. > > 0x00405732 (VFP300.ESL..text+0x3732 in VFP300.ESL): movl > > %edx,0x0(%eax) Wine-dbg>WineDbg terminated on pid a > > > > The winedbg crahes.... > > > > The wine-20030911 runs fine. > > Can someone help me how to correct, or where to find the problem? -- Marcelo Duarte

1 1

configure features summary patch
by Chris Morgan 23 Nov '03

23 Nov '03

Lionel was wondering why just print out the status of openGL, why not of other optional features. I tried to get all of the important ones, comments and suggestions welcome. This patch is intended to replace the previous one. Chris

1 0

Segmentation fault with "./pgm" but not with "wine ./pgm"
by Sundial Services International Inc 23 Nov '03

23 Nov '03

After updating Linux (glibc) the following problem has surfaced: [#1] If a Win32 executable is run from the shell with "./pgmname" the program does not run but produces the message "segmentation fault." (If there is a traceback or log then I don't know how to get it.) [#2] However: if the program is run with "wine ./pgmname" the program runs normally. Perhaps the most basic problem I have here is that, in scenario #1 when all I get is "segmentation fault," I don't know how to get more info, a traceback or a log. System is RHLinux 8.0, Wine 20030318, which ran just fine in both scenarios until an update was applied which included glibc. Incidentally, I rebuilt Wine from source and even rebooted the machine (sigh, thus ending 100-odd days of uptime) with no effect on the prob. Obviously if I knew how to see the real failure-message I could probably shoot it.

2 1

Re: Fixes to wininet.dll
by Uwe Bonnes 23 Nov '03

23 Nov '03

>>>>> "Jens" == Jens Briesofsky <jeb(a)swym.net> writes: Jens> My first set of patches contributed to wine, the results of my Jens> struggle getting Climateprediction.net to work... Perhaps consider writing test cases for yoyr finding to. Look at ../wininet/test/ how that is done. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

configure patch to be clear about the state of opengl support
by Chris Morgan 23 Nov '03

23 Nov '03

Someone on irc had trouble with opengl, it wasn't clear whether opengl support was enabled or not. Thought I might throw out a patch to make things more explicit. Chris

1 0

Re: Japanese default GuiFont
by Shachar Shemesh 23 Nov '03

23 Nov '03

Hi, Are you the same guy who does maintains the ODBC driver for Postgresql? Shachar Hiroshi Inoue wrote: -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

1 1

WineX relation to Wine
by Gerhard W. Gruber 22 Nov '03

22 Nov '03

I was wondering what is the relation of Wine to WineX? There is a CVS access to WineX, at least part of it, which is covered under the GPL. What I was wondering about is, wether this code is the same as wine or is it more advanced? Or is this code only the sutff which is also contained in Wine and all the other stuff is (more or less) closed, so that you can not use it for Wine. I was thinking about subscribing to WineX, at least a test for this three month account, to see if the games, I'm interested in, will work. But then I wonder what this would mean if I do some work for Wine. Is this a problem? Can Wine and WineX co-exist as an installation and for development? I know that I was not exactly busy for wine right now, but I try to get pICE in a state where it will be usefull for wine development, because this is my primary goal, but if this will be a problem after being subscribed to WineX I would rather not subscribe and stick with Wine instead. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu

6 13

Compiling Wine: tokenize.c problem
by Paul Barclay 22 Nov '03

22 Nov '03

I hope this is the right list for this. Version 20031118 redhat 9 After running ./tools/wineinstall everything goes ok until i get the following: . . . . make[2]: Leaving directory `/home/pbarclay/downloads/wine-20031118/dlls/mshtml' make[2]: Entering directory `/home/pbarclay/downloads/wine-20031118/dlls/msi' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o tokenize.o tokenize.c tokenize.c:46: `TK_ABORT' undeclared here (not in a function) tokenize.c:46: initializer element is not constant tokenize.c:46: (near initialization for `aKeywordTable[0].tokenType') tokenize.c:46: initializer element is not constant tokenize.c:46: (near initialization for `aKeywordTable[0]') tokenize.c:47: `TK_AFTER' undeclared here (not in a function) tokenize.c:47: initializer element is not constant tokenize.c:47: (near initialization for `aKeywordTable[1].tokenType') tokenize.c:47: initializer element is not constant tokenize.c:47: (near initialization for `aKeywordTable[1]') tokenize.c:48: `TK_ALL' undeclared here (not in a function) . . . . tokenize.c:296: `TK_ILLEGAL' undeclared (first use in this function) tokenize.c:305: `TK_BITOR' undeclared (first use in this function) tokenize.c:308: `TK_CONCAT' undeclared (first use in this function) tokenize.c:313: `TK_COMMA' undeclared (first use in this function) tokenize.c:317: `TK_BITAND' undeclared (first use in this function) tokenize.c:321: `TK_BITNOT' undeclared (first use in this function) tokenize.c:336: `TK_STRING' undeclared (first use in this function) tokenize.c:341: `TK_DOT' undeclared (first use in this function) tokenize.c:348: `TK_INTEGER' undeclared (first use in this function) tokenize.c:353: `TK_FLOAT' undeclared (first use in this function) tokenize.c:370: `TK_ID' undeclared (first use in this function) make[2]: *** [tokenize.o] Error 1 make[2]: Leaving directory `/home/pbarclay/downloads/wine-20031118/dlls/msi' make[1]: *** [msi] Error 2 make[1]: Leaving directory `/home/pbarclay/downloads/wine-20031118/dlls' make: *** [dlls] Error 2 Could somebody offer a way to fix this? Thanks PB ________________________________________________________________________ E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ________________________________________________________________________

1 0

Re: help with linking needed
by Ralf Juengling 22 Nov '03

22 Nov '03

> I have successfully compiled sources of a Windows application, but > when starting up, it tries to locate and link to a windows dll > to access some C library functions: > > ... > err:module:import_dll No implementation for cw3230.DLL._strlen imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._strncpy imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._strtok imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._tolower imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._toupper imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:LdrInitializeThunk Main exe initialization failed, status > c0000135 > > First of all: Where does the name "cw3230.DLL" come from -- Wine didn't > install such a dll on my system? Okay, I found the answer to this myself, it is quite embarrassing: Amid the sources that I got there was also the executable compiled on a Windows system by a Borland compiler. Since the winelib-generated make file creates a shared library and not an executable, the spurious native Windows executable was not overwritten by my built. The wineapploader script then started wine with the native Windows executable instead of the shared library "memview.exe.so", and the missing DLL reported above is probably Borlands C runtime library or part of it. So forget about the other questions in my previous posting. Now the problem is that the applicaiton doesn't start but immediately fails with a Segmentation Fault. The problem seems to be in the function GetFullName in files/dos_fs.c; here are the last four lines of a startup trace: 0009:trace:nls:WideCharToMultiByte cp 65010 L"memview.exe" -> "memview.exe" 0009:trace:dosfs:DOSFS_FindUnixName (/local/builts/phaeaco-20031119/src/memview,L"memview.exe") -> L"memview.exe" (L"MEMVIEW.EXE") 0009:trace:heap:RtlFreeHeap (0x401e0000,00000002,401e0918): returning TRUE 0009:trace:dosfs:DOSFS_GetFullName returning /local/builts/phaeaco-20031119/src/memview/memview.exe = L"Z:\\LOCAL\\BUILTS\\PHAE~WVJ\\SRC\\MEMVI\ EW\\MEMVIEW.EXE" Segmentation fault (Note: I had renamed the file "memview.exe.so" to "memview.exe"). I haven't looked into and tried to fix GetFullName yet but will do so next week. Of course, I hope somebody who knows the code well will come up with a fix before I try. :-) Thanks for the Wine, Ralf

1 0

Re: help with linking needed
by Ralf Juengling 22 Nov '03

22 Nov '03

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel