wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

3DMark Bench Results
by Tom Wickline 25 Mar '05

25 Mar '05

Hello, Anyone here interested in seeing some 3DMark Bench Results? If so let me know and ill send yout the .3dp file or a shot. Tom

1 0

Re: Handle wParam in WM_PAINT properly
by Filip Navara 25 Mar '05

25 Mar '05

Dimitrie O. Paun wrote: >ChangeLog > Handle wParam in WM_PAINT properly: if non-null, > it is the hdc we are supposed to use to draw into. > > Hmm, MSDN says that the wParam of WM_PAINT is not used and I always believed it. Are you sure that you're not confusing it with WM_PRINTCLIENT? - Filip

2 1

extra copies of Windows DDK
by Brian Vincent 25 Mar '05

25 Mar '05

Ivan asked me if I could order the Windows DDK and bring it to Wineconf since it's cheaper to ship it here. Well, it seems it was the same price to order 5 copies instead of just one. That leaves 4 extra DDK's available. If you want one, and will be at WineConf, let me know and I'll bring one. -Brian

1 0

Re: saving winrash
by Steven Edwards 25 Mar '05

25 Mar '05

--- Chris Morgan <cmorgan(a)alum.wpi.edu> wrote: > I'm certainly open to having it imported into the wine tree if there is some > desire. Yes. I have enough CVS and SVN trees on my desk without having to manage another and manage dealing with keeping them in sync when they share code. If ReactOS is going to use Winetest and Winrash I really need the winrash sources to be in Winehq CVS or the ReactOS people with either A) fork it or B) write there own service. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Dos pgm loading question (Bug#440 ish)
by Ann and Jason Edmeades 24 Mar '05

24 Mar '05

Hiya, I was trying to confirm an old bug still existed and the bug #440 has a tar file with an exe in it which apparently used to run under wine and fails with some problems later on. Nowdays, it fails dismally when you try to launch it. Disclaimer#1 - I haven't tried a regression test but I have looked through the code at the point of the failure all the way back to before winedos existed (pre this problem report) and cant see how it ever worked. If anyone has a working 2002 version of wine and could try it, I'd appreciate it! Basically we look at the header, and see a # pages of 1, and a count of bytes in the last page of 107, and end up loading something like 38 bytes of the exe. The DOS exe starts with JMP 0x88, so a trap occurs Looking under windows, ntvdm does a load for the header, then a load for 464 bytes from the position where the code starts - For the life of me I cant see how that calculation occurs and where our code is wrong. I know its an extremely trivial problem for an ancient thing that no one will probably ever want running under wine, but it really bugs me - Does anyone have any idea why our calculation is wrong? Jason

2 2

Re: ntdll: Implement NtLoadKey
by Alexandre Julliard 24 Mar '05

24 Mar '05

James Hawkins <truiken(a)gmail.com> writes: > This implementation passes the registry tests. A new server function > is added, mount_key. mount_key is similar to load_registry except > that mount_key can only load a key under HKLM or HKU and the key is > created inside mount_key. To use load_registry, the subkey has to be > created and then passed in as a parameter. load_registry is no longer > used by anything, so if it should be remove, let me know. What you should have done is modify load_registry, there's no reason to create a new request that does the same thing. -- Alexandre Julliard julliard(a)winehq.org

2 3

About
by Giovanni Delvecchio 24 Mar '05

24 Mar '05

hello list, i noted that the patch provided ( http://www.winehq.org/hypermail/wine-devel/2005/03/0624.html ) to fix that problem isn't secure yet, because a symlink attack could be possible if /tmp is a mounted NFS file system. Indeed: 1)The name of the file in /tmp is easly predictable , it uses getpid(); 2)O_EXCL when used with O_CREAT, if the file already exists it is an error and the open will fail. O_EXCL is broken on NFS file systems, programs which rely on it for performing locking tasks will contain a race condition. Possible fix using tempnam() function to generate a psued-random string for tmp file name: _______________________________________________________________ --- misc/registry.c Thu Mar 24 13:36:43 2005 +++ misc/registry.c Thu Mar 24 13:46:46 2005 @@ -1222,12 +1222,11 @@ static LPSTR _get_tmp_fn(FILE **f) { LPSTR ret; - int tmp_fd,count; + int tmp_fd; - ret = _xmalloc(50); - for (count = 0;;) { - sprintf(ret,"/tmp/reg%lx%04x.tmp",(long)getpid(),count++); - if ((tmp_fd = open(ret,O_CREAT | O_EXCL | O_WRONLY,0666)) != -1) break; + for (;;) { + ret = tempnam("/tmp", "reg"); + if ((tmp_fd = open(ret,O_CREAT | O_EXCL | O_WRONLY,0600)) != -1) break; if (errno != EEXIST) { ERR("Unexpected error while open() call: %s\n",strerror(errno)); free(ret); _______________________________________________________________ Best regard, Giovanni Delvecchio -- ______________________________________________ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze

2 1

About [ZH2005-02SA] Insecure tmp file creation in Wine
by Giovanni Delvecchio 24 Mar '05

24 Mar '05

1 0

Re: Treeview plus/minus
by Jon Griffiths 24 Mar '05

24 Mar '05

Hi George, >If I change the size to 18 the plus is drawn correctly >Does anybody knows anything about this ? The native controls draw a different kind of cross for large items, which looks a lot nicer. I added this but the initial threshold for deciding when to draw the large cross was too small, as reported by Ge Van Geldorp from the ReactOS crew - The thread starts here: http://www.winehq.com/hypermail/wine-devel/2004/10/0445.html The size was changed to 18 which seems to work (as you found yourself). I don't know what size or algorithm MS uses to determine when to switch the drawn style, but noone has reported an issue with this since then. You should maybe consider working with a more up to date Wine version, since that patch was committed over 2 months ago. Hope that helps, Jon "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

1 0

Re: [OLE #84] Don't use IsBadStringPtr on NULL pointers
by Alexandre Julliard 24 Mar '05

24 Mar '05

Mike Hearn <mike(a)navi.cx> writes: > Don't use IsBadStringPtr on NULL pointers If the goal is to avoid exceptions, then it would be better to do that check directly in the IsBad* functions. -- Alexandre Julliard julliard(a)winehq.org

1 0

Treeview plus/minus
by George Ginden 24 Mar '05

24 Mar '05

Talking about the plus / minus symbols in the treeview control... Why with a size of 16 the plus symbol looks more like a small circle than a cross ? If I change the size to 18 the plus is drawn correctly Does anybody knows anything about this ? Regards. @@ -2329,7 +2330,7 @@ SelectObject(hdc, hOldPen); DeleteObject(hNewPen); - if (height < 16 || width < 16) + if (height < 18 || width < 18) {

1 0

[RFC] Pager: why do we implement WM_NCPAINT instead of WM_PAINT?
by Dimitrie O. Paun 24 Mar '05

24 Mar '05

Hi folks, Does anyone know why the Pager common control (dlls/comctl32/pager.c) implements WM_NCPAINT instead of WM_PAINT? It is the only exception to the rule, all other controls implement WM_PAINT. -- Dimi.

2 1

World of Warcraft
by cyrix12＠cox.net 24 Mar '05

24 Mar '05

Sorry to keep bugging you guys about this, but a recent patch broke the opengl mode of World of Warcraft again. It simply fails to start, similar to the d3d mode (except for the fact that I know why d3d mode doesn't work as of now). I was scanning through the traces and saw no errors though. Seemed odd to me, but I'm not a wine programmer so I'm not exactly sure what to look for anyway. If anyone wants me to send a any sort of debug log (if, for instance, you don't have copy of WoW to test on), let me know (include what you'd want to see as well, if you don't mind). Thanks in advance, Darckness

3 7

Segfault in X11DRV_DIB_BuildColorTable (DIB_PAL_COLORS)
by Jesse D Zbikowski 23 Mar '05

23 Mar '05

I am experiencing a crash during startup of an application (The Rosetta Stone 2.0.7a) under Wine. I reported this earlier on wine-users and after some debugging was advised to move to this list. The line causing a problem is dlls/x11drv/dib.c:425 417 HPALETTE hpal = GetCurrentObject(physDev->hdc, OBJ_PAL); 418 PALETTEENTRY pal_ents[256]; 419 WORD *index = (WORD*) ((LPBYTE) info + (WORD) info->bmiHeader.biSize); 420 421 GetPaletteEntries(hpal, 0, 256, pal_ents); 422 423 for(i = 0; i < colors; i++, index++) 424 { =>425 colorTable[i].rgbRed = pal_ents[*index].peRed; 426 colorTable[i].rgbGreen = pal_ents[*index].peGreen; 427 colorTable[i].rgbBlue = pal_ents[*index].peBlue; 428 colorTable[i].rgbReserved = 0; 429 } This happens when X11DRV_DIB_BuildColorTable() is called with coloruse==DIB_PAL_COLORS, meaning we use an 8-bit palette. It seems to me that (LPBYTE)info must be corrupt and is giving a corrupt value to (WORD)index. Wine-dbg>p i 0 Wine-dbg>p colorTable[i] {rgbBlue=0, rgbGreen=0, rgbRed=0, rgbReserved=0} Wine-dbg>p pal_ents {{peRed=0, peGreen=0, peBlue=0, peFlags=0}, ... } Wine-dbg>p pal_ents[0] {peRed=, peGreen= Exception c0000005 Wine-dbg>p index 0x77aaec20 Wine-dbg>p *index No type or type mismatch Wine-dbg>p info fixme:winedbg:print_value ---error Here is the backtrace. fixme:font:GetKerningPairsW (0x1a28,0,(nil)): almost empty stub! First chance exception: page fault on read access to 0x77ab71cc in 32-bit code (0x7fea1e53). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7fea1e53 ESP:77aae66c EBP:77aaea98 EFLAGS:00010287( - 00 RISP1C) EAX:000022d0 EBX:7fef22c4 ECX:7786aee0 EDX:00000000 ESI:7e042900 EDI:77aaec20 Stack dump: 0x77aae66c: 00000044 00000000 00000100 77aae68c 0x77aae67c: 00000400 00000000 00000100 00000001 0x77aae68c: 00000000 00000080 00008000 00008080 0x77aae69c: 00800000 00800080 00808000 00c0c0c0 0x77aae6ac: 00c0dcc0 00f0caa6 00f0fbff 00a4a0a0 0x77aae6bc: 00808080 000000ff 0000ff00 0000ffff Backtrace: =>1 0x7fea1e53 X11DRV_DIB_BuildColorTable+0x173(physDev=0x7e042408, coloruse=0x1, depth=0x8, info=0x77aaebf8) [/home/jesse/wine/dlls/x11drv/dib.c:425] in x11drv (0x77aaea98) 2 0x7feaa20b X11DRV_DIB_CreateDIBSection+0x22b(physDev=0x7e042408, bmi=0x77aaebf8, usage=0x1, bits=0x7d7703ec, section=0x0, offset=0x0, ovr_pitch=0x0) [/home/jesse/wine/dlls/x11drv/dib.c:4749] in x11drv (0x77aaeb5c) 3 0x77824ab3 DIB_CreateDIBSection+0xa3(hdc=0x5b5c, bmi=0x77aaebf8, usage=0x1, bits=0x7d7703ec, section=0x0, offset=0x0, ovr_pitch=0x0) [/home/jesse/wine/dlls/gdi/dib.c:1107] in gdi32 (0x77aaeb90) 4 0x77824b28 CreateDIBSection+0x48(hdc=0x5b5c, bmi=0x77aaebf8, usage=0x1, bits=0x7d7703ec, section=0x0, offset=0x0) [/home/jesse/wine/dlls/gdi/dib.c:1125] in gdi32 (0x77aaebb8) 5 0x690323bb 1680 in iml32 (0x7b1c7b8c) 6 0x00000264 (0x00000010) 7 0x00000000 (0x00000000) 0x7fea1e53 X11DRV_DIB_BuildColorTable+0x173 [/home/jesse/wine/dlls/x11drv/dib.c:425] in x11drv: movzbl 0xfffffbf4(%ebp,%eax,4),%eax 425 colorTable[i].rgbRed = pal_ents[*index].peRed; I can add a breakpoint before we get here and try to step through, although the flow seems to skip around a bit. Wine-dbg>b X11DRV_DIB_BuildColorTable Breakpoint 1 at 0x7fea1d04 X11DRV_DIB_BuildColorTable+0x24 [/home/jesse/wine/dlls/x11drv/dib.c:377] in x11drv Wine-dbg>cond 1 (coloruse == 1) 417 HPALETTE hpal = GetCurrentObject(physDev->hdc, OBJ_PAL); Wine-dbg>n 419 WORD *index = (WORD*) ((LPBYTE) info + (WORD) info->bmiHeader.biSize); Wine-dbg>n 417 HPALETTE hpal = GetCurrentObject(physDev->hdc, OBJ_PAL); Wine-dbg>n 421 GetPaletteEntries(hpal, 0, 256, pal_ents); Wine-dbg>n 419 WORD *index = (WORD*) ((LPBYTE) info + (WORD) info->bmiHeader.biSize); Wine-dbg>n 421 GetPaletteEntries(hpal, 0, 256, pal_ents); Wine-dbg>n 423 for(i = 0; i < colors; i++, index++) Wine-dbg>n 421 GetPaletteEntries(hpal, 0, 256, pal_ents); Wine-dbg>n 423 for(i = 0; i < colors; i++, index++) Wine-dbg>n 425 colorTable[i].rgbRed = pal_ents[*index].peRed; Wine-dbg>s 868 switch(rec->ExceptionCode) Wine-dbg>s 867 { Wine-dbg>s 868 switch(rec->ExceptionCode) Wine-dbg>s 873 if (!(rec->ExceptionCode = VIRTUAL_HandleFault( (void *)rec->ExceptionInformation[1] ))) Wine-dbg>s 1125 DWORD ret = EXCEPTION_ACCESS_VIOLATION; I am using the latest Wine I built from CVS, after first encountering this problem in the 20050111 and 20050310 Gentoo ebuilds. I have a Linux 2.6.11 system with glibc 2.3.4 20040808 (including nptl), Xorg-x11 6.8.2-rc2 (Trident Cyberblade/i1 "trident_drv.o") @1024x768 16bpp. Also tried kernels 2.6.9 & 2.6.10 and 800x600 24bpp mode. Would appreciate any advice on how to proceed. http://www.winehq.org/hypermail/wine-users/2005/03/0293.html http://www.winehq.org/hypermail/wine-users/2005/03/0296.html http://appdb.winehq.org/appview.php?appId=1867 Thanks, Jesse Z.

2 2

[AppDB] Application queue: Getting ahead of me.
by Tony Lambregts 23 Mar '05

23 Mar '05

I will be unable to tend to the application queue for the next week and as a matter of fact I am already behind maintaining it. (sorry). If one of you good souls (with administrative rights) could take could take care of it for the next week I would really appreciate it. Thanks. -- Tony Lambregts

1 0

World of Warcraft
by cyrix12＠cox.net 23 Mar '05

23 Mar '05

What I meant to say in the previous message was something along the lines of "Here's an opengl trace; let me know if you need any others." Unfortunately, it seemed to come out in some other language which I am not familiar in. So here's the opengl trace. Darckness

1 0

Re: DDRAW: Surface locking patch, take 2
by Tony Lambregts 23 Mar '05

23 Mar '05

Matthew Mastracci wrote: > This patch (correctly) fixes the locking problems in SimCity 3000. We > now check to see if the blit src and dest are the same surface and, if > so, we make sure to lock the surface only once and, in the case of > BltFast, re-adjust the surface pointers. This patch also makes sure the > surfaces are correctly unlocked if a bad rectangle is passed. > > ChangeLog > Correctly lock and unlock surface for a single-surface Blt() and > BltFast() call. > Is there anything wrong with this patch. http://www.winehq.org/hypermail/wine-patches/2005/03/0113.html It works fine for me (and SimCity). and I was wondering why it was not applied. -- Tony Lambregts

1 0

Riched20: regression "beta" not shown; tab-wish
by Tobias Burnus 23 Mar '05

23 Mar '05

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 23 Mar '05

23 Mar '05

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 23 Mar '05

23 Mar '05

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 23 Mar '05

23 Mar '05

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 23 Mar '05

23 Mar '05

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 23 Mar '05

23 Mar '05

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 23 Mar '05

23 Mar '05

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 23 Mar '05

23 Mar '05

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

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