wine-devel

wine-devel@winehq.org

7 participants
84466 discussions

Re: fdopen behaviour correction
by Uwe Bonnes 16 Dec '02

16 Dec '02

>>>>> "Bill" == Bill Currie <bill(a)taniwha.org> writes: Bill> fdopen is not supposed to rewind the file descriptor being given a Bill> FILE *. Proof of this comes from quakeforge working in windows Bill> natively but not in wine without the attatched patch. Bill> ChangeLog * dlls/msvcrt/file.c don't rewind the file after Bill> creating the FILE* handle It is good to have a test case for such cases in wine/dlls/msvcrt/tests. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: resend: ConvertThreadToFiber stub
by Greg Turner 16 Dec '02

16 Dec '02

On Monday 16 December 2002 01:08 pm, Rein Klazes wrote: > Use this one, the previous patch wasn't clean > > > Changelog: > > dlls/kernel : kernel32.spec > scheduler : thread.c > > Add a stub for ConvertThreadToFiber > > Rein. funny, I recently implemented same but never submitted. using HTML Help by any chance? -- gmt

2 1

Re: winmm test extension
by Dan Kegel 16 Dec '02

16 Dec '02

Francois Gouget wrote: > This test extends the winmm test and makes it possible to play actual > sound. Of course the test will not do that unless you specifically ask > for it: > * I doubt anyone would be happy to do 'make test' in Wine's main > directory and to get annoying long beeps comming out of their computer > * tests are usually run unattended and there is not much point playing > the sounds if no-one listens to them to make sure they got played > correctly. > > So what does it do? > For each supported format it plays the international 'LA', i.e. a 440Hz > sinusoid. It is expected that on some sound cards and for some formats > the signal will have to be converted from 8 to 16 bit or from mono to > stereo, or even resampled. Normally this should not affect the sound > being played so you should keep hearing the same tone. If that's not the > case then something went wrong during th I may have a counterexample. The patch I submitted recently was to fix a hang in playing sound. So if you add a timeout to your test, it would at least verify that sounds played in the proper amount of time, and didn't hang wine. - Dan

2 1

Re: DrawCaptionTempW patch
by Uwe Bonnes 16 Dec '02

16 Dec '02

>>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: Rein> Hi, This bug caused uninitialised height and width data to be fed Rein> to the font rasterizer, allocating more then 1.2 GB of VM. What action or program triggered that bug? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

It now hangs when running an install shield
by Ben Clewett 16 Dec '02

16 Dec '02

Wine, You gues have already given me loada help, but straight onto my next stage, and I get (my old friend) the Wine Console error traceback. Running an Install Shield instalation, starts OK, gets past the initial 'Install Shield will now guide you through your instalation'. Then blanks the screen for about ten minutes, returning with the console showing: Unhandles exception: page fault on write access to E:\_ITSTMP.DIR\_INS55765._WP): movl %eax,0x28(%edx,%ecx,4) Looked in /tmp/winetmp-root/_ITSTMP.DIR/* & can't see anything wrong. 'df' shows a few dozen gig free. And clues? I hope at the end of this, I can return the great feedback by answering some questions my self :) Ben

1 0

Workaround for Wine to produce dead-keys with Brazilian ABNT-2 keyboards
by Mauro Carvalho Chehab 16 Dec '02

16 Dec '02

I spent a lot of time looking for a solution for using my Brasilian ABNT-2 keyboard. I've already sent a new patch to wine-patches in order to correct keytables and vkey tables. But it remained a small problem: It was NOT generating the correct dead-key codes. So, I developed a *workaround*. This patch has to be applyied to dlls/x11drv/keyboard.c (It was tested with CVS 20021125). I advice that it wil work only for ABNT-2 keyboards. ---------------------------------------------------------------------------------------------------------------------------------------- --- keyboard.c 2002-11-28 22:33:07.000000000 -0200 +++ keyboard.c 2002-12-16 15:10:07.000000000 -0200 @@ -1759,6 +1794,10 @@ else TRACE("Found keycode %d (0x%2X)\n",e.keycode,e.keycode); ret = XLookupString(&e, (LPVOID)lpChar, 2, &keysym, NULL); + +/* Gambiarra para funcionarem os acentos em teclado ABNT-2 */ +if ((e.keycode==48)||(e.keycode==34)||((e.keycode==15)&&(e.state & ShiftMask))) ret=0; + wine_tsx11_unlock(); if (ret == 0)

1 0

RE: Wine, Windows.Forms on Linux, GC and segfaults.
by Patrik Stridvall 16 Dec '02

16 Dec '02

> The problem is that by the time that Wine has been initialized, > using setjmp/longjmp will always lead to a crash. The code > in pthreads > that performs the longjmp will first try to invoke the pthread cleanup > routines, and then invoke longjmp. This never happens. You can't and needn't link with -lpthread. Wine has its own pthread implmentation. I tried your included code and it works just fine unless you link with -lpthread, then it crashes in the same way as in your attached picture. But then you should never link Wine with -lpthread so that is not really a bug. Of course Wine pthread implementation it not in any way complete so some function might be missing and some might only be only partially implemented and of course some might be incorrectly implemented. So please try again without linking with -lpthread.

3 2

Quick silly question, registering DLL's
by Ben Clewett 16 Dec '02

16 Dec '02

Forgive any stupidness implied, I am UNIX not MS! How does one check whether a DLL is registered, and how does one actually register a DLL in wine? Thanks,

1 0

VarOr / oleaut32
by us＠the-edmeades.demon.co.uk 16 Dec '02

16 Dec '02

Hiya, What app shows this? Can I get hold of it - I should be able to knock something up for it as a test regardless, but it might not be til mid next week. Jason

3 3

GetWindowTextLengthA()/WM_GETTEXTLENGTH issue
by Andreas Mohr 15 Dec '02

15 Dec '02

Hi all, Steuertipps PC 2003 (yeah, right, it's that time of the year again ;) has corrupted button text - drawing beyond the last actual string character. This is because the supplied OWL (Borland, I believe ?) DLL calls DrawTextA with twice the amount of string length (yeah, must be a Unicode issue, of course... :), thus forcing DrawTextA into drawing way too much. (side note: OWL seems to implement its own custom buttons) This doubled value comes from GetWindowTextLengthA() (0x14 bytes instead of 0x0e bytes), which thus comes from WM_GETTEXTLENGTH. WINPROC_UnmapMsg32ATo32W does for a WM_GETTEXTLENGTH unmapping: case WM_GETTEXTLENGTH: case CB_GETLBTEXTLEN: case LB_GETTEXTLEN: /* there may be one DBCS char for each Unicode char */ return result * 2; The button text in question is: L"&Schlie\00dfen" (aka "&Schliessen") (so it's a Unicode string with 0x0e units) MSDN says that both WM_GETTEXTLENGTH and GetWindowTextLength return inexact amounts of string lengths for certain Unicode/DBCS combos (and always at least as much as the minimum storage it requires). However, I guess that we really *shouldn't* double the string length in this case (I guess we better avoid that corruption ;). Hmm, any idea how the unmapping can be improved ? To me it seems that the generic unmapping in WINPROC_UnmapMsg32ATo32W is exactly the place where s^Hcrap happens. (there seems to be a pretty direct connection between GetWindowTextLengthA and DrawTextA) Andreas Mohr

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