This patch fixed it. Could you change the fixme message in user/hook.c
to something more explicit than "won't work right," or at least include
a comment in the code explaining why it won't work right?
-Steve
steve.lustbader(a)philips.com writes:
> It's returning NULL for me, which implies it isn't working. Is there some
> sort of trace that I can send you to help you out?
Oops you are right, this should fix it:
Index: server/hook.c
===================================================================
RCS file: /opt/cvs-commit/wine/server/hook.c,v
retrieving revision 1.1
diff -u -r1.1 hook.c
--- server/hook.c 29 Oct 2002 00:41:42 -0000 1.1
+++ server/hook.c 30 Oct 2002 19:51:20 -0000
@@ -227,7 +227,8 @@
set_error( STATUS_INVALID_PARAMETER );
return;
}
- if (!(thread = get_thread_from_id( req->tid ))) return;
+ if (!req->tid) thread = (struct thread *)grab_object( current );
+ else if (!(thread = get_thread_from_id( req->tid ))) return;
if ((hook = add_hook( thread, req->id - WH_MINHOOK )))
{
--
Alexandre Julliard
julliard(a)winehq.com
Hi,
I have CrossOver beta 1.3 and have got IE6 installed and version 3 of
the Adobe SVG viewer. The installer doesn't work, but I got around that
problem, the issue I'm interested in solving now is that mouse
interaction is messed up, namely that when the plugin receives a
mousemove event, it appears to immediately receive another for 0,0 -
this is just a theory I've got however.
I'm wondering if there's a way to restrict debug logging to code in a
particular file? I'm not interested in any mouse messages except those
to the COM object in NPSVG3.dll
thanks -mike
winapi_check tells me:
ndr_stubless.c:86: rpcrt4: LONG_PTR WINAPIV
NdrClientCall2(PMIDL_STUB_DESC,PFORMAT_STRING,...): argument 1
documentation: \
/* CLIENT_CALL_RETURN */
rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI
RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR):
no translation defined: PRPC_BINDING_VECTOR
rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI
RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR):
no translation defined: PUUID_VECTOR
rpc_epmap.c:102: rpcrt4: RPC_STATUS WINAPI
RpcEpUnregister(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR):
argument 2 type is forbidden: PRPC_BINDING_VECTOR (unknown)
how shall I deal with these?
--
gmt
"The purpose of government is to rein in the rights of the people"
--President Bill Clinton, MTV interview, 1993
>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes:
Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
>> However when unzip has unpacked the 160 MByte file and the Setup
>> should start, a crash happens, and the debugger startup stops with
>> "Memory exhausted". The same happens when I run in winedbg: Loaded
>> debug information from ELF
>> '/home/bon/tmp/wine/compile/wine/miscemu/wine' (0x00000000)
>> Breakpoint 2 at 0x4000c714 (_end+0xf7fec) Memory exhausted.
Alexandre> You probably need reduce the base address a bit to leave more
Alexandre> space for malloc(). Try changing the 0x3ff to 0x3f0. Now of
Alexandre> course we shouldn't be using malloc, so that hack would be a
Alexandre> good way to enforce that <g>
Alexandre,
could we get this into the wine tree? At least one person stumled across
that with the same application I had.
Bye
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Hi!
I am not sure if this is a bug, or I did something wrong. My collegaues
made a little program what shows the bug. It shows an EMF file, but the
text boxes appears bad. Two screenshots and the source
are included in the tar.gz.
Please somebody examine it, and help me if you can.
The source, binaries, and screenshots can be downloaded from
ftp://ftp.uhulinux.hu/misc/testprg.tar.gz. It needs to be exctracted to
the wine c:\ directory
Thanks for your help in advance!
If needed I can send you wine debug msgs.
--
doome
Hello,
is somebody working on the richedit dll? I encountered 3 unknown RTF
control words and wanted to add them but I got scared by the overzealous
use of #define's in rtf.h . My first impuls was exchange that with some
enum's, but i thought i better ask here before i do the work in vain.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbH Email: mstefani(a)redhat.com
Hauptstaetterstr. 58 http://www.redhat.de/
D-70178 Stuttgart
Hallo,
did I miss something or is it me or is the registry entry ( as advertised in
winedefaults.reg)
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Debugger"="winedbg --debugmsg -all %ld %ld"
not honored any more ( since some time).
The relay log is cluttered with about 150k lines of debugger start relay
output :-(
Bye
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Greg Turner <gmturner007(a)ameritech.net> writes:
> diff -ur -x CVS -x 'bigdif*' ../wine.test/dlls/rpcrt4/rpc_binding.c ./dlls/rpcrt4/rpc_binding.c
> --- ../wine.test/dlls/rpcrt4/rpc_binding.c 2002-10-29 12:59:02.000000000 -0600
> +++ ./dlls/rpcrt4/rpc_binding.c 2002-10-29 13:28:39.000000000 -0600
> @@ -865,14 +865,21 @@
> * Exists in win9x and winNT, but with different number of arguments
> * (9x version has 3 arguments, NT has 2).
> */
> +#ifdef WINNT
> +RPC_STATUS WINAPI I_RpcBindingSetAsync( RPC_BINDING_HANDLE Binding, RPC_BLOCKING_FN BlockingFn)
> +#else
> RPC_STATUS WINAPI I_RpcBindingSetAsync( RPC_BINDING_HANDLE Binding, RPC_BLOCKING_FN BlockingFn, unsigned long ServerTid )
> +#endif
> {
This can't work, we are not going to build two versions of Wine with
different #ifdefs. We should simply decide which version we support
(NT would probably be preferable) and get rid of the #ifdefs in the
header.
--
Alexandre Julliard
julliard(a)winehq.com
Hallo,
e.g. on www.heise.de there is the news that MS announces to drop support for
Win98/ME for the next office version.
That's probably a point in time when many people will look for
alternatives. Hopefully Wine and Linux are in good shape then.
Bye
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
On Wed, 30 Oct 2002, Keith Matthews wrote:
[...]
> Stressing the number of calls in the MS API is another important point
> to make, thanks to Andreas for providing an updated figure.
For more API stats you can check out the following page (and
disclaimer):
http://fgouget.free.fr/wine/winapi_stats-en.shtml
While I'm writing I will just mention some other links relevant to the
'Wine perception' aspect:
* Contributing to Wine
Trying to present ways to get started helping Wine. More work is
needed on this section and it needs to be made much more visible.
http://www.winehq.com/about/index.php?contrib
* Why Wine is so important
Many people have a primitive 'say no to Windows software' attitude
because they do not understand why Wine is important.
http://www.winehq.com/about/index.php?why
* Debunking Wine Myths
These myths are quite common and detract to Wine's image
http://www.winehq.com/about/index.php?myths
Here's my thoughts on getting more developpers:
* I think step one is fixing Wine's perception issues by improving the
Web site to make the above more visible, add screenshots and make it
easier to navigate.
* Step two is to add more resources geared towards new developpers to
make it easier for them to get started (e.g. taslets bug list, finish
the conformance testing guide, update the developer's guide, etc.).
* Step three is to be more outgoing. Do a better job at describing the
tasks that need to be done for instance. Let people know that we need
help, that with done much with less than one tenth the number of
developpers that the Linux kernel has. Someone suggested making Wine
presentations at local LUGs. I think that's a goog idea too.
I have done some work on the above items (all committed) but I'm not a
technical writer so it takes me a lot of time to write documentation and
I'm rarely happy with the result. And free time is in very short supply
currently. Plus I'm not familiar with PHP which would be required for
some of the Web site changes (again a time issue). So please, if anyone
feels like updating the web site or writing documentation, go ahead.
Wine needs you!
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
$live{free} || die "";
