wine-devel

wine-devel@winehq.org

1 participants
84464 discussions

Re: rpc_H_PL9
by Michael Stefaniuc 31 Oct '02

31 Oct '02

On Thu, Oct 31, 2002 at 08:49:18AM -0600, Greg Turner wrote: > LICENSE: X11 > > CHANGELOG: > * dlls/rpcrt4: rpc_server.c; > include: rpcdcep.h: > Greg Turner <gmturner007(a)ameritech.net> > - One more fixup for winapi_check > -UINT WINAPI I_RpcWindowProc( HANDLE hWnd, UINT Message, UINT wParam, ULONG lParam) +UINT WINAPI I_RpcWindowProc( void *hWnd, UINT Message, UINT wParam, ULONG lParam ) That's totaly broken. It's a problem in winapi_check and not in your code. Well, their is a problem in your code too, i would change HANDLE to HWND. 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

2 2

RE: winapi_check question...
by Patrik Stridvall 31 Oct '02

31 Oct '02

> winapi_check tells me: > > ndr_stubless.c:86: rpcrt4: LONG_PTR WINAPIV > NdrClientCall2(PMIDL_STUB_DESC,PFORMAT_STRING,...): argument 1 > documentation: \ > /* CLIENT_CALL_RETURN */ This is because winapi_check misparser the line: LONG_PTR /* CLIENT_CALL_RETURN */ RPCRT4_NdrClientCall2(PMIDL_STUB_DESC pStubDesc, PFORMAT_STRING pFormat, va_list args) Ignore it. > rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI > RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR): > no translation defined: PRPC_BINDING_VECTOR This is because winapi_check doesn't know the type of PRPC_BINDING_VECTOR. One day I will teach it to parse the header files properly. Until then tell it what type it is in the the file tools/winapi/win32.api: %%rpcrt4 ... %ptr ... PRPC_BINDING_VECTOR ... Since PRPC_BINDING_VECTOR is presumable a pointer it goes under the ptr section. > rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI > RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR): > no translation defined: PUUID_VECTOR Same as above. > 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) Same as above. > how shall I deal with these? Fix them as above or do as everybody elses do wait for me to fix it. :-)

2 1

Re: dlls/msvcrt/tests: printf
by Uwe Bonnes 31 Oct '02

31 Oct '02

>>>>> "Jaco" == Jaco Greeff <jaco(a)puxedo.org> writes: Jaco> ... Tests that will fail Jaco> with current implementation are temporarily commented out Don't comment them out, matrk them "todo". Look at the syntax in documentation/testing. And plain inlined patches are preferred against attachments. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: Re: So lets say we do it
by chrismorgan＠rcn.com 31 Oct '02

31 Oct '02

> > From: Alexandre Julliard <julliard(a)winehq.com> > Date: 2002/10/31 Thu AM 11:24:28 EST > To: dpaun(a)rogers.com > CC: Wine Devel <wine-devel(a)winehq.com> > Subject: Re: So lets say we do it > > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > So the 5% left, install wine, install a Win-app, and play around. > > Great, it works! > > You forgot a few things here: > > First it doesn't even start because they don't have a config file. OK, > they copy one from somewhere, it doesn't work because the drives are > wrong. Then they don't have the proper registry (winedefault.reg? > what's that?) I was going to reply yesterday on this issue. I help a fair amount of people on irc that have config problems and there are a few things we should probably do to fix this. 1. Check the wine config on startup. If the config is missing or incorrect then launch a gui config app to fix things. It would be best if this tool had two user options, one for an Automatic setup and another for an Expert setup. We do a good job with wineinstall so I don't have much doubt that we could automate the config and satisfy 80%+ of users. 2. Make it easier for users to modify their configs via a gui tool. 3. Straighten out how packages(RPM, deb, etc) setup wine's config. I'm not even sure how this is done right now and LOTS of people come asking for help saying they have installed an RPM version of wine but don't know how to configure it. This might be completely solved by #1. Chris

1 0

Re: Re: So lets say we do it
by chrismorgan＠rcn.com 31 Oct '02

31 Oct '02

> > 2. People will look for the typical left-side menu: > > Home > > About > > Status > > Development > > Download > > Screenshots > > > > *BZZT* We don't have any. 5% will drop off here. > > Sorry to say that, but in this mail, *you* were talking *some* crap IMHO > ;-) > > We *do* have screenshots. The About page has some pretty nice screenshot. > OK, it's a minimalist approach, granted, but it does show IE etc. > I'd also like to second the opinion that we should have a dedicated "Screenshot" entry right off of the main page. I do the same stuff that Dimitrie does, go to a project, look at some text briefly and then immediately want to see what the app looks like when it is working. So maybe leave the screenshot link off of the "About" page but also put a link on the main page. Chris

1 0

RPC test code?
by Greg Turner 31 Oct '02

31 Oct '02

OK, wine made it's first successful RPC's on my box today (yay!) Now, it's time to do a smidgen of housekeeping, and whip up a test. This is a bit tricky, I have a few open questions, which I will enumerate: 1) It feels like cheating to use the same process as client /and/ server. OTOH, it will be a bit cleaner to do it as such... any thoughts on this? specifically, 1a) Will wedging what is basically a winelib app into my test directory create a problem in the configure/make system? Is there a clean way to make sure I invoke the right winelib .exe.so file (the one in my test directory)? 1b) Are all the process-control API's I will need for this in place? (in particular I should kill off the server in case of a failure... will this be a problem? I guess probably not, or else I'd see a lot more wine's hanging around in my process table.) 1c) If the test fails in the winelib thingy, I have to propagate this back to the test; but relying on RPC for this (aside from being unimplemented ATM) is a catch-22, since error propagation might be broken (hence the need for a test)... I guess I can think of creative solutions to this like putting stupid temp files somewhere. Any better ideas? 1d) Anyone know of a problem with this I haven't thought of yet? 2) Whether I use threads or processes, I need some coordination to happen; I am very concerned about race conditions. I want my tests to run under the most absurd and grueling conditions, with NO race conditions. But I can't wrap my mind around how to avoid them ATM. For example: 2a) Should the rpc.c "real" test be the client or the server? I can imagine races either way. Let's say rpc.c is the client. This isn't so bad at a glance; I invoke the server thread/process, and poll RPC from time to time until it goes active (how I do this is another issue, but I'll think of something). Now I do my magic, and request a shutdown via RPC to the server... but, in two cases there is technically a race: first, while I'm invoking the server, I have to wait for it to start as discussed; second, after I send the Shutdown RPC to the server, I have to actually wait for the process/thread to terminate. In both cases, how long is long enough? What if the tests are running on some absurdly bogged down machine that's simultaneously compiling a matrix of 10,000 different wine's, for example? On the other hand, if I use some really liberal timeout like 30 minutes, then in a failure condition, my test would appear to hang, this isn't so great either. If rpc.c is the server, similar problems exist. 2b-?) uh, I guess I squeezed all of these questions into 2a. 3) MIDL? I still haven't figured out the legal ramifications of using midl-generated code. I'd rather not spend a month working on widl before generating a test... so do I need to code my stubs by hand? Even if I do, they're gonna come out looking more-or-less just like MIDL code... maybe I need to figure out the licensing restrictions on MIDL-generated code myself, but does anyone know offhand, I didn't see any obvious discussion of this on microsoft.com or in the platform sdk. ugh. thanks for taking the time to read this long-winded post. Any responses, assistance, flames, etc. are appreciated. -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

4 6

Re: SetWindowHookEx
by steve.lustbader＠philips.com 31 Oct '02

31 Oct '02

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

1 0

Adobe SVG viewer mouse tracing
by Mike Hearn 31 Oct '02

31 Oct '02

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

1 0

winapi_check question...
by Greg Turner 31 Oct '02

31 Oct '02

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

1 0

Re: miscemu/wine gets into the way in map_image
by Uwe Bonnes 31 Oct '02

31 Oct '02

>>>>> "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 ----------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel