October 2002 - Wine-Devel - list.winehq.org

Re: rpc_H_PL9

by Michael Stefaniuc

On Thu, Oct 31, 2002 at 10:55:10AM -0600, Greg Turner wrote: > On Thursday 31 October 2002 09:05 am, Michael Stefaniuc wrote: > > -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 > > Before I change it back on your advice, are you /sure/ about this? > > o rpcrt4 compiles STRICT, so how broken can the conflation of > HANDLE and void* be? (HWND is DECLARE_HANDLE()'ed so I could see > your point there.) HANDLE is a void* therefor "compatible" to any other pointer, that's why you don't get a warning. > o from the Microsoft Platform SDK headers (October '02): > > ./rpcdcep.h-728-RPCRTAPI > ./rpcdcep.h-729-unsigned int > ./rpcdcep.h-730-RPC_ENTRY > ./rpcdcep.h:731:I_RpcWindowProc( > ./rpcdcep.h-732- IN void * hWnd, > ./rpcdcep.h-733- IN unsigned int Message, > ./rpcdcep.h-734- IN unsigned int wParam, > ./rpcdcep.h-735- IN unsigned long lParam > ./rpcdcep.h-736- ) ; > > so, technically, isn't void* a /better/ choice? *Sigh* a HWND should be HWND but m$ seems to have decided to do it in an other way. I would say resend the patch but please change the Changelog. 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

Oct. 31, 2002

Re: winapi_check question...

by Greg Turner

On Thursday 31 October 2002 09:20 am, Patrik Stridvall wrote: > Greg wrote: > > 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. OK. You promise it won't screw up the actual documentation bot? > > > 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. [snip] > Same as above. [snip] > Same as above. I'll take a look and see if I trust myself to mess with this. > > how shall I deal with these? > > Fix them as above or do as everybody elses do wait for me to fix it. > :-) heh. Well, maybe I can set an example for those deadbeats :) -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Uwe Bonnes

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

Oct. 31, 2002

Re: rpc_H_PL9

by Greg Turner

On Thursday 31 October 2002 09:05 am, Michael Stefaniuc wrote: > -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 Before I change it back on your advice, are you /sure/ about this? o rpcrt4 compiles STRICT, so how broken can the conflation of HANDLE and void* be? (HWND is DECLARE_HANDLE()'ed so I could see your point there.) o from the Microsoft Platform SDK headers (October '02): ./rpcdcep.h-728-RPCRTAPI ./rpcdcep.h-729-unsigned int ./rpcdcep.h-730-RPC_ENTRY ./rpcdcep.h:731:I_RpcWindowProc( ./rpcdcep.h-732- IN void * hWnd, ./rpcdcep.h-733- IN unsigned int Message, ./rpcdcep.h-734- IN unsigned int wParam, ./rpcdcep.h-735- IN unsigned long lParam ./rpcdcep.h-736- ) ; so, technically, isn't void* a /better/ choice? Let me know what you think, -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

Oct. 31, 2002

Re: Re: So lets say we do it

by chrismorgan＠rcn.com

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

Oct. 31, 2002

Re: So lets say we do it

by Carlos Lozano

El jue, 31 de oct de 2002, a las 02:11, Dimitrie O. Paun escribio: > That is, > > Lets assume for the sake of argument that Alexandre likes my > 0.8 idea so much, that he releases Wine 0.8 with much fanfare > next Monday (so we have a good audience), 10th Anniversary (??-??-2003)? sounds to a good date. Regards, Carlos. -- ___ _ \ | / Infraestructuras | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.epsxe.com

Oct. 31, 2002

Re: SIGSEGV in IDirectDrawImpl_EnumDisplayModes

by Matthew Bloch

On Thursday 31 October 2002 14:32, Lionel Ulmer wrote: > > Apologies for needing some more hand-holding: from Alexander's advice I > > now have the game linking and beginning to execute. It now gets stuck > > while executing this piece of C++: > > Hmm, according to the backtrace, it is rather crashing when executing > 'User_DirectDraw_EnumDisplayModes' (ie something like > mp_directDraw->EnumDisplayModes(...)) in the > tDirectDrawScreen::setUpWindowedSurfaces method. Sorry, that was the method I posted, I happened to paste the wrong function name; this is the entire function with line 852 marked: ------------------------------------------------------------------------------ void tDirectDrawScreen::setUpWindowedSurfaces() { DDSURFACEDESC ddsd; memset(&ddsd,0,sizeof(DDSURFACEDESC)); ddsd.dwSize = sizeof(DDSURFACEDESC); //Set up the caps for the primary ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; //Finally create the primary surface (line 852) HRESULT hr = mp_directDraw->CreateSurface(&ddsd,&mp_primarySurface,NULL); handleErrors(hr,"Failed to create windowed primary surface."); //Calculate and preserve current screen size setScreenSize(); //Calculate and store current screen position setScreenPosition(); //Create a "backbuffer" surface exactly the same size as primary createBackBuffer(); } ------------------------------------------------------------------------------ the ddraw trace looks like this: ------------------------------------------------------------------------------ trace:ddraw:initialize enabling DirectDraw HAL trace:ddraw:DDRAW_Create ((null),0x808c718,(nil)) trace:ddraw:DDRAW_FindDriver ((null)) trace:ddraw:HAL_DirectDraw_Create trace:ddraw:HAL_DirectDraw_Construct (0x403a9be0) trace:ddraw:User_DirectDraw_Construct (0x403a9be0,0) trace:ddraw:Main_DirectDraw_QueryInterface (0x403a9be0)->({6c14db80-a733-11ce-a521-0020af0be560},0x808c718) trace:ddraw:Main_DirectDraw_AddRef (0x403a9be0)->() incrementing from 1. trace:ddraw:Main_DirectDraw_Release (0x403a9be0)->() decrementing from 2. fixme:ddraw:Main_DirectDraw_WaitForVerticalBlank (0x403a9be0)->(flags=0x00010021,handle=0x8) trace:ddraw:User_DirectDraw_EnumDisplayModes (0x403a9be0)->(0x40c92c4c,0x808c720,0x40c92be8,0x40f55dfc) trace:ddraw:User_DirectDraw_EnumDisplayModes - mode: 512x384 trace:ddraw:User_DirectDraw_EnumDisplayModes - 8 bpp, R=00000000 G=00000000 B=00000000 (bang!) ------------------------------------------------------------------------------ and the backtrace from the exception looks like this: ------------------------------------------------------------------------------ #0 0x40c92c4c in ?? () #1 0x40f56f5f in User_DirectDraw_EnumDisplayModes (iface=0x403a9be0, dwFlags=1086925740, pDDSD=0x808c720, context=0x40c92be8, callback=0x40f55dfc <EnumDisplayModesCallbackThunk>) at ddraw/user.c:373 #2 0x40f55e81 in IDirectDrawImpl_EnumDisplayModes (This=0x40c92be8, dwFlags=1086925900, pDDSD=0x808c720, context=0x40c92a94, cb=0x40c92a94) at ddraw/thunks.c:348 #3 0x4080f9b2 in tDirectDrawScreen::setUpWindowedSurfaces (this=0x808c710) at Source/tDirectDrawScreen.cpp:852 #4 0x4080cf1f in tDirectDrawScreen::initialise (this=0x808c710, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:88 #5 0x4080caac in tDirectDrawScreen::tDirectDrawScreen (this=0x808c710, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:55 #6 0x4082d76f in InitApp (hInst=0x40620000, nCmdShow=1) at Source/Main.cpp:289 #7 0x4082d8fc in WinMain (hInst=0x40620000, hPrevInst=0x0, lpCmdLine=0x403710dd "", nCmdShow=1) at Source/Main.cpp:322 #8 0x4062509c in __wine_exe_main () from /home/mattbee/Work/Nemesis/LSNClient.exe #9 0x400b3799 in start_process () at ../../scheduler/process.c:564 #10 0x400b76c9 in call_on_thread_stack (func=0x400b3558) at ../../scheduler/sysdeps.c:112 ------------------------------------------------------------------------------ > From what I see, I wonder if the enum procedure you give to DDraw has the > right protoype (ie is it a STDCALL or a CDECL function) ? I'm not supplying any procedure to DDraw; could it be that some linking problem has caused EnumDisplayModes to be called instead of CreateSurface? That's what the backtrace implies. I've tried a rebuild of the relevant source files just in case but the same thing happens. If it helps, this is the function that creates the mp_directDraw variable, called before setUpWindowedSurfaces: ------------------------------------------------------------------------------ void tDirectDrawScreen::createDirectDrawObject() { HRESULT hr = DirectDrawCreate(0,&mp_directDraw,NULL); handleErrors(hr,"Failed to create Direct Draw Object."); } ------------------------------------------------------------------------------ cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

Oct. 31, 2002

Re: SetWindowHookEx

by Alexandre Julliard

Shachar Shemesh <wine-devel(a)sun.consumer.org.il> writes: > So you mean to say that my windows X-Eyes implementation won't work on > WINE????? Damn. > > Anyone knows of any Unix port of that program? > > Shachar > > No, wait. I'm using a mouse hook. Maybe it'll work after all. At this point probably not, but if you could send me that app I'd be interested to play with it. -- Alexandre Julliard julliard(a)winehq.com

Oct. 31, 2002

Re: GetComputerName() question

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> writes: > I'd propose: If the registry contains an explicit ComputerName entry, > use it as Netbios name; otherwise, use the Unix hostname. This would > affect only the users that enter a Netbios name in their registry, and > thus not those with changing host names that you're worried about. This works for GetComputerName(), but not for apps that look directly in the registry. This is why we need to put something in there. I'm still not sure what your problem is, apart from it being an FQDN. Why wouldn't it work to set the registry from the hostname on startup? Do you really need a NetBIOS name different from the hostname? -- Alexandre Julliard julliard(a)winehq.com

Oct. 31, 2002

Re: So lets say we do it

by Alexandre Julliard

"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?) Then they finally manage to run the installer but it puts stuff in RunOnce that never gets run so the app doesn't work. Then they finally make the app run but can't print anything. And when they ask for help they get told to fight the FAQ-O-Matic crap to maybe finally find an answer telling them they are an idiot. So no, I'm not going to make a general public release just yet... -- Alexandre Julliard julliard(a)winehq.com

Oct. 31, 2002