September 2002 - Wine-Devel

InitThreadInput16

by Dimitrie O. Paun

OK, This DLL stuff is a bit confusing. In dlls/user/user32.spec we have 409 pascal16 InitThreadInput(word word) InitThreadInput16 so the exported name is InitThreadInput, right? Then how come in ./dlls/x11drv/desktop.c we call it like so: win->hmemTaskQ = InitThreadInput16( 0, 0 ); Shouldn't this yield an error? -- Dimi.

Sept. 27, 2002

WM_STYLECHANG{ING/ED}

by Dimitrie O. Paun

Hi folks, In my relentless quest for speed :), I discovered that we don't send a WM_STYLECHANGED message when we flip the WS_VISIBLE, or WS_VSCROLL, and maybe a bunch of others, I haven't checked. Shouldn't we send such a message, when we touch *any* WS_[EX_]* bits? -- Dimi.

Sept. 27, 2002

Re: How to tell winemaker and winebuild what I want to tell it

by Bill Medland

----- Original Message ----- From: "Alexandre Julliard" <julliard(a)winehq.com> To: "Bill Medland" <billmedland(a)look.ca> Cc: "wine-devel" <wine-devel(a)winehq.org> Sent: Thursday, September 26, 2002 6:20 PM Subject: Re: How to tell winemaker and winebuild what I want to tell it > "Bill Medland" <billmedland(a)look.ca> writes: > > > My winelib wrapper wants to call MultiByteToWideChar and DOSFS_GetFullName. > > As far as I am aware they are available from ntdll.dll (ntdll.dll.so) > > MultiByteToWideChar is exported from kernel32, not ntdll. > DOSFS_GetFullName is not exported and you can't use it from a winelib > app; you may be able to use wine_get_unix_file_name() instead. So I guess I am doing something dangerous in adding -lntdll.dll to the link (which does the trick very nicely). > > -- > Alexandre Julliard > julliard(a)winehq.com >

Sept. 27, 2002

Re: winemaker: wineapploader changes

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > However, looking for wine in bindir does not make sense: > * I don't install the Winelib applications I compile using Winelib. So > * I leave prefix to the default value: /usr/local > > * I always build my application using a Wine source tree. This means > * that there is strictly nothing of interest in /usr/local/bin. > > * configure.ac goes to great length to figure out where wrc, winebuild > * and *wine* are located. So at the end of configure.ac we know very > * well what the path to wine is. It's '$WINE'. There seems to be some confusion here. We have two very different problems: one is how to make things work on the build machine, and one is how to make things work when installed. configure can only detect where things are on the build machine, but in general that's not the right paths to put in the installed binaries. The installed stuff goes in $(prefix), and I think it makes sense to expect that Wine itself will be installed there too. Note that in Wine wineapploader is only used for make install; running from inside the tree is a different problem and is done by a different script. I think winemaker should do the same thing. -- Alexandre Julliard julliard(a)winehq.com

Sept. 27, 2002

Re: winedbg is not finding debug symbols, anybody know what I'm doing wrong?

by Bobby Bingham

I know everytime I run configure, I do CFLAGS="-gstabs" ./configure I don't know if there's a nice way to get configure to do this automatically? is it not portable? probably to best solution is to implement Dwarf II in winedbg ... Bobby Bingham On Thu, Sep 26, 2002 at 04:20:23PM -0500, Greg Turner wrote: > Eric POUECH wrote... > > > but I assume you double checked that more likely, aren't you using gcc 3.2 > > by any chance ? if so, you need to force ELF symbol emission, not > > Dwarf II which became default in 3.2 > > Bingo. Guilty as charged. Thank you SO MUCH for this, I should have figured gcc3.2 was the culprit, > that thing is feisty! I'll take a look at whether I can find a generic solution to this and post a patch. > > Now that you mention it, I think gcc3.2 has some other interesting warnings, something about > some alignment thingys not supported anymore (probably I just change "-m$X" to "-f$X" to fix), > I'll see about those too, could well be important... >

Sept. 27, 2002

Re: How to tell winemaker and winebuild what I want to tell it

by Alexandre Julliard

"Bill Medland" <billmedland(a)look.ca> writes: > My winelib wrapper wants to call MultiByteToWideChar and DOSFS_GetFullName. > As far as I am aware they are available from ntdll.dll (ntdll.dll.so) MultiByteToWideChar is exported from kernel32, not ntdll. DOSFS_GetFullName is not exported and you can't use it from a winelib app; you may be able to use wine_get_unix_file_name() instead. -- Alexandre Julliard julliard(a)winehq.com

Sept. 27, 2002

Re: Unimplemented function... Cause of exception?

by John Coppens

On Thu, 26 Sep 2002 06:20:33 -0700 (PDT) Andriy Palamarchuk <apa3a(a)yahoo.com> wrote: > Hi Andriy, > > Run "bt" (backtrace) command in the debugger window > and report what you found. Here's the debugmsg output near the exception signalled (below is the gdb output and bt): Please tell me if this helps, and what else I can do. Thanks John 080724a8:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=00427544 080724a8:Call ntdll.RtlLeaveCriticalSection(00499770) ret=00427553 080724a8:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=00427553 086ef800: get_console_output_info( handle=12 ) 086ef800: get_console_output_info() = ACCESS_DENIED { cursor_size=0, cursor_visi ble=0, cursor_x=0, cursor_y=0, width=0, height=0, attr=0, win_left=0, win_top=0, win_right=0, win_bottom=0, max_width=0, max_height=0 } 086ef800: get_console_output_info( handle=12 ) 086ef800: get_console_output_info() = ACCESS_DENIED { cursor_size=0, cursor_visi ble=0, cursor_x=0, cursor_y=0, width=0, height=0, attr=0, win_left=0, win_top=0, win_right=0, win_bottom=0, max_width=0, max_height=0 } 086ef800:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40c7b5d1 086ef800:trace:seh:EXC_RtlRaiseException info[0]=00000000 -------------------- This is the exception signalled: 086ef800:trace:seh:EXC_RtlRaiseException info[1]=abe7d58e -------------------- 086ef800: queue_exception_event( first=1, record={context={flags=00000000,eax=ab e7d58e,ebx=40c8275c,ecx=c0000022,edx=000b8000,esi=40db68e2,edi=40db68e3,ebp=40db 68b4,eip=40c7b5d1,esp=40db6888,eflags=00010202,cs=0023,ds=002b,es=002b,fs=0267,g s=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=0000 0000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000 000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,0000 0000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,000 00000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x40c7b5d1,p arams={0,abe7d58e}} ) 086ef800: queue_exception_event() = 0 { handle=0 } 086ef800:trace:seh:EXC_CallHandler calling handler at 0x400d9770 code=c0000005 f lags=0 086ef800:trace:seh:EXC_CallHandler handler returned 2 086ef800:trace:seh:EXC_CallHandler calling handler at 0x400d9e88 code=c0000005 f lags=10 086ef800:trace:seh:EXC_CallHandler handler returned 1 086ef800:trace:seh:EXC_CallHandler calling handler at 0x400d9e88 code=c0000005 f lags=0 086ef800: queue_exception_event( first=0, record={context={flags=00000000,eax=ab e7d58e,ebx=40c8275c,ecx=c0000022,edx=000b8000,esi=40db68e2,edi=40db68e3,ebp=40db 68b4,eip=40c7b5d1,esp=40db6888,eflags=00010202,cs=0023,ds=002b,es=002b,fs=0267,g s=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=0000 0000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000 000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,0000 0000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,000 00000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x40c7b5d1,p arams={0,abe7d58e}} ) ------------------gdb output when running: Warning: unprotecting the first 64KB of memory to allow real-mode calls. NULL pointer accesses will no longer be caught. fixme:int:DOSVM_Int10Handler Get Font Information - Not Supported (BH: 0x0) wine: Unhandled exception, starting debugger... err:win:WIN_FindWndPtr window 10021 belongs to other process Program received signal SIGINT, Interrupt. 0x4024e2db in __sigprocmask (how=2, set=0x40595284, oset=0x0) at ../sysdeps/unix/sysv/linux/sigprocmask.c:58 58 ../sysdeps/unix/sysv/linux/sigprocmask.c: No such file or directory. in ../sysdeps/unix/sysv/linux/sigprocmask.c -------------Backtrace #0 0x4024e2db in __sigprocmask (how=2, set=0x40595284, oset=0x0) at ../sysdeps/unix/sysv/linux/sigprocmask.c:58 #1 0x400cbc7f in wine_server_call (req_ptr=0x40595320) at ../../scheduler/client.c:225 #2 0x400a1cdb in ATOM_FindAtomA (str=0x4717e8 "tty", local=0) at ../../include/wine/server.h:82 #3 0x400a1d76 in GlobalFindAtomA (str=0x4717e8 "tty") at ../../memory/atom.c:588 #4 0x406f986c in FindWindowExA (parent=0, child=0, className=0x4717e8 "tty", title=0x0) at ../../windows/win.c:1626 #5 0x406f9827 in FindWindowA (className=0x4717e8 "tty", title=0x0) at ../../windows/win.c:1605 #6 0x0041dfec in ?? () #7 0x38680805 in ?? () Cannot access memory at address 0xc43c25ff (gdb)

Sept. 27, 2002

Re: Using winbind with Wine

by Andrew Bartlett

Tim Potter wrote: > > On Thu, Sep 26, 2002 at 01:47:38PM +0200, Martin Wilck wrote: > > > To initiate this process we'd "only" need a standardized protocol for > > the socket communication. Andrew said that doesn't exist and won't with > > regard to winbind. I'd like to focus the discussion in this direction. > > > > - is the winbind team willing to standardize the protocol, or at least > > ensure backward compatibility in future versions? > > There is a LGPL client library (well library is probably doing it more > justice than it deserves) called wb_client.c which is used in the > NSS modules that talk to winbindd. I would think that would be a > preferable way of talking to winbindd rather then rewriting code > to talk the winbindd protocol. The problem is that we don't ship it as a shared lib, and it still expects the client program to fill in the winbind struct. This is the problem, becouse that struct changes shape regularly. > > - is the winbind team willing to add more RPC calls to the interface? > > Not unless they are related to authentication or user/group enumeration. Agreed. (However I am thinking of moving nss_wins in there soon too, to match the IRIX code). Andrew Bartlett -- Andrew Bartlett abartlet(a)pcug.org.au Manager, Authentication Subsystems, Samba Team abartlet(a)samba.org Student Network Administrator, Hawker College abartlet(a)hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net

Sept. 27, 2002

Re: winemaker (WAS Where is the specfile documented nowadays?)

by Francois Gouget

On 26 Sep 2002, Martin Wilck wrote: > Am Mit, 2002-09-25 um 20.57 schrieb Bill Medland: [...] > > But winemaker seems to be setting things up so that it will create > > /usr/local/lib/libshfile.dll.so. > > This is because winemaker was designed to create winelib DLL > replacements. Actually the reason why winemaker was creating libshfile.dll.so files is that this once was the right thing to do (even further in the past libraries did not even have the dll extension). But now the names to be used are: for executables: myhello.exe.so for libraries: mylib.dll.so The patch I sent yesterday should make winemaker use the new scheme. The reason why the lib prefix has been dropped is because one is not supposed to link against Winelib dlls in the Unix sense. Instead you must import them using the '-l' option of winebuild. Dropping the 'lib' prefix makes this more obvious. ` -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

Sept. 27, 2002

Re: dlls/xxx/xxx_main.c

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Can we please rename all these > dlls/xxx/xxx_main.c > to > dlls/xxx/xxx.c > > It should be possible now, right? Should I send a patch in? I don't see much reason for that. The xxx_main names are just fine IMO. -- Alexandre Julliard julliard(a)winehq.com

Sept. 27, 2002