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