#wine-staging

better to hide join/part msgs..

:/

[06winetricks/master][05654454a](00http://is.gd/AxkWjs) 02Artem S. Tashkinov: A real albeit untidy help page

[06winetricks/master][0501c9767](00http://is.gd/ry3uxT) 02Artem S. Tashkinov: Preliminary Russian translation

[06winetricks/master][05233009a](00http://is.gd/PgujCA) 02Austin English: Merge pull request #619 from birdie-github/master

[06winetricks/master][0538e1a5f](00http://is.gd/jYcOF2) 02Austin English: Merge pull request #618 from birdie-github/patch-2

[06winetricks/master][0530209b5](00http://is.gd/QCyf1r) 02Artem S. Tashkinov: Typos

[06winetricks/master][05ac1f6e9](00http://is.gd/94jYIF) 02Austin English: Merge pull request #620 from birdie-github/master

slackner: Hi, do you guys have some update on whether you are ok merging gallium nine support ?

we are open to changes to the way the mesa library is packaged/distributed if that helps

would be very nice to have gallium nine support included in wine-staging :)

and gallium ten and eleven after that

we proposed a patch some time ago, but I'm not sure it was the right location

it was on some bug report about missing gallium nine support in staging

probably one issue is that you need to install gallium nine in order to have the headers needed for compiling its wine support

but It's entirely ok to put these headers in a separate package

for better retrocompatibility support, likely would be better put the headers from the new package in a different include directory than when current mesa targets

*where

I have one question though about library loading

Currently we ship a module (not a library), in /usr/lib/d3dadapter9 or something like that

pkg-config can find the location at compile time

obviously if we don't require gallium nine to be installed at wine compilation time (but only the headers), we'd need another solution

Some have suggested packaging instead a library, and putting it into /usr/lib would help. Any suggestion ? Is there other ways to solve the problem, and will that be the solution ?

should i create an issue in the wine or wine-staging entry in bugzilla?

to submit a patch

learn_more: this is one of the things not moved to the winehq infrastructure yet. you can open a patch submission request here: https://bugs.wine-staging.com/buglist.cgi?compo...

or send them directly to me

allright, thanks

i sent a job to patchbot, but its still queued

uhh

most of it's vm's are off?

lol

guess someone is doing maintenance or so

Hi, why does wine-staging need lib32 support?

slackner: can i submit the patch even tho the patchbot didnt process it yet?

learn_more: sure. you can add the link, maybe the testbot wakes up until i take a look ;)

allright

also, i added my name to the contributors list at the top of the c files

if the patch is too small for that, can you remove it?

learn_more: i am not aware of a specific limit, so adding your copyright is fine

ok

learn_more: just wondering, wouldn't it make sense to map the file into memory and use the macros/functions for the PE headers?

for which part DarkPlayer?

i query the stored hash from the pPDSip data

learn_more: the logic in SOFTPUB_HashPEFile

and i need to hash the file from disk, because loading it as image in memory might f.e. relocate it

you can also load a file without relocating it

either directly using MapViewOfFile or load as data file

hm yes, that would also be an option then

would that be better?

learn_more: you could then use commands like RtlImageDirectoryEntryToData

and don't have to implement the logic of parsing the headers

yes but i also need the offset of the DataDirectory entry itself

and iirc RtlImageDir doesnt give that?

learn_more: which offset do you need to know? RtlImageDirectoryEntryToData should return the address to the section

yes, but i need the thing that indicates the rva to the section and the size

as well as the section itself

i skip the OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY] as well

i didn't looked so much at your code yet, but RtlImageDirectoryEntryToData should return the address (i.e. load address + raw image offset) for files that are not mapped as image