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

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