- Wine-Devel - list.winehq.org

Re: virtual memory problems with Linux 2.4.5
by Alexandre Julliard June 14, 2001

June 14, 2001

Alexandre Julliard <julliard(a)winehq.com> writes: > Another related problem is that even without this bug, mmap64 will > always refuse to do an unaligned mmap, even if the kernel might have > accepted it (with kernel 2.2.x for instance). Maybe the best solution > would be to directly call the mmap syscall instead of mmap2 when > mapping executables, this would fix both problems. OK, here we go. Could you please test this, especially people running kernel 2.4? Index: memory/virtual.c =================================================================== RCS file: /opt/cvs-commit/wine/memory/virtual.c,v retrieving revision 1.63 diff -u -r1.63 virtual.c --- memory/virtual.c 2001/06/13 20:13:20 1.63 +++ memory/virtual.c 2001/06/14 02:15:36 @@ -104,7 +104,8 @@ #define VIRTUAL_DEBUG_DUMP_VIEW(view) \ if (!TRACE_ON(virtual)); else VIRTUAL_DumpView(view) -static LPVOID VIRTUAL_mmap( int fd, LPVOID start, DWORD size, DWORD offset, int prot, int flags ); +static LPVOID VIRTUAL_mmap( int fd, LPVOID start, DWORD size, DWORD offset_low, + DWORD offset_high, int prot, int flags ); /* filter for page-fault exceptions */ static WINE_EXCEPTION_FILTER(page_fault) @@ -471,7 +472,7 @@ /* map the header */ - if (VIRTUAL_mmap( fd, ptr, header_size, 0, PROT_READ | PROT_WRITE, + if (VIRTUAL_mmap( fd, ptr, header_size, 0, 0, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_FIXED ) == (char *)-1) goto error; dos = (IMAGE_DOS_HEADER *)ptr; nt = (IMAGE_NT_HEADERS *)(ptr + dos->e_lfanew); @@ -533,7 +534,7 @@ sec->PointerToRawData, pos, sec->SizeOfRawData, size, sec->Characteristics ); if (VIRTUAL_mmap( shared_fd, (char *)ptr + sec->VirtualAddress, size, - pos, PROT_READ|PROT_WRITE|PROT_EXEC, + pos, 0, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED ) == (void *)-1) { ERR_(module)( "Could not map shared section %.8s\n", sec->Name ); @@ -555,7 +556,7 @@ * fall back to read(), so we don't need to check anything here. */ if (VIRTUAL_mmap( fd, (char *)ptr + sec->VirtualAddress, sec->SizeOfRawData, - sec->PointerToRawData, PROT_READ|PROT_WRITE|PROT_EXEC, + sec->PointerToRawData, 0, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE | MAP_FIXED ) == (void *)-1) { ERR_(module)( "Could not map section %.8s, file probably truncated\n", sec->Name ); @@ -650,6 +651,46 @@ } + +/*********************************************************************** + * unaligned_mmap + * + * Linux kernels before 2.4.x can support non page-aligned offsets, as + * long as the offset is aligned to the filesystem block size. This is + * a big performance gain so we want to take advantage of it. + * + * However, when we use 64-bit file support this doesn't work because + * glibc rejects unaligned offsets. Also glibc 2.1.3 mmap64 is broken + * in that it rounds unaligned offsets down to a page boundary. For + * these reasons we do a direct system call here. + */ +static void *unaligned_mmap( void *addr, size_t length, unsigned int prot, + unsigned int flags, int fd, unsigned int offset_low, + unsigned int offset_high ) +{ +#if defined(linux) && defined(__i386__) && defined(__GNUC__) + if (!offset_high && (offset_low & page_mask)) + { + int ret; + __asm__ __volatile__("push %%ebx\n\t" + "movl %2,%%ebx\n\t" + "int $0x80\n\t" + "popl %%ebx" + : "=a" (ret) + : "0" (90), /* SYS_mmap */ + "g" (&addr) ); + if (ret < 0 && ret > -4096) + { + errno = -ret; + ret = -1; + } + return (void *)ret; + } +#endif + return mmap( addr, length, prot, flags, fd, ((off_t)offset_high << 32) | offset_low ); +} + + /*********************************************************************** * VIRTUAL_mmap * @@ -657,15 +698,16 @@ * and falls back to read if mmap of a file fails. */ static LPVOID VIRTUAL_mmap( int fd, LPVOID start, DWORD size, - DWORD offset, int prot, int flags ) + DWORD offset_low, DWORD offset_high, int prot, int flags ) { int pos; LPVOID ret; + off_t offset; if (fd == -1) return wine_anon_mmap( start, size, prot, flags ); - if ((ret = mmap( start, size, prot, flags, fd, offset )) != (LPVOID)-1) - return ret; + if ((ret = unaligned_mmap( start, size, prot, flags, fd, + offset_low, offset_high )) != (LPVOID)-1) return ret; /* mmap() failed; if this is because the file offset is not */ /* page-aligned (EINVAL), or because the underlying filesystem */ @@ -687,6 +729,7 @@ ret = wine_anon_mmap( start, size, PROT_READ | PROT_WRITE, flags ); if (ret == (LPVOID)-1) return ret; /* Now read in the file */ + offset = ((off_t)offset_high << 32) | offset_low; if ((pos = lseek( fd, offset, SEEK_SET )) == -1) { munmap( ret, size ); @@ -1524,8 +1567,8 @@ shared_file, shared_size ); - if (size_high || offset_high) - ERR("Offsets larger than 4Gb not supported\n"); + if (size_high) + ERR("Sizes larger than 4Gb not supported\n"); if ((offset_low >= size_low) || (count > size_low - offset_low)) @@ -1570,7 +1613,7 @@ TRACE("handle=%x size=%x offset=%lx\n", handle, size, offset_low ); - ptr = (UINT)VIRTUAL_mmap( unix_handle, addr, size, offset_low, + ptr = (UINT)VIRTUAL_mmap( unix_handle, addr, size, offset_low, offset_high, VIRTUAL_GetUnixProt( prot ), flags ); if (ptr == (UINT)-1) { /* KB: Q125713, 25-SEP-1995, "Common File Mapping Problems and -- Alexandre Julliard julliard(a)winehq.com

5 5

clipped child
by lawson_whitney＠juno.com June 14, 2001

June 14, 2001

Good day! A little problem. Unhandled exception: page fault on read access to 0x00000067 in 32-bit code (0x40a25f4e). In 32-bit mode. 0x40a25f4e (clip_children+0x7e [winpos.c:83] in libx11drv.so): testb $0x10,0x67(%esi) 83 if (ptr->dwStyle & WS_VISIBLE) Lawson ---

1 0

RE: wine on Alpha (was: Help needed)
by Patrik Stridvall June 14, 2001

June 14, 2001

> > Still, you must be aware of a few thing. > > * Wine is not 100% byte order clean. > > Alpha seems to be "correct" endian ;) True. But what I meant was since the size of integer changes from 32 to 64 bits, any code that rely on the exact layout of memory might have problems becuase of this. This is not the same as the problem below where you have pointer truncation issues or because code expects that DWORD x; int y; x = y; will work correcly. But OK. I shold probably explained better what I meant. Anyway all code should be byte order clean regardless and making it so might solve some 32/64 bit byte layout problems as well. When you change to code for Alpha you might as well change it to work with big endian platforms as well. > > * Wine is not 64 bit clean. > > This is a little worse especially since > > Win32 often stores pointers in 32 bit integers > > and this problem really can't be solved in > > a good way, since extending the size of the storage > > is not possible at least not if you want to > > be able to implement a x86 emulator in the > > future. However I guess it will be possible > > to force all memory usage to be in the lower > > 32 bits of memory to be able to cope with > > truncated pointers. > > Digital has(d) a lot of very good emulation technologies - > FX!32 which let to run win32 386 apps on NT Alpha with > almost full speed, em86 which runs 386 Linux apps on Linux > Alpha (http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html) > x86emu which is used in XFree86 and MILO to initialize > graphic card's 386 BIOS. True, but Wine might need something a little more than that and FX!32 doesn't have souce code available AFAIK. Of course that is perhaps not a problem for an internal Digital project. :-) Anyway, that is a later problem. Just making Winelib work might take some effort.

1 0

OT - a free windows screensaver?
by lawson_whitney＠juno.com June 14, 2001

June 14, 2001

Good day! After I got both my legs broke April 27, my computer and I have been a bit exposed to a small segment of the public, and everybody loves my screensaver. ftp://ftp.ibiblio.org/pub/Linux/utils/console/lockvc-3.9.1.tar.gz Of course, I may have a hard time to get them to install Linux just for a screensaver, so I thought I might see about porting it to windose. A sample or something to plagiarize from would be good, I think. I haven't figured out how to work mingw either, but maybe inspiration will come. Regards, Lawson ---cut here--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

interrupts
by Eugene Toichkin June 14, 2001

June 14, 2001

Hi! I have to run the add-on card with Windows controlling program on my linux box. That card generates the interrupt and requires some port addresses. Is any way to configure WINE to run that kind of application on Linux host? -- Best regards, Eugene Toichkin ugin(a)itc.mecom.ru

1 0

Re: Re: virtual memory problems with Linux 2.4.5
by Mike McCormack June 14, 2001

June 14, 2001

Seems ok to me also, after a quick test. Mike Original message from: lawson_whitney(a)juno.com > > > >On 13 Jun 2001, Alexandre Julliard wrote: > >> OK, here we go. Could you please test this, especially people running >> kernel 2.4? >> >> Index: memory/virtual.c > >Looks good to me. First problem app runs OK, and you get this by the >second one. > >gcc version 2.95.3 20010315 (release) >/lib/libc.so.6 -> libc-2.1.3.so* >Linux giftie 2.4.5 #1 Sat Jun 2 11:23:22 EDT 2001 i586 unknown > >Lawson ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Drawing problems with ControlSpy
by Guy L. Albertelli June 14, 2001

June 14, 2001

With today's CVS (last patch was "wine/ dlls/gdi/wing.c dlls/kernel/comm.c dlls/ ..."), the following problems exist in the ControSpy (REBAR) test program: Problem #1. Using native version of "commctrl,comctl32", get the following fault: /home/albertel/t1/wine/wine -managed -winver win95 -dll commctrl,comctl32=n G:\Rdhat\test-pgm\controls\rebar.exe Could not stat /mnt/winflp (No such file or directory), ignoring drive A: fixme:pthread_kill_other_threads_np Could not stat /mnt/winflp (No such file or directory), ignoring drive A: WineDbg starting... on pid 8064ef0 ...... Unhandled exception: page fault on read access to 0x00000067 in 32-bit code (0x40894f24). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x40894f24 (clip_children+0x24 [winpos.c:70] in libx11drv.so): testb $0x10,0x67(%esi) 70 if (ptr->dwStyle & WS_VISIBLE) break; Wine-dbg>bt Backtrace: =>0 0x40894f24 (clip_children+0x24(win=0x403732dc, last=0x40373370, hrgn=0xa22, whole_window=0x0) [winpos.c:70] in libx11drv.so) (ebp=40586564) 1 0x4089511e (get_visible_region+0x14e(win=0x40373370, top=0x403732dc, flags=0x1001a, mode=0x1) [winpos.c:144] in libx11drv.so) (ebp=405865a4) 2 0x408952ec (X11DRV_GetDC+0x1a8(hwnd=0x1908, hdc=0x88, hrgn=0x0, flags=0x1001a) [winpos.c:229] in libx11drv.so) (ebp=405865e8) 3 0x406874bc (GetDCEx+0x29c(hwnd=0x1908, hrgnClip=0x0, flags=0x10000) [dce.c:531] in libuser32.so) (ebp=40586620) 4 0x4068755c (GetDC+0x2c(hwnd=0x1908) [dce.c:561] in libuser32.so) (ebp=40586638) 5 0xbfb9a055 (COMCTL32.DLL.InitCommonControlsEx+0x4137 in C:\WINDOWS\SYSTEM\COMCTL32.DLL) (ebp=40586694) 6 0xbfb9a037 (COMCTL32.DLL.InitCommonControlsEx+0x4119 in C:\WINDOWS\SYSTEM\COMCTL32.DLL) (ebp=405867fc) 7 0xbfb94e38 (COMCTL32.DLL.ImageList_GetIconSize+0x558 in C:\WINDOWS\SYSTEM\COMCTL32.DLL) (ebp=40586854) 8 0x406b24a7 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=40586878) 9 0x406b2520 (WINPROC_CallWndProc+0x70(proc=0xbfb94a89, hwnd=0x1908, msg=0x81, wParam=0x0, lParam=0x40586b10) [winproc.c:171] in libuser32.so) (ebp=405868a0) The following patch bypasses the tests: --- wine/dlls/x11drv/winpos.c Wed Jun 13 20:03:34 2001 +++ mywine/dlls/x11drv/winpos.c Wed Jun 13 22:59:18 2001 @@ -65,6 +65,9 @@ HRGN rectRgn; int x, y; + /* if no children then nothing to do */ + if (!win->child) return; + /* first check if we have anything to do */ for (ptr = win->child; ptr != last; ptr = ptr->next) if (ptr->dwStyle & WS_VISIBLE) break; Problem # 2. With above patch and still using native comctl32 get the following: /home/albertel/t1/mywine/wine -managed -winver win95 -dll commctrl,comctl32=n G:\Rdhat\test-pgm\controls\rebar.exe Could not stat /mnt/winflp (No such file or directory), ignoring drive A: err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:x11drv:X11DRV_SetDeviceClipping Rgn is 0. Please report this. ##normal exit from wine## Problem # 3. Still with native comctl32. With more than 1 band in a row, when you drag a band from left to right, the band being uncovered is not fully repainted (suspect InvalidateRect too small). This is especially visible if the band being dragged is a different color. It is also sensitive to the speed of the drag. Attached is a control file to create different color bands in a row. If you need any more information, let me know what. I will be doing more work tomorrow night. Thanks, Guy

1 0

Re: wine/windows/x11drv event.c
by Guy L. Albertelli June 14, 2001

June 14, 2001

> >Log message: > Force invalidating of siblings children on expose event. > This seems to allow ControlSpy (rebar) to draw its children again, but exposes some other drawing problems. The symptom is that certain areas do not seem to be invalidated correctly. If the window is overlayed with another the everything is redrawn correctly. I will attempt to get documentation later tonight. Thanks, Guy

1 0

RE: Help needed
by Patrik Stridvall June 13, 2001

June 13, 2001

I'm sorry for not answering earlier. I saw your message but I didn't have time to answer it at the time and then a forgot about it. In truth I wasn't very eager about answering either since I have answered far to many people that just asked questions and then didn't contribute anything because I guess that they felt it was to difficult or to much work. I didn't notice that you were from Digital either, but after reading Kernel Cousin Wine #97 I was made aware of that fact. While it is possible that you are yet another of those people I talked about above, since you are from Digital I will take some time to answer your questions. Note however that I'm not at all unwilling to answer questions. It is just that it has felt like a wasted effort in the past. > We are planning to port wine onto Tru64 Unix. I have some > basic Questions. OK. Sound good. > Can you tell me how to go about it. Yes. But it is better if you ask more specific questions. > How do we start. You try to get it to compile and link. This shouldn't be to difficult. While I never used Tru64 I expect it supports all things Wine will need. > How big > is the task and Well, if you want the emulator (Wine) to work it will be a humongous task, since you will have to emulate x86 instructions on the Alpha among other things. However if you just want the porting tool (Winelib) to work it will be a little easier. Still, you must be aware of a few thing. * Wine is not 100% byte order clean. However there have been some attempts to port it to Sparc which is big endian so don't if I think it is that bad and the remaining problems can be fixed without to much effort. * Wine is not 64 bit clean. This is a little worse especially since Win32 often stores pointers in 32 bit integers and this problem really can't be solved in a good way, since extending the size of the storage is not possible at least not if you want to be able to implement a x86 emulator in the future. However I guess it will be possible to force all memory usage to be in the lower 32 bits of memory to be able to cope with truncated pointers. * Then of course you have Tru64 specific problem. However I don't expect them to be so bad. > how to start about it.. Well as I said. Try to compile and link it. Then try to get some of the simple examples in wine/programs to run.

2 1

Re: virtual memory problems with Linux 2.4.5
by Alexandre Julliard June 13, 2001

June 13, 2001

Mike McCormack <mike_mccormack(a)start.com.au> writes: > your patch produced a yes, BUT when i changed the offset value to > 0x400, and it failed ... see new patch below. That's a bug in glibc 2.1.3. This is from the mmap64 source: [offset is in ecx:edx] testl $0x3ff, %edx jne L(einval) shrdl $12, %ecx, %edx /* mmap2 takes the offset in pages. */ shrl $12, %ecx But of course 0x3ff only tests 10 bits, not 12, so if bits 10 or 11 are set they will be silently dropped. This has been fixed in glibc-2.2. Another related problem is that even without this bug, mmap64 will always refuse to do an unaligned mmap, even if the kernel might have accepted it (with kernel 2.2.x for instance). Maybe the best solution would be to directly call the mmap syscall instead of mmap2 when mapping executables, this would fix both problems. -- Alexandre Julliard julliard(a)winehq.com

1 0