March 2005 - Wine-Devel - list.winehq.org

Riched20: regression "beta" not shown; tab-wish
by Tobias Burnus March 23, 2005

March 23, 2005

Hello, first I'd really like to thank the riched20 workers, notably Krzysztof Foltman and Phil Krylov. For the application Diamond it made a big difference: Instead of "[[Aring]]" etc. one sees the proper symbol and it looks much nicer. But the biggest advantage is that one can now copy or save the text; before the app was simply crashing! Regression: One of the later riched20 patches, possibly http://cvs.winehq.org/patch.py?id=16672, caused a regression with the richedit control in Diamond. Before it showed a beta character from the Symbol font, now it only shows a box ("[]"). If one saves the output (rtf export) one sees ------------------- {\rtf1\ansi\ansicpg1252\uc1\deff0\deflang1031\deflangfe1031{\fonttbl{\f0 Times New Roman;} {\f1\fcharset0 System;} {\f2\fcharset2 Symbol;} }{\*\generator Wine Riched20 2.0.????;}\pard\li0\fi0\ri0{\b\fs18\ul Bibliographic data} \par\pard\li0\fi0\ri0 [...] \par\pard\li0\fi0\ri0{\fs18 }{\i\fs18 b}{\fs18 = 5.8312(2) \'c5} \par\pard\li0\fi0\ri0{\fs18 }{\i\fs18 c}{\fs18 = 7.9564(2) \'c5} \par\pard\li0\fi0\ri0{\fs18 }{\fs18\f2 \u61538?}{\fs18 = 100.77(0) \u176?} ------------------- In the last line, after the \f2 (Symbol font), there should be a beta ("b" + Symbol font). Trace (starting from the "b = 5.8312(2)"): ------------ trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 177), counted = 177, len = 1, txt = "L"b"", flags=00000000, fx&mask = 44000002 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 178), counted = 178, len = 14, txt = "L" = 5.8312(2) \00c5"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 192), counted = 192, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets para, real ofsp = 193, counted = 193 trace:richedit:ME_CheckCharOffsets run, real ofs = 0 (+ofsp = 193), counted = 193, len = 1, txt = "L"\t"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 194), counted = 194, len = 1, txt = "L"c"", flags=00000000, fx&mask = 44000002 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 195), counted = 195, len = 14, txt = "L" = 7.9564(2) \00c5"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 209), counted = 209, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets para, real ofsp = 210, counted = 210 trace:richedit:ME_CheckCharOffsets run, real ofs = 0 (+ofsp = 210), counted = 210, len = 1, txt = "L"\t"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 211), counted = 211, len = 1, txt = "L"\f062"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 212), counted = 212, len = 14, txt = "L" = 100.77(0) \00b0"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 226), counted = 226, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 ------------ * * * * One feature request: Currently, tabs are shown as box ("[]"), how about replacing them with a simple space - that would increase the readability a lot. Compare: WINE-CVS: http://www.physik.fu-berlin.de/~tburnus/wine/diamond3.png Windows: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list.png Tobias

1 0

Re: Native stack overlapping system heap base address on some systems
by Steven Edwards March 23, 2005

March 23, 2005

Hi, --- Alexandre Julliard <julliard(a)winehq.org> wrote: > > Surprise surprise, 0x7fffb000 + (1024 * 20) == 0x80000000 This looks like what I have seen on some users systems running Suse 9.2. Some users see errors like this err:virtual:NtMapViewOfSection map_file_into_view 0x80000000 1000000 000000000 failed err:heap:HEAP_CreateSystemHeap system heap base address 0x80000000 not available > No it doesn't overlap, a 20K mapping at 7fffb000 ends at > 7fffffff. Most likely that kernel is configured for a 2Gb virtual > address space. I will recompile a kernel with 2GB and see what happens. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Re: lostwages/templates/en contributing.template j ...
by Jakob Eriksson March 23, 2005

March 23, 2005

I submitted a patch for all casts I could find with that little grep: find . -name "*.[ch]" | xargs egrep "\) *Heap(Re)?Alloc" Jeremy Newman wrote: >ChangeSet ID: 16817 >CVSROOT: /opt/cvs-commit >Module name: lostwages >Changes by: jnewman(a)wine.codeweavers.com 2005/03/23 08:56:08 > >Modified files: > templates/en : contributing.template janitorial.template > resources.template sending_patches.template > status.template > >Log message: > Mike McCormack <mike(a)codeweavers.com> > * suggest janitoral project > * other updates and W3 fixes > >Patch: http://cvs.winehq.org/patch.py?id=16817 > >Old revision New revision Changes Path > 1.24 1.25 +3 -3 lostwages/templates/en/contributing.template > 1.73 1.74 +17 -7 lostwages/templates/en/janitorial.template > 1.11 1.12 +1 -1 lostwages/templates/en/resources.template > 1.11 1.12 +2 -0 lostwages/templates/en/sending_patches.template > 1.33 1.34 +1 -1 lostwages/templates/en/status.template > > >

1 0

Native stack overlapping system heap base address on some systems
by Mike Hearn March 23, 2005

March 23, 2005

Hi, Bug #2741 comes from a user who was able to grab a dump of the VM mappings when the following error occurred: HEAP_CreateSystemHeap system heap base address 0x80000000 not available I know people have been seeing this intermittently for a while now, we have a few CodeWeavers support tickets with this problem too. The issue seems to be that the Linux native (main thread) stack was allocated here: 7fffb000 20K rwx-- [ stack ] Surprise surprise, 0x7fffb000 + (1024 * 20) == 0x80000000 Unfortunately I lack enough knowledge about the kernels VM algorithms to say why it's being allocated here. For comparison on my Fedora Core 3 machine: fef0d000 16K rwx-- [ stack ] One other thing I don't understand. It seems the stack and the system heap overlap by exactly 1 byte, otherwise the mmap would not fail. But, this area is (theoretically) being protected by the preloader: so how can this be? There is something I'm missing here, I suspect an off-by-one error in my arithmetic. thanks -mike

2 1

Re: Warn users who attempt to use native DirectDraw
by Andreas Mohr March 23, 2005

March 23, 2005

Hi, On Tue, Mar 22, 2005 at 02:26:43PM +0000, Mike Hearn wrote: > + MESSAGE("**********************************************************************"); > + MESSAGE("* Native DirectDraw is not supported, please remove it and try again *"); > + MESSAGE("**********************************************************************"); For such a big message it's still rather unclear/misleading. What about something similar to: *************** Native DirectDraw is not supported by Wine! *************** ****** Please disable loading of any native DDraw DLLs and try again ****** Andreas Mohr

6 7

Re: fix wrc to parse some Borland dialog resources
by Michael Lin March 23, 2005

March 23, 2005

Robert Shearman wrote: >Filip Navara wrote: > >> Michael Lin wrote: >> >>> * change wrc to parse '&' and '~' when specifying style >> >> >> I believe the attached patch would be better solution...you can use >> arbitrary expressions in the style definitions with Microsoft Resource >> Compiler... >In that case, "style '|' style" and "tNOT xpr" are already handled by >the xpr rules so this can be made a lot simpler. Hi all, Just want to bring up this topic again. From what Robert suggested, the style rule can be reduced to the following: style : xpr { $$ = new_style($1, 0); } ; However, this will render the style->and_mask useless as it is never used. In style expression, '~' and tNOT are treated differently. '~' is applied as it is parsed, ie from left to right like normal expressions. However, tNOT is applied at the very end, after all other or_mask are combined and I believe this is why there are or_mask and and_mask in style. xpr won't work here as it treats tNOT and '~' the same. So adding '&' and '~' might be a better solution here. Michael

1 0

Re: registry TODO
by Steven Edwards March 23, 2005

March 23, 2005

Hi, --- Boaz Harrosh <boaz(a)hishome.net> wrote: > How is ReactOS's current (future) system? I think ReactOS's registry is binary compatible with NT4. It and the windows 2000 format was documented/reversed for samba and the linux ntchpwd bootdisk projects. If I remeber right Eirc Kohl offered to release some of his work to Wine for the binary format so you might want to ping him about the implementation details. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Re: dlls/user/button.c - fix AUTO3STATE with BS_OWNERDRAW (Resend)
by Alexandre Julliard March 23, 2005

March 23, 2005

Michael Lin <mlin(a)corvu.com.au> writes: > inline static UINT get_button_type( LONG window_style ) > { > - return (window_style & 0x0f); > + if ((window_style & BS_OWNERDRAW) == BS_OWNERDRAW) > + return BS_OWNERDRAW; > + else > + return (window_style & 0x0f); BS_OWNERDRAW is not a bit mask, this won't work right. What is the problem you are trying to fix? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: Warn users who attempt to use native DirectDraw
by Vincent Béron March 22, 2005

March 22, 2005

Le mar 22/03/2005 à 09:26, Mike Hearn a écrit : [snip] > Index: dlls/gdi/gdi_main.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/gdi_main.c,v > retrieving revision 1.17 > diff -u -p -d -r1.17 gdi_main.c > --- dlls/gdi/gdi_main.c 15 Jan 2004 00:35:40 -0000 1.17 > +++ dlls/gdi/gdi_main.c 22 Mar 2005 14:15:33 -0000 > @@ -24,9 +24,12 @@ > #include "winbase.h" > #include "wingdi.h" > #include "wine/winbase16.h" > +#include <wine/debug.h> Please use "" instead of <> here. Vincent

1 0

msi.spec different parameter count of exported functions
by Stefan Leichter March 22, 2005

March 22, 2005

Hello, when played with native msi.dll i found three functions with have a different parameter count between msi.spec of wine and the native dll. Here are the snoop logs of the native dll and wine: 0009:RET msi.MsiDatabaseImportA(00000000,00000000,00000000) retval=00000006 ret=004013fc 0009:RET msi.MsiDatabaseImportW(00000000,00000000,00000000) retval=00000006 ret=004013fc 0009:RET msi.MsiCreateAndVerifyInstallerDirectory(00000000) retval=00000000 ret=004013fc I have used the msi.dll version 2.6.2600.11833 for testing. The question now is: Can we trust the +snoop logging? Bye Stefan

2 2