March 2002 - Wine-devel - list.winehq.org

wineserver not terminating
by Lonnie Cumberland 27 Mar '02

27 Mar '02

Hello All, I have recently noticed that after starting up a wine instance, that upon closing the appliction sometimes the wine instance is still a running process and I have to kill it manually. I am running the latest version of wine as well. Any ideas as to what is going on here and how this can be fixed. Cheers, Lonnie -- Lonnie Cumberland OutStep Technologies Incorporated EMAIL: Lonnie(a)OutStep.com : Lonnie_Cumberland(a)yahoo.com The Basis Express Virtual Office & Data Backup and Recovery Services URL: http://www.basis-express.com "The Virtual Office without boundaries!!!"

2 1

Re: ntfs filesystem
by Lonnie Cumberland 26 Mar '02

26 Mar '02

Hello Dante, I must be confused. I know about the different types of filesystems that can be made and mounted on the Linux VFS, but doesn't Wine allow you to specify in the ./wine/wine.conf the filesystem type? In Windows NT for example, the user can assign permissions in a similar way that Linux allows. the same is true for Windows 2000 and I suspect for Windows XP as well. So this is really related to wine and how it interacts with the psuedo filesystem. Is this correct? Cheers, Lonnie > Lonnie Cumberland wrote: > >>Hello Again All, >> >>I just had another thought and was wondering if someone was >>working on the NTFS filesystem for Wine? >> >>I am guessing that this is what is being used in the Windows2000 >>and Windows XP as well, right? >> > I believe at least in 2k, you had an option, > but this is a moot point since filesystem layer code is outside > the realm of wine .. > this is done by the host operating system. > There is a ntfs fs project for linux : > http://linux-ntfs.sourceforge.net/ > > --Dante -- Lonnie Cumberland OutStep Technologies Incorporated EMAIL: Lonnie(a)OutStep.com : Lonnie_Cumberland(a)yahoo.com The Basis Express Virtual Office & Data Backup and Recovery Services URL: http://www.basis-express.com "The Virtual Office without boundaries!!!"

2 1

Re: Hack/work-around for cursor problem on sparc-solaris
by Warren_Baird＠cimmetry.com 26 Mar '02

26 Mar '02

> I don't think there are places where LoadCursor can legitimately > fail. Besides, since your SetDefaultCursor is not an exported API it > could only be used inside user32.dll, where LoadCursor will definitely > never fail (modulo bugs of course). Ok - I'll just leave my hack in locally then. Warren

1 0

Re: Hack/work-around for cursor problem on sparc-solaris
by Warren_Baird＠cimmetry.com 26 Mar '02

26 Mar '02

> I don't see how you can do that, SetCursor doesn't call LoadCursor. > And LoadCursor on system cursors is not supposed to fail so there is > no need to handle that case; if it fails it's a bug that should be > fixed. That's true, but the paradigm SetCursor(LoadCursorA(...)); happens in a lot of places... What I'm suggesting is replacing them with something like: HCURSOR cursor = LoadCursorA(...); if (cursor) { SetCursor(cursor); } else { SetDefaultCursor(); } As I said, if you don't think this will ever happen in 'real life', I'm happy to leave my hack in place locally until I get the cursor thing sorted out correctly... But if there are any legitimate cases where LoadCursorA might fail, this would probably give a better result... Warren

2 1

Re: OT: Buggy fonts
by Duane Clark 26 Mar '02

26 Mar '02

Huw D M Davies wrote: > A much better way to do font rendering in Wine is to use the new > client side rendering code. For this you need an XServer capable of > supporting the RENDER extension (xdpyinfo will tell you whether you > have such a beast) and a copy of the FreeType library version at least > 2.0.5 (but the later the better). Add a [FontDirs] section to your > ~/.wine/config file, with entries pointing at any directories that > contain TT fonts... This got me to try out the client side rendering. It really does make the fonts (in MS Word in particular) not suck! Nice job. Guess I will stick with this configuration. I came across two issues. The first is that virtually all dialogs and some windows were being drawn too narrow. The window/dialog height was normal. Looking at traces with and without the client side rendering, I saw this difference: Server rendering: trace:dialog:DIALOG_ParseTemplate32 DIALOG 0, 0, 287, 165, 0 trace:dialog:DIALOG_ParseTemplate32 STYLE 0x80c820c0 trace:dialog:DIALOG_ParseTemplate32 EXSTYLE 0x00000000 trace:dialog:DIALOG_ParseTemplate32 CAPTION L"Open" trace:dialog:DIALOG_ParseTemplate32 FONT 8, L"helv", 0, FALSE trace:font:WineEngCreateFontInstance L"System", h=16, it=0, weight=400, PandF=22, charset=0 orient 0 escapement 0 ... trace:font:XFONT_GetAvgCharWidth retuning 6 trace:font:XFONT_RealizeFont physfont 3 trace:font:GetTextMetricsW text metrics: Weight = 400 FirstChar = 0 AveCharWidth = 6 Client rendering: trace:dialog:DIALOG_ParseTemplate32 DIALOG 0, 0, 287, 165, 0 trace:dialog:DIALOG_ParseTemplate32 STYLE 0x80c820c0 trace:dialog:DIALOG_ParseTemplate32 EXSTYLE 0x00000000 trace:dialog:DIALOG_ParseTemplate32 CAPTION L"Open" trace:dialog:DIALOG_ParseTemplate32 FONT 8, L"helv", 0, FALSE ... trace:font:WineEngCreateFontInstance L"helv", h=-10, it=0, weight=0, PandF=00, charset=1 orient 0 escapement 0 ... trace:font:WineEngGetTextMetrics OS/2 winA = 1854 winD = 434 typoA = 1491 typoD = -431 typoLG = 307 FT_Face a = 1854, d = -434, h = 2355: HORZ a = 1854, d = -434 lg = 67 maxY = 2124 minY = -665 trace:font:WineEngGetTextMetrics xAvgCharWidth 904 x_scale 20480 tmAvgCharWidth 4 trace:font:GetTextMetricsW text metrics: Weight = 400 FirstChar = 32 AveCharWidth = 4 Suspecting the average char width, but not understanding the code that generates it, I cheated. In WineEngGetTextMetrics(), I added: if (ptm->tmAveCharWidth == 4) ptm->tmAveCharWidth = 6; And this fixes all the dialogs and windows for me. The other problem I ran across is shown in these pictures, showing server and client side rendering. My little hack above had no effect on this particular problem. http://www.leewardfpga.com/server.png http://www.leewardfpga.com/client.png As can be seen, the vertical text is getting chopped off slightly. The font with the problem is Tahoma, and this is with a ~/.wine/config that contains [fonts] "Resolution" = "96" "Default" = "-adobe-times-" "DefaultFixed" = "fixed" "DefaultSerif" = "-monotype-times new roman-" "DefaultSansSerif" = "-microsoft-tahoma-"

3 4

Re: Hack/work-around for cursor problem on sparc-solaris
by Warren_Baird＠cimmetry.com 26 Mar '02

26 Mar '02

Alexandre Julliard wrote: > No; you can actually set a NULL cursor to hide the cursor. This is > also used by ShowCursor(). Ok... Do you agree that we should handle the 'failed to load cursor resources' problem in a better way that just drawing no cursor? If not, I'll just leave my change in locally until I get the cursor loading fixed on solaris. Once I get the problem fixed it may not be a big deal... If so - how do you suggest we address it? One possibility would be add a new function named something like 'X11DRV_SetDefaultCursor' and have SetCursor call it when LoadCursor fails... Anyone have a better idea? Warren

2 1

pthreads patch
by Chris Morgan 26 Mar '02

26 Mar '02

After adding some printfs I discovered that jack was locking up at a call to pthread_create. Jack also uses plenty of other pthreads functions so I tried to implement as many as possible. Just wanted to run this patch by people before submitting to wine-patches. scheduler/pthread.c, thread.c, server/thread.c, request.h, include/winbase.h, include/wine/server_protocol.h, dlls/kernel/kernel32.spec Chris Morgan <cmorgan(a)alum.wpi.edu> Implement OpenThread(). Implement a few pthreads functions. Patch is X11 as Ove helped out.

1 0

Re: Conversion of HACMOBJ to void* (bug #478)
by Eric Pouech 26 Mar '02

26 Mar '02

Vincent Béron a écrit : > > I had to transform acmMetrics16 to a atub (was dubbed "semi-stub") > because of an impossibility to convert a HACMOBJ16 (16bit offset > pointer, without segment info) to a HACMOBJ (32bit linear pointer): a > pointer less or equal than 0x0000ffff would certainly not access the > right memory area. two points: 1/ a handle can have any value... it's up to the DLL to decide what value it really is (pointer, index into an internal array, key to look up in a set...). in msacm case, since 16bit handles are not implemented yet, you cannot really tell 2/ you can leave the semi-stub as it is, mainly when the handle is NULL (which is in lots of cases for acmMetrics). However, since no 16 bit handle can be created, acmMetrics16 will only be called with NULL handles, since the semi-stub so, I'd propose to let acmMetrics16 call acmMetrics only if hao is 0 A+

1 0

socket question
by michael cardenas 25 Mar '02

25 Mar '02

I'd like to throw this out there for anyone more familiar with sockets in wine than I am. Here's some of the output of running aol with --debugmsg +winsock: trace:winsock:WS_socket af=2 type=1 protocol=0 trace:winsock:WS_socket created 0320 trace:winsock:WS_bind socket 0320, ptr 0x40595b7c, length 16 trace:winsock:WSAAsyncSelect 0320, hWnd 006f, uMsg 00000468, event 00000033 trace:winsock:WSAEventSelect 00000320, hEvent 00000328, event 01000033 trace:winsock:WS_connect socket 0320, ptr 0x40595b50, length 16 trace:winsock:WINSOCK_DoAsyncEvent socket 00000320, event 00000328 trace:winsock:WINSOCK_DoAsyncEvent post: event bit 4, error 10061 trace:winsock:WINSOCK_DoAsyncEvent socket 00000320, event 00000328 trace:winsock:WINSOCK_DoAsyncEvent post: event bit 5, error 0 trace:winsock:WSAAsyncSelect 0320, hWnd 006f, uMsg 00000468, event 00000000 trace:winsock:WSAEventSelect 00000320, hEvent 00000000, event 00000000 trace:winsock:WINSOCK_DoAsyncEvent socket 00000320, event 00000328 trace:winsock:WINSOCK_DoAsyncEvent orphaned event, self-destructing this seems to happen over and over again. My application sets up it's socket to send it a window message when the event happens, but the event takes too long and so the app turns off the notification, and the event becomes orphaned.

1 0

Re: debugging longman dictionary
by Laurent Pinchart 25 Mar '02

25 Mar '02

I looked at the trace log you attached to your email, and recognised (unfortunately) familiar copy protection output :-( Is anyone working on implementing what would be needed to successfuly run copy-protected softwares ? I ran into the same problems when I tried to play The Longuest Journey with Wine. I disassembled a large part of the code and rewrote it in C to try to understand what was going on. If anyone is interested I can send my work by e-mail (I won't send it to the list as the files are quite big). Basically, the copy protection scheme I studied used the following technique. One of the sections in the PE file is encrypted. The decryption key is generated from the content of the other sections. The process of decrypting the encrypted section tried to detect if a debugger is running, and fails to run properly if so. This results in the inability to decrypt the PE file if the unencrypted section is modified or if a debugger is running. There must be some code to detect if the application CD is genuine but I've never been able to go past the decryption part. To detect if a debugger is running, the following actions are performed (in no particular order): - the code tries to open some files using CreateFileA : "\\.\SICE", "\\.\SIWVID" and "\\.\NTICE". This fails as the SoftICE VxDs are not loaded, so no problems there - it also tries to read/write to the debug registers. this produces an unhandled exception. should be trivial to write an exception handler to support that (right ?) - the code writes binary code to the interrupt vector table (at address 0 - division by 0 handler), and then cause to the division by 0 interrupt handler to be called by dividing a value by 0. - the TIB (Thread Information Block, which address is located at fs:0) is read. The following C code illustrates the technique (which I don't understand :-) bool detect_debugger_from_TIB { char *pTIB; asm ( "mov %%fs:0x18, %", "=g"(pTIB) ); if ( pTIB[0x20] == 0 ) return FALSE; else return TRUE; } - another debugger detection technique uses int 0x68, functino 0x4300. If the content of eax when returning from int 0x68 is not 0x4300, a debugger is present. This is not performed on some NEC Japanese systems, which probably use int 0x68 for another purpose. - the last attempt to detect a debugger uses int 0x01 (enter SMM/ICE mode), which checks if an external hardware emulator is connected to the processor. I haven't been able to understand what the code is supposed to do. There might be some other anti-debugging techniques, I gave up after 2 weeks of disassembly :-) Hope these observations will help someone. Laurent Pinchart

4 15