On Thu, 30 Dec 2004 21:47:42 -0800 (PST), Linus Torvalds
<[EMAIL PROTECTED]> wrote:
>
>
>
> So I looked at just sharing the code with the debug trap handler, and the
> result is appended. strace works, as does all the TF tests I've thrown at
> it, and the code actually looks better anyway (the ol
On Thu, 30 Dec 2004 14:46:17 -0800 (PST), Linus Torvalds
<[EMAIL PROTECTED]> wrote:
>
>
> Ok, here's a patch that may or may not make Wine happier. It's a _lot_
> more careful about TF handling, and in particular it's trying really
> really hard to make sure that a controlling process does not ch
Jon Griffiths wrote:
+docA.lpszDocName = WtoA( doc->lpszDocName );
+docA.lpszOutput = WtoA( doc->lpszOutput );
+docA.lpszDatatype = WtoA( doc->lpszDatatype;
Isn't there a missing parenthesis?
Jacek Caban wrote:
Changelog:
Implemented DllCanUnloadNow
BOOL WINAPI ITSS_DllCanUnloadNow(void)
{
-FIXME("\n");
-
-return FALSE;
+TRACE("dll_count = %lu\n", dll_count);
+return !dll_count;
This function should return an HRESULT, not a BOOL. This error would
have been caught
On Thursday 30 December 2004 18:39, Jesse Allen wrote:
> Blizzard's game patching software seems to use it to authenticate the
> patch archive. Your changes broke the patcher: "unable to
> authenticate", last time I checked, but I am unable to update to the
> current cvs at the moment. No source,
I'm pretty sure Steam does.
And, coincidentally, Steam happens to be broken at the moment, although
it does work in Crossover.
Also, I think the open source eMule uses that DLL a bit, IIRC to
generate a crypt key for each userid. Previous hacks to get eMule
working in Wine involved generating t
On Thu, Dec 30, 2004 at 09:08:58PM +, Mike Hearn wrote:
> I don't really understand why we can't make this an inline or something,
> it seems that it's a lot more convenient than the direct win32
> equivalents. Making it an inline would achieve the same effect as simply
> replacing each usage m
On Thu, 30 Dec 2004 15:41:06 -0500, Dimitrie O. Paun wrote:
> To be honest, I'm not too happy with this patch, HEAP_strdupWtoA
> was a good marker for code that needed fixing, this patch just
> makes those places harder to find.
I don't really understand why we can't make this an inline or somethi
On Wed, 29 Dec 2004, Linus Torvalds wrote:
> On Wed, 29 Dec 2004, Davide Libenzi wrote:
> >
> > I think same. My test simply let the function processing to let thru and
> > reach the fake signal sending point.
>
> No, your test-case doesn't even send a signal at all, because your
> test-program
On Thu, 30 Dec 2004, Jesse Allen wrote:
>
> Using the latest version of the patch on do_syscall_trace(), it still
> doesn't work unless I remove this test. If indeed it's supposed to
> fall through to receive the proper signal, (ie to single step properly
> after an int op), then removing it is
On Thu, Dec 30, 2004 at 07:57:31AM -0800, Jon Griffiths wrote:
> Hi,
>
> After applying, include/heap.h can be removed from cvs.
To be honest, I'm not too happy with this patch, HEAP_strdupWtoA
was a good marker for code that needed fixing, this patch just
makes those places harder to find.
--
On Thu, Dec 30, 2004 at 11:10:19AM -0500, Dimitrie O. Paun wrote:
> The way to do it is to prepare the output in a memory buffer, and
> output it at once. This can be done with the wine_dbg_sprintf()
> function. In cases where you need logic to construct the output
> (like testing for flags, etc),
> Word on the street is that we need an implementation of the DirectDraw
> clipper, but I have no idea if that's correct or if so, how much of it we
> need.
Last time I checked, it was not clipper related at all. It's basically (from
what I remember - I could be wrong) QuickTime that displays on t
On Thu, 30 Dec 2004 09:59:27 -0800 (PST), Davide Libenzi
wrote:
> On Wed, 29 Dec 2004, Linus Torvalds wrote:
>
> > On Wed, 29 Dec 2004, Davide Libenzi wrote:
> > >
> > > I think same. My test simply let the function processing to let thru and
> > > reach the fake signal sending point.
> >
> > No,
On Thu, 30 Dec 2004, Davide Libenzi wrote:
>
> This might explain what they were seeing, but OTOH it seems that the real
> cause of their problems is related to something else (according to other
> emails on this thread).
There's two different problems: the one seen by Thomas (the Xilinx FPGA
On Wed, 2004-12-29 at 20:15 -0800, Andrew Morton wrote:
> You can globally disable flex-mmap with
>
> echo 1 > /proc/sys/vm/legacy_va_layout
>
> Does it fix things?
Haven't tried. But setarch i386 -L /usr/bin/wine ... did fix it.
Tom
On Wed, 29 Dec 2004, Davide Libenzi wrote:
>
> I think same. My test simply let the function processing to let thru and
> reach the fake signal sending point.
No, your test-case doesn't even send a signal at all, because your
test-program just uses a PTRACE_SINGLESTEP without any "send signal"
On Wed, 29 Dec 2004, Linus Torvalds wrote:
> On Wed, 29 Dec 2004, Linus Torvalds wrote:
> >
> > .. no, I see what's up. System call returns _are_ special for
> > single-stepping. I'll think about it..
>
> Ok, I think I know what's up.
>
> It's literally the bogus fake signal that do_syscall_tr
On Wed, 29 Dec 2004, Linus Torvalds wrote:
> Will test whether it cleanly handles your test-case. Davide - you also
> added the TIF_SINGLESTEP flag to that _TIF_WORK_MASK, can you explain
> that?
I honestly do not remember, but I think is wrong and can be removed.
That's not the problem though
Thomas Sailer <[EMAIL PROTECTED]> wrote:
>
> Another pointer towards flexible mmap is that ulimit -s unlimited makes
> it work under 2.6.10-ac1 too.
>
You can globally disable flex-mmap with
echo 1 > /proc/sys/vm/legacy_va_layout
Does it fix things?
On Wed, 29 Dec 2004, Linus Torvalds wrote:
>
> So the updated patch would look something like the appended.
.. no, I see what's up. System call returns _are_ special for
single-stepping. I'll think about it..
Linus
On Wed, 29 Dec 2004, Linus Torvalds wrote:
>
> .. no, I see what's up. System call returns _are_ special for
> single-stepping. I'll think about it..
Ok, I think I know what's up.
It's literally the bogus fake signal that do_syscall_trace() sends. I
think the TIF_SINGLESTEP case in do_syscal
On Thu, 30 Dec 2004, Thomas Sailer wrote:
>
> No joy with
> linux-2.6.10
> patch-2.6.10-ac1
> 01-ptrace-reverse.diff
> sigtrap-reverse.diff
>
> Below is the seh trace output. In the working case (2.6.8) there is no
> trace:seh: output at this point.
I have no idea what "seh" is in wine-speak, b
On Wed, 29 Dec 2004, Linus Torvalds wrote:
> On Wed, 29 Dec 2004, Davide Libenzi wrote:
> >
> > I think same. My test simply let the function processing to let thru and
> > reach the fake signal sending point.
>
> No, your test-case doesn't even send a signal at all, because your
> test-program
Another pointer towards flexible mmap is that ulimit -s unlimited makes
it work under 2.6.10-ac1 too.
Tom
On Wed, 2004-12-29 at 18:10 -0800, Linus Torvalds wrote:
> I have no idea what "seh" is in wine-speak, but it appears that your
seh means structured exception handling in microsoft-speak.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/structured_exception_handling.a
On Wed, 2004-12-29 at 18:10 -0800, Linus Torvalds wrote:
> Some wine person would need to inform us about what the seh exception
> thing means.. "code c005"?
There's an interesting thing. Fedora Kernel 2.6.7 works for me, Fedora
Kernel 2.6.8 breaks wine/xst. Interestingly, Linus 2.6.8 works
On Wed, 29 Dec 2004, Davide Libenzi wrote:
>
> That test went in to be able to have ptrace single step, to see even the
> instruction following the #int instruction (this was the target of the
> patch itself). I just verified that, in 2.6.8 that does not have such test
> anymore, the single-s
No joy with
linux-2.6.10
patch-2.6.10-ac1
01-ptrace-reverse.diff
sigtrap-reverse.diff
Below is the seh trace output. In the working case (2.6.8) there is no
trace:seh: output at this point.
Tom
Compiling vhdl file U:/home/sailer/src/vhdl/dvbc_pcseng/vprim.vhd in
Library synwork.
trace:seh:EXC_Rt
On Wed, 29 Dec 2004, Linus Torvalds wrote:
> On Wed, 29 Dec 2004, Jesse Allen wrote:
> > >
> > > So instead of removing the setting of TIF_SINGLESTEP in set_singlestep(),
> > > can you test whether removing the _testing_ of it in do_syscall_trace()
> > > makes things happier for you? Hmm?
> > >
On Wed, 29 Dec 2004, Jesse Allen wrote:
> >
> > So instead of removing the setting of TIF_SINGLESTEP in set_singlestep(),
> > can you test whether removing the _testing_ of it in do_syscall_trace()
> > makes things happier for you? Hmm?
> >
>
> Yes, doing that does work. But I still have to r
On Thu, 30 Dec 2004 17:50:09 +0100, Michael Jung
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> In order to test rsaenh.dll, I'm looking for software, which applies the
> Microsoft Crypto-API. Any suggestions? It would be ideal, if the source is
> available.
>
> Ciao,
> Michael
>
>
Blizzard's game pa
On Thursday 30 December 2004 17:15, Dimitrie O. Paun wrote:
> I'm afraid it is . This is a case where the wine_dbg_sprintf()
> business is in order.
This time at least I know what I did wrong ^^
I'll fix these up as soon as I understand how wine_dbg_sprintf() works :)
--
Diego "Flameeyes" Pettenò
Hello,
In order to test rsaenh.dll, I'm looking for software, which applies the
Microsoft Crypto-API. Any suggestions? It would be ideal, if the source is
available.
Ciao,
Michael
On Thu, Dec 30, 2004 at 12:37:12PM +0100, Diego 'Flameeyes' Pettenò wrote:
> Hi,
> this time is a very small patch, it simply replace DPRINTF with TRACE without
> oher changes.
Once again, a job for wine_dbg_sprintf().
--
Dimi.
On Thu, Dec 30, 2004 at 12:33:52PM +0100, Diego 'Flameeyes' Pettenò wrote:
> I hope only my usual karma is not here this time or I'll make everybody lost
> time ^^
I'm afraid it is . This is a case where the wine_dbg_sprintf()
business is in order.
--
Dimi.
On Thu, Dec 30, 2004 at 12:22:18PM +0100, Diego 'Flameeyes' Pettenò wrote:
> Hi,
> The attached patch replaces DPRINTF -> TRACE in winedos dll, joining the near
> DPRINTF used to tace dos interrupts.
This looks good, but do we still need the explicit 'if (TRACE_ON(relay))'?
I think we can use the
On Thu, Dec 30, 2004 at 12:04:23PM +0100, Diego 'Flameeyes' Pettenò wrote:
> I had some spare time, and I wanted to do some mostly non-designing code, so
> I
> took the time to look at wine's janitorial projects, and I took a look at the
> DPRINTF -> TRACE conversion.
>
> The attached patch rem
On Thu, 30 Dec 2004 15:25:20 +0100, Michael Stefaniuc wrote:
> Now i get the stupid "make the whole display black" Quicktime thingy
That's a bug in DirectDraw, we have a bad hack in CrossOver for it but it
needs to be fixed properly.
Word on the street is that we need an implementation of the Dir
Eric Pouech wrote:
Is anyone still looking into this?
I'm seeing the same problem here (below messages repeated and 100% CPU
usage)
on RH 9 with the direct sound regression test and some games.
does this (new) patch help ?
Well, i don't know if it fixes their problem but at least it makes
Quickti
Vincent Béron <[EMAIL PROTECTED]> writes:
> Le mer 29/12/2004 à 05:38, Joris Huizer a écrit :
>
>> In debian the package is called libasound2-dev, version
>> "0.9.0beta10.9.0beta1" which should be the 0.9 branch of alsa
>
> Either update to alsa 1.0, downgrade Wine to prior
> 20040505, or switch
On Thu, 2004-12-30 at 11:09 +0100, Thomas Sailer wrote:
> On Wed, 2004-12-29 at 20:15 -0800, Andrew Morton wrote:
> > You can globally disable flex-mmap with
> >
> > echo 1 > /proc/sys/vm/legacy_va_layout
> >
> > Does it fix things?
>
> Haven't tried. But setarch i386 -L /usr/bin/wine ... di
Hi,
I'm still trying to figure out how nls/ime functions are placed in windows
systems to fix up the patch I sent some days ago.
I haven't had the time to find out if YuGiOh calls GetProcAddress (because
isn't mine, it's of a friend of mine which is trying to get it working, so I
need him to tes
On Wed, 2004-12-29 at 18:10 -0800, Linus Torvalds wrote:
> Some wine person would need to inform us about what the seh exception
> thing means.. "code c005"?
STATUS_ACCESS_VIOLATION, or the Win32 equivalent of a segfault. It would
appear that the ptrace changes are not responsible here, thou
Is anyone still looking into this?
I'm seeing the same problem here (below messages repeated and 100% CPU
usage)
on RH 9 with the direct sound regression test and some games.
does this (new) patch help ?
A+
Name: ntk
ChangeLog: fixed some regression from #51
License: X11
GenDate
45 matches
Mail list logo
