wine-devel

wine-devel@winehq.org

12 participants
84488 discussions

GetClipboardData
by Dominik Strasser 25 Sep '01

25 Sep '01

Hello, with MS WinWord I am encountering the following problem: If there's something selected, GetClipboardData is called. In GetClipboardData, there is the line: HWND hWnd = (hWndClipWindow) ? hWndClipWindow : GetActiveWindow(); hWndClipWindow is 0, so GetActiveWindow() is called which also returns 0. I tracked this down to PERQDATA_GetActiveWnd returning 0. This leads later to "w" bening 0 which results in an X error calling XConvertSelection. It happens in all modes, desktop managed, non managed. Does anybody have any clues ? Dominik -- Dominik Strasser | Phone: +49 89 636-43691 SIEMENS AG | Fax: +49 89 636-42284 CT SE 4 | E-Mail:Dominik.Strasser@mchp.siemens.de Otto-Hahn-Ring 6 | D-81739 Muenchen | Room: 53-263

1 0

Callwave doesn't run
by Steven Walter 23 Sep '01

23 Sep '01

Is this a known problem? When I try to run the callwave install program, or the callwave program itself, I merely get: fixme:win32:PE_CreateModule Security directory ignored err:seh:start_debugger Couldn't start debugger (debugger/winedbg 134640112 24) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger Is this a configuration error on my part? Either way, is there some information I need to give to get this fixed? I appreciate it. Thanks -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell Freedom is slavery. Ignorance is strength. War is peace. -- George Orwell

2 5

Re: wsprintf
by Alexandre Julliard 21 Sep '01

21 Sep '01

Jeremy White <jwhite(a)codeweavers.com> writes: > Okay, so it's a slow news day, and I feel like stirring up trouble. Bad boy... > I would argue that it is, in fact, counterintuitive, to have this > sort of comment solely in the change log. The only time I ever think > to look at a diff (or even the change log) is when something has broken > recently. Well, because *you* don't look at it doesn't mean it's not the right place, does it? <g> I look at the CVS history quite often, and I find that in many cases it's the best way to find out why things are done a certain way. I don't see any reason to duplicate this info inside the code itself; since we are using a source control system we might as well take advantage of it. Plus it guarantees the info is stored permanently, unlike a comment that may get moved or lost next time the code is changed. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wsprintf
by Alexandre Julliard 21 Sep '01

21 Sep '01

Aric Stewart <aric(a)codeweavers.com> writes: > I think this is part of what the change log is for. > > Alexandre has committed the patch, i will ask him if he wants me to > document something further and submit another patch. I added a comment in wsprintf16 to make Andreas happy. But I agree that the change log (and cvs diff) is the best way to store this kind of information. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: re-implementing real mode interrupts
by Alexandre Julliard 21 Sep '01

21 Sep '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > For example, currently calling DeviceIoControl VWIN32_DIOC_DOS_INT_13 > on the VWIN32 device calls to the real mode interrupt INT 13. It could > be re-implemented so that INT_Int13Handler does a DeviceIoControl and > the low level disk access code moved into the VWIN32 device > implemetation. VWIN32_DIOC_DOS_INT_13 is not really different from int 13, so it wouldn't make much difference either way. Much better would be to implement the higher level calls that are needed to reimplement the DOS interrupts; for instance int 13 should use the IOCTL_DISK calls of DeviceIoControl, int 25/26 should be replaced by Win32 device access (CreateFile("\\.\PHYSICALDRIVEx")+Read/WriteFile), etc. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wsprintf
by Andreas Mohr 21 Sep '01

21 Sep '01

On Thu, Sep 20, 2001 at 01:38:11PM -0500, Aric Stewart wrote: > The behavior for wsprintfA is different that for wsprintf16 in how it > handles NULLs being passed as character parameters. This patch fixes > that. Hmm, can't you add a small comment inside the code that actually mentions this remarkable difference ? I think we should make every effort possible to ensure that important differences between architectures are being preserved as well as possible. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

2 1

Re: Better font charset handling
by Huw D M Davies 21 Sep '01

21 Sep '01

On Fri, Sep 21, 2001 at 03:46:29PM +0200, Nerijus Baliunas wrote: > On Wed, 19 Sep 2001 17:22:45 +0100 Huw D M Davies <h.davies1(a)physics.ox.ac.uk> wrote: > > HDMD> Huw D M Davies <hdavies(a)codeweavers.com> > HDMD> Use the font charset to obtain a codepage for A->W conversion in the > HDMD> text functions. > > HDMD> Index: objects/text.c > > HDMD> + case VISCII_CHARSET: > HDMD> + case TCVN_CHARSET: > HDMD> + case KOI8_CHARSET: > HDMD> + case ISO3_CHARSET: > HDMD> + case ISO4_CHARSET: > HDMD> + case ISO10_CHARSET: > HDMD> + case CELTIC_CHARSET: > HDMD> + /* FIXME: These have no place here, but becasue x11drv > HDMD> + enumerates fonts with these (made up) charsets some apps > HDMD> + might use them and then the FIXME below would become > HDMD> + annoying. Now we could pick the intended codepage for > HDMD> + each of these, but since it's broken anyway we'll just > HDMD> + use CP_ACP and hope it'll go away... > HDMD> + */ > HDMD> + cp = CP_ACP; > HDMD> + break; > > Why these are here? Because they do not have windows equivalents? > If so, at least KOI8 shouldn't be there (IMHO). AFAIK they're not Windows charsets, somebody has made up some numbers and added them to wingdi.h . The reason they're here at all is because the x11drv enumerates fonts with these charsets and I'm claiming that this is a bug, since no application can be expected to know that these numbers mean. Now there is a RUSSIAN_CHARSET and this gets handled by the TranslateCharsetInfo before the switch. Huw.

1 0

Re: Better font charset handling
by Nerijus Baliunas 21 Sep '01

21 Sep '01

On Wed, 19 Sep 2001 17:22:45 +0100 Huw D M Davies <h.davies1(a)physics.ox.ac.uk> wrote: HDMD> Huw D M Davies <hdavies(a)codeweavers.com> HDMD> Use the font charset to obtain a codepage for A->W conversion in the HDMD> text functions. HDMD> Index: objects/text.c HDMD> + case VISCII_CHARSET: HDMD> + case TCVN_CHARSET: HDMD> + case KOI8_CHARSET: HDMD> + case ISO3_CHARSET: HDMD> + case ISO4_CHARSET: HDMD> + case ISO10_CHARSET: HDMD> + case CELTIC_CHARSET: HDMD> + /* FIXME: These have no place here, but becasue x11drv HDMD> + enumerates fonts with these (made up) charsets some apps HDMD> + might use them and then the FIXME below would become HDMD> + annoying. Now we could pick the intended codepage for HDMD> + each of these, but since it's broken anyway we'll just HDMD> + use CP_ACP and hope it'll go away... HDMD> + */ HDMD> + cp = CP_ACP; HDMD> + break; Why these are here? Because they do not have windows equivalents? If so, at least KOI8 shouldn't be there (IMHO). HDMD> + default: HDMD> + FIXME("Can't find codepage for charset %d\n", lf.lfCharSet); HDMD> + break; Regards, Nerijus

1 0

Re: winsock socket.c patch fixes issues with halflife's multicasting
by Francois Gouget 21 Sep '01

21 Sep '01

On 21 Sep 2001, David Hammerton wrote: > it seems there we're a few (bugs/typos) in dlls/winsock/socket.c which > prevented binding of ports when using multicast, or something along those > lines. > heres a small patch which fixes it. Please, user -u when you do a diff: * it makes it easier to see what the patch changes * it makes it easier to find the location you changed in the file. None of my copies of socket.c match yours so all the line offsets are off * it is more robust if you want to apply the patch to a modified version of the file (translation Unified diff formats actually have a chance to apply properly, yours does not) So I suggest you put the following line in your .cvsrc: diff -u All this is also explained there: Wine Developper's Guide: "Submitting Patches" http://wine.codeweavers.com/docs/wine-devel/patches.shtml#PATCH-FORMAT That said I must appologize: I am the one who broke this piece of code. A very bad case of copy/paste. Sincere appologies. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

1 0

re-implementing real mode interrupts
by Mike McCormack 21 Sep '01

21 Sep '01

Hi, I was wondering if it would be a Good Thing to start re-implementing real mode interrupts using Win32 calls. For example, currently calling DeviceIoControl VWIN32_DIOC_DOS_INT_13 on the VWIN32 device calls to the real mode interrupt INT 13. It could be re-implemented so that INT_Int13Handler does a DeviceIoControl and the low level disk access code moved into the VWIN32 device implemetation. This would better seperate the DOS and Win32 implementations. Any thoughts? Mike ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

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