May 2001 - Wine-Devel - list.winehq.org

Re: set_thread_buffer

by lawson_whitney＠juno.com

On Thu, 31 May 2001, Marcus Meissner wrote: > On Thu, May 31, 2001 at 01:12:14PM -0400, =?iso-8859-1?Q?G=E9rard_Patel_=3Cgerard.patel=40nerim.net=3E?=(a)tourian.nerim.net wrote: > > At 01:24 30/05/2001 +0200, you wrote: > > (yet another self followup) > > > > >Since the commits of last night, every app I have tried only says : > > >wine client error:0x80675a8: set_thread_buffer failed with status c000000d > > > Hmm, can you do 'nm file/file.o|grep stat64' and see if we are including > stat64 there? Should it look like this? U __lxstat64 U __xstat64 > > Ciao, Marcus > > I have had problems since applying the last 8 patches too, but I get a page fault in loader/pe_image, which wasn't touched, so maybe something to do with memory addressing is disturbed? I get this: WineDbg starting... on pid 8064a30 No debug information in 32bit DLL '<Debugged process>' (0x00400000) Loaded debug information from ELF 'wine' (0x00000000) Breakpoint 1 at 0x4000a560 (_end+0x37fbde24) Loaded debug information from ELF '/usr/local/lib/libntdll.so' (0x4001d000) Loaded debug information from ELF '/usr/local/lib/libwine.so' (0x40112000) Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so' (0x40128000) No debug information in ELF '/usr/lib/libncurses.so.5' (0x401f0000) No debug information in ELF '/lib/libm.so.6' (0x4022d000) No debug information in ELF '/lib/libutil.so.1' (0x4024c000) No debug information in ELF '/lib/libdl.so.2' (0x4024f000) No debug information in ELF '/lib/libc.so.6' (0x40253000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) No debug information in 32bit DLL 'NTDLL.DLL' (0x40057000) Unhandled exception: page fault on read access to 0x69000003 in 32-bit code (0x40083480). In 32-bit mode. 0x40083480 (dump_exports+0xe8 [pe_image.c:100] in libntdll.so): movl 0x0(%esi),%edx 100 if (!*function) continue; /* No such function */ Wine-dbg>info reg Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:40083480 ESP:40576d10 EBP:40576d44 EFLAGS:00010287( R- 00 I S - -P1C) EAX:1300c830 EBX:400fb3c4 ECX:ff50d5ff EDX:400f8220 ESI:69000003 EDI:00000000 Wine-dbg>info local dump_exports:hModule == 0x13000000 dump_exports:Module == 0x13a82484 dump_exports:i (optimized into register $edi) == 0x00000000 dump_exports:j (optimized into register $edx) == 0x400f8220 dump_exports:ordinal == 0x13c0bc15 dump_exports:function (optimized into register $esi) == 0x69000003 dump_exports:name == 0x1250d5ff dump_exports:load_addr == 0x13000000 dump_exports:rva_start == 0x0000c830 dump_exports:rva_end == 0x0000c971 dump_exports:pe_exports == 0x1300c830 Wine-dbg>x/24c 0x1250d5ff 0x1250d5ff (_end+0xa4c0ec3): *** Invalid address 0x1250d5ff (_end+0xa4c0ec3) Wine-dbg>x/24x pe_exports 0x1300c830 (_end+0xafc00f4): 850cc483 c08e0fc0 8d000000 00a82484 0x1300c840 (_end+0xafc0104): 6a500000 01896800 f1680000 56000003 0x1300c850 (_end+0xafc0114): ff50d5ff 00c0bc15 248c8d13 000000a8 0x1300c860 (_end+0xafc0124): 03f26851 ff560000 d3ff50d5 0123a0bf 0x1300c870 (_end+0xafc0134): ffc98313 548bc033 aef21024 0123e0a1 0x1300c880 (_end+0xafc0144): 49d1f713 e9505251 00000110 07c40d8b 0x1300c890 (_end+0xafc0154): Wine-dbg> Backtrace: =>0 0x40083480 (dump_exports+0xe8(hModule=0x13000000) [pe_image.c:100] in libntdll.so) (ebp=40576d44) 1 0x40084486 (PE_CreateModule+0x282(hModule=0x13000000, filename=0x403428cc, flags=0x0, hFile=0x18, builtin=0x0) [pe_image.c:632] in libntdll.so) (ebp=40576da8) 2 0x400845a1 (PE_LoadLibraryExA+0x65(name=0x403428cc, flags=0x0) [pe_image.c:704] in libntdll.so) (ebp=40576dd0) 3 0x40082a5d (MODULE_LoadLibraryExA+0x339(libname=0x480f98, hfile=0x0, flags=0x0) [module.c:1405] in libntdll.so) (ebp=40576e10) 4 0x40083aa3 (fixup_imports+0xe3(wm=0x403427e8) [pe_image.c:289] in libntdll.so) (ebp=40576e58) 5 0x40084495 (PE_CreateModule+0x291(hModule=0x400000, filename=0x4010fd20, flags=0x0, hFile=0x0, builtin=0x0) [pe_image.c:636] in libntdll.so) (ebp=40576ebc) 6 0x400c822b (start_process+0x10f [process.c:366] in libntdll.so) (ebp=40576f30) 7 0x400cb7e9 (SYSDEPS_DoCallOnStack+0x25(func=0x400c811c, arg=0x0) [sysdeps.c: 173] in libntdll.so) (ebp=40576ff0) 8 0x400cb88f (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffff474) 9 0x400cb939 (SYSDEPS_SwitchToThreadStack+0x95(func=0x400c811c) [sysdeps.c:236] in libntdll.so) (ebp=bffff4b0) 10 0x400c85fd (PROCESS_InitWine+0x199(argc=0x6, argv=0xbffff54c, win16_exe_name=0x804c620, win16_exe_file=0x804c724) [process.c:525] in libntdll.so) (ebp=bffff4cc) 11 0x0804b1e4 (Letext [main.c] in wine) (ebp=bffff4e4) 12 0x4026bcbe (NTDLL.DLL.sqrt+0x3362e in libc.so.6) (ebp=bffff520) 13 0x08049021 (_start+0x21 in wine) (ebp=00000000) I might be misconfigured somehow, or have missed a patch, but in case this might shed some light here it is. glibc 2.1.3 kernel 2.4.4 with devfs active. X 3.3.5. Have to revert now to mail this. Blah! Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

May 31, 2001

Re: set_errno patch

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > MSVCRT__set_errno should be able to set errno to 0. It's called at > least once explicitly with 0 in dir.c, but many other times it is > called with a GetLastError() that may return 0. I don't think it is ever correct to set errno to 0. Code that does that should be fixed to provide a valid error code instead. -- Alexandre Julliard julliard(a)winehq.com

May 31, 2001

Re: FreeType autoconf checks - please test

by Huw D M Davies

On Thu, May 31, 2001 at 10:02:55AM -0500, Ian Pilcher wrote: > This works on my system (Red Hat 7.1 with FreeType 2.0.1). Please try > it on other variants and let me know if it works. Ian, Looks good with freetype 2.0.3 (and RH 7.1). It's not an offical rpm though, I just dropped the 2.0.3 tarball into the build directory and tweaked the spec file a little. Huw.

May 31, 2001

FreeType autoconf checks - please test

by Ian Pilcher

This works on my system (Red Hat 7.1 with FreeType 2.0.1). Please try it on other variants and let me know if it works. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ======================================================================== diff -urN ../wine-20010529cvs/configure.in ./configure.in --- ../wine-20010529cvs/configure.in Thu May 31 09:16:57 2001 +++ ./configure.in Thu May 31 09:19:41 2001 @@ -402,8 +402,21 @@ wine_cv_msg_freetype=yes else AC_DEFINE(HAVE_FREETYPE) - FREETYPELIBS=`$ft_devel --libs` - FREETYPEINCL=`$ft_devel --cflags` + FREETYPELIBS=`$ft_devel --libs` + FREETYPEINCL=`$ft_devel --cflags` + ft_incl_dir=${FREETYPEINCL#-I} + old_c_include_path="$C_INCLUDE_PATH" + C_INCLUDE_PATH="$ft_incl_dir:$C_INCLUDE_PATH" + export C_INCLUDE_PATH + ft_incl_dir=$ft_incl_dir/freetype + AC_CHECK_HEADER($ft_incl_dir/freetype.h,AC_DEFINE(HAVE_FREETYPE_H)) + AC_CHECK_HEADER($ft_incl_dir/ftglyph.h,AC_DEFINE(HAVE_FTGLYPH_H)) + AC_CHECK_HEADER($ft_incl_dir/tttables.h,AC_DEFINE(HAVE_TTTABLES_H)) + AC_CHECK_HEADER($ft_incl_dir/ftnames.h,AC_DEFINE(HAVE_FTNAMES_H)) + AC_CHECK_HEADER($ft_incl_dir/ftsnames.h,AC_DEFINE(HAVE_FTSNAMES_H)) + AC_CHECK_HEADER($ft_incl_dir/ttnameid.h,AC_DEFINE(HAVE_TTNAMEID_H)) + C_INCLUDE_PATH="$old_c_include_path" + export C_INCLUDE_PATH wine_cv_msg_freetype=no fi fi diff -urN ../wine-20010529cvs/dlls/wineps/truetype.c ./dlls/wineps/truetype.c --- ../wine-20010529cvs/dlls/wineps/truetype.c Thu May 31 09:17:26 2001 +++ ./dlls/wineps/truetype.c Thu May 31 09:17:56 2001 @@ -9,11 +9,30 @@ #ifdef HAVE_FREETYPE +/* + * These stupid #ifdefs should work for FreeType 2.0.1 and 2.0.2. Beyond that + * is anybody's guess. + */ + +#ifdef HAVE_FREETYPE_H #include <freetype/freetype.h> -#include FT_NAMES_H -#include FT_TRUETYPE_NAMES_H -#include FT_TRUETYPE_TABLES_H -#include FT_GLYPH_H +#endif +#ifdef HAVE_FTGLYPH_H +#include <freetype/ftglyph.h> +#endif +#ifdef HAVE_TTTABLES_H +#include <freetype/tttables.h> +#endif +#ifdef HAVE_FTNAMES_H +#include <freetype/ftnames.h> +#endif +#ifdef HAVE_FTSNAMES_H +#include <freetype/ftsnames.h> +#endif +#ifdef HAVE_TTNAMEID_H +#include <freetype/ttnameid.h> +#endif + #include <sys/types.h> #include <dirent.h> #include <string.h> diff -urN ../wine-20010529cvs/include/acconfig.h ./include/acconfig.h --- ../wine-20010529cvs/include/acconfig.h Tue May 29 18:16:35 2001 +++ ./include/acconfig.h Thu May 31 09:17:56 2001 @@ -129,3 +129,11 @@ /* Define if FreeType 2 is installed */ #undef HAVE_FREETYPE + +/* Define if various FreeType headers are present */ +#undef HAVE_FREETYPE_H +#undef HAVE_FTGLYPH_H +#undef HAVE_TTTABLES_H +#undef HAVE_FTNAMES_H +#undef HAVE_FTSNAMES_H +#undef HAVE_TTNAMEID_H

May 31, 2001

[Fwd: autoconf help needed [was wineps include fix.]]

by Ian Pilcher

Ian Pilcher wrote: > > Marcus Meissner wrote: > > > > Add here: > > > > CFLAGS="$CFLAGS -I$ft_incl_dir" > > > > Works great. Thanks! > I spoke too soon. It's finding /usr/include/freetype/freetype.h (from FreeType 1.x). The test is not paying any attention to the CFLAGS variable. So how does one get the autoconf tests to look in a non-standard directory for header files? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 31, 2001

Re: set_thread_buffer

by Marcus Meissner

On Thu, May 31, 2001 at 01:12:14PM -0400, =?iso-8859-1?Q?G=E9rard_Patel_=3Cgerard.patel=40nerim.net=3E?=(a)tourian.nerim.net wrote: > At 01:24 30/05/2001 +0200, you wrote: > (yet another self followup) > > >Since the commits of last night, every app I have tried only says : > > > >wine client error:0x80675a8: set_thread_buffer failed with status c000000d Hmm, can you do 'nm file/file.o|grep stat64' and see if we are including stat64 there? > >with apps that usually work fine. > I have still the problem; I have downloaded a fresh tree from winehq > to make sure it was not a random event. > > I don't have much time to debug until next weekend, but I have done > a bit of searching : this does not happen on my newest computer, a > Mandrake 8 with glibc 2.2. It happens with my other box, a Suse 6.1 > with a manually upgraded glibc 2.1.3 (I use it without this problem since > months) > > The problem occurs in the mmap call in the server subroutine, the parameters > being > size=8192, fd=8,offset=0. > > Has anyone compiled cvs since 3 days with glibc 2.1.3 ? I have build RPMs for OpenLinux eDesktop 2.4, which is kernel 2.2.14 and glibc 2.1.3, and sol.exe still works. You can try them from http://www.lst.de/~mm/wine.html if you want to. Ciao, Marcus

May 31, 2001

Re: WINE server messages

by David Howells

> Maintaining a section list in the server is certainly something we > could do, but I don't really see why you want to get rid of the > modules list. What would you gain by doing that?> NtMapViewOfSection/NtUnmapViewOfSection. Admittedly, these would be hard to implement fully in the current Wine userspace server I think (they can map a section handle into _another_ process's VM space). However, it's something I can do in kernel space reasonably easily. And then there's NtQueryVirtualMemory. This can return a handle to the backing section (assuming I'm recalling this correctly) in some other process. Actually, I see that you do maintain a view list in the client as well as the module list and section lists in the server. What I was thinking of was just consolidating the three into a single view list and a single section list in the server. In effect, Wine'd still have the module list, it's just that there'd be non-modules in the list too. This would mean that the debugger could query from the server what Windows VM mappings should be expected. And, of course, it'd make writing the kernel module slightly easier:-) David

May 31, 2001

Re: Status of ASPI?

by Marcus Meissner

On Tue, May 29, 2001 at 11:38:46PM -0600, Dax Kelson wrote: > > > > I'm having a failure with a windows app. The application starts, and it > > asks me to name my project and pick a directory to store it in. When I do > > so, I get errors such as: > > > > fixme:shell:PathGetCharTypeA d > > fixme:shell:PathGetCharTypeA f > > fixme:shell:PathGetCharTypeA d > > fixme:shell:PathGetCharTypeA t > > Lots of thanks to Marcus, and his implementation of PathGetChar. I can > report that his patch worked for me. > > My next hurdle is ASPI support. This application I'm running needs to > access my DVD drive via ASPI, and it complains it can't see any device. > On the Linux side of things, I've setup ide-scsi emulation for my ATAPI > DVD drive. > > Here is the error I'm getting: > > fixme:aspi:SendASPI32Command ASPI: Partially implemented SC_HA_INQUIRY for > adapter 0. > > At one point I thought ASPI was working since you could use Win32 CDR > burning software with Wine. What is the current status of ASPI in Wine? Its fine, XingDVD even uses ASPI to decrypt DVDs here ;) You need to add to the config file: [scsi c0t0d0] "Device" = "/dev/sg0" [scsi c0t1d0] "Device" = "/dev/sg1" ... And make the sg* corresponding to your DVD drive world read/writeable. (Check /proc/scsi/scsi, count starting with 0 down to your DVD drive. if it is the first entry, it is sg0, the second is sg1 ... ) Ciao, Marcus

May 31, 2001

Re: autoconf help needed [was wineps include fix.]

by Marcus Meissner

> Alexandre Julliard wrote: > > > > Basically do a > > > > AC_CHECK_HEADERS(freetype/freetype.h freetype/foo.h freetype/bar.h) > > > > Unfortunately it's not that simple, because the FreeType include files > won't always be in /usr/include/freetype. On Red Hat 7.1, for example, > they're in /usr/include/freetype2/freetype, to distinguish them from > the FreeType 1.x headers. > > The required compiler flag to include the proper directories is in the > FREETYPEINCL variable. For example, on my Red Hat system it is set to > '-I/usr/include/freetype2'. I tried the following: > > ft_incl_dir=${FREETYPEINCL#-I} Add here: CFLAGS="$CFLAGS -I$ft_incl_dir" > AC_CHECK_HEADER("$ft_incl_dir/freetype/freetype.h",AC_DEFINE(HAVE_FREETYPE_H)) Use here: AC_CHECK_HEADER(freetype/freetype.h) and HAVE_FREETYPE_FREETYPE_H for presence later. > When I run autoconf, autoheader, and configure, I get the following: > > checking for FT_Init_FreeType in -lfreetype... yes > checking for freetype-config... freetype-config > checking for /usr/include/freetype2/freetype/freetype.h... no > > So the AC_CHECK_HEADER macro isn't finding the file, even though it is > right there. > > Anyone have any idea why? Always check config.log for errors. Ciao, Marcus

May 31, 2001

autoconf help needed [was wineps include fix.]

by Ian Pilcher

Alexandre Julliard wrote: > > Basically do a > > AC_CHECK_HEADERS(freetype/freetype.h freetype/foo.h freetype/bar.h) > Unfortunately it's not that simple, because the FreeType include files won't always be in /usr/include/freetype. On Red Hat 7.1, for example, they're in /usr/include/freetype2/freetype, to distinguish them from the FreeType 1.x headers. The required compiler flag to include the proper directories is in the FREETYPEINCL variable. For example, on my Red Hat system it is set to '-I/usr/include/freetype2'. I tried the following: ft_incl_dir=${FREETYPEINCL#-I} AC_CHECK_HEADER("$ft_incl_dir/freetype/freetype.h",AC_DEFINE(HAVE_FREETYPE_H)) When I run autoconf, autoheader, and configure, I get the following: checking for FT_Init_FreeType in -lfreetype... yes checking for freetype-config... freetype-config checking for /usr/include/freetype2/freetype/freetype.h... no So the AC_CHECK_HEADER macro isn't finding the file, even though it is right there. Anyone have any idea why? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 31, 2001