- Wine-Devel - list.winehq.org

winetest on wine and todo_wine
by Paul Vriens Feb. 14, 2005

Feb. 14, 2005

Hi, in shlwapi/tests/shreg.c I've put two todo_wine statements for obvious reasons (they fail, so do not test). If I however look at http://test.winehq.org/data/200502101000/wine_98/shlwapi:shreg.txt These tests are executed! Any ideas what could be wrong? If I execute the tests on my Wine box the tests are skipped. Cheers, Paul Vriens.

5 7

Re: working installshield?
by Mike Hearn Feb. 14, 2005

Feb. 14, 2005

Marcus Meissner wrote: > Hi, > > Is there any chance to have a working installshield at some time? > > I don't really want to fall back to the december or even earlier WINE > releases for our spring SUSE Linux product ;) Rob has a patch that should (touch wood) fix the remaining issues. I'm not sure when he is going to submit it but it looked pretty complete last time I saw it. We may also need to adjust the RPC runtime so that it runs a message loop (for re-entrancy), but I don't think that'd be too hard. So, maybe a week or two? It certainly should not be broken for more than month. thanks -mike

1 0

Re: working installshield?
by Marcus Meissner Feb. 14, 2005

Feb. 14, 2005

And actually this should have gone to wine-devel... > Hi, > > Is there any chance to have a working installshield at some time? > > I don't really want to fall back to the december or even earlier WINE > releases for our spring SUSE Linux product ;) > > Ciao, Marcus

1 0

Compiling the MFC using Winelib
by Dan Dennison Feb. 14, 2005

Feb. 14, 2005

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 Feb. 14, 2005

Feb. 14, 2005

"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 Feb. 14, 2005

Feb. 14, 2005

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 Feb. 14, 2005

Feb. 14, 2005

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 Feb. 14, 2005

Feb. 14, 2005

>>>>> "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 Feb. 14, 2005

Feb. 14, 2005

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 Feb. 13, 2005

Feb. 13, 2005

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