wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Compiling the MFC using Winelib
by Dan Dennison 14 Feb '05

14 Feb '05

Building MFC for winelib has been addressed many times earlier on this list, from what I can see, since at least 2001 if not earlier. However, all together I cannot seem to find a well-written documentation of the process involved to build libmfc.so. So as a service to the Wine community I plan to document the process of building libmfc as part of my master's project. Although the MFC is not the focus of this project, porting of it is a requirement for the package to work using Winelib. Are there resources available beyond simple compilation tips to assist in the building of the MFC library under Winelib? Thanks! Dan Dennison dand(a)csun.edu

6 7

Re: Resend: [Bug 2631] Trap in RegisterClassExA
by Alexandre Julliard 14 Feb '05

14 Feb '05

"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> writes: > Hiya, Was there any problem with this one - It mimics windows behaviour and > resolves a trap for an application (and yes, the behaviour even down to the > setlasterror return code matches windows, well XP at least!). Could you please submit a test case for that? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Text Alignment, how is it handled ?
by Ulrich Czekalla 14 Feb '05

14 Feb '05

Hi George, I haven't heard back from you so I assume you haven't implemented anything yet. Here is my quick attempt at adding support for ES_RIGHT and ES_CENTER. Modifying the edit control made me realize how much room there is to improve the edit control implementation. Of course, my patch makes no attempt to rewrite any of it ;-) /Ulrich On Tue, Feb 08, 2005 at 12:53:56PM -0500, Ulrich Czekalla wrote: > Actually I just started to look at this as well. I expect to have a patch > in the next day or so. If you already have something let me know and I'll > stop working on it. > > Thanks, > > /Ulrich > > On Tue, Feb 08, 2005 at 09:26:30AM +0100, George Ginden wrote: > > Dimitrie O. Paun ha scritto: > > > > >Currently, our edit box (dlls/user/edit.c) does not support > > >right-aligned fields. It is a known limitation. If you want > > >you can try to implement it, and submit a patch. > > > > > > > > OK, I'm into it. But wait, I'm pretty new to the Wine codebase... > > Do you think it is a hard implementation or an easy one ? > > If the alignment thing is still not implement... Well there must be a > > reason ... > > Do I miss somthing ? > > > > Regards. > > > >

2 1

Re: wine/ programs/winhelp/Pt.rc programs/winemine ...
by Marcelo Duarte 14 Feb '05

14 Feb '05

Hi, Sorry for the sincerity, but I am finding bad idea this to mix the translations. My suggestion is to create a new archive for the variation (Ptg.rc or Pt_pt.rc, etc). Thanks for attention. Alexandre Julliard escreveu: >ChangeSet ID: 16040 >CVSROOT: /opt/cvs-commit >Module name: wine >Changes by: julliard(a)wine.codeweavers.com 2005/02/10 11:14:16 > >Modified files: > programs/winhelp: Pt.rc > programs/winemine: Pt.rc > programs/winefile: Pt.rc > programs/winecfg: Pt.rc > programs/wcmd : Pt.rc > programs/view : Pt.rc > programs/start : Pt.rc > programs/regedit: Pt.rc > programs/progman: Pt.rc > programs/notepad: Pt.rc > programs/cmdlgtst: Pt.rc > programs/clock : Pt.rc > dlls/setupapi : Pt.rc > dlls/serialui : Pt.rc > >Log message: > Américo José Melo <mmodem00(a)netvisao.pt> > Francois Gouget <fgouget(a)codeweavers.com> > Translate the Wine resources to Portuguese. > >Patch: http://cvs.winehq.org/patch.py?id=16040 > >Old revision New revision Changes Path > 1.8 1.9 +56 -2 wine/programs/winhelp/Pt.rc > 1.6 1.7 +29 -1 wine/programs/winemine/Pt.rc > 1.2 1.3 +132 -2 wine/programs/winefile/Pt.rc > 1.16 1.17 +44 -2 wine/programs/winecfg/Pt.rc > 1.3 1.4 +210 -1 wine/programs/wcmd/Pt.rc > 1.2 1.3 +39 -2 wine/programs/view/Pt.rc > 1.2 1.3 +45 -1 wine/programs/start/Pt.rc > 1.7 1.8 +203 -2 wine/programs/regedit/Pt.rc > 1.6 1.7 +130 -1 wine/programs/progman/Pt.rc > 1.12 1.13 +88 -1 wine/programs/notepad/Pt.rc > 1.3 1.4 +139 -1 wine/programs/cmdlgtst/Pt.rc > 1.9 1.10 +29 -1 wine/programs/clock/Pt.rc > 1.2 1.3 +17 -1 wine/dlls/setupapi/Pt.rc > 1.2 1.3 +26 -1 wine/dlls/serialui/Pt.rc > > > > > -- Marcelo Duarte DTM Informática 31-3551-3864 dtminfo(a)bol.com.br dtminfo(a)ig.com.br

1 0

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

Latest News needs a url fix!
by Tom 12 Feb '05

12 Feb '05

The latest news on the frontpage has a incorrect link, "Read more" points to : http://www.winehq.org/?announce=1.95 when it should be 1.96 I'm away from my Linux box tonight or I would send a patch... Can someone fix this? Tom

2 1

Re: Fix winsock / protcol.c compilation on Windows
by Paul Vriens 12 Feb '05

12 Feb '05

On Fri, 2005-02-11 at 23:09, Francois Gouget wrote: > I guess this was accidental. > > > Changelog: > > * dlls/winsock/tests/protocol.c > > Francois Gouget <fgouget(a)codeweavers.com> > Tests cannot use wine/test.h because it does not exist on Windows. Hi Francois, the Changelog says wine/test.h, yet you remove wine/debug.h ? Cheers, Paul.

1 0

Appdb hackers please read
by Ivan Leo Puoti 12 Feb '05

12 Feb '05

Hello guys, I have the impression the inactive warning messages have been sent out again, I was convinced they were only sent once, followed a month later by a closed account notification. In any case please solve the problem, I can't take 500+ bounces in my mail box every other day, I'm planning to fill up my gmail box in something like 2040, not mid 2005, and don't want to waste time deleting hundreds of bounces. Ivan.

1 0

strange problem with RtlCompareUnicodeString
by Ivan Leo Puoti 12 Feb '05

12 Feb '05

RtlCompareUnicodeString should return 0 if it receives two identical string. But for some strange reason this code http://rafb.net/paste/results/e3tHCg40.html prints this output http://rafb.net/paste/results/SS5U2N81.html Is it a mistake I've missed, or is this a bug in the implementation of RtlCompareUnicodeString? Ivan.

1 1

Re: Re: winrash bug
by Chris Morgan 11 Feb '05

11 Feb '05

Oh, that's mostly because I was lazy. I'm pretty sure the text says that "if you are on windows95 you should install winsock2". I'm not sure how to detect whether the user needs to install winsock2 or not by looking at dlls. I was planning on adding detection of the windows version and using that as a way of narrowing down who sees the winsock prompt. That doesn't address which version of winsock the user has installed though... I'll put in the windows version check so only 95 users see the winsock2 prompt since thats pretty easy. Chris > > From: Ivan Leo Puoti <ivanleo(a)gmail.com> > Date: 2005/02/08 Tue PM 02:11:29 EST > To: cmorgan(a)alum.wpi.edu > CC: wine-devel(a)winehq.com > Subject: Re: winrash bug > > Chris Morgan wrote: > > >Is this based on what the installer displays or upon output from winrash in the debug.txt file? > > > > > It is based on the installer telling me I'm on windows 95 and that I > must install the > winsock2 update for windows 95. > > Ivan. >

3 2

Re: Real-world appdb
by Holly Bostick 11 Feb '05

11 Feb '05

(3rd of 3) Chris Morgan wrote: >>Then vote for what you really want or need... I want to see 100 games >>working but if I had to pick one >>it would be HL2. And if you give me 20 or 30 votes there *diluted* votes >>from the get-go! > > I agree. Maybe 5 votes per-user is a good number so each one counts but all of their eggs aren't in one basket. > > Chris > > >

1 0

Re: Real-world appdb
by Holly Bostick 11 Feb '05

11 Feb '05

(2nd of 3) Tom wrote: > Chris Morgan wrote: > >>> Having a single vote per-person makes the assumption that the person >>> has a single application that they want working. Often users have a >>> handful of them. I'd prefer multiple votes per-person. >> > Then vote for what you really want or need... I want to see 100 games > working but if I had to pick one > it would be HL2. And if you give me 20 or 30 votes there *diluted* votes > from the get-go! > If you have *one* vote its going to mean something...... if you have > 20-30 votes what is vote 28 > going to really mean to you? That you searched around looking for > something to vote for? > > We have 10 categories at this time and if we do move to multiable votes > I would only hope > we set it to 1 vote per categorie and that would give 10 diluted votes.... > > Tom > >>> Clearing the current votes is a safe bet. >>> >>> Chris >>> > >

1 0

Re: Real-world appdb
by Holly Bostick 11 Feb '05

11 Feb '05

How you guys managed to hit "Reply to all" and somehow not include the list, I don't know, but I'll forward :-) ... (1st of 3 such) Chris Morgan wrote: >>>- Voting for app version ( not app family). >>>- only one vote per person per version. >>>- more total votes, say 10-20 instead of 3. >>> >>> >>I would like to propose......... >> >>- one person one vote >>- vote for app family not version >>- clear the current votes and start fresh... >> > > Having a single vote per-person makes the assumption that the person has a single application that they want working. Often users have a handful of them. I'd prefer multiple votes per-person. > > Clearing the current votes is a safe bet. > > Chris > > > >

1 0

Wine, CrossOver wins LQ Members Choice awards 2004
by Mike Hearn 11 Feb '05

11 Feb '05

Hey, we won by a large margin! http://www.linuxquestions.org/questions/showthread.php?s=&threadid=272137 Wine 293 42.59% Crossover Office 139 20.20% Cedega 131 19.04% VMware 101 14.68% Win4lin 24 3.49% Good going chaps and chapettes! Nice also to see the results are ranked in rough order of "freeness" too. Let's see if we can win again in the 2005 voting :) thanks -mike

3 2

Subject: Re: Faster TlsAlloc() or zero_bit_scan
by Dietrich Teickner 11 Feb '05

11 Feb '05

Not all You can every write in c/c++. Sometime You need a call for a library function. I think, that can be one and I think, not only TlsAlloc use a zero_bit_scan. It must be first zero_bit in the first 'bytecount' DWORD from the bitmap addr. Dietrich On Thu, 10 Feb 2005 18:59:21 +0100, Dietrich Teickner wrote: >> I have a suggestion for a faster implementation of the zero_bit_scan in >> RtlFindClearBits [NTDLL.@] >> (rlbitmap.c) for e.g. TlsAlloc() >> The main is the usage of the instruction 'bsf eax, eax' >> >> This I have implemented in the new experimental odinxp-tree for finding >> the first zero_bit in the first 'bytecount' bytes of the bitmap addr. Does this actually make a noticeable difference? Rewriting stuff in assembly for theoretical performance improvements isn't so great, as far fewer people can read/write assembly than C. thanks -mike

1 0

Subject: Re: Faster TlsAlloc() or zero_bit_scan
by Dietrich Teickner 11 Feb '05

11 Feb '05

Not all You can every write in c/c++. Sometime You need a call for a library function. I think, that can be one and I think, not only TlsAlloc use a zero_bit_scan. Dietrich On Thu, 10 Feb 2005 18:59:21 +0100, Dietrich Teickner wrote: >> I have a suggestion for a faster implementation of the zero_bit_scan in >> RtlFindClearBits [NTDLL.@] >> (rlbitmap.c) for e.g. TlsAlloc() >> The main is the usage of the instruction 'bsf eax, eax' >> >> This I have implemented in the new experimental odinxp-tree for finding >> the first zero_bit in the first 'bytecount' bytes of the bitmap addr. Does this actually make a noticeable difference? Rewriting stuff in assembly for theoretical performance improvements isn't so great, as far fewer people can read/write assembly than C. thanks -mike

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