Hi,
what's the state of CD-ROM support on the Mac?
ntdll/cdrom.c contains quite a few #ifdef apple.
I'm asking because the mcicda currently uses these ioctl:
1. READ_RAW
2. READ_TOC
3. READ_Q -> POSITION
MCICDA could be changed to avoid the third one entirely
-- when using the dsound output. Would that
be enough to use mcicda on MacOS to play music?
Thanks for your help,
Jörg Höhle
On 06/03/2011 04:19 PM, Lucas Fialho Zawacki wrote:
> In the absence of this check apps passing a NULL pointer as callback to
> EnumDevices segfault under Wine.
Do you have an example of such application? And the bug in bugzilla?
Vitaliy.
On 06/04/2011 03:02 PM, Gerald Pfeifer wrote:
> Resending: This really looks like a straightforward bug fix and the
> current code definitely wrong???
>
>
> The difference between two pointers (of the same type) is the number
> of elements, not the number of bytes. Thus the code below was way
> incorrect, luckily only too conversative.
>
> Gerald
>
> ---
> dlls/urlmon/sec_mgr.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/urlmon/sec_mgr.c b/dlls/urlmon/sec_mgr.c
> index 7b4bb35..75850ee 100644
> --- a/dlls/urlmon/sec_mgr.c
> +++ b/dlls/urlmon/sec_mgr.c
> @@ -529,7 +529,7 @@ static HRESULT map_url_to_zone(LPCWSTR url, DWORD *zone, LPWSTR *ret_url)
> hres = CoInternetParseUrl(secur_url, PARSE_PATH_FROM_URL, 0, path,
> sizeof(path)/sizeof(WCHAR),&size, 0);
>
> - if(SUCCEEDED(hres)&& (ptr = strchrW(path, '\\'))&& ptr-path< sizeof(root)/sizeof(WCHAR)) {
> + if(SUCCEEDED(hres)&& (ptr = strchrW(path, '\\'))&& ptr-path< sizeof(root)) {
> UINT type;
>
> memcpy(root, path, (ptr-path)*sizeof(WCHAR));
Indeed, the difference between two pointers is the number of elements.
sizeof(root) is the number of bytes, sizeof(root)/sizeof(WCHAR) is the
number of elements.
HTH,
Joris
On Jun 4, 2011, at 8:02 AM, Gerald Pfeifer wrote:
> Resending: This really looks like a straightforward bug fix and the
> current code definitely wrong???
No. As others have pointed out, your logic is wrong. The existing code is correct.
> The difference between two pointers (of the same type) is the number
> of elements, not the number of bytes. Thus the code below was way
> incorrect, luckily only too conversative.
So, ptr-path is the number of elements between the two pointers. But sizeof(root) is a number of bytes. The precise reason to divide the latter by sizeof(WCHAR) is to arrive at a number of elements so it is proper to compare to ptr-path.
Put another way, look a bit lower in the code:
> memcpy(root, path, (ptr-path)*sizeof(WCHAR));
It is clear that (ptr-path)*sizeof(WCHAR), a measure of bytes, must be no larger than the size of root in bytes. Thus, this is the requirement:
(ptr-path)*sizeof(WCHAR) <= sizeof(root)
Dividing both sides by sizeof(WCHAR) gives an equivalent requirement:
(ptr-path) <= sizeof(root)/sizeof(WCHAR)
which is exactly what the code, as is, tests. (Except that the current code doesn't allow for the equal case, in order to preserve a null terminator.)
Regards,
Ken
> ---
> dlls/urlmon/sec_mgr.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/urlmon/sec_mgr.c b/dlls/urlmon/sec_mgr.c
> index 7b4bb35..75850ee 100644
> --- a/dlls/urlmon/sec_mgr.c
> +++ b/dlls/urlmon/sec_mgr.c
> @@ -529,7 +529,7 @@ static HRESULT map_url_to_zone(LPCWSTR url, DWORD *zone, LPWSTR *ret_url)
> hres = CoInternetParseUrl(secur_url, PARSE_PATH_FROM_URL, 0, path,
> sizeof(path)/sizeof(WCHAR), &size, 0);
>
> - if(SUCCEEDED(hres) && (ptr = strchrW(path, '\\')) && ptr-path < sizeof(root)/sizeof(WCHAR)) {
> + if(SUCCEEDED(hres) && (ptr = strchrW(path, '\\')) && ptr-path < sizeof(root)) {
> UINT type;
>
> memcpy(root, path, (ptr-path)*sizeof(WCHAR));
> --
> 1.7.4.1
>
>
>
Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes:
> +static inline D3DPOOL d3dpool_from_wined3dpool(WINED3DPOOL type)
> +{
> + switch (type)
> + {
> + case WINED3DPOOL_DEFAULT: return D3DPOOL_DEFAULT;
> + case WINED3DPOOL_MANAGED: return D3DPOOL_MANAGED;
> + case WINED3DPOOL_SYSTEMMEM: return D3DPOOL_SYSTEMMEM;
> + case WINED3DPOOL_SCRATCH: return D3DPOOL_SCRATCH;
> + case WINED3DPOOL_FORCE_DWORD: return D3DPOOL_FORCE_DWORD;
> + }
> + return (D3DPOOL) type;
> +}
> +
> +static inline WINED3DPOOL wined3dpool_from_d3dpool(D3DPOOL type)
> +{
> + switch (type)
> + {
> + case D3DPOOL_DEFAULT: return WINED3DPOOL_DEFAULT;
> + case D3DPOOL_MANAGED: return WINED3DPOOL_MANAGED;
> + case D3DPOOL_SYSTEMMEM: return WINED3DPOOL_SYSTEMMEM;
> + case D3DPOOL_SCRATCH: return WINED3DPOOL_SCRATCH;
> + case D3DPOOL_FORCE_DWORD: return WINED3DPOOL_FORCE_DWORD;
> + }
> + return (WINED3DPOOL) type;
> +}
I still don't see the point of that kind of switch statement. To be
honest I don't see either why we even need different enum types in the
first place.
--
Alexandre Julliard
julliard(a)winehq.org
Hi Devels
The app I use runs unacceptably slow under wine. I suspected gdi
routines and wrote a simple win32 api app to make some tests and
comparisons. On my box it shows wine gdi is 10 times slower than the
real windows. Let's get into details.
REASON
I love EditPad Pro (appdb editpad pro
<http://appdb.winehq.org/objectManager.php?sClass=application&iId=8392>), a
text editor with the capabilities for a programmer that I can't find in
any other tool. After upgrade from version 6 to 7 I have problems with
the usability, due to slow performance. The app is written in Delphi and
now they included new interface features. The menus seem to be animated,
they roll down instead of popping up immediately. Menus roll down slowly
on wine, but that's a little problem, just a noticable thing. I have
problems with very typing characters and these problems are almost gone
when I switch off all the toolbars. Looks like the icons on them make
them slow down the whole app.
The author of the app claims that on his vmwared ubuntu everything is
ok. I hope to get the judgement from you.
TESTING APP
I attach zip with source code and the executable of a short win32 api.
It's an animated rectangle, optionally with a bitmap inside. It moves
pixel by pixel from left to right. The next move is generated by
PostMessage(WM_USER) at the end of OnPaint. I hope that's a way of
assessing the gdi speed. Time needed to make the full pass of 500 pixels
is printed on the screen.
RESULTS
test_gdi.exe without parameters draws bitmapped rect, while with the
option "t" - the rect is bare. I tested 3 evironments and took 2
measurings on each of them. First number is the bitmapped time. Units
are seconds.
wine 0.39 0.22 - every movement phase is drawn
vmwared w2k 0.123 0.085 - only several painted rects in random places
w2k 0.0387 0.0285 - several painted every 2nd line, skewed rects
The factor of 10 comes from comparing bitmapped time between wine and
real W2K. Wine graphics is perfect, and the faster environments take
some shorter ways.
POSSIBLE EXPLANATION
Just my imagination. I guess Windows buffer their graphics outcome in
memory. Fast changes in this memory are not passed to the graphic
device. This would explain the artifacts seen in the experiment and also
the lack of flickering of the apps under the real win. For example
mentioned EditPadPro redraws its edit area with every character typed
(at least in the syntax highlighting mode), while under real win this
behaviour is undetectable.
BIBLIOGRAPHY
The speed issue was reviewed in such posts I could locate:
GDI Question
<http://www.winehq.org/pipermail/wine-devel/2003-February/014052.html>
(2003)
Windows 2D GDI benchmark tools?
<http://www.winehq.org/pipermail/wine-devel/2009-July/077144.html> (2009)
Speed problem with Wine...
<http://www.winehq.org/pipermail/wine-users/2001-July/007320.html> (2001)
Has anything changed?
LAST WORD
I hope you'll benefit from the tester I wrote. I'm looking forward to
see your comments. Do you notice the same speed multiplier as me: 10x?
Maybe I have to fix my Debian to reach better results.
Jarek
Hi André,
I'm not sure if we should add this change since for a part it hides
the real problem. Sure this patch likely works, but >32bpp blits
should never enter the software rendering code in the first place. The
code used to be a huge mess and Henri cleaned it up quite a bit
already (thanks, because I became too busy). It may be easier now to
fix this properly.
Roderick
2011/6/4 André Hentschel <nerv(a)dawncrow.de>:
> For http://bugs.winehq.org/show_bug.cgi?id=27377
> ---
> dlls/wined3d/surface.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
> index 91b16a6..7f9d9df 100644
> --- a/dlls/wined3d/surface.c
> +++ b/dlls/wined3d/surface.c
> @@ -6780,6 +6780,9 @@ do { \
> case 4:
> STRETCH_ROW(DWORD);
> break;
> + case 8:
> + STRETCH_ROW(DWORD64);
> + break;
> case 3:
> {
> const BYTE *s;
> --
>
> Best Regards, André Hentschel
>
>
>