June 2001 - wine-devel

16-bit and 32-bit separation
by Patrik Stridvall 18 Jun '01

18 Jun '01

[Since the subject it up because of Dimitry's "Move 16-bit COMM stuff to USER, where it belongs" patch] My new tool winapi_fixup could without to much effort be extended to facillitate separation of 16-bit and 32-bit stuff by moving the 16-bit parts of a file (example: foo.c) to a new 16-bit only file (example: foo16.c). Of course because of dependecies, includes and such things it can only be partly automatic and it will in most cases require quite a lot editing afterwards, so the questions (primarily to Alexandre but other replies welcome to) are: 1. Will/Should Alexandre accept such patches at all? 2. Is it a useful effort to get the 16-bit stuff out of the way so we don't have to see it in the files when editing the 32-bit stuff? 3. Is it a useful effort to make it possible to have --disable-win16 configure option to compile out as much Win16 stuff as possible in order to save space in the binaries for say embedded stuff. 4. While this certainly it not a high or even medium priority effort, should it have low, very low or extremly low priority? PS. I have other stuff planed so I certainly do not lack things to do. However since the subject is up I might just as well ask.

1 0

SIGSEGV while trying to run Word97
by Heiko Nardmann 17 Jun '01

17 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am continously getting a dialog "Nicht genügend Arbeitsspeicher oder unzureichender Speicherplatz, um Word auszuführen" (German version). After trying to examine this problem with debugmsg all (without real success) I added an strace call to the whole call. This resulted in a log file which tells me that a SIGSEGV occurrs. Here is a part of the strace log file which contains the SIGSEGV message. After that the appropriate 'debugmsg all' part follows. What can be done to shed more light onto this problem? strace log: write(2, "08069280:trace:win32:_LeaveSysLe"..., 112) = 112 write(2, "08069280:Ret user32.CreateWindo"..., 68) = 68 write(2, "08069280:RET mso97.486: _MsoCre"..., 84) = 84 write(2, "08069280:trace:heap:HeapFree (40"..., 74) = 74 write(2, "08069280:Call kernel32.GetVersio"..., 49) = 49 write(2, "08069280:Ret kernel32.GetVersio"..., 65) = 65 write(2, "08069280:Call kernel32.GetVersio"..., 60) = 60 write(2, "08069280:Ret kernel32.GetVersio"..., 68) = 68 write(2, "08069280:Call kernel32.GlobalMem"..., 65) = 65 time(NULL) = 992531763 time(NULL) = 992531763 open("/proc/meminfo", O_RDONLY) = 11 fstat(11, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4035c000 read(11, " total: used: free:"..., 1024) = 319 read(11, "", 1024) = 0 close(11) = 0 munmap(0x4035c000, 4096) = 0 write(2, "08069280:Ret kernel32.GlobalMem"..., 73) = 73 write(2, "08069280:CALL mso97.394: _MsoFCr"..., 147) = 147 write(2, ") ret=30011010\n", 15) = 15 write(2, "08069280:Call kernel32.VirtualAl"..., 86) = 86 write(2, "08069280:trace:virtual:VirtualAl"..., 68) = 68 mmap2(NULL, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOSYS (Function not implemented) old_mmap(NULL, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40e90000 munmap(0x40ea0000, 65536) = 0 write(2, "View: 40e90000 - 40e9ffff (vallo"..., 35) = 35 write(2, " 40e90000 - 40e9ffff -----\n", 32) = 32 write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 write(2, "08069280:Call kernel32.VirtualAl"..., 86) = 86 write(2, "08069280:trace:virtual:VirtualAl"..., 68) = 68 write(2, "08069280:trace:virtual:VIRTUAL_S"..., 63) = 63 mprotect(0x40e90000, 4096, PROT_READ|PROT_WRITE) = 0 write(2, "View: 40e90000 - 40e9ffff (vallo"..., 35) = 35 write(2, " 40e90000 - 40e90fff c-rW-\n", 32) = 32 write(2, " 40e91000 - 40e9ffff -----\n", 32) = 32 write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 - --- SIGSEGV (Speicherzugriffsfehler) --- write(2, "08069280:RET mso97.394: _MsoFCr"..., 126) = 126 rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [], 8) = 0 write(5, "F\0\0\0\0\0\34\1<\0336@\1\0\0\0\304\357\17@\0\0\0\0\0\0"..., 64) = 64 read(6, "F\0\0\0\0\0\34\1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 write(2, "08069280:trace:seh:EXC_CallHandl"..., 87) = 87 write(2, "08069280:trace:seh:EXC_RtlUnwind"..., 55) = 55 write(2, "08069280:trace:seh:EXC_CallHandl"..., 87) = 87 write(2, "08069280:trace:seh:EXC_CallHandl"..., 54) = 54 - --- SIGSEGV (Speicherzugriffsfehler) --- write(2, "08069280:trace:seh:EXC_RtlRaiseE"..., 63) = 63 rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [], 8) = 0 write(5, "F\0\0\0\0\0\34\1<\0336@\1\0\0\0\304\357\17@\0\0\0\0\0\0"..., 64) = 64 read(6, "F\0\0\0\0\0\34\1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 wine debug log: 08069280:trace:win32:_LeaveSysLevel (0x40753a74, level 2): thread 0x8069280 (fs 008f, pid 24063) count after 0 08069280:Ret user32.CreateWindowExW() retval=00000138 ret=306cc216 08069280:RET mso97.486: _MsoCreateMonitorWindow@0() retval = 00000000 ret=3000162f 08069280:trace:heap:HeapFree (40360000,00000002,403a4a80): returning TRUE 08069280:Call kernel32.GetVersion() ret=30001984 08069280:Ret kernel32.GetVersion() retval=05650004 ret=30001984 08069280:Call kernel32.GetVersionExA(405c686c) ret=300019b5 08069280:Ret kernel32.GetVersionExA() retval=00000001 ret=300019b5 08069280:Call kernel32.GlobalMemoryStatus(405c6900) ret=300019e2 08069280:Ret kernel32.GlobalMemoryStatus() retval=405c6900 ret=300019e2 08069280:CALL mso97.394: _MsoFCreateIPref@28(<unknown, check return>08069280:trace:heap:HeapAlloc (40360000,00000002,00000040): returning 403a4b98 ) ret=30011010 08069280:Call kernel32.VirtualAlloc(00000000,0000fffc,00002000,00000001) ret=3070b360 08069280:trace:virtual:VirtualAlloc 00000000 0000fffc 2000 00000001 View: 40e90000 - 40e9ffff (valloc) 40e90000 - 40e9ffff ----- 08069280:Ret kernel32.VirtualAlloc() retval=40e90000 ret=3070b360 08069280:Call kernel32.VirtualAlloc(40e90000,00001000,00001000,00000004) ret=3070b38b 08069280:trace:virtual:VirtualAlloc 40e90000 00001000 1000 00000004 08069280:trace:virtual:VIRTUAL_SetProt 40e90000-40e90fff c-rW- View: 40e90000 - 40e9ffff (valloc) 40e90000 - 40e90fff c-rW- 40e91000 - 40e9ffff ----- 08069280:Ret kernel32.VirtualAlloc() retval=40e90000 ret=3070b38b 08069280:RET mso97.394: _MsoFCreateIPref@28(30011020,00000000,08069280:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 08069280: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=400fefc4,ecx=4d535744,edx=00000000,esi=00000000,edi=00000007,ebp=405c6790,eip=400c8aca,esp=405c66cc,eflags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c8aca,params={0,4d535744}} ) 08069280: queue_exception_event() = 0 { handle=0 } 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005b520 code=c0000005 flags=0 08069280:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005ad80 code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler handler returned 1 08069280:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 08069280: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=400fefc4,ecx=4d535744,edx=00000000,esi=00000000,edi=00000007,ebp=405c6790,eip=400c8baa,esp=405c66cc,eflags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c8baa,params={0,4d535744}} ) 08069280: queue_exception_event() = 0 { handle=0 } 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005b520 code=c0000005 flags=0 08069280:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005ad80 code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler handler returned 1 - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7KcuPpm53PRScYygRAlfZAJ91r/8CwDzWpu0TU0vB+FRP18w14QCg4sCK GBnoWm0xkKgHgFucJcNrsno= =8hel -----END PGP SIGNATURE-----

5 6

CS_PARENTDC problems
by Malte.Starostik＠t-online.de 17 Jun '01

17 Jun '01

Hi, we had some serious painting problems with dialog from an ActiveX control. All controls were invisible and only showed up sometimes on getting or losing focus. The cause is a custom class "_BitmapClass" that draws a logo and has the CS_PARENTDC class style (and no other class styles FWIW). Its WM_ERASEBKGND handler fills the complete dialog rect with that default Win95-Desktop-Background colour. According to the Win32 docs winelib behaves correctly wrt CS_PARENTDC and clipping. In this case it'd be Macromedia's fault as to how they implemented that window. However, I just found http://msdn.microsoft.com/library/techart/msdn_classy32.htm: <classy> If you use the CS_PARENTDC style for a class, each window in that class uses its parent window's DC. CS_PARENTDC is similar to CS_CLASSDC in that multiple windows share one DC. In CS_PARENTDC, however, the windows that share the DC need not belong to the same class. </classy> This contradicts the API docu at http://msdn.microsoft.com/library/psdk/winui/winclass_3b1v.htm: <api docs> CS_PARENTDC Sets the clipping rectangle of the child window to that of the parent window so that the child can draw on the parent. A window with the CS_PARENTDC style bit receives a regular device context from the system's cache of device contexts. It does not give the child the parent's device context or device context settings. Specifying CS_PARENTDC enhances an application's performance. <api docs> a little later, this is as near as the "classy" text comes to clipping: <classy> Another outcome of the CS_PARENTDC style is that child windows can draw anywhere in their parent's client area as well as drawing in their own client area. The CTL3D library, which creates 3-D effects around edit controls and list boxes, relies on this behavior. An application should not use CS_PARENTDC if it needs to adjust the mapping modes for different child windows. This will negate much of the benefit and could cause problems ensuring that each child window has the correct mapping mode set. </classy> Then I tried on Windows (2000), created a window with a child that has CS_PARENTDC set and * The paint rect of the PAINTSTRUCT as intialized by BeginPaint() equals the window's client rect - as expected. * but - surprise - so does the DC's clip box and trying to largen it to cover some or all areas of the parent fail and of course any drawing on the parent fails. * same for the DC returned by GetDC(hWnd) * only GetDCEx(hWnd, 0, DCX_PARENTCLIP) returns a DC that allows painting on the parent (no difference to a non-CS_PARENTDC window though) So, how is this painting on the parent with that style flag supposed to work? The things above make me think that it isn't possible at all or requires some additional steps. This would at least explain why the dialog described above looks busted in wine. If anyone could confirm my observations I'd come up with a patch. Thanks for any info, -Malte -- Wars don't determine who's right, only who's left.

1 0

Re: PATCH: wine-config
by Andreas Mohr 17 Jun '01

17 Jun '01

On Sun, Jun 17, 2001 at 10:26:34AM +0200, Marcus Meissner wrote: > Hi, > > to help winelib using developers, this program exports flags and directories > to /usr/bin/. > > I am not sure whether exported cflags and libs are ok. > > Hmm, we probably should also tell how to build .so libs. And specs -> .cs. > (Hmm, supply Makefile snippets?) > > Ciao, Marcus > > Changelog: > Added a 'wine-config' for winelib developers. I don't think this is a good idea. That way it'll get confused with wineconf within fractions of a second... I'd much rather use a name like wlib-config or winelib-config instead. -- Andreas Mohr

1 0

wrc error
by Bang Jun-Young 15 Jun '01

15 Jun '01

Hi, I got the following error when I tried to compile the latest CVS source: gmake[2]: Entering directory `/home/bjy/wine/dlls/user' LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc -I. -I. -I../../include -I../../include -o resources/user32.res -r resources/user32.rc resources/user32_Ca.rc:2:1: Error: syntax error gmake[2]: *** [resources/user32.res] Error 1 After downgrading some files in wrc to earier revisions, Wine was successfully compiled again. I suspect that Francois Gouget's commit made on 2001-06-07 causes this. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

2 1

Re: Hangs in half-life menus (design problem in new queue code)
by Alexandre Julliard 14 Jun '01

14 Jun '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > The new message queue design doesn't seem to allow this to be fixed... > or does it? Working on it... -- Alexandre Julliard julliard(a)winehq.com

1 0

Hangs in half-life menus (design problem in new queue code)
by Ove Kaaven 14 Jun '01

14 Jun '01

The new message queue code has caused the half-life menus to hang, since it handles timers slightly differently now. Now: - User moves mouse over a menu item - On mouseover, game starts a window timer (55ms) - On each WM_TIMER, game redraws the menu item. This takes longer than 55ms - After drawing, it checks messages. Since the 55ms timer has expired, another WM_TIMER is received, item is redrawn, any user input is ignored. Repeat Before, the hardware input queue was checked before WM_PAINT and WM_TIMER was checked, so the user could move the cursor away from the menu item (which would cancel the timer). With the new code, the hardware input queue (x11drv.MsgWaitFor...) is checked *after* timers, so the menu is now completely stuck. The new message queue design doesn't seem to allow this to be fixed... or does it?

1 0

Re: virtual memory problems with Linux 2.4.5
by Alexandre Julliard 14 Jun '01

14 Jun '01

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 14 Jun '01

14 Jun '01

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 14 Jun '01

14 Jun '01

> > 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 14 Jun '01

14 Jun '01

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 14 Jun '01

14 Jun '01

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 14 Jun '01

14 Jun '01

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@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 14 Jun '01

14 Jun '01

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 14 Jun '01

14 Jun '01

> >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 13 Jun '01

13 Jun '01

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 13 Jun '01

13 Jun '01

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

Re: virtual memory problems with Linux 2.4.5
by Alexandre Julliard 13 Jun '01

13 Jun '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > i have found a problem with Wine and the Linux 2.4.5 Kernel. > The Kernel no longer return EINVAL when offsets are not page > aligned... it simply does the mapping ignoring the lower bits of the > offset. This small patch fixes that problem. That's a glibc bug IMO. What version are you using? -- Alexandre Julliard julliard(a)winehq.com

3 5

Re: Re: virtual memory problems with Linux 2.4.5
by Mike McCormack 13 Jun '01

13 Jun '01

Hi Marcus, your patch produced a yes, BUT when i changed the offset value to 0x400, and it failed ... see new patch below. something strange is going on ... ;-) Mike >Could you please apply following check to configure.in, then do: > autoconf > rm config.cache > ./configure > >and check whether mmap64 detects as 'no' and check the output of config.log ? > >Ciao, Marcus > >Index: configure.in .. Index: configure.in =================================================================== RCS file: /home/wine/wine/configure.in,v retrieving revision 1.208 diff -u -r1.208 configure.in --- configure.in 2001/06/08 19:34:57 1.208 +++ configure.in 2001/06/13 01:28:16 @@ -538,6 +538,10 @@ ) { exit(1); } + if (-1!=mmap(0,2,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x400)){ + fprintf(stderr,"mapped at non aligned offset?\n"); + exit(2); + } close(fd); fprintf(stderr,"success!\n"); exit(0); ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

PNG or no PNG
by Igor Furlan 12 Jun '01

12 Jun '01

On Tue, 12 June 2001, Francois Gouget wrote: > Still, quite often I noticed that JPEG is not very good for screenshots: > - screenshots often have large uniform surfaces, e.g. title bar, window > background... JPEG tends to render these with weird dithering-like > patterns. > - it tends to blur fonts. I believe that's because fonts are basically > thin lines, which means high frequency, which is exactly what JPEG's > lossy compression removes. start using PNG format... it is supported by netscape 4.x, mozilla, opera... and yes, big surprise.. it is supported by redmond too Igor

1 0

Re: FYI: ControlSpy has stopped working
by Alexandre Julliard 12 Jun '01

12 Jun '01

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > Well, this simply means there will be no "official" Wine release for some time > to come. > We have two possibilities: > 1. do major changes and debug until it's ready, then commit it > 2. do major changes, commit them and wait for the patches to arrive > > Obviously 2. means there will be *no* new official release before it's fixed > in its entirety (or at least only relatively "trivial" bugs remain). Well, not exactly; the release will be made once I no longer have any bug reports to work on. So if you feel the code is not ready for release, you better send me bug reports... So far the things I'm working on are: - ScrollWindow doesn't always get exposure events - client rect must be empty for zero size window - must create X window before WM_NCCREATE - hardware events priority order is messed up - ControlSpy refresh (?? needs more details) So if you see problems that are not listed here, you have to report them or they won't get fixed before the release. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Make ChooseFontW use ChooseFontA
by Alexandre Julliard 12 Jun '01

12 Jun '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > ChooseFontW was not returning the iPointSize member, and possibly > others. This patch rewrites ChooseFontW to convert all its inputs to > ASCII, call ChooseFontA, and convert the outputs back to Unicode. It would be much better to make ChooseFontA call ChooseFontW instead; converting Unicode to ASCII must be avoided as much as possible. -- Alexandre Julliard julliard(a)winehq.com

2 1

OT: BSD License ?
by Bob 12 Jun '01

12 Jun '01

If Microsoft picked up some of the code in Wine , wouldn't they need to include the copyright , permissions notice, and the authors list? It looks like the license isn't clear as to where the Copyright needs to be displayed? Could anyone clear this up? Daniel Walker

3 4

Missing functionality in mmaux
by Florian Bauer 12 Jun '01

12 Jun '01

Hi, I tried to run Naturally Speaking, a speech recognition software under wine without a real windows installation. It installs just fine, but when I try to run it, it tries to adapt the audio settings. That fails, and I get the following fixme's from wine: fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000007) fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000008) I looked at the sources, and it seems that this is due to missing case clauses in the function MIX_GetLineInfo in mixer.c . Unfortunately, I don't know enough about C programming and the Windows and OSS API's involved to add the missing parts myself. Is it likely that this will be fixed soon? I would love to use NatSpeak under linux, because then I could delete my Windows 98 Partition... Anyway, keep up the good work regards Florian

4 3

Re:Missing functionality in mmaux
by Eric Pouech 12 Jun '01

12 Jun '01

> It installs just fine, but when I try to run it, it tries to adapt the audio > settings. That fails, and I get the following fixme's from wine: > > fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000007) > fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000008) it just misses the wavein component types as a quick fix, you can try to duplicate the case MIXERLINE_COMPONENTTYPE_MIC with MIXERLINE_COMPONENTTYPE_WAVEIN, but I'm not sure it'll fix all your issues, and let the program fully run. I'll have a closer look at it this week-end, if I have some time A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel June 2001