On 3/21/2012 08:58, Eric Culp wrote:
The two functions have different return values on windows for analogous inputs.
Changed to match windows behavior.
---
dlls/shlwapi/url.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
Please add some tests for that.
On 3/21/2012 09:24, Eric Culp wrote:
On Wed, Mar 21, 2012 at 2:59 AM, Nikolay Sivov bungleh...@gmail.com
mailto:bungleh...@gmail.com wrote:
On 3/21/2012 08:58, Eric Culp wrote:
The two functions have different return values on windows for
analogous inputs.
Changed
--- On Tue, 20/3/12, Hin-Tak Leung ht...@users.sourceforge.net wrote:
snipped
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
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 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 note, are
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
make
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
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
- 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:
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
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 does get
On Wed, Mar 21, 2012 at 1:04 AM, Matteo Bruni matteo.myst...@gmail.com wrote:
Il 20 marzo 2012 19:12, Christian Costa titan.co...@gmail.com ha scritto:
* Implement D3DXCreateCubeTextureFrom* and
D3DXCreateVolumeTextureFrom* functions.
That depends on the DDS file format support, I guess.
Le 21/03/2012 20:17, Józef Kucia a écrit :
On Wed, Mar 21, 2012 at 1:04 AM, Matteo Brunimatteo.myst...@gmail.com wrote:
Il 20 marzo 2012 19:12, Christian Costatitan.co...@gmail.com ha scritto:
* Implement D3DXCreateCubeTextureFrom* and
D3DXCreateVolumeTextureFrom* functions.
That depends on
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
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 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
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
MapViewOfFile
On 22 March 2012 00:50, Michael Stefaniuc mstef...@redhat.de 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,
+
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 of
Joey Yandle dra...@dancingdragon.be 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
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 context
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
22 matches
Mail list logo
