- Wine-Devel - list.winehq.org

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 12, 2001

June 12, 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

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

June 12, 2001

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 June 12, 2001

June 12, 2001

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(a)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 June 12, 2001

June 12, 2001

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 June 12, 2001

June 12, 2001

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 June 12, 2001

June 12, 2001

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 June 12, 2001

June 12, 2001

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 June 12, 2001

June 12, 2001

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 June 12, 2001

June 12, 2001

> 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