- Wine-devel - list.winehq.org

Page faults and instruction emulation
by Ove Kaaven 19 Oct '01

19 Oct '01

As we all know, some (kinda worthless) "copy protection" software exist out there that doesn't work under Wine. Some of these work under win9x and winNT by using a different set of techniques for each OS. The winNT code installs a kernel driver, so I'm mainly interested in the win95 code, which only messes with Win95 internals to check that no debugger is snooping, before proceeding. I know of two Wine architecture issues that must be resolved before the anti-debugger check can succeed in win95 mode. 1. it checks that teb->debug_context (TEB offset 0x20) is zero. In Wine, it isn't (the NT pid is stored there), so this check fails. Is it possible to change Wine's TEB structure to fix this? 2. it messes with the IDT. It uses the sidt instruction and tries to change the INT5 vector (BOUND exception vector), later to try to execute a BOUND and expect this vector to be branched to, all protected with exception handlers. Now, this would actually be possible for Wine to emulate, even though sidt is not a privileged instruction. The idea is that sidt returns an address to kernel space, where all access is prohibited, hence causing page faults. Wine could trap these, and then emulate the faulting instruction by operating on a fake IDT instead. And then the segfault caused by BOUND could then look up the fake IDT entry, and call the vector therein. But to emulate an instruction from Wine's pre-exception page fault handler (VIRTUAL_HandleFault()), the current context must be passed along to it, so VIRTUAL_HandleFault and all Wine handlers that can be registered with VIRTUAL_SetFaultHandler must get an extra parameter. Is this too objectionable to do? Alexandre?

1 0

File media type
by Ove Kaaven 18 Oct '01

18 Oct '01

I'm trying to think of a way to make multi-CD installers work under Wine. Right now, the hardest part is that when the installers tell you to change discs, the Setup.exe file mappings are still open. I'm thinking of making Wine not map the file, but read it straight into RAM, if the executable to be mapped is on removable media. But since to do this, MapViewOfFile needs to know the media type, and the file name is only known in CreateFile, I apparently need to store the media type in the wineserver object to accomplish this. Would changing the wineserver protocol in this way be a good idea? Index: server/protocol.def =================================================================== RCS file: /cvsroot/winex/wine/server/protocol.def,v retrieving revision 1.5 diff -u -r1.5 protocol.def --- server/protocol.def 2001/10/13 20:20:06 1.5 +++ server/protocol.def 2001/10/18 22:50:29 @@ -505,6 +505,7 @@ unsigned int sharing; /* sharing flags */ int create; /* file create action */ unsigned int attrs; /* file attributes for creation */ + int mediatype; /* media type file is on */ VARARG(filename,string); /* file name */ @REPLY handle_t handle; /* handle to the file */ @@ -527,6 +528,7 @@ @REPLY int fd; /* file descriptor */ int type; /* the type of file */ + int mediatype; /* media type file is on */ @END #define FD_TYPE_INVALID 0 #define FD_TYPE_DEFAULT 1

2 1

Re: Use the debugmsg for the pthread FIXME messages.
by Alexandre Julliard 18 Oct '01

18 Oct '01

"Medland, Bill" <Bill.Medland(a)accpac.com> writes: > I am fed up with the pthread fixmes; we ought at least to be able to turn > them off with debugmsg. This will crash and burn if glibc calls a pthread function before ntdll has been properly initialized. Besides, the messages are annoying on purpose: to motivate someone to implement the missing functions... -- Alexandre Julliard julliard(a)winehq.com

1 0

lsarpc.idl API
by Luke Kenneth Casson Leighton 18 Oct '01

18 Oct '01

Mail-Followup-To: tng-technical(a)samba-tng.org, lsa-dev(a)lists.dcerpc.net, freedce-dev(a)lists.dcerpc.net, samba-ntdom(a)samba.org, samba-technical(a)samba.org, wine-dev(a)winehq.com User-Agent: Mutt/1.2.4i X-original-sender: lkcl(a)samba-tng.org Precedence: bulk Reply-To: tng-technical(a)lists.dcerpc.org X-list: tng-technical thanks to matty for the lsarpc.idl file: it compiles in dceidl (slightly modified) and we're away! client-side header file and API is generated _automatically_ by dceidl, for immediate use with freedce libraries. porting of TNG's srv_lsa_nt.c can now take place if anyone's interested. volunteers, anyone? luke p.s. we also have winreg.idl so that means that the Reg* API is also automatically available for immediate use. if anyone's interested.

1 0

Wine press : Safedisc by Transgaming
by Gerard Patel 18 Oct '01

18 Oct '01

http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.101701/212902145&ticke r=MVSN Gerard

1 0

Re: RtlEnterCriticalSection
by Marcus Meissner 18 Oct '01

18 Oct '01

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 18 Oct '01

18 Oct '01

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 18 Oct '01

18 Oct '01

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 18 Oct '01

18 Oct '01

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 18 Oct '01

18 Oct '01

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