Bottom post on this ML please.
On 09/20/2010 09:24 AM, Zachary Smith wrote:
(Missed the mailing list the first time, sorry.)
I'll merge the patches and fix the formatting later this evening, as
well as correct a few compiler warnings I accidentally overlooked.
Regarding the spaces with opening
This is a patch that attempts to override mmap, mmap64, and munmap so that
host libs can used memory from the Wine heap instead of being restricted to
the address space Wine leaves unreserved. It is based on Albert Lee's patch
found here:
http://bugs.winehq.org/show_bug.cgi?id=13335#c170
It ha
On Mon, Sep 20, 2010 at 5:38 PM, Joerg Schiermeier
wrote:
> ---
> skins/custom/index.css | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/skins/custom/index.css b/skins/custom/index.css
> index 2c40719..bf064c4 100644
> --- a/skins/custom/index.css
> +++ b/skins/cu
On Mon, 20 Sep 2010, Alexandre Julliard wrote:
>> In the past this has found a dozen or two real issues and lead to some
>> simplifications. Now the tree is clean in that regard, so we can make
>> this a default.
> I still see a ton of warnings here (gcc 4.4.5), mostly because of the
> glibc stri
On Monday, September 20, 2010 06:49:20 Alexandre Julliard wrote:
> Mike Frysinger writes:
> > On Sunday, September 19, 2010 17:17:53 Alexandre Julliard wrote:
> >> Mike Frysinger writes:
> >> > i dont see how that would help. the code is currently:
> >> > typedef struct ... {
> >> >
> >> > ...
>
---
skins/custom/index.css |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/skins/custom/index.css b/skins/custom/index.css
index 2c40719..bf064c4 100644
--- a/skins/custom/index.css
+++ b/skins/custom/index.css
@@ -7,6 +7,8 @@
}
div#login_box {
position: relative
On Monday, September 20, 2010 2:42:51 pm Tijl Coosemans wrote:
> On FreeBSD off_t is always 64 bit.
Even on 32-bit systems? I'll have to take that into account, then.
Hi Vitaly.
Thanks for fixing printing issues.
You use sizeof(DEVMODEW) in you patch, but the correct size is:
devmodeW->dmSize + devmodeW->dmDriverExtra
You should change the FIXME in the comment of get_job_info_2
to a real FIXME, when unicode is FALSE
I'm fine with the unicode - only patch for
On Monday 20 September 2010 23:37:28 Chris Robinson wrote:
> On Monday, September 20, 2010 2:20:00 pm Tijl Coosemans wrote:
>> I've attached a patch that takes a different approach. I still need to
>> test it more extensively, but is this patch acceptable in principle?
>>
>> It adds an mmap symbol
On Monday, September 20, 2010 2:20:00 pm Tijl Coosemans wrote:
> I've attached a patch that takes a different approach. I still need to
> test it more extensively, but is this patch acceptable in principle?
>
> It adds an mmap symbol to the loader thereby overriding the libc symbol.
I've actually
On Monday 20 September 2010 15:10:58 Alexandre Julliard wrote:
> Tijl Coosemans writes:
>> With this patch it is possible that a .dll.so is loaded beyond the
>> 2GiB limit, but this does not seem to be a problem in practice. All
>> mmap calls from within Wine and thus all .dll stay below 2GiB and
Am 20.09.2010 20:05, schrieb Henri Verbeet:
But if it turns out to really be much nicer you could certainly
introduce a dxbc_remove_section() function, but I doubt it. In the
current patch it's simply dead code though. Somewhat related, do you
happen to know if section tags need to be unique wit
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=5355
Your paranoid android.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=5354
Your paranoid android.
2010/9/20 Rico Schüller :
> D3DGetDebugInfo() (D3DGetBlobPart(D3D_BLOB_DEBUG_INFO)) isn't the only one
> which returns just the memory. There are other cases as well (e.g.
> D3D_BLOB_LEGACY_SHADER) which do the same stuff. It doesn't make it
> impossible to add a DXBC containing a SDBG chunk, it on
2010/9/20 Rico Schüller :
> Sure that abroach works pretty well for the D3DGetBlobPart() function, but
> you it is a bit ugly to use it for the D3DStripShader(). There you have to
> add some quirks. You would have to parse the dxbc twice to get the correct
> count (could be != count in dxbc origina
Am 20.09.2010 13:09, schrieb Henri Verbeet:
2010/9/19 Rico Schüller:
---
I don't think this makes a lot of sense. D3DGetDebugInfo() clearly
doesn't return a DXBC, so I think you should just memcpy it into the
blob directly instead of trying to abuse dxbc_write(). This change
would als
Am 20.09.2010 13:09, schrieb Henri Verbeet:
I think it's close, but not entirely what I had in mind. You can avoid
both the callback and some of the data copies if you just let
parse_dxbc() create a list / array of sections. So you'd have
something like this:
struct dxbc_section
{
DWORD tag
Mike Kaplinskiy writes:
> +wsa->read = HeapAlloc( GetProcessHeap(), 0, sizeof(*wsa->read) );
> +if (!wsa->read)
> +{
> +status = STATUS_NO_MEMORY;
> +goto finish;
> +}
> +wsa->read->hSocket = wsa->accept_socket;
> +wsa->read->flags = 0;
> +wsa
(Missed the mailing list the first time, sorry.)
I'll merge the patches and fix the formatting later this evening, as
well as correct a few compiler warnings I accidentally overlooked.
Regarding the spaces with opening and closing parentheses, are you
saying I should or should not include space?
On 9/20/10 12:22 AM, James McKenzie wrote:
Interestingly enough, when Wine goes to update my .wine prefix, the
updater is trying to run regsvr32 through Gecko.
This sentence doesn't make any sense, I'm afraid.
Jacek
On 09/19/2010 03:21 PM, Zachary Smith wrote:
This Patch:
Here I add find_osx_top_level() to the file, which is designed to identify
top level HID collections. It is independent from patch [2/3] but required
for patch [3/3]
Your formatting does not match the rest of the file (curly braces on
s
Tijl Coosemans writes:
> With this patch it is possible that a .dll.so is loaded beyond the
> 2GiB limit, but this does not seem to be a problem in practice. All
> mmap calls from within Wine and thus all .dll stay below 2GiB and core
> .dll.so such as ntdll, kernel32, user32,... are also loaded
Aleksey Bragin writes:
> diff --git a/server/class.c b/server/class.c
> index 0e402ba..90ab436 100644
> --- a/server/class.c
> +++ b/server/class.c
> @@ -47,6 +47,7 @@ struct window_class
> int local; /* local class? */
> atom_t atom;/* class a
Hi,
Alexandre Julliard wrote:
>> it needs to be "foo[]". ANYSIZE_ARRAY is defined as 1
>True, you don't want to change the public one, but you can define a
>shell32-specific version of it. At least then it looks like a normal
>array declaration.
Thank you for pointing to ANYSIZE_ARRAY.
Why not
Gerald Pfeifer writes:
> In the past this has found a dozen or two real issues and lead to some
> simplifications. Now the tree is clean in that regard, so we can make
> this a default.
I still see a ton of warnings here (gcc 4.4.5), mostly because of the
glibc string macros.
--
Alexandre Ju
2010/9/19 Rico Schüller :
> ---
I don't think this makes a lot of sense. D3DGetDebugInfo() clearly
doesn't return a DXBC, so I think you should just memcpy it into the
blob directly instead of trying to abuse dxbc_write(). This change
would also make it impossible to write any DXBC containing an SD
I think it's close, but not entirely what I had in mind. You can avoid
both the callback and some of the data copies if you just let
parse_dxbc() create a list / array of sections. So you'd have
something like this:
struct dxbc_section
{
DWORD tag;
const char *data;
SIZE_T data_size;
}
2010/9/19 Rico Schüller :
> +FIXME("data %p, data_size %lu, part %#x, flags %u, blob %p stub!\n",
> data, data_size, part, flags, blob);
I think %#x is more appropriate than %u for flags.
Mike Frysinger writes:
> On Sunday, September 19, 2010 17:17:53 Alexandre Julliard wrote:
>> Mike Frysinger writes:
>> > i dont see how that would help. the code is currently:
>> > typedef struct ... {
>> >
>> >...
>> >CHAR foo[1];
>> >
>> > } ...;
>> >
>> > it needs to be "foo[]". A
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=5346
Your paranoid android.
31 matches
Mail list logo
