wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: PATCH: set_thread_buffer fixed
by Alexandre Julliard 03 Jun '01

03 Jun '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > Enable 64bit file operations on Linux only for glibc 2.2 or better, > since mmap64 is broken on glibc 2.1. It would be much better to do a configure check. Including features.h from config.h is very ugly IMO (not to mention that mmap64 seems to work fine on my glibc 2.1.3...) -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: PATCH: set_thread_buffer fixed
by Ove Kaaven 03 Jun '01

03 Jun '01

On Sat, 2 Jun 2001, Marcus Meissner wrote: > -/* This is for glibc on Linux, it will turn on 64 bit file support at compile time */ > -#define _FILE_OFFSET_BITS 64 > +#include <features.h> > +/* This is for glibc on Linux, it will turn on 64 bit file support at > + * compile time > + * Since glibc 2.1.x has various degrees of broken mmap64 prototypes, > + * we do not use this on glibc 2.1.x systems. > + */ > +#if (__GLIBC__ >= 2) && (__GLIBC_MINOR__ > 1) > +# define _FILE_OFFSET_BITS 64 > +#endif > + That's probably not going to work. The features.h is the only header that checks whether _FILE_OFFSET_BITS is defined, and it's protected against multiple inclusion, so _FILE_OFFSET_BITS must be defined *before* you include features.h. If you must check version, use autoconf.

1 0

Re: set_thread_buffer (fwd)
by lawson_whitney＠juno.com 02 Jun '01

02 Jun '01

This seems to have bounced once. Hope winehq feels better soon. On Fri, 1 Jun 2001 =?iso-8859-1?Q?G=E9rard_Patel_=3Cgerard.patel=40nerim.net=3E?=(a)tourian.nerim.net wrote: > Just what I have. > > if you verify if you have the same problem as myself, with current cvs > remove the line defining _FILE_OFFSET_BITS. This fixes it for me. > > Gerard > By this I understood to rip #define _FILE_OFFSET_BITS 64 out of config.h (and acconfig.h just to be sure) and rerun make. It recompiles nearly everything, of course, and makes a wine that will run my app again, so I guess it is the same problem. Now, what is the problem? :-/ glibc-2.1.3 - from Mandrake 7.2 - ?? - I am fairly sure I haven't munged any headers myself.. but Mandrake might have. Are <linux/ and <asm/ considered glibc headers? I don't see them in the rpm, but some motorist broke both my legs a while ago and it is too tough to change the CD and see what is in Slackware's glibc-2.1.2. I guess that wouldn't be conclusive anyway. gcc-2.95.2 locally built, with genuine strength-reduce bug. kernel 2.4.4 with devfs? Other? Feels to me like an inconsistancy between headers and library -? Lawson ---cut--- ________________________________________________________________ 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.

1 0

Re:AnimateWindow() constants?
by Eric Pouech 02 Jun '01

02 Jun '01

> I am about to implement the AnimateWindow() function, but I don't have up to > date windows headers. I did some trial and error on a win98 box and came up > with what I think are the correct values, but could somebody check? all correct A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

wine-users down?
by Francois Gouget 02 Jun '01

02 Jun '01

Hi, I didn't receive any message on wine-users since May 30th. Is the mailing list down or is it a problem on my end? There's been many messages since then on the newsgroup. Btw, why is the link to the wine-users archive disabled on WineHQ? (http://www.winehq.com/dev.shtml#ml) I found wine-users archives via Google: http://www.winehq.com/hypermail/wine-users/ And I see in the mailing list archives that there's no message since May 30th either. Looks like a mailing list problem to me... Last question (for this email...): Why do the mailing list archives point to the Integrita archives rather than the WineHQ archives? Is there an advantage of one over the other? -- 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...

2 1

AnimateWindow() constants?
by Bobby Bingham 02 Jun '01

02 Jun '01

I am about to implement the AnimateWindow() function, but I don't have up to date windows headers. I did some trial and error on a win98 box and came up with what I think are the correct values, but could somebody check? AW_SLIDE 0x00040000 AW_ACTIVATE 0x00020000 AW_BLEND 0x00080000 AW_HIDE 0x00010000 AW_CENTER 0x00000010 AW_HOR_POSITIVE 0x00000001 AW_HOR_NEGATIVE 0x00000002 AW_VER_POSITIVE 0x00000004 AW_VER_NEGATIVE 0x00000008 I'm pretty sure about all of them except AW_BLEND because win98 doesn't implement it. Thanks in advance Bobby Bingham uhmmmm(a)ameritech.net

1 0

Finding (or not) the exact number of args
by Gaël de Chalendar 01 Jun '01

01 Jun '01

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.

3 4

Re: critical section blocking
by Duane Clark 01 Jun '01

01 Jun '01

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

3 2

Can MAPI be directed to sendmail from a Windows app on Wine ?
by Steve Ball 01 Jun '01

01 Jun '01

I am running a windows voicemail server under wine and it runs extremely well, but I believe there is no MAPI support in Wine, and the voicemail server complains that there is no MAPI provider. I would not want to install a Windows email client even if I thought I could use MAPI, and would much prefer to use sendmail as the MAPI sender. I don't think it would be difficult to write code that would produce a sendmail mail message from a Wine stub, but I cannot find where the MAPI support goes and I know very little about MAPI under Windows, since I have done very little Windows programming. Has anyone done this before, or could anyone direct me to the hooks in Wine, and preferably some information on how MAPI works in Windows apps. The Wine project is a fantastic achievement, I hope that I can give something back. Steve Ball

1 0

Re: wineps include fix.
by Ian Pilcher 01 Jun '01

01 Jun '01

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 ========================================================================

5 9

Re: WINE server messages
by Alexandre Julliard 01 Jun '01

01 Jun '01

David Howells <dhowells(a)redhat.com> writes: > 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. I still don't see why you want that. The fact that the section list is in the client or in the server is orthogonal to the fact that we maintain a list of modules. If you have a list of mapped views in the server you can simplify the module list a bit by making each module point to the view instead of the backing file, but you still need a module list to send debugger events and do toolhelp snapshots. You could of course hide the module list inside the section list by adding some magic flags to the section descriptor, but all it changes is that you then need to walk the whole section list to retrieve the modules; I don't really see the point. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: set_thread_buffer
by Marcus Meissner 31 May '01

31 May '01

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

2 1

Re: set_errno patch
by Alexandre Julliard 31 May '01

31 May '01

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

1 0

FreeType autoconf checks - please test
by Ian Pilcher 31 May '01

31 May '01

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

2 1

[Fwd: autoconf help needed [was wineps include fix.]]
by Ian Pilcher 31 May '01

31 May '01

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 ========================================================================

1 0

Re: WINE server messages
by Alexandre Julliard 31 May '01

31 May '01

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

2 1

PathGetCharType/PathGetCharTypeA
by Dax Kelson 31 May '01

31 May '01

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

2 3

autoconf help needed [was wineps include fix.]
by Ian Pilcher 31 May '01

31 May '01

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 ========================================================================

2 1

Re: wineps include fix.
by Alexandre Julliard 31 May '01

31 May '01

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

2 1

Re: PATCH: Version 2, GetX11WindowId
by Alexandre Julliard 30 May '01

30 May '01

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

1 0

Re: wineps include fix.
by Alexandre Julliard 30 May '01

30 May '01

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

2 1

Re: wineps include fix.
by Alexandre Julliard 30 May '01

30 May '01

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

3 2

Problems with large file support.
by Ludovic LANGE 30 May '01

30 May '01

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

1 0

Re: PATCH: Version 2, GetX11WindowId
by Alexandre Julliard 30 May '01

30 May '01

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

2 1

PATCH: Version 2, GetX11WindowId
by Nikolas Zimmermann 30 May '01

30 May '01

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

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel