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 the
>> > 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 mas
> 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.
Maybe the format for 32-bit bitmaps should be determined by the alpha
channel options?
On Monday, September 16, 2013, Dmitry Timoshkov wrote:
> Based on a gdiplus implementation.
> ---
> dlls/windowscodecs/imgfactory.c | 149
+-
> dlls/windowscodecs/tests/bi
> 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'
BTW, we should probably quit early if max_glyphsize is 0 at the end of
the first loop, rather than fail with OutOfMemory.
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?
> 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. F
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.
+/* 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 the
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 s
> mscoree.c:179: Test failed: version is L"v1.1.4322" , expected L"v2.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
On Wed, Aug 14, 2013 at 4:04 PM, Daniel Jeliński 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 because it would affect
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.
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?
Looks good, thanks.
>> 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 on
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 dedicate
> 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 t
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 feed
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.
Actually, this will be a problem on libtiff 3.x, where toff_t really
is supposed to be 32-bit.
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?
> 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?
> 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 de
The series looks good to me.
This series looks good to me.
I'm curious what happens if the world transform has some rotation. It
seems like transform_rectf would break in that case.
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 resou
> 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
ac
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 poi
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 example
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 esse
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?
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 tha
> 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 bina
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 GetCurr
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 64-b
> 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
hap
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 wha
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 requir
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 as
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
gdip_for
> 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.
> -if (format) halign = format->align;
> -else halign = StringAlignmentNear;
> -
How are you handling the case where format is NULL?
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 yo
Never mind, this makes sense to me now.
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 prem
> 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.
> 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 pe
> 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.
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 t
> +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 handl
> @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
+{ 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 test_s
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.
Other than the 6/6, this series looks good to me.
Thanks for breaking this up. It makes it much easier to review.
+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 f
if (This->properties[i].pstrName)
{
HeapFree(GetProcessHeap(), 0, This->properties[i].pstrName);
+VariantClear( This->values+i ); /* Not initialized if
pstrName not initialized */
}
...
{
This->properties = Heap
+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.
>> > 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 d3d
>> 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'v
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
> 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,
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?
+FIXME("Appl
Looks good to me.
I hadn't noticed you had resent this, and made comments on the earlier
mail which still apply.
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.
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 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 anyway. Any assoc
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 inter
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.
On Wed, Jan 2, 2013 at 11:42 PM, Dmitry Timoshkov 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
make that assumpt
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).
>> 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 fir
E_OUTOFMEMORY;
> +}
> +This->owndata = TRUE;
> }
> +else
> +This->owndata = FALSE;
>
> This->IWICBitmap_iface.lpVtbl = &BitmapImpl_Vtbl;
> This->ref = 1;
> diff --git a/dlls/windowscodecs/imgfactory.c b/dlls/windowscod
>> 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 w
> 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 t
From c785203469fe96df081c5b0812d64699ec8f4f2f Mon Sep 17 00:00:00 2001
From: Vincent Povirk
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/graphics.c|
>>> 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
> 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.
> 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
> 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 b
Series looks good to me.
>> 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
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 broken.
1 - 100 of 582 matches
Mail list logo
