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

Re: RtlEnterCriticalSection
by Marcus Meissner Oct. 18, 2001

Oct. 18, 2001

On Thu, Oct 18, 2001 at 12:22:10AM +0200, Michael Marxmeier wrote: > After encountering timeout messages from > RtlEnterCriticalSection i had a look at it. > > Since interlocked_inc() should never return zero > the following patch is likely necessary. > I was unable to test this as now wine crashes with > a segmentation fault (which also terminates gdb). That is a sign that your patch is faulty. Any number of threads can increase this counter, it only succeeds if the count is really 0 before the call. (0 meaning the critical section is completely unlocked). If it is any other number, it is either a recursive enter or a different thread. Ciao, Marcus > Michael > > --- critsection.c.orig Wed Oct 17 23:24:13 2001 > +++ critsection.c Thu Oct 18 00:04:32 2001 > @@ -233,7 +233,7 @@ > */ > NTSTATUS WINAPI RtlEnterCriticalSection( RTL_CRITICAL_SECTION *crit ) > { > - if (interlocked_inc( &crit->LockCount )) > + if (interlocked_inc( &crit->LockCount ) != 1) > { > if (crit->OwningThread == GetCurrentThreadId()) > { > >

2 2

Re: SystemParametersInfo / GetSystemMetrics
by Alexandre Julliard Oct. 18, 2001

Oct. 18, 2001

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > One more question while we are on it. > We are going to check whether X settings correspond to > our settings only on initialization and reload > requests and are not going to do the check in "Get" > logic, right? Yes; in fact I'd argue that we shouldn't care at all about X settings in most cases, except maybe to get initial values. For instance if the app remaps mouse buttons, or changes mouse threshold or whatever, you don't want to apply this to the whole X session IMO. If users want to reconfigure X behavior, they have to use the X configuration programs. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: MDI FindWndPtr fix
by Alexandre Julliard Oct. 18, 2001

Oct. 18, 2001

Mike McCormack <mike_mccormack(a)start.com.au> writes: > i think i fixed that one too in the patch... there's probably similar > problems in other files, since WIN_GetPtr and WIN_FindWndPtr seem do > basically the same thing, but one reference counts and one doesn't. i > think we're going to see WIN_GetPtr disappear eventually... maybe. No, it is WIN_FindWndPtr and the whole reference counting that is going to disappear. The reference counting is needed only when we give control to the application while holding the window lock, and this is something we should never do. Another difference is that WIN_GetPtr returns a special value for windows belonging to another process, to force us to think about this case and handle it properly. -- Alexandre Julliard julliard(a)winehq.com

1 0

Problem with kernel32 on SPARC solaris 8.0
by Mrugan Oct. 18, 2001

Oct. 18, 2001

I am trying to link kernel32 and ntdll libraries to my source code on SPARC Solaris 8.0. My executable does not exit. It gets stuck after spawning 4 threads. The gdb trace is as below: Starting program: /export/home/mrugan/src/HACore/HaNuanceChannelComRCE/nuancetest.exe warning: Lowest section in /usr/lib/libintl.so.1 is .hash at 00000074 warning: Lowest section in /usr/lib/libw.so.1 is .hash at 00000074 [New LWP 1] [New LWP 2] [New LWP 3] [New LWP 4] ^C Program received signal SIGINT, Interrupt. 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 (gdb) where #0 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff192c08 in _lwp_cond_wait () from /usr/lib/libc.so.1 #2 0xfef8c2f0 in _lrw_wrlock () from /usr/lib/libthread.so.1 #3 0xff3bdacc in ?? () #4 0xff3c34f0 in ?? () #5 0xff3b29a0 in ?? () #6 0xff0863c8 in __DTOR_END__ () from /opt/wine/dlls/libkernel32.so #7 0xff02e140 in frame_dummy () from /opt/wine/dlls/libkernel32.so #8 0xff02cf80 in _init () from /opt/wine/dlls/libkernel32.so #9 0xff3bada0 in ?? () #10 0xff3baa18 in ?? () #11 0xff3c4da0 in ?? () #12 0xff3b2958 in ?? () (gdb) inf thr 8 Thread 3 0xfef8d948 in _reap_wait () from /usr/lib/libthread.so.1 7 Thread 2 (LWP 2) 0xff19ad50 in _signotifywait () from /usr/lib/libc.so.1 6 Thread 1 (LWP 1) 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 * 5 LWP 1 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 4 LWP 4 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 3 LWP 3 0xff1988f4 in door_restart () from /usr/lib/libc.so.1 2 LWP 2 0xff19ad50 in _signotifywait () from /usr/lib/libc.so.1 * 1 LWP 1 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 Note that I had to hit cntl-C to come out of thread message. I guess this is happening because kernel32 tries to use thread library. Is there any way I can make it use pthread or is there any other solution to this? Any help will be greatly appreciated Thanks Mrugan

1 1

RE: Q: Unimplemented control 256 for VxD device VNETBIOS
by Patrik Stridvall Oct. 18, 2001

Oct. 18, 2001

> > NETBIOS.VXD. I propose you run with --debugmsg > +relay,+snoop,+vxd and try > > to decipher what is going on before that failing VXD call. > In the easiest > > Done. Please find the messages in the attachement. I shrinked > the 7 MB > file to those lines around the error message. But because I'm a > Windows's internal newbie it'll take me some hours to understand the > messages. But anyhow I'll investigate the messages later but also any > help is very welcome. >From the attachment: < 0806a488:CALL netapi32.1: Netbios(<unknown, check return>) ret=1001de6e < 0806a488:CALL netbios.6: _Netbios(<unknown, check return>) ret=7f9c1026 [snip] < 0806a488:Call kernel32.CreateFileA(7f875000 "\\\\.\\VNETBIOS",c0000000,00000003,00000000,00000003,00000080,00000000) ret=7f8710a6 [snip] < 0806a488:Call kernel32.DeviceIoControl(00000070,00000100,405f193c,00000040,00000000,000000 00,00000000,00000000) ret=7f871b0d < fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS < 0806a488:Ret kernel32.DeviceIoControl() retval=00000000 ret=7f871b0d [snip] < 0806a488:RET netbios.6: _Netbios(405f193c) retval = 00000000 ret=7f9c1026 < 0806a488:RET netapi32.1: Netbios(405f193c) retval = 00000000 ret=1001de6e Good. It seems to work exactly the way I thought (or rather hoped) it would. Now we can presumably forget about the VxD and the undocumented NETBIOS DLL and concentrate on implementing the documented NETAPI32 DLL. It would be intresting to know what the content of NCB structure that Netbios takes as pointer to as argument. So the next step would be to make a Wine implementation of the NETAPI32.DLL with a stub with an appropriate TRACE to display to NCB structure. I don't think I have time do it is the next few days though. Can somebody else please do it? PS. On second thought perhaps we should make the NETAPI32.DLL just a forward to the NETBIOS.DLL. It seems from the trace above that the Netbios function in NETAPI32.DLL is the same function as _Netbios in NETAPI32.DLL and Netbios is the only function in NETAPI32 while NETBIOS have more functions eventhough they are AFAIK undocumented.

2 3

Q: Unimplemented control 256 for VxD device VNETBIOS
by Michael Riedel Oct. 18, 2001

Oct. 18, 2001

I am going to migrate the EDA software environment from Windows NT to Linux but I have still some software components requireing Windows. That's why I use Wine. I own and use some software packages licensed to a valid MAC address (flexlm MAC based license) and the corresponding NIC is present in the Linux system. Using wine-20010824 I get the following message: fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS I scanned the Web resources and studied the file 'win32/device.c' a little bit but I got no answers to my questions. Is there already a solution/implementation for this service? I am also ready to contribute (at least I hope I'm able to do so and it would be fun ;-) but I need some advice (docus, especially related to the VNETBIOS VxD and some general hints). I'm looking forward for any hints. Michael -- ---------------------------------------- mriedel(a)inova-semiconductors.de ----------------------------------------

3 3

Re: MDI FindWndPtr fix
by Mike McCormack Oct. 18, 2001

Oct. 18, 2001

Hey Uwe, i think i fixed that one too in the patch... there's probably similar problems in other files, since WIN_GetPtr and WIN_FindWndPtr seem do basically the same thing, but one reference counts and one doesn't. i think we're going to see WIN_GetPtr disappear eventually... maybe. Mike > Mike> This fixes a reference counting problem with MDI. (tested with > Mike> Koala term) > > Hallo, > > aren't there more problems of that kind, e.g. in windows/mdi.c > MDIClientWndProc_common in the WM_CREATE path? > > Bye ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: SystemParametersInfo / GetSystemMetrics
by Andriy Palamarchuk Oct. 18, 2001

Oct. 18, 2001

By mistake I sent the response to you directly, instead of the newsgroup. --- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > Do you mean we can keep GetSystemMetrics simple if > we don't use all > > these synchronizations? Use some hardcoded values, > maybe load from > > registry and that's it? > > You need the synchronizations, but this doesn't mean > sysmetrics have > to be more complex. All it means is that when > something changes in > registry or x11, the code that does the change has > to do a > SYSMETRICS_Set to update the sysmetrics. But the > sysmetrics themselves > don't need to know anything except how to get the > initial value. > > > I don't see big difference between > SystemParametersInfo and > > GetSystemMetrics data. Sometimes these are even > the same! Example - flag > > SHOWSOUNDS. It can be read by GetSystemMetrics and > read and set by > > SystemParametersInfo. > > Yes they are the same, that's why you can have the > registry update > code either in sysparams.c or in sysmetrics.c; and > since we want to > keep sysmetrics simple it has to be in sysparams.c. > > > The infrastructure I created is used to access and > update SHOWSOUNDS > > flag. Can you suggest how to implement it in other > way? > > The existing implementation is OK, what you need is > to add registry > update in sysparams.c upon SPI_SETSHOWSOUNDS, and > add a call to > SystemParametersInfo(SPI_GETSHOWSOUNDS) in > SYSMETRICS_Init. You do not > need to add any registry access in sysmetrics.c, > everything will be > done by SystemParametersInfo. Ok, I see. I'll change the code and resend the patch. One more question while we are on it. We are going to check whether X settings correspond to our settings only on initialization and reload requests and are not going to do the check in "Get" logic, right? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

RE: Q: Unimplemented control 256 for VxD device VNETBIOS
by Patrik Stridvall Oct. 18, 2001

Oct. 18, 2001

> Michael> I'm looking forward for any hints. > > These FLEX LMs are always a problem. > > I guess, the license isn't bind to a physical dongle on the parallel > port. So one can conclude that the software tries to read the > MAC. This > probably happens in a NETBIOS.DLL call which then probably calls the > NETBIOS.VXD. I propose you run with --debugmsg > +relay,+snoop,+vxd and try > to decipher what is going on before that failing VXD call. In > the easiest > approach, you can build a fake builtin NETBIOS DLL, with the > appropriate > function returning the MAC in the first approach hardcoded or > really reading > it with OS calls. > > If running with --debugmsg +snoop crashes, I have a hack that may help > there. I have also patches for an empty NETBIOS dll. Why haven't you submitted it? Did Alexandre reject it? Having empty version of a standard DLL is almost always useful. Of course Wine should be configured to use the native DLL in the first place but still. > However I guess that this probably isn't enough to make FLEX LM happy. It is worth trying as well. However NETBIOS.DLL is not documented like NETAPI32 AFAIK is so it is more likely that it calls NETAPI32. Also note the NETAPI32 imports the NETBIOS.DLL function _Netbios so it would be a little strange if the application called NETBIOS directly but you never know. :-) Oh, well. Only one way to find out. Please do as Uwe suggest and run wine with --debugmsg +relay,+snoop,+vxd and post the result.

2 1

RE: Unimplemented control 256 for VxD device VNETBIOS
by Patrik Stridvall Oct. 18, 2001

Oct. 18, 2001

> I am going to migrate the EDA software environment from Windows NT to > Linux but I have still some software components requireing Windows. > That's why I use Wine. I own and use some software packages > licensed to > a valid MAC address (flexlm MAC based license) and the > corresponding NIC > is present in the Linux system. > > Using wine-20010824 I get the following message: > > fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device > VNETBIOS Given what you said above I wouldn't be entirely suprised if control 256 of VNETBIOS return the MAC address. However... > I scanned the Web resources and studied the file 'win32/device.c' a > little bit but I got no answers to my questions. Is there already a > solution/implementation for this service? I am also ready to > contribute > (at least I hope I'm able to do so and it would be fun ;-) but I need > some advice (docus, especially related to the VNETBIOS VxD and some > general hints). ... documentation for VxD:s is virtually non existant. Find out how VxD:s work generally involves low level reverse engineering. > I'm looking forward for any hints. Hmm. Reading MSDN... There is a DLL called NETAPI32.DLL that is not currentlu implemented in Wine that has a function Netbios that possible calls the VNETBIOS VxD. Perhaps implementing this DLL in Wine would help at least it would be better than trying the figure out what the VNETBIOS VxD does. The function Netbios in NETAPI32.DLL is at least documented. Hmm. Reading some more... Netbios has a command NCBASTAT that retreives the adapter status in a structure called ADAPTER_STATUS that has a field: UCHAR adapter_address[6]; // Specifies encoded address of the adapter. This might be the MAC address. Implementing this in Wine wouldn't be that hard. If Linux provides a way to get the MAC that is. I assume Linux does but I don't know how. Does anybody else know?

5 4