> Is it possible to compile 32bit wine in 64bit ubuntu 12.10? I heard
> there were problems in 12.04 - were they resolved?
>
I've been happily building 32-bit wine on 64-bit ubuntu 12.04. I just
had to make a debootstrap chroot:
https://help.ubuntu.com/community/DebootstrapChroot/
It only ta
> I know that for a while there were some packaging problems that meant
> that upgrading to 12.04 made compiling 32-bit Wine on a 64-bit PC
> extremely difficult.
I was able to patch and build 32-bit wine on 64-bit 12.04, using a
debootstrap chroot:
https://help.ubuntu.com/community/Debootstr
>
> Writable shared memory is unacceptable, but as long as it's read-only
> from the client there's no problem in principle.
>
Excellent, thanks Alexandre.
I'm attaching my current shared memory diff. It uses shm_open + mmap in
wineserver to map the shared memory area read/write, and shm_open
>
> Can you use a separate process -- a Win32 service -- to update this shared
> memory?
>
Something like plugplay.exe? I don't see why not. I'll look over the
plugplay.exe code and see if it looks promising.
cheers,
Joey
> It's been continously said that any memory sharing scheme between a client
> and wineserver won't be accepeted, ever.
You're the second person to make that assertion without pointing out the
relevant discussion. Such assertions are not helpful.
> You need to make wineserver multithreaded then,
> Why do you need to update the data in wineserver and not in the client?
The problem is that the timer updates need to be extremely precise, or
they are worse than useless. So we can either do that in every wine
process, or do it once in wineserver and share the memory.
On Windows, the kernel s
>
> I know they declined an in-process wineserver due to difficulties
> blaming the right component on a crash: is it the app or wine that's faulty?
>
> I found no other relevant discussion on wine-devel since January 2010,
> when searching for first 'share' and then 'server'.
>
If anyone does
> When numbers don't increment (as happens now) protection is
> happy. When they start to increment, even on fast PCs round trip
> user-space->wineserver->ntoskrnl will take way longer then it "should".
>
Indeed, that pathway will never be fast enough. I'm surprised it works
with no incrementing,
>
> BTW one more thing, this change will most likely break number of copy
> protection systems. Such as safedisk. They use user shared date times to
> estimate time it took for some kernel operations. And some of those time
> intervals are really tight.
>
I'm extremely confused by this statement
>
> 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
>
> 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
> 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
>
> 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.
>> 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
>
> - 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
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
17 matches
Mail list logo
