wine-devel February 2005

wine-devel@winehq.org

157 participants
316 discussions

Re: ntdll/time.c - TZ_INFO
by Uwe Bonnes 14 Feb '05

14 Feb '05

>>>>> "Marcelo" == Marcelo Duarte <wine-devel(a)bol.com.br> writes: Marcelo> Hi, In my system/language I see some messages: Marcelo> fixme:ntdll:TIME_GetTZAsStr Can't match system time zone name Marcelo> "BRST" to an entry in TZ_INFO fixme:ntdll:TIME_GetTZAsStr Marcelo> Please add appropriate entry to TZ_INFO and submit as patch to Marcelo> wine-patches Marcelo> And before to update TZ_INFO I modifyied the FIXME and I think Marcelo> that it explain better the problem: fixme:ntdll:TIME_GetTZAsStr Marcelo> Can't match system time zone name "BRST", bias=120 and dst=1 to Marcelo> an entry in TZ_INFO. Please add appropriate entry to TZ_INFO Marcelo> and submit as patch to wine-patches Marcelo> And I see the real problem. In TZ_INFO bias=180 and dst=0. I Marcelo> added another BRST information. Is this correct? I don't live in the Brasilian Timezone, so I cant tell. Maybe the old entry was wrong, or there is a mixup with standard and summer time... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 3

Re: mmtimer resolution question
by Robert Reif 14 Feb '05

14 Feb '05

Jeremy White wrote: > > You might try putting traces around the > conditional YieldExecution on line 730 > of ntdll/sync.c and see if that chews up time; > if it does, removing the Yield might help. Removing the Yield fixes a regression in Need For Speed III where the loader and server consume 100% of the CPU. This is with RH 9 which is a 2.4 kernel.

4 11

Re: mmtimer resolution question
by Jeremy White 13 Feb '05

13 Feb '05

I'm taking a public thread that I responded to privately back to public view: Robert Reif wrote: > Jeremy White wrote: > >>> Putting traces into the mmtimer thread loop shows >>> WaitForSingleObject is sleeping for about 20 ms and then >>> calling the callback twice to catch up. >> >> >> >> Well, that means mmtimer is right. >> >> You might try putting traces around the >> conditional YieldExecution on line 730 >> of ntdll/sync.c and see if that chews up time; >> if it does, removing the Yield might help. >> >> > Interesting results. It fixes the sound quality and FIXME problem > but it is still going about 20 ms between callback pairs. > > Could the yield just be aggravating the timer resolution problem? I think this is the thread priority problem I mentioned earlier. The behavior of winmm is correct; it is supposed to deliver every single timer request, even if it has to double or triple (or more!) up to do it. I verified that very carefully on Windows. The reason you see pretty steady 10 ms resolution on Windows is that the winmm thread on Windows is flagged as a priority 15 thread, so it does not get interrupted or time sliced away; it fires precisely when it wants to. It's much harder to achieve the same thing on Linux, sadly. Hmm. As I sit here and think about this, though, I do find myself a little bit puzzled. I would have expected that, if my understanding is right, you would have seen much more dramatic time gaps. On a 2.6 kernel, for example, I would expect you to see jumps on the order of 100 ms (hence ten winmm requests fired). And exactly 20 ms spacing is a little too consistent and interesting a number; it suggests that there is a more precise understanding that should be available. That may be a function of the test program, though. I suspect in a 'real' program, where other active threads are demanding more cpu that you might get more sporadic results. It might be interesting to add a spin looping thread to the test case and see if you suddenly get larger gaps. Cheers, Jeremy

4 13

Problem to minimize a window
by Maxime Bellengé 13 Feb '05

13 Feb '05

Hello, Has anybody managed to minimize a window in managed mode since this patch ? Maximizing and restoring a window works but minimizing does not work, the window minimizes and then reopen itself immediately. I doubt it is a problem with my window manager (metacity), however I tried all this afternoon to identify the problem with no success. Thanks Max ChangeSet ID: 15812 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard(a)wine.codeweavers.com 2005/01/31 10:34:07 Modified files: dlls/x11drv : x11drv.h winpos.c window.c mouse.c dlls/wined3d : directx.c dlls/d3d8 : directx.c Log message: Only create an X window for top-level windows, not for child windows. Get rid of the X client window too, it's no longer needed. Patch: http://cvs.winehq.org/patch.py?id=15812

3 3

Numpad evilness
by Crestez Leonard 13 Feb '05

13 Feb '05

I've found a wierd bug in keyboard handling. The problem is that wine doesn't seem to correctly translate key board messages. The program receives WM_KEYDOWN VK_NUMPAD2 and WM_KEYUP VK_DOWN(really bad). I've traced the bug to dlls/x11drv/keyboard.c. Apparently EVENT_event_to_vkey correctly converts KeyPress message, but not KeyRelease messages. If you look at the source code there is a hack of sorts for numpad keys. EVENT_event_to_vkey calls something from X to get a keysym, and does some special handling for numpad 0-9 and dot. Apparently for the KeyRelease event that doesn't work, keysym comes back as 0, causing EVENT_event_to_vkey to malfunction. This bug doesn't always happen (but it does most of the time). I'm scared this might be a bug in my X, but I hope it's not. BTW, isn't there a better way to handle numpad stuff? Here is the relevant portion of the wine log: trace:key:X11DRV_KeyEvent type 2, window 3600001, state 0x0010, keycode 0x0058 trace:key:X11DRV_KeyEvent state = 10 nbyte = 1, status 0x4 trace:key:X11DRV_KeyEvent KeyPress : keysym=FFB2 (KP_2), # of chars=1 / 0x32 / '2' trace:key:X11DRV_KeyEvent keycode 0x58 converted to vkey 0x62 trace:key:X11DRV_KeyEvent bScan = 0x50. trace:key:queue_kbd_event wParam=0062, lParam=40500001, InputKeyState=81 trace:msg:MSG_peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10022 wp 62 lp 40500001 trace:msg:MSG_peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10022 wp 62 lp 40500001 trace:key:TranslateMessage (WM_KEYDOWN, 0062, 40500001) trace:key:TranslateMessage Translating key VK_NUMPAD2 (0062), scancode 50 trace:msg:GetKeyboardState (0x778da29c) trace:key:X11DRV_ToUnicodeEx (0062, 4050) : faked state = 0x0010 trace:key:X11DRV_ToUnicodeEx type 2, window 3600001, state 0x0010, keycode 0x0058 trace:key:X11DRV_ToUnicodeEx Translating char 0x32 to unicode trace:key:X11DRV_ToUnicodeEx ToUnicode about to return 1 with char 32 trace:key:TranslateMessage 1 -> PostMessageW(0x10022,WM_CHAR,0032,40500001) trace:msg:PostMessageW hwnd 0x10022 msg 102 (WM_CHAR) wp 32 lp 40500001 trace:msg:GetKeyState key (0x14) -> 0 trace:msg:MSG_peek_message got type 6 msg 102 (WM_CHAR) hwnd 0x10022 wp 32 lp 40500001 trace:msg:MSG_peek_message got type 6 msg 102 (WM_CHAR) hwnd 0x10022 wp 32 lp 40500001 trace:key:TranslateMessage (WM_CHAR, 0032, 40500001) trace:key:X11DRV_KeyEvent type 3, window 3600001, state 0x0010, keycode 0x0058 trace:key:X11DRV_KeyEvent state = 10 nbyte = 0, status 0x1 trace:key:X11DRV_KeyEvent KeyRelease : keysym=0 (No Name), # of chars=0 / 0x00 / '' trace:key:EVENT_event_to_vkey e->keycode = 58 trace:key:X11DRV_KeyEvent keycode 0x58 converted to vkey 0x28 trace:key:X11DRV_KeyEvent bScan = 0x50. trace:key:queue_kbd_event wParam=0028, lParam=c0500001, InputKeyState=0 trace:msg:MSG_peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10022 wp 28 lp c0500001 trace:msg:MSG_peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10022 wp 28 lp c0500001 trace:key:TranslateMessage (WM_KEYUP, 0028, C0500001)

1 0

RtlFillMemoryUlong
by Dietrich Teickner 13 Feb '05

13 Feb '05

With one inline asm-statement this function would smaler and faster. And the comment for * ulCount [I] Number of bytes to write need change. And one question, How can I start ntdll_test.exe.so in wine ? Dietrich /************************************************************************* * RtlFillMemoryUlong [NTDLL.@] * * Fill memory with a 32 bit (dword) value. * * PARAMS * lpDest [I] Bitmap pointer * ulCount [I] Number of bytes to write * ulValue [I] Value to fill with * * RETURNS * Nothing. */ VOID WINAPI RtlFillMemoryUlong(ULONG* lpDest, ULONG ulCount, ULONG ulValue) { TRACE("(%p,%ld,%ld)\n", lpDest, ulCount, ulValue); #if 1 ulCount /= sizeof(ULONG); __asm__ __volatile__("rep stosl" : :"D" (lpDest), "c" (ulCount), "a" (ulValue)); #else ulCount /= sizeof(ULONG); while(ulCount--) *lpDest++ = ulValue; #endif }

3 2

Re: REGION_FrameRgn fix.
by Filip Navara 13 Feb '05

13 Feb '05

Rein Klazes wrote: >Hi, > >FrameRgn paints a frame around a region, the frame should be painted on >the inside of the edges, not the outside as it does now. > > It's a shame that we're duplicating work all over again :-( http://www.winehq.org/hypermail/wine-patches/2004/06/0250.html

2 1

Regression in "Braveheart"
by Carlos Lozano 13 Feb '05

13 Feb '05

Hello, The patch: http://www.winehq.org/hypermail/wine-cvs/2004/06/0104.html Log message: Dmitry Timoshkov <dmitry(a)codeweavers.com> Do nothing in ShowWindow(SW_SHOW) if a window is already visible. Causes regression in the game "Braveheart". The intro was working before of the patch, now it freezes with black screen on start. Regards, Carlos. -- ___ _ \ | / Consulting | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.ePSXe.com

2 1

Re: setupapi - ReactOS Merge 20050205
by Alexandre Julliard 12 Feb '05

12 Feb '05

Steven Edwards <steven_ed4153(a)yahoo.com> writes: > +BOOL WINAPI DelayedMove(LPCWSTR lpExistingFileName, LPCWSTR lpNewFileName) > +{ > + if (OsVersionInfo.dwPlatformId != VER_PLATFORM_WIN32_NT) > + { > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return FALSE; > + } > + > + return MoveFileExW(lpExistingFileName, lpNewFileName, > + MOVEFILE_REPLACE_EXISTING | MOVEFILE_DELAY_UNTIL_REBOOT); > +} You shouldn't do that kind of preventive version check, you should always call the function and then deal with failures appropriately. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: Regression in "DeusEx"
by luis lenders 12 Feb '05

12 Feb '05

Hello again, > The patch: > http://www.winehq.org/hypermail/wine-cvs/2004/10/0395.html > > Log message: > Get rid of the WIN_NEEDS_BEGINPAINT flag, Windows will happily loop > forever too if WM_PAINT is not handled properly. > > Causes regression in the game "DeusEx". > The game was playable before of the patch, now it freezes > in the 2th title screen. The same patch causes regression in the game "Trickstyle". The same problems, it was playable, and now it freezes in the 2th title screen. Regards, Carlos. The aforementioned patch also screws up foobar2000. See http://appdb.winehq.org/appview.php?versionId=2355 , last comment. Maybe someone could have a look at it because it affects, as it appears, quite some apps. Regards ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

2 1

← Newer
1
...
18
19
20
21
22
23
24
...
32
Older →

Jump to page:

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 February 2005