April 2003 - Wine-devel - list.winehq.org

hi wine team
by Yu Neil 09 Apr '03

09 Apr '03

hello: did the wine team consider construct the win32 support (wine) within a micro-kernel architecture, just like the microsoft`s interix ? Neil Yu _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

2 1

Re: Wine start.exe
by Dan Kegel 08 Apr '03

08 Apr '03

Vilppa Salt wrote: > I posted earlier to the wine-devel about the launching files with params. Now my Wine should be ok. > > In the start.exe the /wait switch doesn't work. If you try to run from wcmd somebatfile.bat file which includes following lines: > > start /wait some-exefile.exe > del some-exefile.exe > > and you have some-exefile.exe in the same directory it fails. This is because the file gets deleted, the wait switch doesn't work. Maybe you could fix it? I would but my c-skills aren't that good. Thanks for the bug report. I'll try to have a look tonight. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Re: Resend: Implements languagegroups functions
by Alexandre Julliard 08 Apr '03

08 Apr '03

Maxime Bellengé <maxime.bellenge(a)laposte.net> writes: > This patch implements the languagegroups functions. > As I have access to a French and English windows 2k+, I set > the resources accordingly for the kernel32 resources. However, as > I don't know the resources for other languages, I have put English > resources in the other nls files. People will have to change them to the > correct values. You should really implement the A functions by calling the W ones instead of duplicating the code. Also I'm not sure there's much point in looking up the info in the registry, we don't support installing locales dynamically anyway so we might as well have a static table in the code. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Re: Re: Stuck on threading
by Pouech Eric DMI AEI CAEN 08 Apr '03

08 Apr '03

> See section 2.6.4 in the wine hackers guide, the command reference: > > bt print calling stack of current thread > bt N print calling stack of thread of ID N (note: this > doesn't change the position of the current frame as > manipulated by the up & dn commands) > up goes up one frame in current thread's stack > up N goes up N frames in current thread's stack it doesn't mean (at least it doesn't implement it) that current thread is changed bt N just 1/ stops thread of ID N (if it isn't stopped already) 2/ prints its backtrace but current thread doesn't change in the process (ie, the cont/step... commands still apply to current thread) Mike, BTW, I don't know why, but my ISP seems to have blacklisted the qinetic domain, so I can't reply to you directly (always thru wine-devel) A+

2 1

Re: Re: Stuck on threading
by Pouech Eric DMI AEI CAEN 08 Apr '03

08 Apr '03

> tid as a parameter for instance, and I can't see any way to switch the > current thread, despite the docs mentioning such a concept. which docs... this isn't implemented in winedbg another solution for this would be using gdb thru winedbg (run winedbg -- --gdb) you'll get gdb as a front end, but communicating thru winedbg to the wineserver using gdb commands, you might be able to control a bit more the threads A+

2 1

Re: IP Multicast
by Mike Hearn 08 Apr '03

08 Apr '03

Anything wrong with this one? FYI it uses a different structure to the original (rejected) patch from Marcus. thanks -mike On Tue, 2003-04-01 at 13:54, Mike Hearn wrote: > Hi, > > This patch adds support for IP multicast sockets to winsock. I stole > liberally from a patch from the summer of 2001 from Marcus, so thanks to > him for that: > > http://www.winehq.com/hypermail/wine-patches/2001/07/0009.html > > ChangeLog: > - Map winsock sockopts to the POSIX equivalents for IP multicast > - Remap winsock1 constant values to winsock2 using a forwarder function > - Change a FIXME to a TRACE, it appeared to be simply reporting progress > > thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

3 2

Stuck on threading
by Mike Hearn 08 Apr '03

08 Apr '03

Hi, I'm a bit stuck. I have a DLL that does a FindWindow on DLL attach, and as part of that it does a GetWindowText which tries to send a message to another thread, using send_inter_thread_message. Other threads then attempt to load a DLL and the loader section prompty deadlocks. In gdb, if I attach at this point I can see a nice backtrace of the thread waiting for the reply to its WM_GETTEXT message, along with the thread ID. I'd quite like to see what the thread it sent the message to is doing, but for some reason in gdb "info threads" doesn't do anything and "thread 18" says, thread ID not known, despite it clearly being there in the backtrace: #5 0x40abd0cf in send_inter_thread_message (dest_tid=18, info=0x4072187c, res_ptr=0x40721874) at message.c:1719 So, I'm wondering if this is due to the funny games Wine plays with threads, I'm on a standard glibc 2.2 system by the way. For some reason I can't use winedbg because it stops with a load of exceptions inside the DLL that seem to be red herrings. Is there any way of switching to a wine thread using gdb to get a backtrace? Is there a sneakier approach I can use to find out why thread 18 has apparently deadlocked? There is probably a race condition here - this program will start some times but not others :( Has anybody got any tips on how to debug this sort of thing? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

3 2

Building WINE with other headers
by Steven Edwards 08 Apr '03

08 Apr '03

Hello, I know we have discussed this before and Dimi put it on the Janitorial site but I dont think we ever came a conclusion on it and I could not find a easy fix. Last time I tried to change the include path manualy I ran in to lots of problems. I would like to attempt to build parts of WINE with only the mingw headers and exclude the winehq headers so I can: 1. Find out where the mingw w32api package is broken. 2. Impove the Wine headers if they are wrong. 3. Not use the winehq headers for the ReactOS (We wont try this untill 1 and 2 are in sync) BTW thanks for the winsock.h patch, it is nice to not have to have a simple command line now. Sorry for the head-ache <g> Steven

2 1

Visual FoxPro 8 / Wine20030318 crash
by Paul McNett 08 Apr '03

08 Apr '03

I crash when building an EXE in the new version of Visual Foxpro. Any ideas? "windows" = "nt351", all dlls built-in. Here's the output leading up to the crash: fixme:hook:NotifyWinEvent (32769,0x50032,1,0)-stub! fixme:pidl:SHLogILFromFSIL (pidl=0x4032b090) fixme:dc:LockWindowUpdate (0x50033), partial stub! fixme:shell:ISVBgCm_fnGetCommandString unknown command string fixme:shell:ISVBgCm_fnGetCommandString unknown command string fixme:shell:ISVBgCm_fnGetCommandString unknown command string fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:shell:ReadCabinetState 0x4071e2e0 0x000c stub fixme:hook:NotifyWinEvent (32773,0x30031,7,1)-stub! fixme:hook:NotifyWinEvent (32768,0x90032,1,0)-stub! fixme:hook:NotifyWinEvent (32769,0x90032,256,0)-stub! fixme:hook:NotifyWinEvent (32769,0x90032,1,0)-stub! fixme:ole:DispCallFunc Do not know how to handle pvargResult 0x4071e5cc. Expect crash ... fixme:ole:DispCallFunc Method returned 0 err:ole:TLB_ReadTypeLib Loading of typelib L"E:\\src\\vfp\\sbs\\sbs.exe" failed with error 0 fixme:seh:EXC_RtlRaiseException call to unimplemented function kernel32.dll.BeginUpdateResourceA fixme:process:CreateProcessA (E:\prg\vfp8\dw15.exe,...): NORMAL_PRIORITY_CLASS ignored fixme:process:CreateProcessA (E:\prg\vfp8\dw15.exe,...): CREATE_DEFAULT_ERROR_MODE ignored fixme:win32:PE_CreateModule Security directory ignored fixme:ntdll:NtQuerySystemInformation (0x00000005,0x4028d858,0x00010000,(nil)) stub fixme:win32:PE_CreateModule Security directory ignored fixme:advapi:RegisterEventSourceW ((null),L"Microsoft Visual FoxPro"): stub fixme:advapi:ReportEventA stub fixme:advapi:DeregisterEventSource (0x1): stub fixme:wininet:InternetGetConnectedState always returning LAN connection. -- Paul McNett Liberal Earthling

4 5

NTPL & pthreads locks
by Dimitrie O. Paun 08 Apr '03

08 Apr '03

Alexandre, If I understand correctly, we currently implement the pthreads locks on top on Wine locks because the standard pthreads locks are not powerful enough to support all Win32 locking primitives. Integrating these locks is necessary for integrating Wine with the pthreads Universe. Now, given the new NTPL work, would it be possible/feasible/desirable to implement the Win32 locks on top of NTPL primitives (such as futexes)? At the very least it makes the setup a lot more intuitive, and less likely to break. If we are to follow this path, there are portability problems. But do we support this sort of libc integration of Solaris and *BSD? And it seems to me that it shouldn't be too hard for these systems to provide something that would allow us to implement all Win32 locking primitives, and the end result would be a lot less brittle. -- Dimi.

3 3