On 3/22/2012 6:00 AM, Dmitry Timoshkov wrote:
Joey Yandle wrote:
It's been explained several times already that any approach to share data
between wineserver and clients is going to be rejected.
I think this is the reason that timers in shared_user_data are not being
updated. I also think tha
On 03/21/2012 10:19 PM, Joey Yandle wrote:
If not, can you look at the APC based patch I posted and let me know how
to make the callbacks happen with more precise timing?
Yes, that is the only possible way to do this currently in Wine. Separate
thread is a no-go. It will break some application
>
> It's been explained several times already that any approach to share data
> between wineserver and clients is going to be rejected.
>
Can you point me to such an explanation? I joined wine-devel just
before posting my RFC. If this has been discussed previously, I'd
prefer to get the contex
Joey Yandle wrote:
> After looking over the code, I think I should just mmap() directly in
> wineserver rather than using MapViewOfFile; I should however still use
> MapViewOfFile in ntdll/thread.c.
>
> Mr Google tells me that I can get a handle for MapViewOfFile by calling
> CreateFileMapping.
>
> So I'm going to go ahead and try this now. If anyone has a issue with
> this approach, please let me know.
>
I implemented this approach, only to find that numerous places in ntdll/
write to user_shared_data. I need to move all of that code to server/,
which will take a while, since much o
On 22 March 2012 00:50, Michael Stefaniuc wrote:
> -static HRESULT STDMETHODCALLTYPE d3d10_device_inner_QueryInterface(IUnknown
> *iface, REFIID riid, void **object)
> +static HRESULT STDMETHODCALLTYPE d3d10_device_inner_QueryInterface(IUnknown
> *iface, REFIID riid,
> + void **ppv)
> {
> 2. in server/main.c:
>
> int fd = shm_open("/KUSER_SHARED_DATA", O_RDWR | O_CREAT, 0600);
> // call MapViewOfFile to map fd to 0x7ffe
>
After looking over the code, I think I should just mmap() directly in
wineserver rather than using MapViewOfFile; I should however still use
MapViewOf
>
> MapViewOfFile (and the underlying NtMapViewOfSection) has support for
> specifying the address to map it.
>
So what I should do is:
1. in ntdll/thread.c:thread_init:
int fd = shm_open("/KUSER_SHARED_DATA", O_RDONLY | O_CREAT, 0600);
// call MapViewOfFile to map fd to 0x7ffe
2. in
On 3/21/2012 9:11 PM, Joey Yandle wrote:
If user_shared_data was written by wineserver and mapped read-only to
wine processes there was no need to create separate threads in wine
processes. As I know Windows is sharing this structure and is updating
it in kernel mode so wine behavior was similar
>
> If user_shared_data was written by wineserver and mapped read-only to
> wine processes there was no need to create separate threads in wine
> processes. As I know Windows is sharing this structure and is updating
> it in kernel mode so wine behavior was similar if was updated by
> wineserver.
On 3/21/2012 2:20 PM, Marcus Meissner wrote:
However, I do not know if we can have additional threads at all in a
Win32 process without confusing the win32 processes, or if this needs
to be solved differently (APC?).
If user_shared_data was written by wineserver and mapped read-only to
wine pr
Le 21/03/2012 20:17, Józef Kucia a écrit :
On Wed, Mar 21, 2012 at 1:04 AM, Matteo Bruni wrote:
Il 20 marzo 2012 19:12, Christian Costa ha scritto:
* Implement D3DXCreateCubeTextureFrom* and
D3DXCreateVolumeTextureFrom* functions.
That depends on the DDS file format support, I guess.
Yes,
On Wed, Mar 21, 2012 at 1:04 AM, Matteo Bruni wrote:
> Il 20 marzo 2012 19:12, Christian Costa ha scritto:
>>> * Implement D3DXCreateCubeTextureFrom* and
>>> D3DXCreateVolumeTextureFrom* functions.
>
> That depends on the DDS file format support, I guess.
>
Yes, it could be a part of my GSoC pro
>> However, I do not know if we can have additional threads at all in a
>> Win32 process without confusing the win32 processes, or if this needs
>> to be solved differently (APC?).
>>
>
> A previous version of my patch used NtTimer/APC:
>
I'm attaching a cleaned up version of my APC code. It do
On 3/21/12 6:48 PM, HolyCause wrote:
Jacek,
Perhaps there would be needed some temporary hacks
that would allow mixing new and old parsing code while it's rewritten
part by part. I think such a project would be good, as long as student
is prepared to deal with this.
I'm not sure we want to pr
>
> - The shared data structure should be modified with atomic
> accesses only. (Or use a criticalsection if possible.)
>
According the this website, Windows updates the times too frequently to
use a critical section:
http://www.dcl.hpi.uni-potsdam.de/research/WRK/2007/08/getting-os-informat
Jacek,
Perhaps there would be needed some temporary hacks
that would allow mixing new and old parsing code while it's rewritten
part by part. I think such a project would be good, as long as student
is prepared to deal with this.
I'm not sure we want to promote larger tasks on cmd, such as GS
Andrew, Aric, Maarten,
I'm pleased to see that patches to quartz and mciqtz keep flowing in.
For the last years, I've wondered whether I should open a sort of generic bug
that mciqtz/quartz still is a mostly broken MCI device, missing many basic
functions. Every time I try it out using my MCI sh
On Tue, Mar 20, 2012 at 06:40:37PM -0700, Joey Yandle wrote:
> Hi everybody,
>
> As originally discovered by Carsten Juttner, Star Wars: The Old Republic
> uses the time values in KUSER_SHARED_DATA to trigger network send
> buffers. wine does not currently update these values, so TOR does not
> m
On 03/20/12 23:15, HolyCause wrote:
> michael,
>
> > Getting that into Wine in small and incremental patches will be hard as
> > a big drop in patch is not an option.
> I don't know if I understand "a big drop in patch"... Do you mean
> committing all of the changes as one, large patch?
>
> On that
Hi everybody,
As originally discovered by Carsten Juttner, Star Wars: The Old Republic
uses the time values in KUSER_SHARED_DATA to trigger network send
buffers. wine does not currently update these values, so TOR does not
make it past an initial server handshake.
I'm attaching my current patch
--- On Tue, 20/3/12, Hin-Tak Leung wrote:
> > FWIW I was planning on improving cmd as my GSoC
> project, and
> > I've talked to Dan Kegel about it - there's been no
> protests
> > (only support) thus far on that front, so it at least
> seems
> > doable.
> >
> > In terms of being valid... if cmd
22 matches
Mail list logo
