September 2001 - Wine-devel

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(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: Implementation of SPI_GETSHOWSOUNDS action in SystemParametersInfo
by Gerard Patel 20 Sep '01

20 Sep '01

At 02:34 PM 20/09/2001 -0400, you (Andriy Palamarchuk <apa3a(a)yahoo.com>) wrote: >File: windows/sysparams.c <snip> use diff -u See: http://www.winehq.com/dev.shtml (section : patches) Gerard

1 0

Re: min/max and types
by Francois Gouget 20 Sep '01

20 Sep '01

On Tue, 18 Sep 2001, eric pouech wrote: [...] > however, comparaisons like min(short, int) or min(size_t, DWORD) don't > provide lots of errors. integral promotions are straightforward, and > behave as expected by any programmer. so it would be rather ugly IMO > to write something like min((int)s, i) (s being short and i int) But in this last example, wouldn't it be better to declare s as an int or i as a short? Then we would not need a cast. I believe we would rarely be forced to really compare integers of different sizes. Of course the only way to be sure is to really look at the actual warnings... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

3 2

GetSystemMetrics / SetSystemMetrics ?
by Andriy Palamarchuk 20 Sep '01

20 Sep '01

Question: How to update metrics data returned by GetSystemMetrics function? Problem: Currently I'm implementing some easiest FIXMEs (e.g. SPI_GETSHOWSOUNDS) in function SystemParametersInfo. GetSystemMetrics is used to return information for a few types of SPI_GETxxx actions from this function, including the action I'm working on. Logic for corresponding SPI_SETxxx actions is not implemented and contains commented out calls to SetSystemMetrics. As I understand this comment is a mark that corresponding GetSystemMetrics data should be updated in this place. GetSystemMetrics returns data from array sysMetrics. I did not find any function which provides update access to the array. Can you advise how to deal with this problem? Regards, Andriy Palamarchuk

1 0

Quicktime 5.0.x / XVideo usage
by Matthias Dahl 20 Sep '01

20 Sep '01

Hey there... ]) powered by Linux 2.4.8 ([ I have discovered some strange behavior with WINE and Quicktime 5.0.x. As long as the "time slider" and the "audio bars" are being updated the video runs quite sluggish. But if you open a menu or a dialog box both the "time slider" and the "audio bars" stop updating - which is normal. BUT the video itself runs at full speed as long as both are not being updated. Which is kinda strange I guess. Even those animation content which is included with some movs doesn't slow the playback down, so it cannot be a performance issue. (on PIII with 500 Mhz, 256 MB ram and X 4.1.x (G400MAX)) Also if you maximize the video to full screen or anything that is not its original size, the playback also becomes very sluggish. Doesn't WINE use the XVideo protocol for such operations? By the way. I am using yesterday's CVS checkout without any windows DLLs. I'll happily provide more informations - just let me know what you need. Last but not least. All you guys are doing a great job -- and I wanted to take the opportunity to say THANK YOU to you all. :-) -- So long, Matt ]) matthew2k(a)web.de, GPG key available at public keyservers ([

3 4