I don't think it's possible to properly implement SwitchDesktop in
either the X11 or Mac driver. There's just nothing sensible for it to
do.
One possible strategy would be to implement SwitchDesktop in user32
and wineserver. Wineserver could logically track the input desktop,
and OpenInputDesktop
HRESULT CLRMetaHost_CreateInstance(REFIID riid, void **ppobj)
{
+GlobalCLRMetaHost.callback = NULL;
return ICLRMetaHost_QueryInterface(GlobalCLRMetaHost.ICLRMetaHost_iface,
riid, ppobj);
}
I don't think we should be changing global state every time someone
creates an instance of this
I guess if you SetLastError to not implemented you cannot return S_OK too
It doesn't make sense to use SetLastError at all for functions
returning HRESULT.
Any reason not to share code with CLRCreateInstance?
Isn't this going to make the caption Wine Gecko Installer in both cases?
I don't think this is going to work correctly when replacing hotkeys
(by passing an already-registered hwnd and id to RegisterHotKey with a
different key combination). Since the user driver's RegisterHotKey
function will be called with the new id/vkey/flags before
UnregisterHotKey is called for
Typically, native GetGlyphOutlineW(hdc, ' ', GGO_BITMAP, gm, 0, NULL, ...)
returns gm.gmBlackBoxX = 1 instead of 0. Unfortunately, Wine's didn't,
and existing source codes (winex11, gdiplus, gdi32) expect 0 in this
case.
I don't think the existing code for finding the mask size would
Thanks for you comments. The answer is yes, as you guessed.
Typically, native GetGlyphOutlineW(hdc, ' ', GGO_BITMAP, gm, 0, NULL, ...)
returns gm.gmBlackBoxX = 1 instead of 0. Unfortunately, Wine's didn't,
and existing source codes (winex11, gdiplus, gdi32) expect 0 in this
case.
I don't
Maybe the format for 32-bit bitmaps should be determined by the alpha
channel options?
On Monday, September 16, 2013, Dmitry Timoshkov dmi...@baikal.ru wrote:
Based on a gdiplus implementation.
---
dlls/windowscodecs/imgfactory.c | 149
+-
Probably, but as the patch comment says the code is based on gdiplus
implementation, and there is no such an option flag in the corresponding
gdiplus API params. I'd suggest to accept the patch as as, and make further
improvements based on it.
Fair enough, the patch looks good otherwise.
This seems suspicious to me. Why can't we use those values in
glyphmetrics if GetGlyphOutlineW returns 0? Does Windows provide bad
values in this case, or is our GetGlyphOutlineW broken? When does the
call to GetGlyphOutlineW in the second loop fail, and why ignore those
failures?
BTW, we should probably quit early if max_glyphsize is 0 at the end of
the first loop, rather than fail with OutOfMemory.
The systray/notification area code has to do that:
http://source.winehq.org/source/dlls/winex11.drv/systray.c#L620
I don't think it can be done without modifying winex11.drv.
This solutions implies to modify wine, so do you think that this patch
or an improved version could be merged into wine?
Because I don't want to require a custom version of wine.
Even if it were merged, that would not give you the ability to use it
from within a Windows or winelib program. For
+/* Assume the namespace is the Assembly name */
Uh, what?
We should only be passing an assembly name to
get_file_from_strongname, not the class name. You shouldn't even have
access to the class name.
I think what you're actually doing here is skipping the assembly name
and using
If we really want the links to be up to date, we should figure out a
way to make them show up on bugzilla, without clicking through to a
search. Otherwise, the only time someone is likely to notice a bug
that hasn't been linked is if they're looking for it specifically and
happened to start their
mscoree.c:179: Test failed: version is Lv1.1.4322 , expected Lv2.0.50727
Ah, that's because we're hard-coding the index to 2.0 here:
http://source.winehq.org/source/dlls/mscoree/metahost.c#L1392
Looks good, thanks.
This seems suspicious to me. You appear to be taking the namespace of
the class and assuming it's an assembly name.
Is there really no other information in the registry that could be
used to identify the assembly?
If we have the assembly name, then we should be using that to decide
on the filename to try in the application directory, not the
namespace.
On Wed, Aug 14, 2013 at 4:04 PM, Daniel Jeliński djelins...@gmail.com wrote:
That being said, I think this is the wrong place for this change. Method
get_file_from_strongname [1] is better suited for that purpose IMO.
Doing it that way is probably more correct, but it's also more
dangerous
There is dedicated git hosting software (such as gitolite and gitosis
- most people in #git seem to prefer gitolite) that provides
account-based access to Git repositories without providing any general
shell access. Perhaps something like that could be set up on
source.winehq, running on a
if (!(format_flags StringFormatFlagsNoClip)
-scaled_rect.Width != 1 23 scaled_rect.Height != 1 23)
+scaled_rect.Width != 1 23 scaled_rect.Height != 1 23
+rect-Width 0.0 rect-Height 0.0)
{
/* FIXME: If only the width or only the height is
This is awfully overcomplicated (plus I do not know how to make such a
global variable in wine) so I was wondering is it OK to implement this
differently than windows does it.
If the implementation does not have to be the same to preserve
compatibility, then you should ignore those details
You can also run console apps without a graphics driver (if they don't
do anything that requires one).
Wouldn't these two points simply earn a 'Rejected' status and/or some kind of
comment on the wine-devel list?
Applying a Rejected status would require looking at the patch.
But it could be nice to have a status that means I will not even read
a patch from this person to do this specific thing
I think I've seen patches stay in the New state in the following cases:
* He's convinced you do not have the ability to write a patch he
would accept. (There's a common pattern where people will take
feedback and attempt to revise their patch to account for it, but not
really understand the
There's a TIFF_VERSION define that seems to have been renamed to
TIFF_VERSION_CLASSIC in 4.0.
It doesn't make sense to do the check at runtime, given we're only
going to link to one of the versions.
I have no opinion on this sort of work-around (it should work afaict,
and I haven't found any other places where we currently use toff_t),
but did you file a bug with whatever distro has such broken headers?
Actually, this will be a problem on libtiff 3.x, where toff_t really
is supposed to be 32-bit.
Okay but at the moment, in those languages, a user is currently being told
Gecko needs to be installed, followed by Gecko needs to be installed.
Are you sure this isn't caused by needing 32-bit and 64-bit builds of Gecko?
I'm curious what happens if the world transform has some rotation. It
seems like transform_rectf would break in that case.
This series looks good to me.
The series looks good to me.
It works just fine in the samples I have here, why would it break?
If the rotation is a multiple of 90 degrees, the upper-left corner
will not be the same point, but you're not making any attempt to use a
different corner for the origin of your rectangle.
If the rotation is something like 45
I'm not sure we should change this during code freeze.
Do you mean by winelib dll that the wine/Liunux native .so style DLL
is built which is linked/imported through fakedlib to the application?
That looks like feasible solution and I would consider this solution
if there is interrest in the application in Linux community
and not enough resource
I don't know much about this, but it sounds like a driver is the right
way to do this. It's probably just a case of Wine's driver support not
being good enough yet to support what you want to do. So the less
intrusive/hacky way to fix this would be to improve Wine's driver
support, ideally to a
What others have suggested in similar situations is to build a Linux
application that speaks to the device driver directly, and provides a socket
interface, then use sockets from the Windows program to talk to the device.
I didn't think of that. A winelib dll providing an API for directly
What if rect.Width is 0.25? Shouldn't we still clip then?
You may want to look into libwapi, which is a small library bundled in
the Mono source code that provides implementations of some Windows API
functions, which are simple but lacking features/compatibility.
Synchronization objects are local to the process, and there are no
drive letters, for
The man page for modf claims it produces an exact fractional part:
http://manpages.ubuntu.com/manpages/quantal/en/man3/modf.3.html
It's possible for modf to do this because the fractional part of a
floating point number cannot require more precision than the original
value.
So I think you've
Dealing with the bits of a floating point number directly is a bit
odd, and it makes it hard to review the code. Is there a reason you
don't want to use things like modf, floor, and ceil?
considering how old zlib is and the vast number of windows application which
uses zlib
Given how many people duplicate the effort to package zlib, the fact
that they're rarely updated, and the sort of problems gnulib exists to
work around, it would not surprise me if your particular zlib
Well, here's a simple thing you can check: Does your zlib dll link to
_lseek or _lseeki64? The first one uses a 32-bit offset. Wine's
implementation (http://source.winehq.org/source/dlls/msvcrt/file.c#L1090)
expands that to 64-bit and later truncates the file offset to 32-bit.
For a file larger
This looks wrong.
scaled_rect is an internally calculated value, not something supplied
by the user, and comparing it to 0.5 doesn't make sense, especially
since by this point the width was altered to add padding.
And why bother checking UNICODE?
Please clarify.
+MIDL_INTERFACE(509aaeda-5639-11d1-b6a1-f8757bf9)
+IPrintDialogServices : public IUnknown
+{
+#ifdef UNICODE
+virtual HRESULT STDMETHODCALLTYPE GetCurrentDevMode(LPDEVMODEW,UINT *) = 0;
+virtual HRESULT STDMETHODCALLTYPE
Is there anything wrong with my patches? The first one is marked as Pending.
The tests at least seem fine to me, assuming they currently pass on Wine.
Patch 2 still has some struct initialization with named fields, which
I don't think is allowed, but I figured I'd let that go and see what
Given that Wine uses winelib for its builtin exe's and dll's, and that
the way it works is not much different from a PE exe or dll, I don't
think winelib is likely to be at fault here. My guess is that you are
running into an ordinary Wine bug relating to your specific dll (and
probably Wine's
Mono on non-Windows platforms ships with a static library called
io-layer that implements a small subset of the Windows API for
compatibility reasons, without any server processes or a registry. It
does not (normally) attempt to do any path translation, so I think
that's as close as possible to
I think the reasons for the limitation on the virtual desktop setting
are more ideological than technical. It used to work the way you say,
but then Wine's desktop management was overhauled so that:
* Explorer.exe manages all desktop windows, including the virtual
desktop. I believe this is
I guess this makes sense, because having the clipping region change
with transforms would be weird when drawing recursively and changing
the transform. I had assumed clipping regions were in world
coordinates because most things are, but I didn't really have any
information either way.
Yay, thanks for fixing this. +1 :D
Maybe we could just skip loading the x11 driver is DISPLAY is unset.
It brings some logic into the driver logic that doesn't really belong
there, but it seems like a reasonable optimization and in practice
would work the way Alexandre wants even when the x11 libraries are as
spectacularly broken
Sorry, I'm still not sure this is going to work. It seems to me that
different lines will have to be offset by different amounts, and it's
not clear to me how that's going to happen without the alignment logic
in gdip_format_string.
I'm also wondering if a change to the alignment logic in
-if (format) halign = format-align;
-else halign = StringAlignmentNear;
-
How are you handling the case where format is NULL?
How are you handling the case where format is NULL?
Never mind, I see what you're doing. But since the block where you now
handle the horizontal alignment is inside an if (format-vertalign !=
StringAlignmentNear), this will break horizontal alignment when a
vertical alignment is not set.
Are you sure about this?
Other tests have suggested that native is not this exact when dealing
with color values, and different OS versions have produced slightly
different results.
Is there an application that relies on this, or is there a reason this
is generally more correct behavior when
Never mind, this makes sense to me now.
While this may be a useful exercise (and I'd personally like to see
some demangler improvements, particularly support for managed
references), this sort of broad test doesn't make sense for the Wine
test suite, especially if we can't be sure it will always work on
Windows. It's the sort of thing
alpha_blend_bmp_pixels() calls them while copying bitmap bits with an
alpha channel. This makes debug logs huge, hard to analyze, and completely
unmanagable in size.
GDI+ should be fixed so it doesn't call these functions internally.
It's just not an efficient way to render to bitmaps.
Please don't apply this [14/14] patch, it causes a test failure. I'm sending
it to show how this is going to look like eventually.
Yeah, GdipWidenPath isn't good enough for this yet. But I agree this
is the way to go, and the rest of the series looks good.
Well, GdipWidenPath is actually good enough for the things I've tested
so far, so it's basically working. What are the possible problems with
it you are aware of?
It doesn't implement dashed lines and most line cap styles. I think it
also mishandles pen-width == 0.
It doesn't have to be
OK, I'm about to say something weird, and I'll understand if everyone
else decides to ignore it.
I don't think WICCreateColorTransform_Proxy, or any of the Proxy
functions, should initialize or make use of COM.
Instead, I think it should work by calling WICCreateImagingFactory_Proxy.
I suspect
+hr = map_file(file, map, mem, size);
+if (FAILED(hr)) return hr;
+
...
+
+hr = IWICStreamImpl_InitializeFromMemory(stream, mem, size.u.LowPart);
+if (FAILED(hr)) goto error;
This makes me sad.
Is this really simpler than implementing Write and Seek for a file handle?
+{ wszTiffCompressionMethod, VT_UI1, VT_UI1,
{.iVal=WICTiffCompressionDontCare} },
This .field=value initialization syntax is not acceptable for Wine
(not in C89). I don't know another way to initialize unions.
+if (clsid_encoder == CLSID_WICTiffEncoder)
+todo_wine
@Vincent: I thought about adding the properties one at a time but it seemed
a bit like overkill for the tiff encoder, which has only two options. But I
will defenitly do this for the jpeg encoder, which has much more options.
Well, actually, on further consideration I can understand why you
Did you try running the tests in valgrind with this change? You're
essentially reverting 0ecd8daa16e4aa3df157a1175c611cdffc66d6fe which I
think was done to make valgrind happy.
+if (This-properties[i].pstrName)
+{
+HeapFree(GetProcessHeap(), 0, This-properties[i].pstrName);
+}
HeapFree already checks for NULL, so there's no need for an if statement here.
if (This-properties[i].pstrName)
{
HeapFree(GetProcessHeap(), 0, This-properties[i].pstrName);
+VariantClear( This-values+i ); /* Not initialized if
pstrName not initialized */
}
...
{
This-properties =
+if (idx -1)
+{
+VariantInit(pvarValue+i);
+res = VariantCopy(pvarValue+i, This-values+idx);
+phrError[i] = res;
+if (FAILED(res))
+break;
+}
This looks wrong to me. We have an array of error values to set
Other than the 6/6, this series looks good to me.
Thanks for breaking this up. It makes it much easier to review.
I'd suggest to use public APIs instead of inventing extenstions.
CreateBitmapFromMemory should work for this purpose if you really need
to do it using windowscodecs, otherwise GDI APIs may work as well.
I've been of the opinion that we should have a separate dll for Wine
extensions to WIC,
If there's really a demand for using native windowscodecs without
breaking d3dx9 (which already happens because of the TGA decoder), I
can supply a win32 build of our WIC extensions that winetricks could
install with it. I can't do anything about ICNS.
Yes, there are other ways we could do this.
If there's really a demand for using native windowscodecs without
breaking d3dx9 (which already happens because of the TGA decoder), I
can supply a win32 build of our WIC extensions that winetricks could
install with it. I can't do anything about ICNS.
TGA is the simplest format I've ever
TGA is the simplest format I've ever seen, CreateBitmapFromMemory is
the straight way to handle it. I haven't looked at ICNS support, but
probably it could be implemented using public APIs as well.
The main reason I put the TGA decoder in WIC is that I know nothing
about d3dx9 and wanted
You'll probably have to split this into smaller patches.
+return E_FAIL; /* FIXME: Function is not atomar on error,
but MSDN does not say anything about it */
I don't understand. Are you saying native leaks memory on error, and
if so how do you know this?
+
Looks good to me.
You appear to be leaking the IWICBitmapLock object.
Also, it seems odd that you're using the buffer AND IWICBitmapLock. I
assume the point of passing a buffer to BitmapImpl_Create (and wasting
a bit of time/memory) was to avoid IWICBitmapLock.
I hadn't noticed you had resent this, and made comments on the earlier
mail which still apply.
Series looks fine to me. And yes, testbot has been broken for a while now..
On Mon, Jan 7, 2013 at 11:24 AM, Charles Davis cdavi...@gmail.com wrote:
One area that might still be a problem, though, is if we associate *.exe
files with Wine itself: then when a user double-clicks on a Win32 executable,
LS will go straight to executing Wine.
You shouldn't be doing that
This looks good to me (and it's hard for me to stick to my preference
for IWICBitmapLock, given how little code is needed here to accomplish
the same thing).
The remaining todo is an unrelated bug that's my fault, and I'll
resend my patch for it if this one is accepted.
The series looks good to me. Of course, we can already read 8-bit
tiffs just fine, but I guess your app makes use of the 8bpp RGB
format.
We could probably avoid a double conversion between rgb and bgr when
reading an 8-bit tiff as rgb, by implementing and using the
IWICBitmapSourceTransform
On Wed, Jan 2, 2013 at 11:42 PM, Dmitry Timoshkov dmi...@baikal.ru wrote:
It's better to actually check return value of IWICBitmapLock_GetDataPointer
before memecpy(), or if that's not supposed to fail drop 'hr' assignment.
Whoops, good catch. (I don't think it can fail, but I didn't mean to
/imgfactory.c
+++ b/dlls/windowscodecs/imgfactory.c
@@ -1,5 +1,6 @@
/*
* Copyright 2009 Vincent Povirk for CodeWeavers
+ * Copyright 2012 Dmitry Timoshkov
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
I'm pretty sure CreateBitmapFromMemory copies the data rather than
referencing existing data.
How do you know that? In any case adding a test case and support for that
behaviour should be pretty trivial once this patch is accepted.
I believe it was this stack overflow question that first
Looks like I won't be around when this finishes, but I sent a test to
testbot: https://testbot.winehq.org/JobDetails.pl?Key=23638
This should succeed if your implementation is correct (data is
referenced, not copied).
It's much simpler if I can build on 12.04 and copy the binary packages,
however this means I can't use libtiff5 if I do so. Is there any
benefit in doing a separate build just for this?
At this point there is no benefit, but once bigtiff support is added to
windowscodecs.dll there will be
Thank you. That makes sense - that's the size of mono thereabouts. I guess my
next question is, does it also have codeweaver-specific bits? Sorry this
sounds rather lazy, but I am sure more than one person wants to know :-).
There are no CrossOver-specific changes to wine-mono. It's even the
From c785203469fe96df081c5b0812d64699ec8f4f2f Mon Sep 17 00:00:00 2001
From: Vincent Povirk vinc...@codeweavers.com
Date: Wed, 5 Dec 2012 13:15:25 -0600
Subject: [PATCH 3/4] gdiplus: Always use AlphaBlend to draw to 32-bit DIB's.
---
dlls/gdiplus/gdiplus_private.h |1 +
dlls/gdiplus
you won't get a negative height with GetObject,
Hmm, is GdipCreateBitmapFromHBITMAP doing it right, then? It assumes
all DIB objects have positive stride.
you won't get DIB info at all for DDBs.
I don't think it makes sense to do this for DDBs, as I can't draw them
directly and don't expect
It assumes all DIB objects have positive stride.
Sorry, I misread, that's assuming a negative stride.
you won't get a negative height with GetObject,
Hmm, is GdipCreateBitmapFromHBITMAP doing it right, then? It assumes
all DIB objects have positive stride.
No, that's wrong. It should most likely just do a GetDIBits (in one go,
not line by line like it currently does).
Does that mean
test failure
I.. might have forgotten this test was in a different file from the
other one I was working on when I went to run it on my Windows VM. In
any case, sorry about the noise, please disregard this last one.
It might be useful to post a listing of the files where unmarked
fall-throughs (falls-through?) appear, and I could see if any of them
are on my turf.
Does QueryCapability really initialize the decoder? Can you get a
frame out of it? I guess it never occurred to me to try.
I was OK with this for the other implementations because I figured
it'd be easy enough to invalidate the decoder after successfully
calling Initialize, if that turned out to
Series looks good to me.
You should at least look at the stream and check that it looks like an
image in a format the decoder can read.
For PNG, you could maybe argue that given a correct magic number and a
correctly-working decoder, the decoder must be able to read all the
images or either the decoder or image is
For JPEG and TIFF, which are extensible formats, there's also the
possibility that an image has something in it that we don't support
(and that the corresponding decoder on Windows doesn't support) but
some other decoder on the system can.
A not supported stream format is a bug and should be
1 - 100 of 576 matches
Mail list logo
