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

Re: wineps include fix.

by Ian Pilcher

Alexandre Julliard wrote: > > The page at http://freetype.sourceforge.net/freetype2/docs/tutorial/step1.html > says that you have to include ft2build.h and use macros to include > freetype.h, and that other inclusion schemes will get broken in 2.1. > I have no idea if this page is up-to-date or if the recommendations > have changed again. Aargh! It seems we're stuck with autoconf checks then. (I'm starting to wish I'd pushed harder for my "TTFM file" idea.) > > Except with the autoconf checks we control what macros are being > defined, we don't have to guess which file to include to get the > proper macros. Frankly this idea of defining macros to specify include > file names is hopelessly brain-damaged, and the less we have to do > with that the happier I will be. I certainly agree with you on this. If they can't even keep source compatibility between 2.0.x versions, I fail to see what benefit the whole scheme has. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 31, 2001

Re: critical section blocking

by Me

> With this patch, Myst locks up solid as soon as the mouse is moved into > the Myst window. Without it, Myst works fine. Same with Red Alert, except without the patch the mouse would eventually lock up, instead of right away with this patch. The bug is actually there, and it's really annoying, but the fix is wrong. -Ryan

May 31, 2001

Re: wineps include fix.

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > Did you read somewhere that they're getting rid of freetype.h? > > I've looked at 2.0.1 and 2.0.2: > > * In 2.0.1, the header macros are defined in > freetype/config/ftbuild.h, which is included in freetype/freetype.h. > > * In 2.0.2, the header macros are defined in ft2build.h, which is > included in freetype/freetype.h. > > So as long as they keep freetype/freetype.h around, we can include that > and get the macro definitions. The page at http://freetype.sourceforge.net/freetype2/docs/tutorial/step1.html says that you have to include ft2build.h and use macros to include freetype.h, and that other inclusion schemes will get broken in 2.1. I have no idea if this page is up-to-date or if the recommendations have changed again. > We still have to test which macros are defined and only include the ones > that exist, but it does save the work of adding extra autoconf checks. Except with the autoconf checks we control what macros are being defined, we don't have to guess which file to include to get the proper macros. Frankly this idea of defining macros to specify include file names is hopelessly brain-damaged, and the less we have to do with that the happier I will be. -- Alexandre Julliard julliard(a)winehq.com

May 30, 2001

Re: PATCH: Version 2, GetX11WindowId

by Alexandre Julliard

Nikolas Zimmermann <wildfox(a)kde.org> writes: > ah > i mean, this feature would _only_ be used in kdenonbeta/activexproxy > and it would be great to have this in CVS until you've done this rewrite-task. > > Do you think that's a good, short-term, solution for me? For you certainly. But it doesn't have to be in CVS for you to use it, does it? These kinds of quick hacks have a way of staying around much too long, especially when external packages depend on them, and the best way to avoid that is to not put them in CVS the first place. -- Alexandre Julliard julliard(a)winehq.com

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

Alexandre Julliard wrote: > > It seems the rule is now to use ft2build.h instead of freetype.h. And > this will certainly change in the next release again... so yes, it > will be a nightmare if we actually try to use the silly macros. But if > we simply bypass them and do autoconf checks like we do for every > other package, I think it should work, and be harder to break (though > I'm sure the freetype guys will manage to do it ;-) > Did you read somewhere that they're getting rid of freetype.h? I've looked at 2.0.1 and 2.0.2: * In 2.0.1, the header macros are defined in freetype/config/ftbuild.h, which is included in freetype/freetype.h. * In 2.0.2, the header macros are defined in ft2build.h, which is included in freetype/freetype.h. So as long as they keep freetype/freetype.h around, we can include that and get the macro definitions. We still have to test which macros are defined and only include the ones that exist, but it does save the work of adding extra autoconf checks. I sent a test patch to wine-devel earlier today which does this, and I'm waiting to hear how it works. I'd prefer to stick with this scheme *until* it breaks; anyone looked at 2.0.3? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

Ove Kaaven wrote: > > Just checking - are you sure? The ft2build.h isn't where the other > freetype headers are, it is in /usr/include, not in /usr/include/freetype. > (I wonder if these guys have written a readme file or something for using > freetype that we haven't read) Just checked. It's not in /usr/include/ or /usr/include/freetype2/. (Red Hat puts the FreeType 1.x headers in /usr/include/freetype/ and the 2.x headers in /usr/include/freetype2/freetype/). -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 30, 2001

Re: wineps include fix.

by Ove Kaaven

On 30 May 2001, Alexandre Julliard wrote: > Ian Pilcher <ian.pilcher(a)home.com> writes: > > > FT_SFNT_NAMES_H doesn't appear anywhere in the 2.0.1 headers. It > > appears to be impossible to be source code compatible between 2.0.1 and > > 2.0.2. > > How about doing autoconf checks for all the possible header names > variations, and including the ones we find? This would be a lot more > robust than trying to find the header that defines the macros that > define the headers that define what we need... The first step isn't a problem, freetype/freetype.h includes ft2build.h and hence ft2header.h, so including freetype.h and counting on macros to exist should work on all FT2 versions. Then, conditionally including stuff using the HAVE_FOO_H macros that autoconf would define wouldn't be much better than conditionally including stuff based on the FT_FOO_H macros.

May 30, 2001

Re: wineps include fix.

by Ove Kaaven

On Wed, 30 May 2001, Ian Pilcher wrote: > Huw D M Davies wrote: > > > > Actually aren't you supposed to do this? > > > > #include <ft2build.h> > > #include FT_FREETYPE_H > > #include FT_xxxx_H > > > > 2.0.1 (at least as packaged by Red Hat) does not include a file named > ft2build.h. Just checking - are you sure? The ft2build.h isn't where the other freetype headers are, it is in /usr/include, not in /usr/include/freetype. (I wonder if these guys have written a readme file or something for using freetype that we haven't read)

May 30, 2001

Problems with large file support.

by Ludovic LANGE

Hello, A few days ago (15 or 16) the support for large files / 64bits was added to Wine ( files/files.c, server/file.c, win32/file.c). Since that modification, my Wine installation isn't functional any more, and wine throws an exception while setting up the SystemHeap. The exception occurs in heap.c, function HEAP_InitSubHeap, just at the instruction : "subheap->heap = heap;" while the subheap pointer is valid. It seems as if the protection of this memory areay was set to read-only, and that the mprotect() call did not succeed in setting it to read/write. I don't know where the real problem is, but since I found no record of such problem in the lists archive, it may be a configuration problem of mine. However, having not found the solution, I'd like some advices. I also think it could be a problem with my glibc not functionning with 64bits functions. My system is a Linux 2.4.4 / RedHat 7.0 / redhat's glibc 2.2-12 Here is a working trace, before the support for 64bits functions was added : ============================================================================== 0806cb00:trace:virtual:CreateFileMappingA (ffffffff,(nil),08000004,0000000000110000,"__SystemHeap") 0806cb00: create_mapping( size_high=0, size_low=1114112, protect=67, inherit=0,file_handle=0, name=L"__SystemHeap" ) 0806cb00: create_mapping() = 0 { handle=32 } 0806cb00: get_mapping_info( handle=32 ) 0806cb00: get_mapping_info() = 0 { size_high=0, size_low=1114112, protect=67, header_size=0, base=(nil), shared_file=0, shared_size=0 } 0806cb00: get_handle_fd( handle=32, access=00000000 ) 0806cb00: *fd* 32 -> 9 0806cb00: get_handle_fd() = 0 { fd=-1 } 0806cb00: set_handle_info( handle=32, flags=0, mask=0, fd=6 ) 0806cb00: set_handle_info() = 0 { old_flags=0, cur_fd=6 } 0806cb00:trace:virtual:MapViewOfFileEx handle=20 size=110000 offset=0 0806cb00: dup_handle( src_process=-1, src_handle=32, dst_process=-1, access=00000000, inherit=0, options=2 ) 0806cb00: dup_handle() = 0 { handle=36, fd=-1 } View: 65430000 - 6553ffff 36 65430000 - 6553ffff c-rW- 0806cb00:trace:virtual:VirtualAlloc 65430000 00110000 1000 00000040 0806cb00:trace:virtual:VIRTUAL_SetProt 65430000-6553ffff c-rWx View: 65430000 - 6553ffff 36 65430000 - 6553ffff c-rWx 0806cb00: create_semaphore( initial=00000000, max=00000001, inherit=0, name=L"") ============================================================================== Here is the stack trace with support for 64 bits functions (more debug traces of mine.) ============================================================================== 0806cb40:trace:virtual:CreateFileMappingA (ffffffff,(nil),08000004,0000000000110000,"__SystemHeap") 0806cb40: create_mapping( size_high=0, size_low=1114112, protect=67, inherit=0, file_handle=0, name=L"__SystemHeap" ) 0806cb40: create_mapping() = 0 { handle=32 } 0806cb40:trace:heap:HEAP_CreateSystemHeap LLA 0806cb40: get_mapping_info( handle=32 ) 0806cb40: get_mapping_info() = 0 { size_high=0, size_low=1114112, protect=67, header_size=0, base=(nil), shared_file=0, shared_size=0 } 0806cb40: get_handle_fd( handle=32, access=00000000 ) 0806cb40: *fd* 32 -> 9 0806cb40: get_handle_fd() = 0 { fd=-1 } 0806cb40: set_handle_info( handle=32, flags=0, mask=0, fd=6 ) 0806cb40: set_handle_info() = 0 { old_flags=0, cur_fd=6 } 0806cb40:trace:virtual:MapViewOfFileEx handle=20 size=110000 offset=0 0806cb40: dup_handle( src_process=-1, src_handle=32, dst_process=-1, access=00000000, inherit=0, options=2 ) 0806cb40: dup_handle() = 0 { handle=36, fd=-1 } View: 65430000 - 6553ffff 36 65430000 - 6553ffff c-rW- 0806cb40:trace:heap:HEAP_CreateSystemHeap LLA - after MapViewOfFileEx : 1077 0806cb40:trace:heap:HEAP_CreateSystemHeap LLA - line 1081 0806cb40:trace:heap:HEAP_InitSubHeap LLA address = 65430000 - line 478 0806cb40:trace:heap:HEAP_InitSubHeap LLA - line 482 0806cb40:trace:virtual:VirtualAlloc 65430000 00110000 1000 00000040 0806cb40:trace:virtual:VIRTUAL_SetProt 65430000-6553ffff c-rWx View: 65430000 - 6553ffff 36 65430000 - 6553ffff c-rWx 0806cb40:trace:virtual:VirtualAlloc LLA 65430000 00110000 1000 00000040 VIRTUAL_SetProt : base= 65430000 0806cb40:trace:heap:HEAP_InitSubHeap LLA - line 491 0806cb40:trace:heap:HEAP_InitSubHeap LLA subheap = 65430000 - line 518 0806cb40:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 0806cb40: queue_exception_event( first=1, record={context={flags=00000000,eax=00000047,ebx=4012c0ec,ecx=65430000,edx=65430000,esi=40128e05,edi=00110000,ebp=00000000,eip=400bb7eb,esp=40626dd0,eflags=00010212,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400bb7eb,params={1,65430010} ) 0806cb40: queue_exception_event() = 0 { handle=0 } ============================================================================== Any clues are welcome. Best regards, Ludovic LANGE

May 30, 2001

Re: PATCH: Version 2, GetX11WindowId

by Nikolas Zimmermann

On Wednesday 30 May 2001 22:40, you wrote: > Nikolas Zimmermann <wildfox(a)kde.org> writes: > > Hi there, > > > > andrewl (#winehq) advised me to remove > > the winuser.h dependencies > > > > here is the new patch > > > > Any comments? > > The main problem is that this requires linking the application to > x11drv, which is not a good idea. x11drv is an internal driver that > should only be loaded by user/gdi. There needs to be a way to do that > without loading x11drv, for instance by using window properties. This > is somewhere on my todo list for the new window management code that > I'm currently working on. ah i mean, this feature would _only_ be used in kdenonbeta/activexproxy and it would be great to have this in CVS until you've done this rewrite-task. Do you think that's a good, short-term, solution for me? Bye Bye Niko -- Nikolas Zimmermann wildfox(a)kde.org

May 30, 2001

Re: PATCH: Version 2, GetX11WindowId

by Alexandre Julliard

Nikolas Zimmermann <wildfox(a)kde.org> writes: > Hi there, > > andrewl (#winehq) advised me to remove > the winuser.h dependencies > > here is the new patch > > Any comments? The main problem is that this requires linking the application to x11drv, which is not a good idea. x11drv is an internal driver that should only be loaded by user/gdi. There needs to be a way to do that without loading x11drv, for instance by using window properties. This is somewhere on my todo list for the new window management code that I'm currently working on. -- Alexandre Julliard julliard(a)winehq.com

May 30, 2001

Re: wineps include fix.

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > I *believe* that <freetype/freetype.h> should always include the header > that defines the macros. If not, it's going to be a nightmare checking > for 2.0.1, 2.0.2, 2.0.3, etc. -- let alone every intermediate snapshot > that a rawhide/cooker distribution might use. It seems the rule is now to use ft2build.h instead of freetype.h. And this will certainly change in the next release again... so yes, it will be a nightmare if we actually try to use the silly macros. But if we simply bypass them and do autoconf checks like we do for every other package, I think it should work, and be harder to break (though I'm sure the freetype guys will manage to do it ;-) Basically do a AC_CHECK_HEADERS(freetype/freetype.h freetype/foo.h freetype/bar.h) and then #ifdef HAVE_FREETYPE_FREETYPE_H #include <freetype/freetype.h> #endif #ifdef HAVE_FREETYPE_FOO_H #include <freetype/foo.h> #endif etc. Then when they change all the header names again in the next release we can simply add the new names to the list. -- Alexandre Julliard julliard(a)winehq.com

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

Alexandre Julliard wrote: > > > FT_SFNT_NAMES_H doesn't appear anywhere in the 2.0.1 headers. It > > appears to be impossible to be source code compatible between 2.0.1 and > > 2.0.2. > > How about doing autoconf checks for all the possible header names > variations, and including the ones we find? This would be a lot more > robust than trying to find the header that defines the macros that > define the headers that define what we need... > I *believe* that <freetype/freetype.h> should always include the header that defines the macros. If not, it's going to be a nightmare checking for 2.0.1, 2.0.2, 2.0.3, etc. -- let alone every intermediate snapshot that a rawhide/cooker distribution might use. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 30, 2001

Re: WINE server messages

by Alexandre Julliard

David Howells <dhowells(a)redhat.com> writes: > I'm having a little trouble deciding exactly how to emulate the "module > registration" functionality in my kernel module. It occurs to me that this > might be easier to accomplish with a change to the current wine server message > set. My idea is: > > * Have the server only deal with NT Section objects and views of Sections. > > * Have no separate module table attached to a process. > > * Implement NtQuerySectionInformation/NtSetSectionInformation calls (or > whatever they're called) as wineserver messages. > > * Add an extra Wine-specific information class for the purpose of recording > the extra module information. > > * The wineserver process structure can then be changed so that rather than > keeping a separate list of process_dlls, they can just keep a list of > section views, some of which will be images/modules. 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?> -- Alexandre Julliard julliard(a)winehq.com

May 30, 2001

Re: wineps include fix.

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > FT_SFNT_NAMES_H doesn't appear anywhere in the 2.0.1 headers. It > appears to be impossible to be source code compatible between 2.0.1 and > 2.0.2. How about doing autoconf checks for all the possible header names variations, and including the ones we find? This would be a lot more robust than trying to find the header that defines the macros that define the headers that define what we need... -- Alexandre Julliard julliard(a)winehq.com

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

Ove Kaaven wrote: > > So FT_TRUETYPE_TABLES_H and FT_GLYPH_H is covered, but FT_NAMES_H and > FT_TRUETYPE_NAMES_H is not. Apparently the defines were changed or > something - FT_SFNT_NAMES_H is apparently the one you must use now? Let me know if this works. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ======================================================================== diff -urN ../wine-20010529cvs/dlls/wineps/truetype.c ./dlls/wineps/truetype.c --- ../wine-20010529cvs/dlls/wineps/truetype.c Tue May 29 18:16:33 2001 +++ ./dlls/wineps/truetype.c Wed May 30 13:24:37 2001 @@ -9,11 +9,31 @@ #ifdef HAVE_FREETYPE +/* + * These stupid ifdefs should work for FreeType 2.0.1 and 2.0.2. 2.0.3 and + * beyond are anybody's guess. + */ + #include <freetype/freetype.h> -#include FT_NAMES_H -#include FT_TRUETYPE_NAMES_H -#include FT_TRUETYPE_TABLES_H #include FT_GLYPH_H +#include FT_TRUETYPE_TABLES_H + +#ifdef FT_NAMES_H +#include FT_NAMES_H /* 2.0.1 */ +#endif + +#ifdef FT_SFNT_NAMES_H +#include FT_SFNT_NAMES_H /* 2.0.2 */ +#endif + +#ifdef FT_TRUETYPE_NAMES_H +#include FT_TRUETYPE_NAMES_H /* 2.0.1 */ +#endif + +#ifdef FT_TRUETYPE_IDS_H +#include FT_TRUETYPE_IDS_H /* 2.0.2 */ +#endif + #include <sys/types.h> #include <dirent.h> #include <string.h>

May 30, 2001

PATCH: Version 2, GetX11WindowId

by Nikolas Zimmermann

Hi there, andrewl (#winehq) advised me to remove the winuser.h dependencies here is the new patch Any comments? Bye Bye Niko -- Nikolas Zimmermann wildfox(a)kde.org

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

Huw D M Davies wrote: > > Actually aren't you supposed to do this? > > #include <ft2build.h> > #include FT_FREETYPE_H > #include FT_xxxx_H > 2.0.1 (at least as packaged by Red Hat) does not include a file named ft2build.h. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

Ove Kaaven wrote: > > So FT_TRUETYPE_TABLES_H and FT_GLYPH_H is covered, but FT_NAMES_H and > FT_TRUETYPE_NAMES_H is not. Apparently the defines were changed or > something - FT_SFNT_NAMES_H is apparently the one you must use now? FT_SFNT_NAMES_H doesn't appear anywhere in the 2.0.1 headers. It appears to be impossible to be source code compatible between 2.0.1 and 2.0.2. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 30, 2001

Re: some unimplemented COM stuff

by David Hagood

> Because all I have is an IDispatch pointer and a vtable offset to the method. > Calling Invoke itself is not a problem at all. The method to be called by > Invoke isn't known at compile time. > -Malte > It sounds to me like you have an impedance mismatch: you have a system that wants to call a C linkage function, and you want to tie it into a C++ object. What you'll have to do is something like this: class Base_class { ... virtual RETTYPE Real_func(arg1, arg2, <etc>) = 0; static RETTYPE Entry_func_stub(void *dis, arg1, arg2, <etc>) { Base_class *ptr = (Base_class *)dis; return dis->Real_func(arg1,arg2,<etc>); } void Hook_up_function(void) { Set_some_func_ptr(Entry_func_stub,(void *)this); } }; .... class Child1: public Base_class { RETTYPE Real_func(arg1,arg2,<etc>); }; Class Child2: public Base_class { RETTYPE Real_func(arg1,arg2,<etc>); }; The stub function in the base class can be coorced into having non-C++ linkage with an appropriate declaration, and will call the appropriate vtable entry and offset the this pointer correctly. While I've not done this under Wine or Windows, I have done this sort of thing in several RTOSs with great success.

May 30, 2001

Re: wineps include fix.

by Huw D M Davies

Actually aren't you supposed to do this? #include <ft2build.h> #include FT_FREETYPE_H #include FT_xxxx_H Huw. -- Dr. Huw D M Davies | Clarendon Laboratory h.davies1(a)physics.ox.ac.uk | Parks Road Tel: +44 1865 272390 | Oxford OX1 3PU Fax: +44 1865 272400 | UK

May 30, 2001

EMAIL REJECTED. RE: Re: wineps include fix.

by ian.pilcher＠home.com

<!! You are not on my whitelist, to avoid spam, I have not recieved your email !!> If your message was not Spam or USE, I strongly apologize for the inconvenice cause by this block, but the ammount of spam recieved on this email address (around 10 per day) is too much for me, and I refuse to read it, so please, accept this appology and resend your message to the address below. Thank you for your time. This message was generated by antispam Your message was not accepted either because: * I don't recognize your address, or * The magic cookie in the 'dated' or 'sender' address you sent to has expired or is invalid. You can contact me using the address: <crazney-dated-80d93cd3482f4319(a)crazney.net> but it will only work for the next 5 days. If you're just sending me SPAM/UCE, buzz off. Regards, David Hammerton aka crazney --your email-- On Wed, 30 May 2001, Ian Pilcher wrote: > You're getting the error because FreeType's macros are not being defined > by your include files. This is supposed to be the way to work around > the > fact that the FreeType guys rename their include files with every minor > release. > > freetype/freetype.h should either define the macros or include another > file that does so. If you can figure out why that isn't happening, let > me know. It is happening, ftheader.h just doesn't define those two symbols. It defines these: #define FT_CONFIG_CONFIG_H <freetype/config/ftconfig.h> #define FT_CONFIG_OPTIONS_H <freetype/config/ftoption.h> #define FT_CONFIG_MODULES_H <freetype/config/ftmodule.h> #define FT_FREETYPE_H <freetype/freetype.h> #define FT_ERRORS_H <freetype/fterrors.h> #define FT_SYSTEM_H <freetype/ftsystem.h> #define FT_IMAGE_H <freetype/ftimage.h> #define FT_TYPES_H <freetype/fttypes.h> #define FT_LIST_H <freetype/ftlist.h> #define FT_OUTLINE_H <freetype/ftoutln.h> #define FT_MODULE_H <freetype/ftmodule.h> #define FT_RENDER_H <freetype/ftrender.h> #define FT_TYPE1_TABLES_H <freetype/t1tables.h> #define FT_TRUETYPE_IDS_H <freetype/ttnameid.h> #define FT_TRUETYPE_TABLES_H <freetype/tttables.h> #define FT_TRUETYPE_TAGS_H <freetype/tttags.h> #define FT_GLYPH_H <freetype/ftglyph.h> #define FT_BBOX_H <freetype/ftbbox.h> #define FT_BEZIER_H <freetype/ftbezier.h> #define FT_CACHE_H <freetype/ftcache.h> #define FT_CACHE_IMAGE_H <freetype/cache/ftcimage.h> #define FT_CACHE_SMALL_BITMAPS_H <freetype/cache/ftcsbits.h> #define FT_MAC_H <freetype/ftmac.h> #define FT_MULTIPLE_MASTERS_H <freetype/ftmm.h> #define FT_SFNT_NAMES_H <freetype/ftsnames.h> #define FT_TRIGONOMETRY_H <freetype/fttrigon.h> #define FT_SYNTHESIS_H <freetype/ftsynth.h> #define FT_CACHE_MANAGER_H <freetype/cache/ftcmanag.h> #define FT_CACHE_INTERNAL_LRU_H <freetype/cache/ftlru.h> #define FT_CACHE_INTERNAL_GLYPH_H <freetype/cache/ftcglyph.h> #define FT_CACHE_INTERNAL_CHUNK_H <freetype/cache/ftcchunk.h> #define FT_INTERNAL_INTERNAL_H <freetype/internal/internal.h> So FT_TRUETYPE_TABLES_H and FT_GLYPH_H is covered, but FT_NAMES_H and FT_TRUETYPE_NAMES_H is not. Apparently the defines were changed or something - FT_SFNT_NAMES_H is apparently the one you must use now?

May 30, 2001

Re: wineps include fix.

by Ove Kaaven

On Wed, 30 May 2001, Ian Pilcher wrote: > You're getting the error because FreeType's macros are not being defined > by your include files. This is supposed to be the way to work around > the > fact that the FreeType guys rename their include files with every minor > release. > > freetype/freetype.h should either define the macros or include another > file that does so. If you can figure out why that isn't happening, let > me know. It is happening, ftheader.h just doesn't define those two symbols. It defines these: #define FT_CONFIG_CONFIG_H <freetype/config/ftconfig.h> #define FT_CONFIG_OPTIONS_H <freetype/config/ftoption.h> #define FT_CONFIG_MODULES_H <freetype/config/ftmodule.h> #define FT_FREETYPE_H <freetype/freetype.h> #define FT_ERRORS_H <freetype/fterrors.h> #define FT_SYSTEM_H <freetype/ftsystem.h> #define FT_IMAGE_H <freetype/ftimage.h> #define FT_TYPES_H <freetype/fttypes.h> #define FT_LIST_H <freetype/ftlist.h> #define FT_OUTLINE_H <freetype/ftoutln.h> #define FT_MODULE_H <freetype/ftmodule.h> #define FT_RENDER_H <freetype/ftrender.h> #define FT_TYPE1_TABLES_H <freetype/t1tables.h> #define FT_TRUETYPE_IDS_H <freetype/ttnameid.h> #define FT_TRUETYPE_TABLES_H <freetype/tttables.h> #define FT_TRUETYPE_TAGS_H <freetype/tttags.h> #define FT_GLYPH_H <freetype/ftglyph.h> #define FT_BBOX_H <freetype/ftbbox.h> #define FT_BEZIER_H <freetype/ftbezier.h> #define FT_CACHE_H <freetype/ftcache.h> #define FT_CACHE_IMAGE_H <freetype/cache/ftcimage.h> #define FT_CACHE_SMALL_BITMAPS_H <freetype/cache/ftcsbits.h> #define FT_MAC_H <freetype/ftmac.h> #define FT_MULTIPLE_MASTERS_H <freetype/ftmm.h> #define FT_SFNT_NAMES_H <freetype/ftsnames.h> #define FT_TRIGONOMETRY_H <freetype/fttrigon.h> #define FT_SYNTHESIS_H <freetype/ftsynth.h> #define FT_CACHE_MANAGER_H <freetype/cache/ftcmanag.h> #define FT_CACHE_INTERNAL_LRU_H <freetype/cache/ftlru.h> #define FT_CACHE_INTERNAL_GLYPH_H <freetype/cache/ftcglyph.h> #define FT_CACHE_INTERNAL_CHUNK_H <freetype/cache/ftcchunk.h> #define FT_INTERNAL_INTERNAL_H <freetype/internal/internal.h> So FT_TRUETYPE_TABLES_H and FT_GLYPH_H is covered, but FT_NAMES_H and FT_TRUETYPE_NAMES_H is not. Apparently the defines were changed or something - FT_SFNT_NAMES_H is apparently the one you must use now?

May 30, 2001

WINE server messages

by David Howells

Hello Alexandre, I'm having a little trouble deciding exactly how to emulate the "module registration" functionality in my kernel module. It occurs to me that this might be easier to accomplish with a change to the current wine server message set. My idea is: * Have the server only deal with NT Section objects and views of Sections. * Have no separate module table attached to a process. * Implement NtQuerySectionInformation/NtSetSectionInformation calls (or whatever they're called) as wineserver messages. * Add an extra Wine-specific information class for the purpose of recording the extra module information. * The wineserver process structure can then be changed so that rather than keeping a separate list of process_dlls, they can just keep a list of section views, some of which will be images/modules. David

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

David Hammerton wrote: > > hi, seems you have done some updating on it.. but now it still doesnt compile, > im not sure if your trying to include something that is defined elsewhere or > you made a typo, but it seems to bawk on: > > gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -g -O2 > -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT > -I/usr/X11R6/include -o truetype.o truetype.c > truetype.c:13: `#include' expects "FILENAME" or <FILENAME> > truetype.c:14: `#include' expects "FILENAME" or <FILENAME> > I give up. You're getting the error because FreeType's macros are not being defined by your include files. This is supposed to be the way to work around the fact that the FreeType guys rename their include files with every minor release. freetype/freetype.h should either define the macros or include another file that does so. If you can figure out why that isn't happening, let me know. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 30, 2001

Re: some unimplemented COM stuff

by Malte.Starostik＠t-online.de

On Mittwoch, 30. Mai 2001 07:46, Marcus Meissner wrote: > On Wed, May 30, 2001 at 04:32:19AM +0200, Malte Starostik wrote: > > Well, that was just the first thing that came to mind. Assembler was the > > second. I somehow didn't even think of a plain function pointer - well > > yes, I am more used to C++ than C :) > > Of course it's kinda hard to initialize a C++ method pointer from a > > vtable offset. Anyway, it should be implemented in winelib and not in my > > app, so it's not feasible after all. > > But that doesn't matter now that I realized a full implementation will > > probably need assembler as the number of arguments is virtually > > unlimited. So an array of parameters that is copied to the stack via > > inline assembler is IMHO the way to go. Will give it a try. > > ? > > Why can't you use the WINE supplied macros INTERFACE_FUNCTION? > > IDispatch_Invoke(ptr,arg1,arg2,.......); > > They should be defined to the correct C++ method calls. Because all I have is an IDispatch pointer and a vtable offset to the method. Calling Invoke itself is not a problem at all. The method to be called by Invoke isn't known at compile time. -Malte -- Wars don't determine who's right, only who's left.

May 30, 2001

Re: some unimplemented COM stuff

by Marcus Meissner

On Wed, May 30, 2001 at 04:32:19AM +0200, Malte Starostik wrote: > On Mittwoch, 30. Mai 2001 03:33, Ove Kaaven wrote: > > On Wed, 30 May 2001, Malte Starostik wrote: > > > On Mittwoch, 30. Mai 2001 00:39, Ove Kaaven wrote: > > > > On Mon, 28 May 2001, Malte Starostik wrote: > > > > > unfortunately g++ doesn't support specifying a calling convention for > > > > > method pointers like HRESULT (IDispatch::*setProp)(BSTR). > > > > > > > > Since when? The construct HRESULT CALLBACK (*stuff)(...) is used all > > > > over the Wine headers, so I'd think someone would have noticed if g++ > > > > didn't support it... > > > > > > HRESULT CALLBACK (*stuff)(...) > > > works indeed. I only tried > > > HRESULT CALLBACK (IFooBar::*stuff)(...) > > > which yields: > > > warning: `stdcall' attribute directive ignored > > > and results in stack corruption then I ignore this warning. > > > > Can you explain why you do this, then? I can't imagine why you would want > > to declare a method pointer like this. > Well, that was just the first thing that came to mind. Assembler was the > second. I somehow didn't even think of a plain function pointer - well yes, I > am more used to C++ than C :) > Of course it's kinda hard to initialize a C++ method pointer from a vtable > offset. Anyway, it should be implemented in winelib and not in my app, so > it's not feasible after all. > But that doesn't matter now that I realized a full implementation will > probably need assembler as the number of arguments is virtually unlimited. So > an array of parameters that is copied to the stack via inline assembler is > IMHO the way to go. Will give it a try. ? Why can't you use the WINE supplied macros INTERFACE_FUNCTION? IDispatch_Invoke(ptr,arg1,arg2,.......); They should be defined to the correct C++ method calls. Ciao, Marcus

May 30, 2001

Status of ASPI?

by Dax Kelson

> > 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? Many thanks! Dax

May 30, 2001

Re: some unimplemented COM stuff

by Malte.Starostik＠t-online.de

On Mittwoch, 30. Mai 2001 03:33, Ove Kaaven wrote: > On Wed, 30 May 2001, Malte Starostik wrote: > > On Mittwoch, 30. Mai 2001 00:39, Ove Kaaven wrote: > > > On Mon, 28 May 2001, Malte Starostik wrote: > > > > unfortunately g++ doesn't support specifying a calling convention for > > > > method pointers like HRESULT (IDispatch::*setProp)(BSTR). > > > > > > Since when? The construct HRESULT CALLBACK (*stuff)(...) is used all > > > over the Wine headers, so I'd think someone would have noticed if g++ > > > didn't support it... > > > > HRESULT CALLBACK (*stuff)(...) > > works indeed. I only tried > > HRESULT CALLBACK (IFooBar::*stuff)(...) > > which yields: > > warning: `stdcall' attribute directive ignored > > and results in stack corruption then I ignore this warning. > > Can you explain why you do this, then? I can't imagine why you would want > to declare a method pointer like this. Well, that was just the first thing that came to mind. Assembler was the second. I somehow didn't even think of a plain function pointer - well yes, I am more used to C++ than C :) Of course it's kinda hard to initialize a C++ method pointer from a vtable offset. Anyway, it should be implemented in winelib and not in my app, so it's not feasible after all. But that doesn't matter now that I realized a full implementation will probably need assembler as the number of arguments is virtually unlimited. So an array of parameters that is copied to the stack via inline assembler is IMHO the way to go. Will give it a try. -Malte -- Wars don't determine who's right, only who's left.

May 30, 2001

Re: some unimplemented COM stuff

by Ove Kaaven

On Wed, 30 May 2001, Malte Starostik wrote: > On Mittwoch, 30. Mai 2001 00:39, Ove Kaaven wrote: > > On Mon, 28 May 2001, Malte Starostik wrote: > > > unfortunately g++ doesn't support specifying a calling convention for > > > method pointers like HRESULT (IDispatch::*setProp)(BSTR). > > > > Since when? The construct HRESULT CALLBACK (*stuff)(...) is used all over > > the Wine headers, so I'd think someone would have noticed if g++ didn't > > support it... > HRESULT CALLBACK (*stuff)(...) > works indeed. I only tried > HRESULT CALLBACK (IFooBar::*stuff)(...) > which yields: > warning: `stdcall' attribute directive ignored > and results in stack corruption then I ignore this warning. Can you explain why you do this, then? I can't imagine why you would want to declare a method pointer like this.

May 30, 2001

set_thread_buffer

by gerard patel

Since the commits of last night, every app I have tried only says : wine client error:0x80675a8: set_thread_buffer failed with status c000000d with apps that usually work fine. Gerard

May 29, 2001

Re: some unimplemented COM stuff

by Malte.Starostik＠t-online.de

On Mittwoch, 30. Mai 2001 00:39, Ove Kaaven wrote: > On Mon, 28 May 2001, Malte Starostik wrote: > > unfortunately g++ doesn't support specifying a calling convention for > > method pointers like HRESULT (IDispatch::*setProp)(BSTR). > > Since when? The construct HRESULT CALLBACK (*stuff)(...) is used all over > the Wine headers, so I'd think someone would have noticed if g++ didn't > support it... HRESULT CALLBACK (*stuff)(...) works indeed. I only tried HRESULT CALLBACK (IFooBar::*stuff)(...) which yields: warning: `stdcall' attribute directive ignored and results in stack corruption then I ignore this warning. So it seems it accepts __attribute__ ((stdcall)) for function pointers but not method pointers :( -Malte -- Wars don't determine who's right, only who's left.

May 29, 2001

Re: some unimplemented COM stuff

by Ove Kaaven

On Mon, 28 May 2001, Malte Starostik wrote: > unfortunately g++ doesn't support specifying a calling convention for method > pointers like HRESULT (IDispatch::*setProp)(BSTR). Since when? The construct HRESULT CALLBACK (*stuff)(...) is used all over the Wine headers, so I'd think someone would have noticed if g++ didn't support it...

May 29, 2001

PATCH: GetX11WindowId()

by Nikolas Zimmermann

Hi there, this is my first wine patch. it allows the coder to get the X11 Window Id of a HWND. People ask me why this belongs into x11drv and why i need it. ActiveX support for Konqueror, Malte Starostik (who will post some oleaut and urlmon patches soon) and me are working on this. I need to embed the created window, therefore i need this window id. Thank you in advance Bye Bye Niko -- Nikolas Zimmermann wildfox(a)kde.org

May 29, 2001

Re: some unimplemented COM stuff

by James Hatheway

Hi Malte, We (Macadamian) were working on implementing oleaut32.dll, if you search the archives of WINE HQ around dec 2000 / jan 2001 you can see some of the patches that we submitted. Unfortunately, work has been shelved for the moment, but there is a starting point for you. For IDispatch::Invoke / ITypeInfo::Invoke, there is a patch at: http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/archives/2000-12/… As well please see discussion of patch at: http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2001-01/da… (with reasons why it wasn't committed, search for "invoke") As for your other issues: > - typelib registration Requires adding some registry entries. Not too bad, pretty much any COM book will tell you all you need to do. > - IDispatch::Invoke() See above > - RegisterBindStatusCallback() and probably asyncronous bind contexts Hummm... no idea. > - probably a "real" URL Moniker, not just CreateURLMoniker() using a File > Moniker See the Brockschmidt book. Have fun. :-) Seriously, I don't think anyone has done any work on this one or is currently working on this besides the stubbed DLL that is in the tree. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com Funniest Definition found in a Japanese<->English Dictionary so far: Moose: Amerika Ushi (American Cow) (should be: mu-su in katakana)

May 29, 2001

PATCH: Re: PathGetCharType/PathGetCharTypeA

by Marcus Meissner

On Mon, May 28, 2001 at 10:32:01PM -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 > I'm a perl guy, but I'm learning C. Maybe I'm naive, but fleshing out the > Wine version of this function shouldn't be too hard it seems. You'd have > to go track down the rules. > Can some point me in the right direction on fixing this up? Can someone > give me a quick hack to make my application work? You just have to guess sometimes too ;) I did a quick implementation of it, which might not be quite correct. Ciao, Marcus Changelog: First try at implementing PathGetCharType() Index: include/shlwapi.h =================================================================== RCS file: /home/wine/wine/include/shlwapi.h,v retrieving revision 1.13 diff -u -r1.13 shlwapi.h --- include/shlwapi.h 2001/02/12 01:29:08 1.13 +++ include/shlwapi.h 2001/05/29 06:08:36 @@ -8,6 +8,13 @@ #endif /* defined(__cplusplus) */ +/* Mask returned by GetPathCharType */ +#define GCT_INVALID 0x0000 +#define GCT_LFNCHAR 0x0001 +#define GCT_SHORTCHAR 0x0002 +#define GCT_WILD 0x0004 +#define GCT_SEPARATOR 0x0008 + /* * The URL_ defines were determined by trial and error. If they become * documented please check them and add the missing ones including: Index: dlls/shlwapi/path.c =================================================================== RCS file: /home/wine/wine/dlls/shlwapi/path.c,v retrieving revision 1.6 diff -u -r1.6 path.c --- dlls/shlwapi/path.c 2001/01/07 21:50:53 1.6 +++ dlls/shlwapi/path.c 2001/05/29 06:08:38 @@ -1617,8 +1617,23 @@ */ UINT WINAPI PathGetCharTypeA(UCHAR ch) { - FIXME("%c\n", ch); - return 0; + UINT flags = 0; + + TRACE("%c\n", ch); + + /* We could use them in filenames, but this would confuse 'ls' */ + if (iscntrl(ch)) + return GCT_INVALID; + if ((ch == '*') || (ch=='?')) + return GCT_WILD; + if ((ch == '\\') || (ch=='/')) + return GCT_SEPARATOR; + flags = 0; + /* all normal characters, no lower case letters */ + if ((ch > ' ') && (ch < 0x7f) && !islower(ch)) + flags |= GCT_SHORTCHAR; + /* All other characters are valid in long filenames, even umlauts */ + return flags | GCT_LFNCHAR; } /************************************************************************* @@ -1626,8 +1641,8 @@ */ UINT WINAPI PathGetCharTypeW(WCHAR ch) { - FIXME("%c\n", ch); - return 0; + FIXME("%c, using ascii version\n", ch); + return PathGetCharTypeA(ch); } /*************************************************************************

May 29, 2001

PathGetCharType/PathGetCharTypeA

by Dax Kelson

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 And apps reports "such such character isn't valid", and doesn't continue (each time I try again, it generates another fixme message). According to MSDN: http://msdn.microsoft.com/library/psdk/shellcc/shell/SHLWAPI/Path/PathGetCh… PathGetCharType/PathGetCharTypeA part of shlwapi.h returns one or more of the following values that define the type of character: GCT_INVALID The character is not valid in a path. GCT_LFNCHAR The character is valid in a long file name. GCT_SEPARATOR The character is a path separator. GCT_SHORTCHAR The character is valid in a short (8.3) file name. GCT_WILD The character is a wildcard character. This is the current Wine code: /************************************************************************* * PathGetCharTypeA [SHLWAPI.@] */ UINT WINAPI PathGetCharTypeA(UCHAR ch) { FIXME("%c\n", ch); return 0; } I'm a perl guy, but I'm learning C. Maybe I'm naive, but fleshing out the Wine version of this function shouldn't be too hard it seems. You'd have to go track down the rules. Can some point me in the right direction on fixing this up? Can someone give me a quick hack to make my application work? Many thanks, Dax

May 29, 2001

Re: some unimplemented COM stuff

by Malte.Starostik＠t-online.de

On Montag, 28. Mai 2001 22:19, Malte Starostik wrote: > Anyway, what I'd basically need to get this to work properly is > - typelib registration As a start I gave RegisterTypeLib() a try. There are a few things I'm uncertain about, but for the typelibs I tried the resulting registry entries match the ones windows generates. -Malte -- Wars don't determine who's right, only who's left.

May 29, 2001

Re: Small fixes in controls/menu.c

by kenon＠go2.pl

On Mon, May 28, 2001 at 10:45:56PM +0200, gerard patel wrote: <snip> > > All right, I still can't see this bad redrawing , but I can see the menu not > accessible behaviour now. > I'll try to understand something in this problem this week. Let me know what is wrong with my patches , so I can try to do something with this problem. > Btw, this app does not work at all for me in managed mode, it hangs after > displaying the splash screen. (but sm7.exe - version 7.5 and sm99.exe - version 9 > both load). I think it's an unrelated problem though since it happens with my > oldest wine version (20000801) and it's not fixed by your patch. > In my sandbox wine(20010510) every thing works well (sm8.exe in managed mode. ) --

May 28, 2001

Re: Small fixes in controls/menu.c

by gerard patel

At 10:46 PM 25/05/2001 +0200, you wrote: >I downloaded ftp://ftp.supermemo.com/ftp/sm8zip.exe and managed to >reproduce the bug. (WINE version 20010510) >The way: >1) Using mouse chose File>SuperMemo >2) When app changes its mode click at capition of window >"Contents: E:\SM8\SYSTEMS\SUPERMEMO" >And now main menu is inaccesible (using mouse) >When you force wine to repaint all windows (eg. switch to linux console >and back to X-Window ) you can see menu is drawn up 10-20 pixels than >it should. All right, I still can't see this bad redrawing , but I can see the menu not accessible behaviour now. I'll try to understand something in this problem this week. Btw, this app does not work at all for me in managed mode, it hangs after displaying the splash screen. (but sm7.exe - version 7.5 and sm99.exe - version 9 both load). I think it's an unrelated problem though since it happens with my oldest wine version (20000801) and it's not fixed by your patch. Gerard

May 28, 2001

some unimplemented COM stuff

by Malte.Starostik＠t-online.de

Hello, I have started implementing a small winelib-program that shall eventually add ActiveX support to the Konqueror web browser. For testing I'm using the Shockwave Flash OCX and experienced some problems due to unimplemented functions and features in winelib. First thing is typelib registration, which doesn't work yet as the debug output tells. Okay, did that manually. Then, for setting the control's properties, I tried the easy way via IDispatch::Invoke(), which calls ITypeInfo::Invoke() and that's only a stub :( I worked around this via evil assembler hacks to call the interface's members as given by the vtable offsets in the FUNCDESC using stdcall convention - unfortunately g++ doesn't support specifying a calling convention for method pointers like HRESULT (IDispatch::*setProp)(BSTR). After getting this to work, I hit the next problem: unimplemented urlmon.RegisterBindStatusCallback and when I use a native urlmon.dll it tries to call shlwapi.154, with native shlwapi it still doesn't work somehow, but that's a different story. Anyway, what I'd basically need to get this to work properly is - typelib registration - IDispatch::Invoke() - RegisterBindStatusCallback() and probably asyncronous bind contexts - probably a "real" URL Moniker, not just CreateURLMoniker() using a File Moniker What I'd like to know is if anyone is already working on any of these and if so what's the status and how I could help getting these implemented. if no one started yet, I'd still like to give it a try. Thanks, -Malte PS: the attached patch fixes urlmon.h not being C++-safe. -- Wars don't determine who's right, only who's left.

May 28, 2001

a tool: simple C++ interface definition -> ICOM_ macro converter.

by TAKESHIMA Hidenori

This program may help creating ICOM_ macro. (but this code doesn't have portability, so some modification may be required.) for example, if give the following codes to stdin, we gets ICOM_ macros for IPersist. class IUnknown { public: HRESULT QueryInterface( REFIID riid, LPVOID *ppvObj) ; ULONG AddRef() ; ULONG Release() ; }; export interface IPersist : public IUnknown { virtual HRESULT STDMETHODCALLTYPE GetClassID( CLSID *pClassID ); };

May 28, 2001

Wrc patch

by kenon＠go2.pl

Hi, This patch is an answer for "Call for volunteers". I hope it fixes : "wrc fails on preprocessed files" #115: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=115 Maciek Changelog * tools/wrc/ppy.y Maciek Kaliszewski <kenon(a)go2.pl> Added better GCC-style #line directive handling. --

May 28, 2001

Enabling backing store

by David Hagood

Has any thought been given to enabling backing store on Wine's windows? As it stands now, when you obscure a Wine window, it forces the Windows app to redraw the screen. Many times this is not needed. Perhaps a configuration option to allow certain apps to have backing store on would be useful. I know that up until a few months ago, it was possible to go into wnd.c and change the default from NotUseful to WhenMapped and things seemed to work well. However, the structure of the X driver has changed, and a simple patch is no longer possible.

May 27, 2001

Re: X Error with latest Wine and Notes

by Ian Pilcher

David.Goodenough(a)dga.co.uk wrote: > > I have noticed that with the latest Wine (May drop) I have started to get X > Errors. This typically happens as a dialog is being dismissed. > > The latest of these errors read:-- > > X Error of failed request: BadWindow (invalid Window parameter) > Major opcode of failed request: 12 (X_ConfigureWindow) > Resource if in failed request: 0x1c24350 > Serial number of failed request: 9920 > Current serial number in output stream: 9922 > > I get the feeling, although I can not prove it, that this may be timing > related, as it tends to happen when I am a bit quick completing the dialog. > The other odd thing that happens when this occurs is that a second copy of > the window, not the detail face of the window, just the window and its > frame controls, is drawn slightly down and right of the original window, > then it blows and Notes hangs. > > I had not noticed this behaviour before switching to the May drop. There > are no other console messages that are out of the ordinary set that I have > been reporting for a while. > > Is this a known problem? David - I have also seen this problem, but I have no idea what causes it. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 27, 2001

Re: Q: anybody using Exceed on NT4 as X server for wine?

by Stefan Leichter

Heiko Nardmann wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Is there anybody out there who uses Exceed on NT4 as the X server to display > wine applications (like winemine from examples) which have been started on > Linux? > > If yes are did you try 20010510 snapshot (or CVS) to run your applications? > > If yes could you provide me with your configuration files? I am still not > able to start winemine since snapshot 20010418 (20010326 works fine). > Hello, i am able to run programs on a remote computer using Exceed for NT4. I tried FREECELL and regw32.exe (www.heise.de) I have started the programs from an xterm, maybe this is not what you like to do. With the attached xstart file i am also able to run freecell directly. But if i remove /usr/bin/X11/xtern from the xstart file the program terminates after some minutes. Bye Stefan [Xstart] Start Method=4 Program Type=0 User Id=sle Password= Command=export DISPLAY=sle2:0 ; /usr/bin/X11/xterm -ls -e wine -- 'D:\FREECELL\FREECELL.EXE' 2>&1 | tee /wine_app/tmp/freecell.log Info Prompt=0 Description=Freecell(a)sle3 Host=sle3 Connect Timeout=1 Close Timeout=50 Response Timeout=4 Prompt Timeout=2 Show Progress=1 Log Reply=0 UserId Prompt=login:|Username: Password Prompt=password:

May 26, 2001

Re: AFM files no longer required

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > Here's a thought. How about creating a data subdirectory for the Post- > Script driver (i.e. dlls/wineps/data). The data could then be put in > separate files in that directory without confusing things. (The data > isn't interdependent from a build point of view, just from a main- > tenance point of view.) > > I don't know the Makefile magic necessary to do this, but if someone > could step forward with that piece, I suspect it would address both of > our concerns. > > What do you think? That's certainly a viable solution yes. If you send me a patch implementing the separate files I'll do the Makefile magic. -- Alexandre Julliard julliard(a)winehq.com

May 25, 2001

Re: AFM files no longer required

by Ian Pilcher

Here's a thought. How about creating a data subdirectory for the Post- Script driver (i.e. dlls/wineps/data). The data could then be put in separate files in that directory without confusing things. (The data isn't interdependent from a build point of view, just from a main- tenance point of view.) I don't know the Makefile magic necessary to do this, but if someone could step forward with that piece, I suspect it would address both of our concerns. What do you think? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 25, 2001

Re: AFM files no longer required

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > I actually gave quite a bit of thought to the large file issue before > submitting it, and I would agree with you if there were any functional > code in the file. Because it's entirely data, and it's heavily > interdependent, I really think that one file is better. I disagree. If the data is so interdependent that you cannot split the file, you are doing something wrong IMO. And in fact splitting it will help enforce a clean data structure, which is a major advantage. > From a build point of view, gcc has no problem at all with the file. In > fact it compiles much faster than many of Wine's functional files. I know some older versions of gcc had problems with large data structures, using exponential memory to compile them or something like that. > If a > target compiler (does Wine build with anything other than gcc?) does have > a problem with it, I will yield to necessity. Until that happens, how- > ever, I believe that the practical benefit of maintainability outweighs > stylistic concerns. (After all, it's not like anyone will ever need to > read all the way through the file to understand it, as is the case with > functional code.) You may not need to read every single line, but you still need to go through it if you want to understand the structure (this is how I noticed it was too large...). So please consider splitting it. -- Alexandre Julliard julliard(a)winehq.com

May 25, 2001

Re: AFM files no longer required

by Ian Pilcher

Forgot to cc wine-devel. Alexandre Julliard wrote: > > You should really split it into separate files, a 40,000 lines file is > a bit too much. Also all this data must be constant and in a read-only > section, it's eating 400k of data space right now. I actually gave quite a bit of thought to the large file issue before submitting it, and I would agree with you if there were any functional code in the file. Because it's entirely data, and it's heavily interdependent, I really think that one file is better. (As the person most likely be tweaking the data in the near future, I can tell you that having a single file to edit, albeit a long one, will be heck of a lot easier than having 39 separate files, and isn't that really the point?) >From a build point of view, gcc has no problem at all with the file. In fact it compiles much faster than many of Wine's functional files. If a target compiler (does Wine build with anything other than gcc?) does have a problem with it, I will yield to necessity. Until that happens, how- ever, I believe that the practical benefit of maintainability outweighs stylistic concerns. (After all, it's not like anyone will ever need to read all the way through the file to understand it, as is the case with functional code.) I would like to make the data constant, but that would require major surgery to afm.c, which is more than I can take on at this point. Keep in mind that the same amount of memory is being used currently; it's just dynamically allocated as the AFM files are read in. > > I'm guessing that you have a script to generate all this; could you > please consider submitting it? This way other people can make changes > too. > I have attached the two programs I use to generate agl.c. I have always intended to submit them, but didn't know where in the source tree to put them. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 25, 2001

Re: critical section blocking

by Duane Clark

Aric Stewart wrote: > > Working with QuickTime5 I found a situation where mouse messages could > lockup wine. This leaving and entering the critical section resolves > that bug. > > -aric > > ------------------------------------------------------------------------ > Index: windows/message.c > =================================================================== > RCS file: /home/wine/wine/windows/message.c,v With this patch, Myst locks up solid as soon as the mouse is moved into the Myst window. Without it, Myst works fine. Duane

May 25, 2001

Re: Small fixes in controls/menu.c

by kenon＠go2.pl

On Wed, May 23, 2001 at 12:11:28AM +0200, gerard patel wrote: > > Btw, I have downloaded several of the availables app on your web site > and I don't see anything wrong with menus; IIRC I have tried 7.5 for > Win3.11, and trial versions 8 and 9 (32 bits). Is it with the main menu > that you see this problem ? > I downloaded ftp://ftp.supermemo.com/ftp/sm8zip.exe and managed to reproduce the bug. (WINE version 20010510) The way: 1) Using mouse chose File>SuperMemo 2) When app changes its mode click at capition of window "Contents: E:\SM8\SYSTEMS\SUPERMEMO" And now main menu is inaccesible (using mouse) When you force wine to repaint all windows (eg. switch to linux console and back to X-Window ) you can see menu is drawn up 10-20 pixels than it should. --

May 25, 2001

Re: Unused OPTIONS variable in configure.in

by Alexandre Julliard

Fran=E7ois Gouget <fgouget(a)codeweavers.com> writes: > I noticed that OPTIONS is not used anymore in 'configure.in'. I > believe it may have been used to store the --enable-* stuff at one ti= me > but AFAIU this is now stored in 'config.h'. So I propose to remove it > altogether. Or is it set as a side effect of some standard autoconf > macro on some exotic system? It's here so that you can specify extra flags that configure doesn't know about, by doing OPTIONS=3D-Dfoo ./configure. This can be useful in some cases. --=20 Alexandre Julliard julliard(a)winehq.com

May 25, 2001

Re: AFM files no longer required

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > I decided to put all of the data into dlls/wineps/agl.c, since changing > the glyph list data without regenerating the font metrics data would > cause things to break in extremely bizarre ways. (Well, it will once I > actually use the glyph names.) You should really split it into separate files, a 40,000 lines file is a bit too much. Also all this data must be constant and in a read-only section, it's eating 400k of data space right now. I'm guessing that you have a script to generate all this; could you please consider submitting it? This way other people can make changes too. -- Alexandre Julliard julliard(a)winehq.com

May 25, 2001

Re: Strange Wine Problems

by r.maurizzi＠gvs.it

That's the same kernel problem that plagues Lotus Notes (If I've understood correctly the message in German ;-) Lotus Notes will die with the same problem if you use a SuSE 7.0 with SuSE kernel 2.2.18 (Mandrake kernels have the same problem, according to other people here) If you compile the kernel yourself starting from ftp.kernel.org's sources, all is well (at least for Notes). I didn't try SuSE Kernels 2.2.19 / 2.4.2 however. Ciao, Roberto.

May 25, 2001

Re: PATCH: mirc dcc send

by Dmitry Timoshkov

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > + /* This might be a DOS device we do not handle yet ... */ > + FIXME("(%) not detected as DOS device!\n",devname); ^^^ Seems a typo to me.

May 25, 2001

Strange Wine Problems

by Josef.Wegner＠t-online.de

Hi, I have some strange errors with wine the last few weeks. Everytime I try to start an application (mainly Ultima Online and Baldur's Gate) wine crashes (stops) with this errors: >wine client.exe For language 'german' several language ids were found: de_DE - 0407; de_CH - 0807; de_LU - 1007; de_LI - 1407; Instead of using first in the list, suggest to define your LANG environment variable like this: LANG=de_DE Protocol error:0x8071580: read : Die Ressource ist zur Zeit nicht verfügbar fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403938fc,00000138,3):stub fixme:pthread_kill_other_threads_np For language 'german' several language ids were found: de_DE - 0407; de_CH - 0807; de_LU - 1007; de_LI - 1407; Instead of using first in the list, suggest to define your LANG environment variable like this: LANG=de_DE Protocol error:0x8067660: read : Die Ressource ist zur Zeit nicht verfügbar Beendet Protocol error:0x8075258: read : Die Ressource ist zur Zeit nicht verfügbar I don't know what the problem is. My first thought was that I have problems with my sound drivers (Alsa 0.5.11) , so I tried the kernel emu10k1 driver and after that I loaded no sound module. All with the same result. The only other thing I did with my linux installation was upgrading to a 2.2.18 kernel. My system specs: Latest wine cvs SuSE Linux 7.0 All updates from Suse.com (new glibc 2.1.3) Kernel 2.2.18 (SMP) Alsa 0.5.11 KDE 2.1.1 Xfree86 4.0.3 (Ximera on) Dual PIII 500Mhz 384 MB Ram Adaptec AIC-7880 Ultra SCSI host adapter Matrox G400 Max Dualhead SoundBlaster Live! Value Regards -Josef Wegner

May 25, 2001

Q: anybody using Exceed on NT4 as X server for wine?

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there anybody out there who uses Exceed on NT4 as the X server to display wine applications (like winemine from examples) which have been started on Linux? If yes are did you try 20010510 snapshot (or CVS) to run your applications? If yes could you provide me with your configuration files? I am still not able to start winemine since snapshot 20010418 (20010326 works fine). - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7DgpMpm53PRScYygRAn6cAKDaQl3Tm4l/sIe9cQoRbdwo7vf7bwCg8gm5 38OwXBWHUxJVc1ZV91iywRY= =CjPM -----END PGP SIGNATURE-----

May 25, 2001

Re: More wine beginner questions

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > So according to the dll separation rules we must not make msvcrt > depend on an API not exported by a regular windows dll. But in the case > of ntdll I'm not sure. Can we use native ntdll in Wine? I don't think so > since it also exports things like 'wine_dbgstr_[aw]n?'. So maybe we can > bend the rules a little and export _vsnwprintf anyway. A better solution would be to put the *wprintf functions inside libwine_unicode. -- Alexandre Julliard julliard(a)winehq.com

May 23, 2001

Re: More wine beginner questions

by Francois Gouget

On Wed, 23 May 2001, Mike Bond wrote: > I was just perusing through msvcrt and noticed that in wcs.c there is > an implementation of _vsnwprintf, which also exists, verbatim, in it's > entirety, in ntdll/wcstring.c. Unless I am misunderstanding the .spec > files there appears to be a method of "forward"ing a symbol to an > external implementation, such as: > > @ forward -noimport wcslen ntdll.wcslen > > Is there any particular reason this was not done for _vsnwprintf as well? The problem is that _vsnwprintf is not exported by ntdll. On Win9x I don't see any *printf function in ntdll. But on Win2000 there is: _snprintf, _snwprintf, _vsnprintf, sprintf, swprintf and vsprintf. But no _vsnwprintf. So according to the dll separation rules we must not make msvcrt depend on an API not exported by a regular windows dll. But in the case of ntdll I'm not sure. Can we use native ntdll in Wine? I don't think so since it also exports things like 'wine_dbgstr_[aw]n?'. So maybe we can bend the rules a little and export _vsnwprintf anyway. Better ask Alexandre... [...] > Also, on perhaps a style note, I've noticed some implementations are > prefixed by the dll name in all caps, such as MSVCRT_vfprintf, and some > are not, such as _wmkdir. Is this just personal style or is there more > to these differences? There's more to it. Here are the MSVCRT conventions: * any function name which may conflict with a regular C function is prefixed with 'MSVCRT_'. In particular this includes all functions that don't start with '_'. Example: vfprintf -> MSVCRT_vfprintf _errno -> MSVCRT__errno (exception) * Any function name that will not conflict with a regular C function name is not prefixed. This includes most functions starting with a single '_'. Example: _access -> _access _wchmod -> _wchmod * Internal functions are prefixed by 'msvcrt_', but I'm not sure I renamed strictly all of them (so there might still be internal functions prefixed with 'MSVCRT_'). (I say function but it's really any symbol) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

May 23, 2001

Finding (or not) the exact number of args

by Gaël de Chalendar

Hi, I'm trying to implement stubs for some missing ordinal functions in shlwapi. Reading the NOTES comment in dlls/shlwapi/ordinal.c I don't know if it is a good idea, but it allows explorer.exe (Win 98) to show its desktop and it is what I'm testing (just for fun. I do not hope to be able to use it right now). Anyway, it uses at a moment or another unimplemented ordinal functions. To implement their stubs, I begins with a lot of args, reducing this number until the function is passed. It seems to work but I wonder if I do not add only problems with this strategy. If I left the stack in a corrupted state, maybe the problem will become visible a lot later... I was not able to find in docs, mails archives or google groups any useful tip to find (simply) the right number of args. Particularly, the URL http://www.ece.cmu.edu/afs/ece/usr/dacut/www/src is dead. So, do I continue ? If yes, in this way or differently ? Thanks for your advices. Gael. PS: I will not read my mail until monday 28.

May 23, 2001

Re: Finding (or not) the exact number of args

by 520053692817-0001＠t-online.de

On Wed, May 23, 2001 at 06:01:51PM +0000, Gaël de Chalendar wrote: [...] > Anyway, it uses at a moment or another unimplemented ordinal functions. To > implement their stubs, I begins with a lot of args, reducing this number > until the function is passed. It seems to work but I wonder if I do not add > only problems with this strategy. If I left the stack in a corrupted state, > maybe the problem will become visible a lot later... > I was not able to find in docs, mails archives or google groups any useful > tip to find (simply) the right number of args. Particularly, the URL > http://www.ece.cmu.edu/afs/ece/usr/dacut/www/src is dead. > > So, do I continue ? If yes, in this way or differently ? Differently. You get a nice "crash" when the program hits an unimplemented function. Do a backtrace, then do a disas of the code that led to the unimplemented function. Count the number of pushes before that call. That's usually the number of arguments you need to use. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

May 23, 2001

Re: Configuration/Announce

by Ian Pilcher

Mike Bond wrote: > > I believe it should have been HKEY_CURRENT_USER instead of HKEY_LOCAL_USER. > That did it. Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 23, 2001

More wine beginner questions

by Mike Bond

I was just perusing through msvcrt and noticed that in wcs.c there is an implementation of _vsnwprintf, which also exists, verbatim, in it's entirety, in ntdll/wcstring.c. Unless I am misunderstanding the .spec files there appears to be a method of "forward"ing a symbol to an external implementation, such as: @ forward -noimport wcslen ntdll.wcslen Is there any particular reason this was not done for _vsnwprintf as well? There is even a comment in the wcs.c copy saying to mirror any fixes in the ntdll copy. Also, on perhaps a style note, I've noticed some implementations are prefixed by the dll name in all caps, such as MSVCRT_vfprintf, and some are not, such as _wmkdir. Is this just personal style or is there more to these differences? -- TTFN MikeB

May 23, 2001

Re: Configuration/Announce

by Mike Bond

I believe it should have been HKEY_CURRENT_USER instead of HKEY_LOCAL_USER. On Tue, May 22, 2001 at 05:21:44PM -0500, Ian Pilcher wrote: > eric pouech wrote: > > > > regapi setValue < foo > > Anyone know why I would get the following? > > regapi: doSetValue failed to open key > [HKEY_LOCAL_USER\Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap] -- TTFN MikeB

May 23, 2001

Re: Configuration/Announce

by Ian Pilcher

eric pouech wrote: > > regapi setValue < foo Anyone know why I would get the following? regapi: doSetValue failed to open key [HKEY_LOCAL_USER\Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap] -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 22, 2001

Re: Small fixes in controls/menu.c

by gerard patel

At 03:42 AM 22/05/2001 +0200, you wrote: >In attachement WIN.3_11 you can see listing generated under windows 3.11. >( Borland WinSight ) (If you want get a listing generated under win98/95 - no >problem , but I'll have to format&reinstall ,because this copy of windows >stopped functioning about 6 months ago ) >WINE_SETWINPOS ,WINE_NCALC- under wine with first and second version of >patch. >I think WINE_NCALC is more similar to WIN.3_11 . There is nothing looking like a SetWindowPos call between WM_INITMENU and WM_INITPOPUPMENU, yes. But as Alexandre Julliard was pointing, it does not mean that something like calling NC_HandleNCCalcSize is done. >I'm wondering why menu->Height == 0. I'll investigate it. height = 0 because at some point the menu has been changed; this is a Wine flag to signal that the menu dimensions have to be calculated again. The problem with my test app without my original patch is that the menu sizes are not calculated at this point so the mouse clicks are ignored Btw, I have downloaded several of the availables app on your web site and I don't see anything wrong with menus; IIRC I have tried 7.5 for Win3.11, and trial versions 8 and 9 (32 bits). Is it with the main menu that you see this problem ? Gerard

May 22, 2001

Re: Configuration/Announce

by Alexandre Julliard

eric pouech <eric.pouech(a)wanadoo.fr> writes: > First of all, your Wine configuration file now needs a WinMM section > containing the following: > [WinMM] > "Drivers" = "wineoss.drv" > "WaveMapper" = "msacm.drv" > "MidiMapper" = "midimap.drv" > > Not adding this will print the following message > > You didn't setup properly the config file for the Wine multimedia modules. > > Will use the hard-coded setup, but this will disapear soon. > > Please add a WinMM section to your Wine config file. > Note that the above configuration will be shortly required, so don't > wait before setting your configuration up Please keep the defaults. There is no reason to force people to update their configuration file when there are workable defaults that we can use. Ideally Wine should behave reasonably even with an empty configuration file; this is not entirely possible because things like paths don't have reasonable defaults, but forcing people to specify things that we could guess is not user-friendly. -- Alexandre Julliard julliard(a)winehq.com

May 22, 2001

Configuration/Announce

by eric pouech

with today's CVS commit (for those who stay up to date with the latest developments), you'll have to modify your Wine configuration to reflect the changes. First of all, your Wine configuration file now needs a WinMM section containing the following: [WinMM] "Drivers" = "wineoss.drv" "WaveMapper" = "msacm.drv" "MidiMapper" = "midimap.drv" Not adding this will print the following message > You didn't setup properly the config file for the Wine multimedia modules. > Will use the hard-coded setup, but this will disapear soon. > Please add a WinMM section to your Wine config file. Note that the above configuration will be shortly required, so don't wait before setting your configuration up Next, you have also to add a key to your registry. To do so, create a sample file (let's call it foo) containing the following text: [HKEY_LOCAL_USER\Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap] 989041554 "AutoScheme"=dword:00000000 "CurrentInstrument"="#0" "UseScheme"=dword:00000000 then goto the <wine>/programs/regapi and compile the program the run: regapi setValue < foo that's it Not applying the key in the registry will result in various errors in MIDIMAP_ functions (mainly if Wine is set up to use a native Windows system) Maintainers are welcome to update theirs packages accordingly (default values are in documentation/samples/config & winedefault.reg) Detailed information is available in documentation/multimedia.sgml. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

May 22, 2001

Re: Small clean up

by eric pouech

> Is it because I made changes to these files (probably traces) that CVS > did not dare delete them? yes > But shouldn't it say 'was removed, no comparison available'? well, it's hard to tell between a deleted file and a not yet submitted file (knowing that you can also recreate a file with the same name as one you've already deleted) so, an error message telling that a file with the same name exists in Attic would make more sense anyway, it's a always a good point to inspect closely the output of a cvs update A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

May 22, 2001

Re: Small clean up

by Francois Gouget

On Tue, 22 May 2001, Dmitry Timoshkov wrote: > Hello. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Small clean up. > > diff -u cvs/wine/dlls/kernel/comm.c wine/dlls/kernel/comm.c > --- cvs/wine/dlls/kernel/comm.c Sun Apr 22 07:54:54 2001 > +++ wine/dlls/kernel/comm.c Thu May 17 14:21:58 2001 > @@ -535,7 +535,7 @@ > return IE_HARDWARE; > } else { > unknown[port] = SEGPTR_ALLOC(40); > - bzero(unknown[port],40); > + memset(unknown[port], 0, 40); > COM[port].fd = fd; > COM[port].commerror = 0; > COM[port].eventmask = 0; Checking for other instances of this problem I found one in 'misc/comm.c'. But CVS claims that: cvs server: misc/comm.c is a new entry, no comparison available Yet I'm pretty sure I did not create such a file. But when a file is deleted CVS should not give me such a message. Is it because I made changes to these files (probably traces) that CVS did not dare delete them? But shouldn't it say 'was removed, no comparison available'? I also have this message for: cvs server: dlls/ddraw/ddraw/dga.c is a new entry, no comparison available cvs server: dlls/ddraw/ddraw/x11.c is a new entry, no comparison available cvs server: dlls/winspool/winspool.spec is a new entry, no comparison available cvs server: misc/comm.c is a new entry, no comparison available -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

May 22, 2001

Re: Anybody know int-31?

by Alexandre Julliard

Bob Goodwin <goodie1(a)pacbell.net> writes: > When calling the save/restore handler function, the only parameter > passed is a byte in AL to indicate whether to save the current context > or restore a saved context. My question is, are there multiple copies of > the save/restore function or at least multiple entry points? It seems > that this would be the only way of having multiple unique context saves. No, the app is supposed to allocate a buffer of the right size (as returned by the int31 call) and pass it to the save/restore function in ES:EDI. Anyway, I'm not sure you need this functionality at all, the current implementation should work OK (except that it needs a dummy protected mode entry point). -- Alexandre Julliard julliard(a)winehq.com

May 22, 2001

Re: vxd support?

by Osvaldo Fornaro

El Dom 20 May 2001 18:32, escribiste: > >>>>> "Osvaldo" == Osvaldo Fornaro <ofornaro(a)exa.unicen.edu.ar> writes: > > Osvaldo> Hi, I were far from the project for a while, so sorry if this > Osvaldo> topic is trivial, but I wish to use a parallel port scanner > Osvaldo> with wine. Under Windows, appears a device to treat the > Osvaldo> parallel port as a SCSI port, but is based on a VxD archive, > Osvaldo> and wine don't find it. > > Does the scanner use it's own's VXDs or does it use the system parallel > VXD? In the latter case, supplying the needed functionality might be > possible. > > Bye I suppose that are propietary drivers, eppscsi.vxd or something like that. However, such files there is not exist in a windows instalation of the scanner. It sounds like the file is unpacked or renamed during execution. If there exist any hope, I will try to install the scanner again (vmware deals fine with the scanner, but is so heavy...) Thanks, Osvaldo

May 22, 2001

Re: Question on exposing non-windows functions from dlls...

by Ian Pilcher

Mike Bond wrote: > > On the question of determining compatibility, what methods are we "allowed" > to persue? For instance, I created a small test app for the exec variants, > tested it under Windows NT then under Wine. I would hope this is a valid > method, but with the way the lawyers work, it's sometimes hard to tell. > Big disclaimer: I am not a lawyer; if you end up in court because you pay attention to anything I say, that's just too darn bad. It depends on which country you're in. What you've done is classic "black box" reverse engineering, which has historically been protected by the U.S. legal system. Even the DMCA protects it as long as you don't decrypt anything. UCITA in its unaltered form, however, legitimizes all those software license agreements that U.S. courts have found unenforceable. So I guess it's starting to depends on what state you're in if you're in the U.S. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 22, 2001

Re: Question on exposing non-windows functions from dlls...

by Mike Bond

On Fri, May 18, 2001 at 06:59:12PM +0200, Ove Kaaven wrote: > The guidelines are pretty simple and easy to understand: with a very few > *very* exceptional exceptions, never ever expose them. And definitely > never to non-core DLLs such as msvcrt - there's no reason an application > DLL like msvcrt can't be implemented on top of the Win32 API the same way > it's implemented on Windows. I have gone ahead and implemented most of the exec variants as described just terminating the previous process, the internal spawn implementation already provided a flag to accomplish this easily. On the question of determining compatibility, what methods are we "allowed" to persue? For instance, I created a small test app for the exec variants, tested it under Windows NT then under Wine. I would hope this is a valid method, but with the way the lawyers work, it's sometimes hard to tell. As a note, it seems NT is doing the same thing as they end up with different address spaces and pids after execl. -- TTFN MikeB

May 22, 2001

Re: Patch for a bug in server/select.c

by Bang Jun-Young

On Sun, May 20, 2001 at 10:32:58AM -0700, Alexandre Julliard wrote: > Bang Jun-Young <bjy(a)mogua.org> writes: > > > It has been observed that poll always returns POLLNVAL without waiting > > when fd is -1. > > Then we cannot use the current code on NetBSD, otherwise we'll be > eating 100% CPU as soon as an fd becomes -1. You'll probably need to > do a poll() wrapper that removes the invalid fds before calling the > real poll. Or you could ask the NetBSD folks to fix their > implementation. I'll put it on my TODO list. :) Thanks for your comments. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

May 22, 2001

Re: history of CVS files?

by eric pouech

> How can I see the history of files in CVS? Is there a WebCVS access provided? > > Reason: I have a 20010112 version of wine running fine but current CVS > version does not start any windows application. if you have cvs setup on your machine, you can do cvs log <filename> otherwise, cvsweb is set up on Winehq (http://www.winehq.com/cvsweb/wine/) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

May 22, 2001

Re: history of CVS files?

by Marcus Meissner

On Tue, May 22, 2001 at 10:32:49AM +0200, Heiko Nardmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > How can I see the history of files in CVS? Is there a WebCVS access provided? > > Reason: I have a 20010112 version of wine running fine but current CVS > version does not start any windows application. cvs log filename cvs diff -u -r1.xx -r1.yy filename Also there is a online CVS browser on winehq.com last time I checked. Ciao, Marcus

May 22, 2001

history of CVS files?

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How can I see the history of files in CVS? Is there a WebCVS access provided? Reason: I have a 20010112 version of wine running fine but current CVS version does not start any windows application. - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7CiQypm53PRScYygRAuZsAKDhwkJRltKTFWU8Dtmg4DHIOGkYMwCgsusj Izxj4GqmLT7dYzVkEpZVHjA= =DzY7 -----END PGP SIGNATURE-----

May 22, 2001

Re: problem starting winword 97SR2

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 21 May 2001 23:46, James Juran wrote: > Heiko Nardmann wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Monday 21 May 2001 13:05, Andreas Mohr wrote: > > > On Mon, May 21, 2001 at 11:30:11AM +0200, Heiko Nardmann wrote: > > > > When starting WinWord I get a dialog saying that either I have not > > > > enough work space or memory space. The program exits then. > > > > > > > > So after playing with the debug options I found out that this happens > > > > after a key named "Office.SharedMemory.1" is accessed inside the > > > > registry. Can someone tell me what to do to make word no longer > > > > complain? > > > > > > [HKEY_LOCAL_MACHINE\\Software\\Classes\\Office.SharedMemory.1] > > > "CLSID" = "{000c0114-0000-0000-c000-000000000046}" > > > "IID" = "{000c0507-0000-0000-c000-000000000046}" > > > > > > But don't think that your Wine config is broken if you don't have > > > registry settings from an already installed Office ? > > > > Hmm ... I did not install Office on my machine, just copied the following > > files from my Windows NT machine into a separate directory: > > > > - - winword.exe > > - - mso97.dll > > - - wwintl32.dll > > > > To be honest: I even have not installed Windows at all on this machine > > although I have a license for it. > > > > The files stated above are enough to resolve the linker dependencies. > > You will need to run the installation program or manually copy all the > registry entries from an existing installation. The Microsoft Office > applications put tons of stuff in the registry which is necessary for > them to run. > I would have expected to be able to go step for step through all problems which I can see in the wine log messages and then solve them. Interestingly enough I just see that I don't have a registry entry called "Office.SharedMemory.1" on my Windows NT 4.0 machine (used regedit and searched registry for "SharedMemory" string). How can this be??? > -- > James Juran > jamesjuran(a)alumni.psu.edu - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7CgBupm53PRScYygRAsOzAKD1HPC4nwdIMClOJnUpfy0d5a4S6ACfYzET dMG4uu1f4eL2bd8NuDqcFd8= =fX40 -----END PGP SIGNATURE-----

May 22, 2001

Re: Small fixes in controls/menu.c

by kenon＠go2.pl

On Sun, May 20, 2001 at 11:33:45PM +0200, gerard patel wrote: > At 10:20 AM 20/05/2001 -0700, you wrote: > >gerard patel <gerard.patel(a)asi.fr> writes: > > > >> (patch using NC_HandleNCCalcSize instead of SetWindowPos) > >> > >> IMO it's better and it solves my problem as well. > > > >I think the SetWindowPos one was better. If the app handles > >WM_NCCALCSIZE we shouldn't try to bypass it. > > But does Windows send this message in this case ? From what > I can see in the traces, I don't think so. > Maybe Maciek could look at the behaviour of his app under > Windows. Or I could download it and try to solve the problem > myself (I'd better not :-/) > I have small experience in debugging apps under windows ,so any hints are welcomed. In attachement WIN.3_11 you can see listing generated under windows 3.11. ( Borland WinSight ) (If you want get a listing generated under win98/95 - no problem , but I'll have to format&reinstall ,because this copy of windows stopped functioning about 6 months ago ) WINE_SETWINPOS ,WINE_NCALC- under wine with first and second version of patch. I think WINE_NCALC is more similar to WIN.3_11 . I'm wondering why menu->Height == 0. I'll investigate it. Maciek --

May 22, 2001

Re: Wine build failure in tools/winebuild/spec16 due to recent change

by Ove Kaaven

On Mon, 21 May 2001, Marcus Meissner wrote: > Changelog: > In case our stat already supports 64bit operations (like FreeBSD > stat does), we don't need to stub them, we can just define the > x64 functions to x. You know, glibc would also have such an interface if you used the -D_FILE_OFFSET_BITS=64 compilation option. Wouldn't it be simpler to unify the 64-bit interface code by using that?

May 21, 2001

Re: warning fixes

by Francois Gouget

On Mon, 21 May 2001, eric pouech wrote: > ChangeLog: fixed a couple of warnings This does not fix the warnings, it just hides the bug. As the comments say, the assignments are plain wrong in the first place. /* FIXME: This is plain wrong, we must convert from a '\0' separated * memory block to an array of pointers to string format. */ - MSVCRT__environ = GetEnvironmentStringsA(); + MSVCRT__environ = (char**)GetEnvironmentStringsA(); MSVCRT___initenv = MSVCRT__environ; /* FIXME: This is plain wrong, we must convert from a '\0' separated * memory block to an array of pointers to string format. */ - MSVCRT__wenviron = GetEnvironmentStringsW(); + MSVCRT__wenviron = (WCHAR**)GetEnvironmentStringsW(); MSVCRT___winitenv = MSVCRT__wenviron; -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

May 21, 2001

Re: problem starting winword 97SR2

by James Juran

Heiko Nardmann wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 21 May 2001 13:05, Andreas Mohr wrote: > > On Mon, May 21, 2001 at 11:30:11AM +0200, Heiko Nardmann wrote: > > > When starting WinWord I get a dialog saying that either I have not enough > > > work space or memory space. The program exits then. > > > > > > So after playing with the debug options I found out that this happens > > > after a key named "Office.SharedMemory.1" is accessed inside the > > > registry. Can someone tell me what to do to make word no longer complain? > > > > [HKEY_LOCAL_MACHINE\\Software\\Classes\\Office.SharedMemory.1] > > "CLSID" = "{000c0114-0000-0000-c000-000000000046}" > > "IID" = "{000c0507-0000-0000-c000-000000000046}" > > > > But don't think that your Wine config is broken if you don't have registry > > settings from an already installed Office ? > > Hmm ... I did not install Office on my machine, just copied the following > files from my Windows NT machine into a separate directory: > > - - winword.exe > - - mso97.dll > - - wwintl32.dll > > To be honest: I even have not installed Windows at all on this machine > although I have a license for it. > > The files stated above are enough to resolve the linker dependencies. You will need to run the installation program or manually copy all the registry entries from an existing installation. The Microsoft Office applications put tons of stuff in the registry which is necessary for them to run. -- James Juran jamesjuran(a)alumni.psu.edu

May 21, 2001

Anybody know int-31?

by Bob Goodwin

I want to run an application that requires win95 but relys heavily on DOS interupt functions. Specifically it requires interupt 31 which is just a stub in Wine. It appears (from R.B.'s list) that there is no limit on calls to interupt_31-AX=0305 (request the address of (?:the:a) save/restore handler.) That implies more than one thread could have a save/restore pointer. When calling the save/restore handler function, the only parameter passed is a byte in AL to indicate whether to save the current context or restore a saved context. My question is, are there multiple copies of the save/restore function or at least multiple entry points? It seems that this would be the only way of having multiple unique context saves. It would be differrent if a unique `handle' was returned by int_31 instead of a call address. If only one context can be stored at a time, do I need a spin-lock within the save/restore function to keep other applications holding until their turn? Thanks. Bob Goodwin

May 21, 2001

Re: Networking with Mandrake 8.0 and SuSE 7.1

by Steve Fox

This weekend I upgraded to Mandrake's 2.4.4 kernel from Cooker (since it fixed both my mouse and token ring) and suddenly this problem has gone away (using Notes 5.0.7 and wine-20010305). I'm still planning to go through Mandrake's 2.2.19 SRPM and find which patch messes things up (I can't use a Linus-only kernel because I need reiserfs). I will post again once I have narrowed down the list of suspects. I'm guessing it has to be a common patch since SuSE seems to have the same symptoms. Steve Fox IBM Linux Technology Center http://www.ibm.com/linux/ltc http://k-lug.com

May 21, 2001

Re: problem starting winword 97SR2

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 21 May 2001 14:40, Heiko Nardmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 21 May 2001 14:09, Heiko Nardmann wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Monday 21 May 2001 13:05, Andreas Mohr wrote: > > > On Mon, May 21, 2001 at 11:30:11AM +0200, Heiko Nardmann wrote: > > > > When starting WinWord I get a dialog saying that either I have not > > > > enough work space or memory space. The program exits then. > > > > This happens with CVS version, too, which I just compiled and installed. - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7CRSRpm53PRScYygRAhk2AKC+eu8s5jBxNbigCDL/G+w+Sd7eTwCeIBcV xr9+ceOMQ4rEcUFj6fkB6bk= =LTIH -----END PGP SIGNATURE-----

May 21, 2001

Re: problem starting winword 97SR2

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 21 May 2001 14:09, Heiko Nardmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 21 May 2001 13:05, Andreas Mohr wrote: > > On Mon, May 21, 2001 at 11:30:11AM +0200, Heiko Nardmann wrote: > > > When starting WinWord I get a dialog saying that either I have not > > > enough work space or memory space. The program exits then. > > > > > > So after playing with the debug options I found out that this happens > > > after a key named "Office.SharedMemory.1" is accessed inside the > > > registry. Can someone tell me what to do to make word no longer > > > complain? > > > > [HKEY_LOCAL_MACHINE\\Software\\Classes\\Office.SharedMemory.1] > > "CLSID" = "{000c0114-0000-0000-c000-000000000046}" > > "IID" = "{000c0507-0000-0000-c000-000000000046}" > > And now I have to say that this did not work. Sorry ... Any other idea? Here are the lines of debug with +all which contain references to this SharedMemory stuff; maybe someone can tell me what to do: Call advapi32.211: RegDeleteKeyA(80000000,3079075c "Office.SharedMemory.1") ret=307907f6 fs=008f Call ntdll.419: RtlInitAnsiString(405b6b88,3079075c "Office.SharedMemory.1") ret=407c591a fs=008f Ret ntdll.419: RtlInitAnsiString() retval=00000016 ret=407c591a fs=008f Call ntdll.281: RtlAnsiStringToUnicodeString(405b6b90,405b6b88,00000001) ret=407c5926 fs=008f trace:heap:HeapAlloc (40360000,00000002,0000002c): returning 403a7a2c Ret ntdll.281: RtlAnsiStringToUnicodeString() retval=00000000 ret=407c5926 fs=008f Call ntdll.132: NtOpenKey(405b6bd4,00000000,405b6b98) ret=407c593d fs=008f trace:reg:NtOpenKey (0x80000000,L"Office.SharedMemory.1",0,0x405b6bd4) 080687e8: open_key( parent=-2147483648, access=00000000, name=L"Office.SharedMemory.1" ) Create key \\Machine\\Software\\Classes Open key ERROR 080687e8: open_key() = c0000034 { hkey=0 } Ret ntdll.132: NtOpenKey() retval=c0000034 ret=407c593d fs=008f Call ntdll.396: RtlFreeUnicodeString(405b6b90) ret=407c5945 fs=008f trace:heap:HeapFree (40360000,00000002,403a7a2c): returning TRUE Ret ntdll.396: RtlFreeUnicodeString() retval=00000001 ret=407c5945 fs=008f Call ntdll.466: RtlNtStatusToDosError(c0000034) ret=407c594b fs=008f Ret ntdll.466: RtlNtStatusToDosError() retval=00000002 ret=407c594b fs=008f Ret advapi32.211: RegDeleteKeyA() retval=00000002 ret=307907f6 fs=008f Call advapi32.211: RegDeleteKeyA(80000000,3079075c "Office.SharedMemory.1") ret=307907f6 fs=008f Call ntdll.419: RtlInitAnsiString(405b6b88,3079075c "Office.SharedMemory.1") ret=407c591a fs=008f Ret ntdll.419: RtlInitAnsiString() retval=00000016 ret=407c591a fs=008f Call ntdll.281: RtlAnsiStringToUnicodeString(405b6b90,405b6b88,00000001) ret=407c5926 fs=008f trace:heap:HeapAlloc (40360000,00000002,0000002c): returning 403a7a2c Ret ntdll.281: RtlAnsiStringToUnicodeString() retval=00000000 ret=407c5926 fs=008f Call ntdll.132: NtOpenKey(405b6bd4,00000000,405b6b98) ret=407c593d fs=008f trace:reg:NtOpenKey (0x80000000,L"Office.SharedMemory.1",0,0x405b6bd4) 080687e8: open_key( parent=-2147483648, access=00000000, name=L"Office.SharedMemory.1" ) Open key ERROR 080687e8: open_key() = c0000034 { hkey=0 } Ret ntdll.132: NtOpenKey() retval=c0000034 ret=407c593d fs=008f - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7CQy2pm53PRScYygRAknkAKD4itFKCJQH4hHwXyZBzL0OQP6hjACg54JL YL/rNoN1Zd5m0EsNZ0FZaYU= =nahH -----END PGP SIGNATURE-----

May 21, 2001

Re: problem starting winword 97SR2

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 21 May 2001 13:05, Andreas Mohr wrote: > On Mon, May 21, 2001 at 11:30:11AM +0200, Heiko Nardmann wrote: > > When starting WinWord I get a dialog saying that either I have not enough > > work space or memory space. The program exits then. > > > > So after playing with the debug options I found out that this happens > > after a key named "Office.SharedMemory.1" is accessed inside the > > registry. Can someone tell me what to do to make word no longer complain? > > [HKEY_LOCAL_MACHINE\\Software\\Classes\\Office.SharedMemory.1] > "CLSID" = "{000c0114-0000-0000-c000-000000000046}" > "IID" = "{000c0507-0000-0000-c000-000000000046}" > > But don't think that your Wine config is broken if you don't have registry > settings from an already installed Office ? Hmm ... I did not install Office on my machine, just copied the following files from my Windows NT machine into a separate directory: - - winword.exe - - mso97.dll - - wwintl32.dll To be honest: I even have not installed Windows at all on this machine although I have a license for it. The files stated above are enough to resolve the linker dependencies. Additionally I added a font alias: "Alias0" = "Tahoma,-adobe-helvetica-" This is because I did not get xfstt work together with my Windows Exceed X Server (to use the original tahoma.ttf files). This suppresses the error message saying that it could not find Tahoma font. - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7CQVopm53PRScYygRAhC3AJ9LT7kmMKs70B1pBSxd8Cu/+O5XLwCfQacB cEGRUSg6rZCePcagBBBrWdA= =66Sq -----END PGP SIGNATURE-----

May 21, 2001

Re: problem starting winword 97SR2

by Andreas Mohr

On Mon, May 21, 2001 at 11:30:11AM +0200, Heiko Nardmann wrote: > When starting WinWord I get a dialog saying that either I have not enough > work space or memory space. The program exits then. > > So after playing with the debug options I found out that this happens after > a key named "Office.SharedMemory.1" is accessed inside the registry. Can > someone tell me what to do to make word no longer complain? [HKEY_LOCAL_MACHINE\\Software\\Classes\\Office.SharedMemory.1] "CLSID" = "{000c0114-0000-0000-c000-000000000046}" "IID" = "{000c0507-0000-0000-c000-000000000046}" But don't think that your Wine config is broken if you don't have registry settings from an already installed Office ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

May 21, 2001

problem starting winword 97SR2

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When starting WinWord I get a dialog saying that either I have not enough work space or memory space. The program exits then. So after playing with the debug options I found out that this happens after a key named "Office.SharedMemory.1" is accessed inside the registry. Can someone tell me what to do to make word no longer complain? BTW: I use wine 20010112 since the last snapshot 20010418 does not work on my machine (unhandled exception). Here is the last line from the logfile when starting wine with '+reg': trace:reg:NtOpenKey (0x80000000,L"Office.SharedMemory.1",0,0x405b6d10) - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7COAjpm53PRScYygRAibvAKCXFuh51LK3S//Ber6iQSjgjvrmNwCffRTy MRUAdaCXrhST+oDmu5WHjtg= =2kDj -----END PGP SIGNATURE-----

May 21, 2001

Re: Small fixes in controls/menu.c

by Alexandre Julliard

gerard patel <gerard.patel(a)asi.fr> writes: > But does Windows send this message in this case ? From what > I can see in the traces, I don't think so. Maybe Windows does this differently then. But doing the NC calculation without sending a WM_NCCALCSIZE does not seem right. -- Alexandre Julliard julliard(a)winehq.com

May 21, 2001

Re: More breakages

by Alexandre Julliard

gerard patel <gerard.patel(a)asi.fr> writes: > There is a nice FIXME in the new message handling around the > old timer handling code, so maybe fix is pending ? I guess you could say that... Hardware messages need to be integrated into the new queue handling, I'm working on it but it will probably take a few days. -- Alexandre Julliard julliard(a)winehq.com

May 21, 2001

Re: More breakages

by gerard patel

At 10:28 AM 20/05/2001 +0200, I wrote: >(one more time following up to myself) >Now searching for the Acrobat Reader funny scrolling... I guess that this one is probably because of a still incomplete implementation; what happens is : - I click in the vertical scrollbar - the text begins to scroll (for some reason this particular text is very slow to scroll) - the scroll timer expires and scrolls again the page The WM_LBUTTONUP (supposed to end this loop) is not received until 20 pages later. If I test with a text that scrolls much faster, the problem is much less severe (only one page too much). It seems to be a message order problem; before Wine had - hardware messages (mouse, keyboard) - timer Now it is - timer - hardware messages There is a nice FIXME in the new message handling around the old timer handling code, so maybe fix is pending ? Gerard

May 20, 2001

Re: More breakages

by gerard patel

At 02:49 PM 20/05/2001 +0200, you wrote: >That sounds correct, even for all mailing lists, not just wine-cvs. The >hypermail archives at winehq.com is updated simultaneously with the list >mail being sent out to all subscribers. Ah, I was not understanding how the moderation is working (just read Andi's explanations on cemw). So the extraordinary delays I see sometimes on my posts to wine mailing lists are probably caused by my ISP beta testing IP on avian carriers. >(This is not the case with the >integrita archives, though, since integrita is just one of the >subscribers, subject to the whims of the MTA.) Did you use Reload? It's hard to remember what I did past 2 in the morning. I think that the following morning I looked only at Integrita; they seem to have not taken in account anything since. I'll take a look more accurately next time. Thanks for the explanations. Gerard

May 20, 2001

Re: Small fixes in controls/menu.c

by gerard patel

At 10:20 AM 20/05/2001 -0700, you wrote: >gerard patel <gerard.patel(a)asi.fr> writes: > >> (patch using NC_HandleNCCalcSize instead of SetWindowPos) >> >> IMO it's better and it solves my problem as well. > >I think the SetWindowPos one was better. If the app handles >WM_NCCALCSIZE we shouldn't try to bypass it. But does Windows send this message in this case ? From what I can see in the traces, I don't think so. Maybe Maciek could look at the behaviour of his app under Windows. Or I could download it and try to solve the problem myself (I'd better not :-/) Gerard

May 20, 2001

Re: vxd support?

by Uwe Bonnes

>>>>> "Osvaldo" == Osvaldo Fornaro <ofornaro(a)exa.unicen.edu.ar> writes: Osvaldo> Hi, I were far from the project for a while, so sorry if this Osvaldo> topic is trivial, but I wish to use a parallel port scanner Osvaldo> with wine. Under Windows, appears a device to treat the Osvaldo> parallel port as a SCSI port, but is based on a VxD archive, Osvaldo> and wine don't find it. Does the scanner use it's own's VXDs or does it use the system parallel VXD? In the latter case, supplying the needed functionality might be possible. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

May 20, 2001

Re: What about XP?

by Francois Gouget

On Fri, 18 May 2001, Uhmmmm wrote: > Just wondering: Is there anything being done to update wine for windoze XP? I understand what you mean, but nope, I think we don't really care about XP. Sure, one day we'll have to implement whatever new APIs are in XP, but this will come when an application needs it. The Wine development is application driven, not Windows driven: what we want is for applications to run in Wine and the release of a new version of Windows changes nothing for the 99.99999% of applications that are already out there (and solitaire XP is not the most important app although I quite sure that it will be one of the first XP apps to run). Now, if you were to ask about Office XP (if such a thing exists)... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

May 20, 2001

Re: Patch for a bug in server/select.c

by Alexandre Julliard

Bang Jun-Young <bjy(a)mogua.org> writes: > It has been observed that poll always returns POLLNVAL without waiting > when fd is -1. Then we cannot use the current code on NetBSD, otherwise we'll be eating 100% CPU as soon as an fd becomes -1. You'll probably need to do a poll() wrapper that removes the invalid fds before calling the real poll. Or you could ask the NetBSD folks to fix their implementation. -- Alexandre Julliard julliard(a)winehq.com

May 20, 2001

Re: Small fixes in controls/menu.c

by Alexandre Julliard

gerard patel <gerard.patel(a)asi.fr> writes: > (patch using NC_HandleNCCalcSize instead of SetWindowPos) > > IMO it's better and it solves my problem as well. I think the SetWindowPos one was better. If the app handles WM_NCCALCSIZE we shouldn't try to bypass it. -- Alexandre Julliard julliard(a)winehq.com

May 20, 2001

Re: wineps include fix.

by Ian Pilcher

Ove Kaaven wrote: > > Same as everyone else with cutting-edge Debian? These are post-2.0.2 > snapshots, according to the changelog. > I just checked, and they appear to have changed the name between 2.0.1 and 2.0.2. I can't help wondering how the FreeType people expect any- one to keep up with this. I guess I can do an autoconf check specifically for 2.0.1. I simply refuse to try to #ifdef every point release of FreeType. Down that road lies madness. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 20, 2001

EMAIL REJECTED. RE: Re: wineps include fix.

by ian.pilcher＠home.com

<!! You are not on my whitelist, to avoid spam, I have not recieved your email !!> If your message was not Spam or USE, I strongly apologize for the inconvenice cause by this block, but the ammount of spam recieved on this email address (around 10 per day) is too much for me, and I refuse to read it, so please, accept this appology and resend your message to the address below. Thank you for your time. This message was generated by antispam Your message was not accepted either because: * I don't recognize your address, or * The magic cookie in the 'dated' or 'sender' address you sent to has expired or is invalid. You can contact me using the address: <crazney-dated-ddb0ffdac8b667f5(a)crazney.net> but it will only work for the next 5 days. If you're just sending me SPAM/UCE, buzz off. Regards, David Hammerton aka crazney --your email-- On Sun, 20 May 2001, Ian Pilcher wrote: > David Hammerton wrote: > > > > it should be > > #include <freetype/ftsnames.h> > > instead of > > #include <freetype/ftnames.h> > > > > David - > > It's definitely ftnames.h on my system (Red Hat 7.1). What version of > FreeType do you have? Same as everyone else with cutting-edge Debian? These are post-2.0.2 snapshots, according to the changelog. Package: libfreetype6-dev Status: install ok installed Priority: optional Section: devel Installed-Size: 2428 Maintainer: Anthony Fok <foka(a)debian.org> Source: freetype Version: 2.0.2.20010514-1 Replaces: freetype0-dev, freetype1-dev Depends: libfreetype6 (= 2.0.2.20010514-1), libc6-dev Conflicts: freetype0-dev, freetype1 (<= 1.0.0.1998-03-22-1), freetype1-dev Description: FreeType 2 font engine, development files

May 20, 2001

Re: wineps include fix.

by Ove Kaaven

On Sun, 20 May 2001, Ian Pilcher wrote: > David Hammerton wrote: > > > > it should be > > #include <freetype/ftsnames.h> > > instead of > > #include <freetype/ftnames.h> > > > > David - > > It's definitely ftnames.h on my system (Red Hat 7.1). What version of > FreeType do you have? Same as everyone else with cutting-edge Debian? These are post-2.0.2 snapshots, according to the changelog. Package: libfreetype6-dev Status: install ok installed Priority: optional Section: devel Installed-Size: 2428 Maintainer: Anthony Fok <foka(a)debian.org> Source: freetype Version: 2.0.2.20010514-1 Replaces: freetype0-dev, freetype1-dev Depends: libfreetype6 (= 2.0.2.20010514-1), libc6-dev Conflicts: freetype0-dev, freetype1 (<= 1.0.0.1998-03-22-1), freetype1-dev Description: FreeType 2 font engine, development files

May 20, 2001

Re: wineps include fix.

by Ian Pilcher

David Hammerton wrote: > > it should be > #include <freetype/ftsnames.h> > instead of > #include <freetype/ftnames.h> > David - It's definitely ftnames.h on my system (Red Hat 7.1). What version of FreeType do you have? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 20, 2001

wineps include fix.

by David Hammerton

hey mate.. just got latest CVS of wine (From winehq), it didnt compile, something about not finding "freetype/ftnames.h"... i couldnt find it on my system, in any deb packages, no one had it... so i went hunting, find you left out an 's'.. it should be #include <freetype/ftsnames.h> instead of #include <freetype/ftnames.h> i've cc'd this to "wine-devel"... so yer, if you could fix it, thatd be cool.. but whatever ;p cheers David -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Hammerton aka crazney Victoria, Australia http://crazney.net/ HOWTO maintainer and Linux Half-Life http://lhl.linuxgames.com/ email: http://crazney.net/contact.html -> Note: this email address expires after one week.

May 20, 2001

Re: More breakages

by Ove Kaaven

On Sun, 20 May 2001, gerard patel wrote: > At 02:38 PM 19/05/2001 +0200, you wrote: > > >What do you mean? It's there... > >http://www.winehq.com/hypermail/wine-cvs/2001/05/0095.html > > Yes :-/ > I should have checked again, I was thinking that because wine-cvs input > was generated automatically there could be no reason for data not to be posted > to archives immediately. That sounds correct, even for all mailing lists, not just wine-cvs. The hypermail archives at winehq.com is updated simultaneously with the list mail being sent out to all subscribers. (This is not the case with the integrita archives, though, since integrita is just one of the subscribers, subject to the whims of the MTA.) Did you use Reload?

May 20, 2001

Re: More breakages

by gerard patel

At 11:07 AM 19/05/2001 +0200, I wrote: (again following up to myself) >But there are other strange crashes that I have not yet investigated Now I have, this change in server/queue.c removes the 3 remaining hangings : --- queue.c.orig Sat May 19 21:06:18 2001 +++ queue.c Sun May 20 09:37:09 2001 @@ -695,7 +695,7 @@ } /* now check for WM_PAINT */ - if (queue->wake_bits & QS_PAINT) + if (((WM_PAINT >= req->get_first) && (WM_PAINT <= req->get_last)) && (queue->wake_bits & QS_PAINT)) { req->type = 0; req->win = 0; @@ -707,6 +707,9 @@ } /* now check for timer */ This check was done in previous code, but I am not completely sure that this is the correct place for this check, though. Now searching for the Acrobat Reader funny scrolling... Gerard

May 20, 2001

Re: More breakages

by gerard patel

At 02:38 PM 19/05/2001 +0200, you wrote: >What do you mean? It's there... >http://www.winehq.com/hypermail/wine-cvs/2001/05/0095.html Yes :-/ I should have checked again, I was thinking that because wine-cvs input was generated automatically there could be no reason for data not to be posted to archives immediately. I checked yesterday and it seems that a delay of several hours can happen between a cvs commit and the updating of archives. Gerard

May 20, 2001

Re: Small fixes in controls/menu.c

by gerard patel

At 03:33 AM 20/05/2001 +0200, you wrote: >I think it shouldn't generate infinite loops, but my patch could work >improperly when app catches and doesn't pass to defwndproc WM_NCCALCSIZE >message. So I wrote next patch (attached to this e-mail). (patch using NC_HandleNCCalcSize instead of SetWindowPos) IMO it's better and it solves my problem as well. >Any comments,hints ? - you are supposed to send patches against current Wine, not an outdated version - you are supposed to { respect the indentation style of the file you patch; } >When WIN_FindWndPtr(hWnd) return a NULL pointer doesn't it means that >something bad happens ? Yes but I have a hunch that this WARN will be edited out by the Wine maintainer anyway. You'll notice that in similar cases there are never warnings in Wine code; this is not because Wine coders are lazy, it's because the Wine maintainer thinks it's a bad idea to add warnings everywhere. Gerard

May 20, 2001

Re: Small fixes in controls/menu.c

by kenon＠go2.pl

On Sat, May 19, 2001 at 11:07:19AM +0200, gerard patel wrote: > At 03:35 AM 18/05/2001 +0200, you wrote: > > > My patch is certainly not positioning the menu correctly in the case of your > app, and your patch fixes the app I did this patch for all right, but I am wondering > if calling SetWindowPos could not generate infinite loops in some cases. I think it shouldn't generate infinite loops, but my patch could work improperly when app catches and doesn't pass to defwndproc WM_NCCALCSIZE message. So I wrote next patch (attached to this e-mail). Any comments,hints ? When WIN_FindWndPtr(hWnd) return a NULL pointer doesn't it means that something bad happens ? > > Is Super Memo 8 available on the web as a demo app (freely downloable) ? > At http://www.supermemo.com/ or ftp://ftp.supermemo.com/ftp/sm8zip.exe you can find demo version of that app. (I have full ;-) version). But I'm not sure If it is the same version ,and that bug occurs. It is hard to me to check it because I have only dial-up connection to internet :-( . Maciek --

May 20, 2001

Desktop mode

by lawson_whitney＠juno.com

Good day! In case anyone is bored and wants a little bug, Dmitry's little About.exe program will answer neither the keyboard nor the mouse in desktop mode. In any other mode it works fine. Sorry, I didn't notice when it happened, but it has been a while. 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 19, 2001

Re: Patch for a bug in server/select.c

by Bang Jun-Young

On Fri, May 18, 2001 at 02:10:51PM -0700, Alexandre Julliard wrote: > I'm not sure I understand what they mean in the manpage. Could you > write a small test program to determine the exact behavior WRT invalid > fds? Particularly interesting would be to determine if poll actually > sleeps waiting for something, or if it returns POLLNVAL at once. It has been observed that poll always returns POLLNVAL without waiting when fd is -1. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

May 19, 2001

Re: More breakages

by Ove Kaaven

On Sat, 19 May 2001, gerard patel wrote: > The patch moving queue management to the server has made about 10 casualties > in my toy test suite (btw, why is this patch not appearing on any archive of wine-cvs > either Integrita or the winehq one ? I am not suscribed to wine-cvs so I don't > know if anyone has received it at all) What do you mean? It's there... http://www.winehq.com/hypermail/wine-cvs/2001/05/0095.html

May 19, 2001

queue management problem

by eric pouech

after last night move of queue management to the server, one of my test app stopped working. What happens is that it's waiting on a WM_TIMER message, but which is no longer triggered. After some investigation, it turned out that message retrieval did change a bit: - in previous code, if the QS_PAINT bit was set, but no window to redraw was found, then the QS_TIMER bit was tested - current code, returns from the server a WM_PAINT message in any case, and if no window can be found, then we retry the whole loop, and we don't check the timer case for my, the wPaintCount was always > 1, meaning that the QS_PAINT bit was never reset then, I investigated why the wPaintCount was > 1. It seems that when a visible window, needing some redraw, is hidden before the update takes place, then we don't update the paint count (which should be decreased) the attached patch does take care of it (basically, if we find a hidden window with an update region, then we destroy the region, and clear the internal paint flag), but I don't think it's the best place to do it. any better idea ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle Index: windows/win.c =================================================================== RCS file: /usr/share/cvs/cvsroot/wine/wine/windows/win.c,v retrieving revision 1.130 diff -u -r1.130 win.c --- windows/win.c 2001/05/18 22:51:57 1.130 +++ windows/win.c 2001/05/19 11:39:54 @@ -367,8 +367,15 @@ { if (!(pWnd->dwStyle & WS_VISIBLE)) { - TRACE("skipping window %04x\n", - pWnd->hwndSelf ); + TRACE("skipping window %04x\n", pWnd->hwndSelf); + if ((pWnd->flags & WIN_INTERNAL_PAINT) || pWnd->hrgnUpdate) + { + if (pWnd->hrgnUpdate) DeleteObject(pWnd->hrgnUpdate); + pWnd->hrgnUpdate = 0; + pWnd->flags &= ~WIN_INTERNAL_PAINT; + QUEUE_DecPaintCount(hQueue); + } + } else if ((pWnd->hmemTaskQ == hQueue) && (pWnd->hrgnUpdate || (pWnd->flags & WIN_INTERNAL_PAINT)))

May 19, 2001

Re: Small fixes in controls/menu.c

by gerard patel

At 03:35 AM 18/05/2001 +0200, you wrote: >Application Super Memo 8 has two modes of functioning. One mulit-document >(using MDI) and the other single-document. <snip> >Second Problem: >Also occurs at switching between modes. >The menu is displayed at improper place (about 10-20 pixels upper than it >should). >I think the problem is in the function MENU_InitTracking in code : <snip one of my patches> My patch is certainly not positioning the menu correctly in the case of your app, and your patch fixes the app I did this patch for all right, but I am wondering if calling SetWindowPos could not generate infinite loops in some cases. Is Super Memo 8 available on the web as a demo app (freely downloable) ? Also vs your ignored patch, I don't know - only Alexandre Julliard is judge and executioner of all that is posted to wine-patches - but in such cases check always if your patch applies; if it does not, either because you did a mistake or the cvs code was changed too much between the creation of your sandbox and the moment he looked at your patch, it could be the reason. Gerard

May 19, 2001

More breakages

by gerard patel

The patch moving queue management to the server has made about 10 casualties in my toy test suite (btw, why is this patch not appearing on any archive of wine-cvs either Integrita or the winehq one ? I am not suscribed to wine-cvs so I don't know if anyone has received it at all) The simplest problem is : --- timer.c.orig Sat May 19 01:24:04 2001 +++ timer.c Sat May 19 10:04:57 2001 @@ -104,7 +104,7 @@ TIMER * pTimer; HWINDOWPROC winproc = 0; - if (GetWindowThreadProcessId( hwnd, NULL ) != GetCurrentThreadId()) + if (hwnd && (GetWindowThreadProcessId( hwnd, NULL ) != GetCurrentThreadId())) { SetLastError( ERROR_INVALID_WINDOW_HANDLE ); return 0; This fixes ForteFreeAgent dying immediately with a 'no windows timer', Bcb4, and also funny menus problems. I checked GetWindowThreadProcessId under NT and it fails for hwnd=0 so I think that this is the proper fix. But there are other strange crashes that I have not yet investigated, also clicking in the vertical scrollbar in Acrobat Reader scrolls too much. Gerard

May 19, 2001

Re: Patch for a bug in server/select.c

by Bang Jun-Young

On Fri, May 18, 2001 at 06:42:59PM -0000, Morten Welinder wrote: > > > +#ifdef __NetBSD__ > > + if (pollfd[i].revents & !(pollfd[i].revents & POLLNVAL)) > > +#else > > if (pollfd[i].revents) > > +#endif > > I would hate to see this kind of __NetBSD__ pollution of Wine. > (I believe something like it slipped through recently -- not > good.) > > It used to be that documentation/porting contained lots of reasons > why mentioning any OS name in places like this is a bad idea. > > I suggest a suitable configure test or a porting wrapper for poll. I believe stripping __NetBSD__ #if/endif pair doesn't any harm in any cases, but just a little bit of performance degradation. Which one should we choose between readability, portability, or performance? Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

May 19, 2001

Re: PATCH: PeekMessage - reducing load

by Francois Gouget

On Sat, 19 May 2001, Ove Kaaven wrote: > > On Fri, 18 May 2001, Marcus Meissner wrote: > > > winword.exe apparently uses a while (PeekMessage()) loop. > > > > Both wineserver and 1 wine thread take up 90% CPU even if idle. > > > > This adds a timeout of 10 milliseconds so we are still interactive, > > but do not take up as much CPU. (We basically wait 1 timeslice if 100HZ > > scheduling). > > I question this... an app could be doing something important in such a > loop, i.e. while (!PeekMessage()) do_a_piece_of_important_stuff(), and > this would severely slow down things like that. In particular, I expect a > lot of games to use such loops. If you need CPU time reduction, at least > make it configurable. Me too. There are (badly written) applications that suffer greatly from this. Furthermore I did some tests on Win 95 and Word 97 only does that with some files, not all. Also, Word 2000 no longer behaves that badly. Now, if it were a per application setting it could make sense. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

May 18, 2001

Re: Question on exposing non-windows functions from dlls...

by Ove Kaaven

On Fri, 18 May 2001, Mike Bond wrote: > If you can point me to some way of implementing _exec[lv][ep] using the > standard win32 API I would be more than willing to. You could do: if (CreateProcess(...) == successful) ExitProcess(...); > Unfortunately that was one arguable shortcoming of win32 process > management in that it did not have any interface that allowed loading > and running an image in-process. No, but who says that that's what exec does in msvcrt anyway? It would be a big mistake to accuse Microsoft implementations of having the same semantics as similarly-named Unix functions, so don't do that, please.

May 18, 2001

Re: vxd support?

by Francois Gouget

On Fri, 18 May 2001, Osvaldo Fornaro wrote: > Hi, > > I were far from the project for a while, so sorry if this topic is trivial, > but I wish to use a parallel port scanner with wine. Under Windows, appears a > device to treat the parallel port as a SCSI port, but is based on a VxD > archive, and wine don't find it. > > Is there any solution to deal with VxD or not yet? No, and ther most likely never will be. VxDs are more or less equivalent to Linux's kernel modules: most need direct access to the hardware, must run in ring 0 (the most priviledged level of the processor) and use a separate API (the DDK API rather than the Win32 API). So Wine does not deal with VxDs. Maybe we should add a section in the Wine User Guide to list what Wine does not do right after 'Wine capabilities': http://wine.codeweavers.com/docs/wine-user/wine-stats.shtml#WINE-CAPABILITI… -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

May 18, 2001

Re: Fix in Variant's coerce function

by Francois Gouget

On 18 May 2001, Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > > > So I'm in favor of uncommenting the calls in Coerce, and if these > > cases are really being used then either we do a full-fledged > > implementation or we write pseudo-stubs for these functions. > > > > Do we have a know app that crashes with this patch? > > It won't ever get to crashing, since it doesn't even link! Sorry about that. I missed it somehow. > Try a make checklink and you'll see. I did not know about checklink. > Unfortunately because of the way we link libraries you can actually > create a .so that contains undefined symbols; it will only fail at > load-time. This is why we have make checklink to spot this kind of > problems at compile-time. Yes I know. It's a pain too for winelib applications. It makes detecting errors at compile time pretty difficult. Maybe checklink should be part of the winelib development tools? And maybe it should be systematically called after a link? Hmmm, is 'make checklink' supposed to work in the top-level directory? I get: $ make checklink gcc -o checklink ./library/checklink.c -L./library -lwine -lncurses -lm -lutil -ldl && rm -f checklink make[1]: Entering directory `/home/fgouget/wine/wine.ref/dlls' make[2]: Entering directory `/home/fgouget/wine/wine.ref/dlls/ddraw' gcc -o checklink ../../library/checklink.c -L. -lddraw -L../../library -lwine -L../../ole -lwine_uuid -lncurses -lm -lutil -ldl && rm -f checklink /usr/bin/ld: warning: libuser32.so, needed by ./libddraw.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libx11drv.so, needed by ./libddraw.so, not found (try using -rpath or -rpath-link) ... We should set LD_LIBRARY_PATH like for winebuild & co... Even after setting LD_LIBRARY_PATH I get the following though: $ make checklink gcc -o checklink ./library/checklink.c -L./library -lwine -lncurses -lm -lutil -ldl && rm -f checklink make[1]: Entering directory `/home/fgouget/wine/wine.ref/dlls' make[2]: Entering directory `/home/fgouget/wine/wine.ref/dlls/ddraw' gcc -o checklink ../../library/checklink.c -L. -lddraw -L../../library -lwine -L../../ole -lwine_uuid -lncurses -lm -lutil -ldl && rm -f checklink /usr/X11R6/lib/libXpm.so.4: undefined reference to `atexit' collect2: ld returned 1 exit status ... That's strange. Shouldn't atexit be defined in the C library? (I have the 2.2.3-1 .deb here). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ {free} || die "";

May 18, 2001

Re: Fix in Variant's coerce function

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > So I'm in favor of uncommenting the calls in Coerce, and if these > cases are really being used then either we do a full-fledged > implementation or we write pseudo-stubs for these functions. > > Do we have a know app that crashes with this patch? It won't ever get to crashing, since it doesn't even link! Try a make checklink and you'll see. Unfortunately because of the way we link libraries you can actually create a .so that contains undefined symbols; it will only fail at load-time. This is why we have make checklink to spot this kind of problems at compile-time. -- Alexandre Julliard julliard(a)winehq.com

May 18, 2001

Re: Fix in Variant's coerce function

by Francois Gouget

On 18 May 2001, Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > > > It seemed wrong, as did the 32 suffixes, and leaving all the > > xxxFromDisp functions commented out. > > It may be a good idea to actually implement the functions before > uncommenting the calls ;-) On the other hand at least you would quickly notice that the function is being used and that you should stub it out. Currently you would get an error code and no message in the log so that you may not notice. What also bothers me is that the person implementing the xxxFromDisp functions has an 80% chance of forgetting to update the Coerce function. So I'm in favor of uncommenting the calls in Coerce, and if these cases are really being used then either we do a full-fledged implementation or we write pseudo-stubs for these functions. Do we have a know app that crashes with this patch? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

May 18, 2001

What about XP?

by Uhmmmm

Just wondering: Is there anything being done to update wine for windoze XP?

May 18, 2001

Re: Fix in Variant's coerce function

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > It seemed wrong, as did the 32 suffixes, and leaving all the > xxxFromDisp functions commented out. It may be a good idea to actually implement the functions before uncommenting the calls ;-) -- Alexandre Julliard julliard(a)winehq.com

May 18, 2001

Re: Patch for a bug in server/select.c

by Alexandre Julliard

Bang Jun-Young <bjy(a)mogua.org> writes: > According to the manpage, NetBSD implementation of poll(2) is different > from historical one in that a given fd may not cause poll to return with > an error. I'm not sure if this is the case, however. I'm not sure I understand what they mean in the manpage. Could you write a small test program to determine the exact behavior WRT invalid fds? Particularly interesting would be to determine if poll actually sleeps waiting for something, or if it returns POLLNVAL at once. -- Alexandre Julliard julliard(a)winehq.com

May 18, 2001

Re: Question on exposing non-windows functions from dlls...

by Alexandre Julliard

Mike Bond <mbond(a)cox.rr.com> writes: > If you can point me to some way of implementing _exec[lv][ep] using the > standard win32 API I would be more than willing to. Unfortunately that > was one arguable shortcoming of win32 process management in that it did not > have any interface that allowed loading and running an image in-process. You cannot do this with the Win32 API, that's true. And since the native msvcrt is implemented on top of the Win32 API, this means that msvcrt exec functions cannot possibly behave exactly like the Unix ones. What you must do is find out the expected behavior of the msvcrt exec, and implement the same behavior; you should then be able to do this using the Win32 API, since this is how the native one does it. -- Alexandre Julliard julliard(a)winehq.com

May 18, 2001

Re: Patch for a bug in server/select.c

by Morten Welinder

> +#ifdef __NetBSD__ > + if (pollfd[i].revents & !(pollfd[i].revents & POLLNVAL)) > +#else > if (pollfd[i].revents) > +#endif I would hate to see this kind of __NetBSD__ pollution of Wine. (I believe something like it slipped through recently -- not good.) It used to be that documentation/porting contained lots of reasons why mentioning any OS name in places like this is a bad idea. I suggest a suitable configure test or a porting wrapper for poll. Morten

May 18, 2001

Re: Question on exposing non-windows functions from dlls...

by Mike Bond

On Fri, May 18, 2001 at 06:59:12PM +0200, Ove Kaaven wrote: > > On Fri, 18 May 2001, Mike Bond wrote: > > > I just submitted a patch to wine-patches that provides the implementation > > of spawnl and spawnlp. I had been hoping to implement execl and execlp as > > well but found that the underlying functionality that I would need is not > > exposed outside scheduler/process.c. My question is what guidelines are > > there, if any, are there to exposing non-win functions, such as > > exec_wine_binary in scheduler/process.c? > > The guidelines are pretty simple and easy to understand: with a very few > *very* exceptional exceptions, never ever expose them. And definitely > never to non-core DLLs such as msvcrt - there's no reason an application > DLL like msvcrt can't be implemented on top of the Win32 API the same way > it's implemented on Windows. If you can point me to some way of implementing _exec[lv][ep] using the standard win32 API I would be more than willing to. Unfortunately that was one arguable shortcoming of win32 process management in that it did not have any interface that allowed loading and running an image in-process. -- TTFN MikeB

May 18, 2001

Re: Question on exposing non-windows functions from dlls...

by Ove Kaaven

On Fri, 18 May 2001, Mike Bond wrote: > I just submitted a patch to wine-patches that provides the implementation > of spawnl and spawnlp. I had been hoping to implement execl and execlp as > well but found that the underlying functionality that I would need is not > exposed outside scheduler/process.c. My question is what guidelines are > there, if any, are there to exposing non-win functions, such as > exec_wine_binary in scheduler/process.c? The guidelines are pretty simple and easy to understand: with a very few *very* exceptional exceptions, never ever expose them. And definitely never to non-core DLLs such as msvcrt - there's no reason an application DLL like msvcrt can't be implemented on top of the Win32 API the same way it's implemented on Windows.

May 18, 2001

vxd support?

by Osvaldo Fornaro

Hi, I were far from the project for a while, so sorry if this topic is trivial, but I wish to use a parallel port scanner with wine. Under Windows, appears a device to treat the parallel port as a SCSI port, but is based on a VxD archive, and wine don't find it. Is there any solution to deal with VxD or not yet? Thanks in advance. -- Dr. Osvaldo Fornaro <ofornaro(a)exa.unicen.edu.ar> Universidad Nacional del Centro de la Provincia de Buenos Aires Instituto de Física de Materiales Tandil - CICPBA Pinto 399 (B7000GHG) Argentina

May 18, 2001

Re: Networking with Mandrake 8.0 and SuSE 7.1

by Christopher Morgan

Is this patch in the main kernel source? If so then why not just install from a source tgz? Chris On Fri, 18 May 2001, Steve Fox wrote: > > Unfortunately I can't really try the 2.4 kernel because Mandrake didn't get > the PCMCIA token ring patch in there. I failed miserably to patch it in the > last time I tried :( I plan to examine all the patches that Mandrake > applies to their 2.2.19 kernel and back out some of them. > > Steve Fox > IBM Linux Technology Center > http://www.ibm.com/linux/ltc > http://k-lug.com > > > > >

May 18, 2001

Re: Networking with Mandrake 8.0 and SuSE 7.1

by Steve Fox

Unfortunately I can't really try the 2.4 kernel because Mandrake didn't get the PCMCIA token ring patch in there. I failed miserably to patch it in the last time I tried :( I plan to examine all the patches that Mandrake applies to their 2.2.19 kernel and back out some of them. Steve Fox IBM Linux Technology Center http://www.ibm.com/linux/ltc http://k-lug.com

May 18, 2001

Question on exposing non-windows functions from dlls...

by Mike Bond

I just submitted a patch to wine-patches that provides the implementation of spawnl and spawnlp. I had been hoping to implement execl and execlp as well but found that the underlying functionality that I would need is not exposed outside scheduler/process.c. My question is what guidelines are there, if any, are there to exposing non-win functions, such as exec_wine_binary in scheduler/process.c? Also, from just a cursory glance at exec_wine_binary that I may need to wrap it to do some of the work that fork_and_exec and PROCESS_Create are doing, such as calling DOSFS_GetFullName. I'm not sure what, if anything, the server would need to know about this. -- TTFN MikeB

May 18, 2001

Re: Networking with Mandrake 8.0 and SuSE 7.1

by gerard patel

At 10:14 AM 17/05/2001 -0500, you wrote: >I'm running Lotus Notes 5.04a under WINE with one of the January releases >and its been working great for months. However, any release since February >does not seem to do reliable networking on my Mandrake 8.0 system. With the other replies to this post, I'd say that it would be interesting to try to configure your Mandrake system with kernel 2.4 (I suspect that you choosed 2.2 kernel). Gerard

May 18, 2001

Re: Networking with Mandrake 8.0 and SuSE 7.1

by Steve Fox

In my case I'm using Mandrake's 2.2.19 kernel, but apparently the straight unpatched 2.2.19 works ok. I guess I'll have to go look through the patches Mandrake applied to the kernel. Thanks for the response. Steve Fox IBM Linux Technology Center http://www.ibm.com/linux/ltc http://k-lug.com

May 18, 2001

Re: Networking with Mandrake 8.0 and SuSE 7.1

by Michael Stefaniuc

On Fri, May 18, 2001 at 09:51:41AM +0100, r.maurizzi(a)gvs.it wrote: > > > > I'm running Lotus Notes 5.04a under WINE with one of the January releases > > and its been working great for months. However, any release since February > > does not seem to do reliable networking on my Mandrake 8.0 system. > (...) > > On a related note, another cow-orker who is using Mandrake Cooker > > (development distro) and his own compiled kernel does not have this > > problem. I am on a token ring network, which I don't think should matter. > > I had the exact problem with SuSE Linux: starting from Kernel SuSE-2.2.18, wine The 2.2.18 Linux kernel was in general a little bit broken. The best thing is to upgrade to 2.2.19 or later. bye michael > doesn't work anymore, but if I use a self compiled "stock" kernel, it works > again. It's a pity I know little of both Wine and Kernel tcp/ip, and I don't > have time to check kernels and diffs... :-( > I don't know about Mandrake, but SuSE distributes a tar.gz with all the patches > they apply to their kernels. If Mandrake does something similar, I guess a few > "apply a part of the patches - compile - test" cycle should help spot the > problem(s). > > If anyone on the list has ideas on tests I could do to gather more info, I'll be > glad to help (I still have SuSE stock kernels installed, so I can test > differences in behaviours between different versions rather quickly) -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

May 18, 2001

Re: Networking with Mandrake 8.0 and SuSE 7.1

by r.maurizzi＠gvs.it

> I'm running Lotus Notes 5.04a under WINE with one of the January releases > and its been working great for months. However, any release since February > does not seem to do reliable networking on my Mandrake 8.0 system. (...) > On a related note, another cow-orker who is using Mandrake Cooker > (development distro) and his own compiled kernel does not have this > problem. I am on a token ring network, which I don't think should matter. I had the exact problem with SuSE Linux: starting from Kernel SuSE-2.2.18, wine doesn't work anymore, but if I use a self compiled "stock" kernel, it works again. It's a pity I know little of both Wine and Kernel tcp/ip, and I don't have time to check kernels and diffs... :-( I don't know about Mandrake, but SuSE distributes a tar.gz with all the patches they apply to their kernels. If Mandrake does something similar, I guess a few "apply a part of the patches - compile - test" cycle should help spot the problem(s). If anyone on the list has ideas on tests I could do to gather more info, I'll be glad to help (I still have SuSE stock kernels installed, so I can test differences in behaviours between different versions rather quickly) Ciao, Rob!

May 18, 2001

Re: Documentation: lists interfer with the TOC

by Francois Gouget

On Thu, 17 May 2001, Francois Gouget wrote: > On Fri, 18 May 2001, Ove Kaaven wrote: > > > > > On Thu, 17 May 2001, Francois Gouget wrote: > > > > > If you look at the documentation table of contents you'll see things > > > like: > > > Anonymous unions/structs > > > Unicode > > > 21. > > > C library > > > 22. > > > 23. > > > > Not in the HTML docs generated on Debian (db2html from cygnus-stylesheets > > 0.10.2-8, docbook-stylesheets 1.64-1). > > Ah! I'm using Debian too but I have (from testing): > cygnus-stylesheets 0.10.2-7 > docbook-stylesheets 1.60-3 > > I'm going to try to update them. Yes, upgrading docbook-stylesheets to 1.64-1 (from unstable) fixed it. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

May 18, 2001

Re: Documentation: lists interfer with the TOC

by Francois Gouget

On Fri, 18 May 2001, Ove Kaaven wrote: > > On Thu, 17 May 2001, Francois Gouget wrote: > > > If you look at the documentation table of contents you'll see things > > like: > > Anonymous unions/structs > > Unicode > > 21. > > C library > > 22. > > 23. > > Not in the HTML docs generated on Debian (db2html from cygnus-stylesheets > 0.10.2-8, docbook-stylesheets 1.64-1). Ah! I'm using Debian too but I have (from testing): cygnus-stylesheets 0.10.2-7 docbook-stylesheets 1.60-3 I'm going to try to update them. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

May 18, 2001

Re: Documentation: lists interfer with the TOC

by Ove Kaaven

On Thu, 17 May 2001, Francois Gouget wrote: > If you look at the documentation table of contents you'll see things > like: > Anonymous unions/structs > Unicode > 21. > C library > 22. > 23. Not in the HTML docs generated on Debian (db2html from cygnus-stylesheets 0.10.2-8, docbook-stylesheets 1.64-1).

May 18, 2001

Documentation: lists interfer with the TOC

by Francois Gouget

If you look at the documentation table of contents you'll see things like: Anonymous unions/structs Unicode 21. C library 22. 23. The 21, 22 and 23 are not supposed to be here. What I noticed is that they appear each time I have an orderedlist or an itemizedlist in the section. If I put them in a para instead of directly at the level of the section then I don't get the extra numbers anymore. So should I go through all the doc to make things look like that? <para> <orderedlist> ... </orderedlist> </para> Hmmm, I don't see this problem in the postscript version and DocBook doesn't say that the orderedlist elements must be in a para tag. So it looks like a bug in the HTML generation. Does anyone know how to go fix this? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

May 18, 2001

Call for volunteers

by Francois Gouget

Hi, I have built a list of projects that should be easy to tackle by new Wine developpers. The main goal is to provide the needed inspiration to potential Wine developpers that just are not motivated by the standard 'grep FIXME' answer (and I can understand them). I'm posting it here first so that experienced Wine developpers can tell me if I misclassified a project or if they have suggestions for more projects. Once the list seems stable I'll post it on the newsgroup. Easy: * Builtin msvcrt mishandles the cmdline to argv conversion #234: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=234 This prevents 'wine /mnt/win/Program\ Files/whatever/foo.exe' from working if you're using the builtin msvcrt! * Builtin msvcrt mishandles the cmdline to argv conversion #245: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=245 A big bug in how the environment variable is set. * PrgWin95/98: System metrics differ from the Win9x values #48: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=48 One day I'll fix this one... I swear. Unless you want to work on it first. In that case I'll provide you with my test application and dumps of the metrics for Win95, Win98, NT4, ... * winelib lacks VT_DECIMAL support #181: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=181 May require to modify many LOCs, but should be pretty easy to do. * The doc about the command line arguments and the config file is out of date. See TextCP, XVideoPort and Synchronous for instance. I'm sure there are plenty of other things that are out of date. * Metabug: Test Wine with the VXCL samples #242: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=242 Get the VXCL samples, test them with Wine and report the bugs in the bugzilla database. I know there's lots of them. Then people (or yourself) can start fixing these bugs in a distributed fashion. You can probably start reporting the most obvious bugs just by testing in Wine, but for more subtle bugs you will need two computers (or Win4Lin/VmWare) to more easily compare the behavior in Windows and in Wine. * Metabug: Test Wine with the Common Control Spy Samples #239: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=239 Get the Common Control Spy samples and test Wine with them. You will need the native comctl32 dll but you can do the tests without rebooting between each test or using two computers. * PrgWin95: Listbox getting a recessed border instead of a flat one #56: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=56 (I can provide you with the sample application) * I think it would be nice to add a tool that displays the dlls version information like 'About' does in the windows explorer. I have some code you could use as a starting point and I think it could be merged with winver. In fact this would be almost stabdard windows programming. * Tabs are missing their inner border #243: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=243 There's a bug in the drawing of the border of the common control tabs. Fixing each of the four instances of the code is easy. It would be interesting to find a way to factorize some of this code. Medium (I expect these would take longer or be a bit harder) * Provide a pedump utility #91: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91 I know there's sample code that does that already floating around so it should be relatively simple. * wrc fails on preprocessed files #115: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=115 I believe it's just a grammar problem. You'll need to know (or to get cozy with) lex/yacc... * CreateIcon does not resize bitmaps #175: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=175 I did a similar fix somewhere some time ago. I can provide a sample application and I might be able to point you in the right direction. * winemaker: 'winemaker --nomfc' does not have the intended effect #227: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=227 * winemaker: Ignores the '--with-{mfc,wine}' options once they are cached #225: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=225 If you're familiar with autoconf and know how configure scripts should behave... * StrokePath ignores PS_JOIN_xxx #11: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=11 This should not be too difficult to fix but it would certainly help if you are familiar with GDI. * Checking the differences between what's in the Windows dlls and what's in our spec files... and fix the contents of our spec files as appropriate. I already have a list of all the APIs in each of the dlls for Win95, Win98, NT4 and Wine2000, plus a script that can show the differences. * Enhancing the above perl script. In particular it could be made smarter wrt. detecting whether an API is exported by ordinal or not. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

May 17, 2001

Networking with Mandrake 8.0 and SuSE 7.1

by Steve Fox

Repost from wine.users since no reply. Thanks for any help. ------------------------- I'm running Lotus Notes 5.04a under WINE with one of the January releases and its been working great for months. However, any release since February does not seem to do reliable networking on my Mandrake 8.0 system. I can occassionally actually get into my inbox and even open up a message, but I've never been able to read more than one. Some cow-orkers using this same setup on Redhat 7.1 do not have this problem, but others using SuSE 7.1 do too. Does anyone have any ideas why only networking would be affected and only on select distributions? It stumps me because all three mentioned distros use glibc-2.2 and gcc-2.96 (SuSE may use 2.95...not sure). On a related note, another cow-orker who is using Mandrake Cooker (development distro) and his own compiled kernel does not have this problem. I am on a token ring network, which I don't think should matter. -- Steve Fox IBM Linux Technology Center http://oss.software.ibm.com/developerworks/opensource/linux/ http://k-lug.com (Rochester Linux Users Group)

May 17, 2001

Re: Patch for a bug in server/select.c

by Bang Jun-Young

On Wed, May 16, 2001 at 02:09:39PM -0700, Alexandre Julliard wrote: > POLLERR and POLLHUP are legitimate results, and you definitely have to > call the function in that case. POLLNVAL is not supposed to happen, > unless there is a bug in the fd management. Or does NetBSD set > POLLNVAL when the file descriptor is -1? This wouldn't be correct > according to the Single Unix spec. According to the manpage, NetBSD implementation of poll(2) is different from historical one in that a given fd may not cause poll to return with an error. I'm not sure if this is the case, however. Anyway, I'm attaching another patch for it. ChangeLog: * server/select.c: Workaround for a problem that may cause a segfault on NetBSD when the preceding poll returned pollfd.revents with POLLNVAL set. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

May 17, 2001

Re: Patch for a bug in server/select.c

by Alexandre Julliard

Bang Jun-Young <bjy(a)mogua.org> writes: > Suppose that > > ret = poll( pollfd, nb_users, diff ); > > has returned an error bit (either of POLLERR, POLLHUP, or POLLNVAL) > set in pollfd[].revents. Those error codes are defined in positive > numbers in poll.h, so in this case when > > poll_users[i]->ops->poll_event( poll_users[i], pollfd[i].revents ); > > is called, it tries to get an access to an already freed function and > causes a segfault. POLLERR and POLLHUP are legitimate results, and you definitely have to call the function in that case. POLLNVAL is not supposed to happen, unless there is a bug in the fd management. Or does NetBSD set POLLNVAL when the file descriptor is -1? This wouldn't be correct according to the Single Unix spec. -- Alexandre Julliard julliard(a)winehq.com

May 16, 2001

Re: DLL separation and PROFILE functions

by Ove Kaaven

On Tue, 15 May 2001, Ian Pilcher wrote: > DLL separation has been mentioned quite a few times on this list > (usually as the ultimate solution to a problem), but I don't think I've > ever seen it actually defined. Based on my own misadventures in this > area, however, I would hazard a guess that is essentially the conversion > of all inter-DLL function calls from OS-based dynamic linking to the > Wine DLL loading mechanism. Yes, this is needed to be able to have Wine DLLs and Winelib apps be able to seamlessly import and use native PE DLLs. > Under this assumption, adding 'IMPORTS = ntdll' to a DLL's Makefile.in > file (in order to use one of the PROFILE functions) seems like a > definite step backwards. The profile functions are not exported and you should not use them. If you're trying to access the config file, use the registry API instead; for an example, see what Alexandre did in dlls/x11drv/x11drv_main.c. You'll see the reason Alexandre changed the .wine/config file format to the registry format. > ################## > # Wine extensions > # > # All functions must be prefixed with '__wine_' (for internal functions) > # or 'wine_' (for user-visible functions) to avoid namespace conflicts. > > This would seem to indicate that the PROFILE functions (in > files/profile.c) need to have their names changed before they are > exported. Is this an appropriate time to go crazy with grep and sed? You could use #defines in a .h file too, but you shouldn't add wine extensions without a *very* good reason. Alexandre has even advocated code duplication in some instances to keep DLL separation tight.

May 16, 2001

DLL separation and PROFILE functions

by Ian Pilcher

DLL separation has been mentioned quite a few times on this list (usually as the ultimate solution to a problem), but I don't think I've ever seen it actually defined. Based on my own misadventures in this area, however, I would hazard a guess that is essentially the conversion of all inter-DLL function calls from OS-based dynamic linking to the Wine DLL loading mechanism. Under this assumption, adding 'IMPORTS = ntdll' to a DLL's Makefile.in file (in order to use one of the PROFILE functions) seems like a definite step backwards. I think that the proper approach is to add the function in question to dlls/ntdll/ntdll.spec and make sure that the importing DLL lists ntdll.dll as an import in its own SPEC file. All of which is wonderful until you consider the following in ntdll.spec: ################## # Wine extensions # # All functions must be prefixed with '__wine_' (for internal functions) # or 'wine_' (for user-visible functions) to avoid namespace conflicts. This would seem to indicate that the PROFILE functions (in files/profile.c) need to have their names changed before they are exported. Is this an appropriate time to go crazy with grep and sed? (For example, PROFILE_EnumWineIniString would become __wine_EnumIniString.) -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 15, 2001

Re: Crash in MSG_PeekHardwareMsg

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Rein Klazes <rklazes(a)xs4all.nl> writes: >> Dutch tax 2000 declaration setup program crashes at exactly the same >> point. Cause of this seems to be some memory allocation/corruption >> problem. At some point the memory used by the sysMsgQueue, is >> allocated again by some HeapAlloc() and happily used by its >> requester. Alexandre> Does this help? Alexandre> Index: windows/queue.c Yes, it helps for start.exe (heise). Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

May 14, 2001

Re: Crash in MSG_PeekHardwareMsg

by Rein Klazes

On 14 May 2001 12:19:34 -0700, you wrote: > Rein Klazes <rklazes(a)xs4all.nl> writes: > > > Dutch tax 2000 declaration setup program crashes at exactly the same > > point. Cause of this seems to be some memory allocation/corruption > > problem. At some point the memory used by the sysMsgQueue, is > > allocated again by some HeapAlloc() and happily used by its requester. > > Does this help? It does. Thanks! Rein. -- Rein Klazes rklazes(a)xs4all.nl

May 14, 2001

Re: Crash in MSG_PeekHardwareMsg

by Alexandre Julliard

Rein Klazes <rklazes(a)xs4all.nl> writes: > Dutch tax 2000 declaration setup program crashes at exactly the same > point. Cause of this seems to be some memory allocation/corruption > problem. At some point the memory used by the sysMsgQueue, is > allocated again by some HeapAlloc() and happily used by its requester. Does this help? Index: windows/queue.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/queue.c,v retrieving revision 1.70 diff -u -r1.70 queue.c --- windows/queue.c 2001/04/04 00:19:55 1.70 +++ windows/queue.c 2001/05/14 18:55:22 @@ -598,7 +598,7 @@ /* Note: We dont need perQ data for the system message queue */ if (!(hmemSysMsgQueue = QUEUE_CreateMsgQueue( FALSE ))) return FALSE; - + FarSetOwner16( hmemSysMsgQueue, 0 ); sysMsgQueue = (MESSAGEQUEUE *) GlobalLock16( hmemSysMsgQueue ); return TRUE; } -- Alexandre Julliard julliard(a)winehq.com

May 14, 2001

CalcChildScroll

by Bill Medland

Does anyone have a problem with the following fix to windows/mdi.c/CalcChildScroll? It fixes a problem for one product but I am not in a position to test it thoroughly. When measuring the union of the children rectangles only the visible children should be included: .. } else if( pWnd->dwStyle & WS_VISIBLE) UnionRect( &childRect, &pWnd->rectWindow, &childRect ); This stops scrollbars appearing and disappearing while resizing apparently empty mdi clients etc. Bill Medland

May 14, 2001

Re: Crash in MSG_PeekHardwareMsg

by Rein Klazes

On Sat, 12 May 2001 20:56:35 +0200, you wrote: > Hallo, > > the archive viewer "start.exe" for the CDROM archive of german magazine CT > crashes since some time: > > 085a8b90:Ret USER.114: DISPATCHMESSAGE() retval=0x00000000 ret=02ef:005c ds=033f > 085a8b90:Call USER.108: GETMESSAGE(0x033fd1be,0x0000,0x0000,0x0000) ret=02ef:4055 ds=033f > fixme:pthread_kill_other_threads_np > ... > Unhandled exception: page fault on read access to 0xffff0203 > in 32-bit code (0x40a1718f). > In 32-bit mode. > 0x40a1718f (MSG_PeekHardwareMsg+0x4f [message.c:595] in libkeyboard.so): repe movsl (%esi),% > es:(%edi) > 597 nextqmsg = qmsg->nextMsg; > Wine-dbg>bt > Backtrace: > =>0 0x40a1718f (MSG_PeekHardwareMsg+0x4f(msg=0x40d26d28, hwnd=0x0, first=0x0, last=0x0, remove=0x1) [message.c:595] in libkeyboard.so) (ebp=40d26cbc) Dutch tax 2000 declaration setup program crashes at exactly the same point. Cause of this seems to be some memory allocation/corruption problem. At some point the memory used by the sysMsgQueue, is allocated again by some HeapAlloc() and happily used by its requester. I haven't found out why unfortunately. Rein. -- Rein Klazes rklazes(a)xs4all.nl

May 14, 2001

Re: GDB remote debugging

by Ove Kaaven

On Mon, 14 May 2001 =?iso-8859-1?Q?G=E9rard_Patel_=3Cgerard.patel=40asi.fr=3E?=(a)s5.asi.fr wrote: > At 11:12 PM 09/05/2001 +0200, Ove Kaaven wrote: > >For any sufficiently disillusioned Wine hackers, here's my current > >experimental code for letting GDB attach to a Wine process. > <snip> > > Is there any way to debug an application from the beginning using this tool ? > (the reason I would like to try it is of course that the app crashes while starting) > If not, is it thinkable to change the code to wait for gdb to connect when > the initial Wine thread connects to the server ? I put that variable "create_suspended" in gdbremote.c for that purpose... just change it from 0 to 1... ought to be a command-line option, but that patch won't be included in wine in its current form anyway, so...

May 14, 2001

Re: Problem with tooltips

by gerard patel

At 09:56 PM 13/05/2001 +0200, you wrote: <snip tooltip file dialog problem> >Does anyone know how to fix this? http://www.winehq.com/hypermail/wine-devel/2001/05/0035.html (or replace winehq by 130.225.13.222 if the Corel Dns is still down :-/) Gerard

May 14, 2001

Re: Crash in MSG_PeekHardwareMsg

by gerard patel

At 08:56 PM 12/05/2001 +0200, you wrote: >085a8b90:Ret USER.114: DISPATCHMESSAGE() retval=0x00000000 ret=02ef:005c ds=033f >085a8b90:Call USER.108: GETMESSAGE(0x033fd1be,0x0000,0x0000,0x0000) ret=02ef:4055 ds=033f >fixme:pthread_kill_other_threads_np >... >Unhandled exception: page fault on read access to 0xffff0203 > in 32-bit code (0x40a1718f). >In 32-bit mode. >0x40a1718f (MSG_PeekHardwareMsg+0x4f [message.c:595] in libkeyboard.so): repe movsl (%esi),% >es:(%edi) >597 nextqmsg = qmsg->nextMsg; <snip> >Any ideas? There is not much to go on in this information. I can't see this problem with any of my 16 bits apps, but maybe none of them use this kind of GetMessage without specifying a window. I'd suggest first that you compile message.c with optimization level O0 : it seems clear that the displayed instruction is not the one responsible for the crash; the crash happens really in *msg = qmsg->msg. Maybe having no optimization could give more accurate information. When you have done that, rerun and enter info reg and info local when the crash occurs. Also a trace with +relay could be interesting but I think that you know that since you post this tip on cemw often enough :-) Gerard

May 14, 2001

Re: Could someone check this on windoze

by Uhmmmm

On Saturday 12 May 2001 04:14 am, you wrote: > On Fri, May 11, 2001 at 07:24:31PM -0400, Uhmmmm wrote: > > Could someone please doublecheck this. On windoze, does the bitmap in a > > SS_BITMAP style STATIC control change if you send it WM_SETTEXT or call > > SetWindowText() on it like it does in WINE? I don't think it does, but > > I'd like it if someone could check before I start changing things. > > Uh, you don't want to change things there, do you ??? > > The whole code there is completely and totally broken. > In fact it is the cause of a bug that I've been trying to track down > for more than 3 (!) years (whole dialogs get blanked when an icon is drawn, > as the code erases the background, which it shouldn't do at all). > > I've already implemented some parts of the SS_BITMAP and SS_ICON handling, > but it's not complete yet. > > Hmm, so do you want to work on that ? > If so, then you should probably be able to compile lots of test programs, > as the interaction is a bit complicated, and we should Do It Right (tm) > anyway :) > > Just ask me for further information or test programs I already created > to assist in creating a compatible wine implementation in case you want > to work in that area... > > And yes, I could doublecheck this, but not now. I'd like to take a look at those test programs, and I'll see what I can do.

May 13, 2001

Problem with tooltips

by Marcus Meissner

Hi, Start any program that uses the common dialog file open dialog (Win95 style) using -managed. Then move the mouse over any of the toolbar icons. Watch a VERY HUGE window manager window pop up displaying the tooltip text in the upper left corner. Reason for this appears to be some changed flags that lets WIN_WindowNeedsWMBorder fail on tooltips. Does anyone know how to fix this? Adding WS_EX_TOOLWINDOW to the tooltip CreateWindow is probably wrong :/ Ciao, Marcus

May 13, 2001

RE: WINEPS: Read metrics from TrueType fonts

by Nerijus Baliunas

> This patch enables the PostScript driver to read font metrics directly > from TrueType font files with FreeType 2. It looks for font files in > directories listed in the [TrueType Font Directories] section of the > wine config file. For example: > > [TrueType Font Directories] > "dir0" = "/usr/X11R6/lib/X11/fonts/TrueType" > "dir1" = "/usr/share/fonts/default/TrueType" > etc. > > It does not embed the fonts into its output. Ghostscript users can > install their TrueType fonts in Ghostscript (with their Fontmap file or > the GS_FONTPATH environment variable); users printing to PostScript > printers will have to convert their fonts to Type 1 or Type 42 format > and use an external program to add them to the print jobs. Hello, Why don't you add this text to documentation/printing? Regards, Nerijus

May 13, 2001

Crash in MSG_PeekHardwareMsg

by Uwe Bonnes

Hallo, the archive viewer "start.exe" for the CDROM archive of german magazine CT crashes since some time: 085a8b90:Ret USER.114: DISPATCHMESSAGE() retval=0x00000000 ret=02ef:005c ds=033f 085a8b90:Call USER.108: GETMESSAGE(0x033fd1be,0x0000,0x0000,0x0000) ret=02ef:4055 ds=033f fixme:pthread_kill_other_threads_np ... Unhandled exception: page fault on read access to 0xffff0203 in 32-bit code (0x40a1718f). In 32-bit mode. 0x40a1718f (MSG_PeekHardwareMsg+0x4f [message.c:595] in libkeyboard.so): repe movsl (%esi),% es:(%edi) 597 nextqmsg = qmsg->nextMsg; Wine-dbg>bt Backtrace: =>0 0x40a1718f (MSG_PeekHardwareMsg+0x4f(msg=0x40d26d28, hwnd=0x0, first=0x0, last=0x0, remove=0x1) [message.c:595] in libkeyboard.so) (ebp=40d26cbc) 1 0x40a17faf (MSG_PeekMessage+0x30f(type=0x0, msg_out=0x40d26d84, hwnd=0x0, first=0x0, last=0x0, flags=0x1, peek=0x0) [message.c:1187] in libkeyboard.so) (ebp=40d26d44) 2 0x40a185d7 (GetMessage32_16+0x67(msg16_32=0x33fd1be, hWnd=0x0, first=0x0, last=0x0, wHaveParamHigh=0x0) [message.c:1468] in libkeyboard.so) (ebp=40d26da0) 3 0x40a186b0 (GetMessage16+0x30(msg=0x33fd1be, hwnd=0x0, first=0x0, last=0x0) [message.c:1491] in libkeyboard.so) (ebp=40d26dc0) 4 0x409c6e20 (USER_CallFrom16_p_word_lwww+0x30(proc=0x40a18680, args=0x404690a4) [user.spec.c:213] in libkeyboard.so) (ebp=40d26ddc) 5 0x4008d7ae (__wine_call_from_16_word+0x8e [asmrelay.s] in libntdll.so) (ebp=40d26e0c) 6 0x02ef:0x4055 (bp=d1ec) 7 0x02ef:0x4240 (bp=d200) 8 0x02e7:0x5a11 (bp=d26a) 9 0x02e7:0x0063 (bp=0000) Any ideas? Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

May 12, 2001

Wine logo

by Ian Pilcher

Inspiration for the graphically (and accurately) inclined: http://www.sutterhome.com/interactive/in1034.html -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 12, 2001

Re: Could someone check this on windoze

by Andreas Mohr

On Fri, May 11, 2001 at 07:24:31PM -0400, Uhmmmm wrote: > Could someone please doublecheck this. On windoze, does the bitmap in a > SS_BITMAP style STATIC control change if you send it WM_SETTEXT or call > SetWindowText() on it like it does in WINE? I don't think it does, but I'd > like it if someone could check before I start changing things. Uh, you don't want to change things there, do you ??? The whole code there is completely and totally broken. In fact it is the cause of a bug that I've been trying to track down for more than 3 (!) years (whole dialogs get blanked when an icon is drawn, as the code erases the background, which it shouldn't do at all). I've already implemented some parts of the SS_BITMAP and SS_ICON handling, but it's not complete yet. Hmm, so do you want to work on that ? If so, then you should probably be able to compile lots of test programs, as the interaction is a bit complicated, and we should Do It Right (tm) anyway :) Just ask me for further information or test programs I already created to assist in creating a compatible wine implementation in case you want to work in that area... And yes, I could doublecheck this, but not now. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

May 12, 2001

Re: Missing INT21h functions

by Marcus Meissner

On Sat, May 12, 2001 at 08:25:46AM +0100, davep wrote: > Trying (more in hope than expectation) to run an ancient DOS program under > Wine, I get this failure: > > err:int21:DOS3Call int21: unknown/not implemented parameters: > int21: AX 0f9f, BX 005c, CX 0000, DX 005c, SI 008e, DI 005c, DS 107f, ES 109f > > Sure enough, DOS3Call() has a series of functions, including 0fh, which are > unimplemented. > > Is there any reason why these functions should not be implemented? The win31 > sdk doesn't mention any restrictions on which INT21 functions can be used, > neither does Schulman. Not really. But if you want a DOS emulator, use dosemu. Spent more effort getting Windows programs to run in WINE ;) |--------D-210F------------------------------- |INT 21 - DOS 1+ - OPEN FILE USING FCB | AH = 0Fh | DS:DX -> unopened File Control Block (see #01345,#01346) |Return: AL = status | 00h successful | FFh file not found or access denied |Notes: (DOS 3.1+) file opened for read/write in compatibility mode | an unopened FCB has the drive, filename, and extension fields filled | in and all other bytes cleared | not supported by MS Windows 3.0 DOSX.EXE DOS extender | DR DOS checks password attached with AX=4303h | (FAT32 drive) this function will only succeed for creating a volume | label; FAT32 does not support FCBs for file I/O Ciao, Marcus

May 12, 2001

Missing INT21h functions

by davep

Trying (more in hope than expectation) to run an ancient DOS program under Wine, I get this failure: err:int21:DOS3Call int21: unknown/not implemented parameters: int21: AX 0f9f, BX 005c, CX 0000, DX 005c, SI 008e, DI 005c, DS 107f, ES 109f Sure enough, DOS3Call() has a series of functions, including 0fh, which are unimplemented. Is there any reason why these functions should not be implemented? The win31 sdk doesn't mention any restrictions on which INT21 functions can be used, neither does Schulman. Dave Pickles

May 12, 2001

Could someone check this on windoze

by Uhmmmm

Could someone please doublecheck this. On windoze, does the bitmap in a SS_BITMAP style STATIC control change if you send it WM_SETTEXT or call SetWindowText() on it like it does in WINE? I don't think it does, but I'd like it if someone could check before I start changing things.

May 11, 2001

Re: Qusetion From New Developer

by Francois Gouget

On Fri, 11 May 2001, Uwe Bonnes wrote: > >>>>> "Uhmmmm" == Uhmmmm <uhmmmm(a)ameritech.net> writes: > > Uhmmmm> I've been using WINE for a while now, and I thought it was just > Uhmmmm> about time to start helping out. I found some very easy things > Uhmmmm> I can fix (a lot of the FIXMEs in the basic controls (botton, > Uhmmmm> static, etc)). The only problem is that, I'm not sure how to > Uhmmmm> submit the code once I've fixed it. > > Uhmmmm> If someone could let me know, I could start coding. Thanks in > Uhmmmm> advance. > > Have a look at http://www.winehq.com More precisely: * CVS http://www.winehq.com/dev.shtml#CVS The best way to stay up to date. * wine-patches http://www.winehq.com/mailman/listinfo/wine-patches It's best if you subscribe to wine-patches (otherwise each of your emails will go through the moderator) * Wine Developer's Guide: Chapter 4. Submitting Patches http://www.winehq.com/Docs/wine-devel/patches.shtml All you need to know about submitting patches (I hope) Should you run out of FIXMEs (!), don't hesitate to ask for ideas of things to hack on this list. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

May 11, 2001

Re: __compar_fn_t Linuxism in dlls/wineps/afm.c

by Ian Pilcher

Gerald Pfeifer wrote: > > I believe relying on __compar_fn_t in dlls/wineps/afm.c is a Linuxism > recently added to dlls/wineps/afm.c (and only there), Ian. > My apologies. The GNU version of stdlib.h includes the following snippet, which led be to believe that __compar_fn_t was standard: /* Shorthand for type of comparison functions. */ #ifndef __COMPAR_FN_T # define __COMPAR_FN_T typedef int (*__compar_fn_t) (__const void *, __const void *); # ifdef __USE_GNU typedef __compar_fn_t comparison_fn_t; # endif #endif (Trying to show that I'm not a complete idiot!) I have sent a patch in to replace the use of __compar_fn_t with a typedef. Thanks for catching that. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 11, 2001

Wine Logo ?

by Marcus Meissner

Hi, Is the WINE Logo as used by WineHQ available somewhere in higher resolution? I need it for preparation of LinuxTag 2001 :) Ciao, Marcus

May 11, 2001

Re: __compar_fn_t Linuxism in dlls/wineps/afm.c

by Bang Jun-Young

On Fri, May 11, 2001 at 01:09:27PM +0200, Gerald Pfeifer wrote: > I believe relying on __compar_fn_t in dlls/wineps/afm.c is a Linuxism > recently added to dlls/wineps/afm.c (and only there), Ian. I have experienced the same problem with NetBSD. > Given that __compar_fn_t is only used in that single file and nowhere > else, I'd suggest to simply use a typedef of your own instead of the > non-portable __compar_fn_t. -- Could you please have a look? I agree. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

May 11, 2001

Re: win32 binary DLLs -> Unix wrappers?

by Ove Kaaven

On Fri, 11 May 2001, Peter Duthie wrote: > Can anyone please direct me to relevant documentation/examples/code? Take a look at tools/specmaker, its README file tells you what you need to know.

May 11, 2001

Re: win32 binary DLLs -> Unix wrappers?

by Michael Stefaniuc

Hello! On Fri, May 11, 2001 at 01:30:26AM -0400, Peter Duthie wrote: > What I would like to do is take an existing windows DLL for which I have > the SDK but not the source, and write/generate a C++ wrapper that accesses > the code contained therein, and be linked with existing unix programs. > > Eg, say I have X.DLL, X.LIB and X.h > Is there a way using wine that I can generate wrapper code (say > X_wrapper.cc), so that I can link it with a unix program that I would > write around the wrapper? > > Thus I would have the benefits of developing under the unix environment > and libraries, while utilising a necessary proprietary windows DLL. Note, > native windows applications that use this DLL work fine when run under > wine regularly. > > I cannot find documentation for this in the mailing list archives, or the > official docs, although Chapter 5 of the winelib users guide seems to be > the right place to look, it appears to not be written yet. > > Can anyone please direct me to relevant documentation/examples/code? Take a look at aviplay: http://divx.euro.ru/ bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

May 11, 2001

__compar_fn_t Linuxism in dlls/wineps/afm.c

by Gerald Pfeifer

I believe relying on __compar_fn_t in dlls/wineps/afm.c is a Linuxism recently added to dlls/wineps/afm.c (and only there), Ian. Given that __compar_fn_t is only used in that single file and nowhere else, I'd suggest to simply use a typedef of your own instead of the non-portable __compar_fn_t. -- Could you please have a look? Alexandre, in the mean-time please consider my patch below, which gets rid of the build failure at least. /usr/bin/gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o afm.o afm.c afm.c: In function `SortFontMetrics': afm.c:686: `__compar_fn_t' undeclared (first use in this function) afm.c:686: (Each undeclared identifier is reported only once afm.c:686: for each function it appears in.) afm.c:686: syntax error before `UnicodeGlyphByNameIndex' afm.c:698: syntax error before `UnicodeGlyphByNameIndex' afm.c:718: syntax error before `UnicodeGlyphByUV' afm.c:729: syntax error before `AFMMetricsByUV' afm.c:691: warning: `pug' might be used uninitialized in this function afm.c: At top level: afm.c:644: warning: `UnicodeGlyphByNameIndex' defined but not used afm.c:649: warning: `UnicodeGlyphByUV' defined but not used afm.c:654: warning: `AFMMetricsByUV' defined but not used gmake[2]: *** [afm.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/dlls/wineps' gmake[1]: *** [wineps/libwineps.so] Error 2 Thanks, Gerald Index: afm.c =================================================================== RCS file: /home/wine/wine/dlls/wineps/afm.c,v retrieving revision 1.13 diff -u -3 -p -r1.13 afm.c --- afm.c 2001/05/09 17:11:59 1.13 +++ afm.c 2001/05/11 10:58:58 @@ -683,7 +683,7 @@ static BOOL SortFontMetrics() qsort(aglCopy, PSDRV_AdobeGlyphList.size, sizeof(UNICODEGLYPH), - (__compar_fn_t)UnicodeGlyphByNameIndex); + UnicodeGlyphByNameIndex); } for (i = 0; i < afm->NumofMetrics; ++i) @@ -695,7 +695,7 @@ static BOOL SortFontMetrics() pug = bsearch(&ug, aglCopy, PSDRV_AdobeGlyphList.size, sizeof(UNICODEGLYPH), - (__compar_fn_t)UnicodeGlyphByNameIndex); + UnicodeGlyphByNameIndex); if (pug == NULL) { WARN("Glyph '%s' in font '%s' does not have a UV\n", @@ -715,7 +715,7 @@ static BOOL SortFontMetrics() /* typecast avoids compiler warning */ qsort((void *)(afm->Encoding->glyphs), afm->Encoding->size, - sizeof(UNICODEGLYPH), (__compar_fn_t)UnicodeGlyphByUV); + sizeof(UNICODEGLYPH), UnicodeGlyphByUV); for (i = 0; i < afm->Encoding->size; ++i) if (afm->Encoding->glyphs[i].UV >= 0) @@ -726,7 +726,7 @@ static BOOL SortFontMetrics() } qsort(afm->Metrics, afm->NumofMetrics, sizeof(AFMMETRICS), - (__compar_fn_t)AFMMetricsByUV); + AFMMetricsByUV); for (i = 0; i < afm->NumofMetrics; ++i) if (afm->Metrics[i].UV >= 0)

May 11, 2001

Re: Qusetion From New Developer

by Uwe Bonnes

>>>>> "Uhmmmm" == Uhmmmm <uhmmmm(a)ameritech.net> writes: Uhmmmm> I've been using WINE for a while now, and I thought it was just Uhmmmm> about time to start helping out. I found some very easy things Uhmmmm> I can fix (a lot of the FIXMEs in the basic controls (botton, Uhmmmm> static, etc)). The only problem is that, I'm not sure how to Uhmmmm> submit the code once I've fixed it. Uhmmmm> If someone could let me know, I could start coding. Thanks in Uhmmmm> advance. Have a look at http://www.winehq.com Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

May 11, 2001

Qusetion From New Developer

by Uhmmmm

I've been using WINE for a while now, and I thought it was just about time to start helping out. I found some very easy things I can fix (a lot of the FIXMEs in the basic controls (botton, static, etc)). The only problem is that, I'm not sure how to submit the code once I've fixed it. If someone could let me know, I could start coding. Thanks in advance.

May 11, 2001

win32 binary DLLs -> Unix wrappers?

by Peter Duthie

What I would like to do is take an existing windows DLL for which I have the SDK but not the source, and write/generate a C++ wrapper that accesses the code contained therein, and be linked with existing unix programs. Eg, say I have X.DLL, X.LIB and X.h Is there a way using wine that I can generate wrapper code (say X_wrapper.cc), so that I can link it with a unix program that I would write around the wrapper? Thus I would have the benefits of developing under the unix environment and libraries, while utilising a necessary proprietary windows DLL. Note, native windows applications that use this DLL work fine when run under wine regularly. I cannot find documentation for this in the mailing list archives, or the official docs, although Chapter 5 of the winelib users guide seems to be the right place to look, it appears to not be written yet. Can anyone please direct me to relevant documentation/examples/code? Thanks, -peter

May 11, 2001

Re: Add support for NOMINMAX

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Why? It doesn't make a big difference but after all, if min/max are > defined in their own header, why not take advantage of it to avoid > duplication? (I hate duplicating code :-) Because that's not how Windows does it. And I think it's a good thing to avoid unnecessary dependencies between the Windows headers and the MSVC ones. -- Alexandre Julliard julliard(a)winehq.com

May 11, 2001

Re: Add support for NOMINMAX

by Francois Gouget

I noticed that you didn't apply this part of the minmax patch: --- cut here --- Index: include/windef.h =================================================================== RCS file: /home/cvs/wine/wine/include/windef.h,v retrieving revision 1.57 diff -u -r1.57 windef.h --- include/windef.h 2001/05/07 20:14:00 1.57 +++ include/windef.h 2001/05/11 01:17:37 @@ -14,6 +14,9 @@ #define WINVER 0x0500 #include "winnt.h" +#ifndef NOMINMAX +#include "minmax.h" +#endif #ifdef __cplusplus @@ -140,15 +143,6 @@ #define ADD_LOWORD(dw,val) ((dw) = ((dw) & 0xffff0000) | LOWORD((DWORD)(dw)+(val))) #endif -/* min and max macros */ -#ifndef NOMINMAX -#ifndef max -#define max(a,b) (((a) > (b)) ? (a) : (b)) -#endif -#ifndef min -#define min(a,b) (((a) < (b)) ? (a) : (b)) -#endif -#endif /* NOMINMAX */ #ifndef _MAX_PATH /* FIXME: These are supposed to be in stdlib.h only */ --- cut here --- Why? It doesn't make a big difference but after all, if min/max are defined in their own header, why not take advantage of it to avoid duplication? (I hate duplicating code :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

May 11, 2001

[PATCH] Small SetParent fix

by gerard patel

Calling SetParent of a child window does not create a X counterpart in current Cvs if parent = 0. Fixes one at least of the 2 crashes I had pointed to with the User patch of 24 april. ChangeLog: * dlls/x11drv/window.c creates (again) a X counterpart for children windows reparented to 0

May 10, 2001

Re: GDB remote debugging

by eric pouech

> winedbg can't, at least nobody knows > how to attach winedbg to a running process. well, winedbg can... and now everybody *SHOULD* know start winedbg without any argument on commande line then, use command walk process you'll get a list of running processes using the command attach <pid> really attaches to the running process the only drawback of the method (compared to gdb interface) is that the Win32 API doesn't allow to detach the debugger from a running process the only issue is to kill the debuggee (or the debugger) > Anyone is free to migrate my code to winedbg or whatever if they think > they can get around these issues, of course, but I don't plan to spend > more time on this (that's why I submitted it). me neither for the time being A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

May 10, 2001

Re: GDB remote debugging

by Ove Kaaven

On 9 May 2001, Alexandre Julliard wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > I assume Alexandre isn't going to like some of the stuff in here, but I > > suppose it's up to him whether to take it or leave it... > > How did you guess I wouldn't like it? ;-) > > Actually I think it's a neat hack, but it doesn't belong in the server > at all. You should be able to do the same thing as a client-side > process using the Win32 debugging API. It could be either a > stand-alone Winelib app, or a special mode inside winedbg so that you > can reuse some of the code in there. One big problem is that when GDB is attached, it must immediately be known exactly which process to attach to. If the server allocates one socket per process and prints out its port when the process starts, it's easy for the user to choose one, but it's harder for a client process to know. I can also attach and detach gdb at will (if I detach gdb in some exception, winedbg even launches as normal)... winedbg can't, at least nobody knows how to attach winedbg to a running process. Anyone is free to migrate my code to winedbg or whatever if they think they can get around these issues, of course, but I don't plan to spend more time on this (that's why I submitted it). Might be a good (and very useful) job for a new developer, though. Any takers?

May 10, 2001

Small Fixes

by kenon＠go2.pl

Hi, I had some problems with application Super Memo 8.0 . It is an old 16-bit app ( hard for debugging :-) ) written in Borland Delphi (I guess). I wrote a patch and posted to wine-patches two months ago ,but that patch was rejected :-( . Now I have much simpler and I think correct patch solving the problem. --- windows/painting.c_or Wed Mar 28 16:39:17 2001 +++ windows/painting.c Sat May 5 14:19:43 2001 @@ -1710,7 +1710,7 @@ { /* send palette change notification */ HWND hWnd = WindowFromDC( hDC ); - if (hWnd) SendMessageA( HWND_BROADCAST, WM_PALETTECHANGED, hWnd, 0L); + if (hWnd) PostMessageA( HWND_BROADCAST, WM_PALETTECHANGED, hWnd, 0L); } return realized; } There is another bug. When I press <ENTER> the app runs in other way under wine than it runs under Windoze. My workaround ( only workaround ) is --- controls/edit.c_or Thu May 10 03:24:06 2001 +++ controls/edit.c Thu May 10 03:24:10 2001 @@ -849,7 +849,7 @@ case WM_GETDLGCODE: DPRINTF_EDIT_MSG32("WM_GETDLGCODE"); - result = DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS; + result = DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS |DLGC_WANTMESSAGE; if (lParam && (((LPMSG)lParam)->message == WM_KEYDOWN)) { --

May 10, 2001

Re: Is the DECIMAL variant type too long ?

by Francois Gouget

On Thu, 10 May 2001, gerard patel wrote: [...] > Could the DECIMAL type be a pointer to the real data ?? No. The problem is the tagVARIANT type: sizeof(DECIMAL) -> 16 in Windows, 16 in Wine sizeof(VARIANT) -> 16 in Windows, 24 in Wine Oups, that's where the problem is. In Windows DECIMAL is not at the same level as the other fields. It's part of an englobing union: you basically have: union { struct { VARTYPE vt; WORD wReserved1; WORD wReserved2; WORD wReserved3; union { lots of fields... } } DECIMAL decVal; } In Wine decVal is with the other variant fields so the total size of VARIANT is 2+2+2+2+16 -> 24 Temporary fix: comment out decVal. Correct fix: add the global union and update lots of places in Wine to match. Plus on Windows, just for VARIANT, they use n1, n2, n3 as the dummy union/struct names. Hmm... this must be breaking lots of things, sending the quick fix to wine-patches. Any volunteer for the right fix? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

May 10, 2001

Re: Stupid winedbg question

by Francois Gouget

On Wed, 9 May 2001, Marcus Meissner wrote: > On Wed, May 09, 2001 at 08:37:10PM +0200, eric pouech wrote: > > > There's another anomaly. When winedbg is started via the > > > 'just-in-time' debugging feature > > > - it displays all lines in a stair-case fashion. It's as if it was > > > missing a CR (no, I cannot copy/paste an example). > > > - The 'Enter' key does not work. All other keys seem to work > > > fine. I can type 'b', I can use backspace to erase it and type 'quit' > > > instead. But typeing 'Enter' has no effect. Pretty limiting. > > sounds more like a strange xterm behavior; may be the xterm, while > > started > > this way looks for a wrong termcap entry... could you check which value > > has the TERM environment variable when the xterm is started (TRACE("%s", > > getenv("TERM")) > > in win32/console.c after the fork ? > > this may help figuring this out > > > No the problem is that I enable Mouse Input in the Win32 Console, which > disallows Cut & Paste. I think Eric meant it for the staircase effect and Enter not working. I'll try to dump the TERM value if I can reproduce the problem. As often as not the debugger does not start at all because I get into an infinite loop in the SEH handling. So this tells me that cut&paste is implemented with a Win95-like interface rather than the much better NT user interface. In Win95 you have to click on a button to be allowed to select stuff and another to copy, and yet another to paste. In NT a right-click + drag will select stuff. Another right-click will copy it, and a right-click will paste the contents of the clipboard. In any case there's a documentation issue (surprise, surprise)... > You can enable cut & paste by pressing NumLock usually. NumLock has no effect on cut&paste on my machine (but my window manager does not like it). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

May 10, 2001

Is the DECIMAL variant type too long ?

by gerard patel

After the following patch : ChangeSet ID: 989259340138108821120113 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard(a)wine2. 01/05/07 14:15:40 Modified files: include : oleauto.h wtypes.h include/wine : obj_base.h obj_oleaut.h Log message: Francois Gouget <fgouget(a)codeweavers.com> Added support for the DECIMAL type. Names are no longer suffixed with 32! Removed it. Borland Builder 4 crashes while starting :-/ Tracing the crash shows that it hangs immediately after the *first* variant Api access : Call oleaut32.VariantCopyInd(405869b0,40586974) ret=405b2e6b tid=08065a10 trace:ole:VariantCopyInd (0x405869b0, 0x40586974) trace:ole:VariantCopy (0x405869b0, 0x40586974) trace:ole:VariantClear (0x405869b0) Ret oleaut32.VariantCopyInd() retval=00000000 ret=405b2e6b tid=08065a10 Call oleaut32.VariantChangeTypeEx(40586968,405869b0,00000400,00000000,00000003) ret=405b301c tid=08065a10 trace:ole:VariantInit (0x4058685c),stub trace:ole:VariantChangeTypeEx (0x40586968, 0x405869b0 (11), 1024, 0, 3),stub trace:ole:VariantClear (0x40586968) trace:ole:VarI4FromBool ( -1, 0x40586970 ), stub trace:ole:VariantClear (0x4058685c) Ret oleaut32.VariantChangeTypeEx() retval=00000000 ret=405b301c tid=08065a10 err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. I have changed the trace slightly, the 11 listed for the VariantChangeTypeEx shows that the original type is a boolean. The call is trying to change a boolean (11) into an integer (3). The changes in include/wtypes.h are the important ones. Replacing the new DECIMAL type by typedef struct tagDEC { BYTE aa[2]; } DECIMAL; get rid of the crash. If I make the byte array 16 bytes long, same crash as the current Wine behaviour. If I make it 10 bytes long, access violation. If I make it 8 bytes long, it works too. Could the DECIMAL type be a pointer to the real data ?? Gerard

May 9, 2001

Re: GDB remote debugging

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > I assume Alexandre isn't going to like some of the stuff in here, but I > suppose it's up to him whether to take it or leave it... How did you guess I wouldn't like it? ;-) Actually I think it's a neat hack, but it doesn't belong in the server at all. You should be able to do the same thing as a client-side process using the Win32 debugging API. It could be either a stand-alone Winelib app, or a special mode inside winedbg so that you can reuse some of the code in there. -- Alexandre Julliard julliard(a)winehq.com

May 9, 2001

Re: Stupid autoconf question

by Norman Stevens

On Thu, 3 May 2001, Ian Pilcher wrote: > Here is my first cut at adding a check for the FreeType libraries and > header files to the Wine configuration scripts. It's basically a copy > of Marcus' CUPS stuff. > > Since this is the first time I've done anything with autoconf, I figured > I'd post it here for review: > > diff -urN ../wine-20010502cvs/configure.in ./configure.in > --- ../wine-20010502cvs/configure.in Wed May 2 12:57:30 2001 > +++ ./configure.in Thu May 3 01:44:48 2001 > @@ -378,6 +378,19 @@ > ) > AC_SUBST(CUPSLIBS) > > +FREETYPELIBS="" > +dnl **** Check for FreeType 2 **** > +wine_cv_warn_ftsystem_h=no > +AC_CHECK_LIB(freetype,FT_Init_FreeType, > + AC_CHECK_HEADER(freetype2/freetype/ftsystem.h, > + AC_DEFINE(HAVE_FREETYPE) > + FREETYPELIBS="-lfreetype" > + FREETYPEINCL="-I/usr/include/freetype2", FREETYPELIBS=`freetype-config --libs` FREETYPEINCL=`freetype-config --cflags` Norman

May 9, 2001

Re: Stupid winedbg question

by Marcus Meissner

On Wed, May 09, 2001 at 08:37:10PM +0200, eric pouech wrote: > > There's another anomaly. When winedbg is started via the > > 'just-in-time' debugging feature > > - it displays all lines in a stair-case fashion. It's as if it was > > missing a CR (no, I cannot copy/paste an example). > > - The 'Enter' key does not work. All other keys seem to work > > fine. I can type 'b', I can use backspace to erase it and type 'quit' > > instead. But typeing 'Enter' has no effect. Pretty limiting. > sounds more like a strange xterm behavior; may be the xterm, while > started > this way looks for a wrong termcap entry... could you check which value > has the TERM environment variable when the xterm is started (TRACE("%s", > getenv("TERM")) > in win32/console.c after the fork ? > this may help figuring this out No the problem is that I enable Mouse Input in the Win32 Console, which disallows Cut & Paste. You can enable cut & paste by pressing NumLock usually. Ciao, Marcus

May 9, 2001

Re: Stupid winedbg question

by eric pouech

> There's another anomaly. When winedbg is started via the > 'just-in-time' debugging feature > - it displays all lines in a stair-case fashion. It's as if it was > missing a CR (no, I cannot copy/paste an example). > - The 'Enter' key does not work. All other keys seem to work > fine. I can type 'b', I can use backspace to erase it and type 'quit' > instead. But typeing 'Enter' has no effect. Pretty limiting. sounds more like a strange xterm behavior; may be the xterm, while started this way looks for a wrong termcap entry... could you check which value has the TERM environment variable when the xterm is started (TRACE("%s", getenv("TERM")) in win32/console.c after the fork ? this may help figuring this out A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

May 9, 2001

Re: Stupid winedbg question

by eric pouech

> How do I copy-paste something from winedbg? > > A backtrace for instance. Or how do I copy/paste anything to/from any > console application for that matter. well, there are different behaviors based on your xterm conf - holding the shift key while selecting the area may work - there was another trick, using the print screen key (but it no longer works on my latest Xterm...) another solution is to set the debugger variable StdChannelMask to 1 (or the same value as ConChannelMask), you'll get everything on the starting console HTH A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

May 9, 2001

Re: doors IPC

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > Since critical sections are thought to be 'fast' and 'short time' locking > primitives, and Win32 threads should not sleep in a critical section, > we can just give up our timeslice and wait for the other thread that > has the lock to continue. Well, there are tons of places where we will sleep inside a critical section, so it could potentially burn a lot of CPU. That doesn't necessarily make it slower, but it would probably impact other applications more. As usual, the only way to tell is to do benchmarks. -- Alexandre Julliard julliard(a)winehq.com

May 9, 2001