December 2003 - Wine-Devel - list.winehq.org

Re: Processor-Type and -Level

by Olaf Leidinger

Hello! Am Mon, 2003-12-01 um 21.02 schrieb Roderick Colenbrander: > Hi, > > The problem seems to be a bug in the cpu code. You had almost found it > yourself. If you had scrolled a few more lines down you would have seen that > we are already using /proc/cpuinfo. I think that bug is in the following > piece of code. When the cpu is a p2/p3/p4/p-m/ppro we set wProcessorLevel to > 5 while it needs to be 6: Yes, some minutes later I scrolled down ;-) This is the bug, I agree with you ! Will anybody of you commit the fix? Ciao, Olaf Leidinger

Dec. 1, 2003

Re: Processor-Type and -Level

by Roderick Colenbrander

Hi, The problem seems to be a bug in the cpu code. You had almost found it yourself. If you had scrolled a few more lines down you would have seen that we are already using /proc/cpuinfo. I think that bug is in the following piece of code. When the cpu is a p2/p3/p4/p-m/ppro we set wProcessorLevel to 5 while it needs to be 6: .... case 4: cachedsi.dwProcessorType = PROCESSOR_INTEL_486; cachedsi.wProcessorLevel= 4; break; case 5: case 6: /* PPro/2/3 has same info as P1 */ cachedsi.dwProcessorType = PROCESSOR_INTEL_PENTIUM; cachedsi.wProcessorLevel= 5; break; .... So I think you just need to change the switch statement to fix the problem. Roderick On Monday 01 December 2003 20:22, Olaf Leidinger wrote: > Hello! > > Once I tried to install the win32 version of gimp-1.3.xx-i686 using wine > and the installer refused to install because gimp was only compiled for > newer processors. The author told me, that he uses the GetSystemInfo > function to get the data he needs. > > Running a modified MS-example on wine I get this result: > > Hardware information: > OEM ID: 0 > Number of processors: 1 > Page size: 4096 > Processor type: 586 > Processor Level: 5 > Processor Revision: 0 > Minimum application address: 10000 > Maximum application address: 7fffffff > Active processor mask: 1 > > And the same on Win2k I get this output: > > Hardware information: > OEM ID: 0 > Number of processors: 1 > Page size: 4096 > Processor type: 586 > Processor Level: 6 > Processor Revision: 2560 > Minimum application address: 10000 > Maximum application address: 7ffeffff > Active processor mask: 1 > > Note - I am using an athlon-xp. > > /********** some source ***********/ > #include <windows.h> > #include <stdio.h> > > int main() > { > SYSTEM_INFO siSysInfo; > > // Copy the hardware information to the SYSTEM_INFO structure. > > GetSystemInfo(&siSysInfo); > > // Display the contents of the SYSTEM_INFO structure. > > printf("Hardware information: \n"); > printf(" OEM ID: %u\n", siSysInfo.dwOemId); > printf(" Number of processors: %u\n", > siSysInfo.dwNumberOfProcessors); > printf(" Page size: %u\n", siSysInfo.dwPageSize); > printf(" Processor type: %u\n", siSysInfo.dwProcessorType); > printf(" Processor Level: %u\n", siSysInfo.wProcessorLevel); > printf(" Processor Revision: %u\n", siSysInfo.wProcessorRevision); > printf(" Minimum application address: %lx\n", > siSysInfo.lpMinimumApplicationAddress); > printf(" Maximum application address: %lx\n", > siSysInfo.lpMaximumApplicationAddress); > printf(" Active processor mask: %u\n", > siSysInfo.dwActiveProcessorMask); > > return 1; > } > > /********** end of some source ***********/ > > To bring a long story to an end: > I had a look at cpu.c from dll/kernel directory and I found this part: > [line 251] > /* FIXME: the two entries below should be computed somehow... */ > cachedsi.lpMinimumApplicationAddress = (void *)0x00010000; > cachedsi.lpMaximumApplicationAddress = (void *)0x7FFFFFFF; > cachedsi.dwActiveProcessorMask = 1; > cachedsi.dwNumberOfProcessors = 1; > cachedsi.dwProcessorType = PROCESSOR_INTEL_PENTIUM; > cachedsi.dwAllocationGranularity = 0x10000; > cachedsi.wProcessorLevel = 5; /* 586 */ > cachedsi.wProcessorRevision = 0; > > So the corresponding values are compiled in. > > Either we change wProcessorLevel to 6 or get it from the running system. > I'd prefer the later ;-) > > When I have some free time I could -perhaps- try to fix it but I've > never changed something in the wine source. Does anybody have any > proposals of how to change it in an acceptable manner? > > I know that all the information I need can be read from /proc/cpuinfo - > but perhaps there is an easier way then reading it from there as I don't > know if it is still there in 2.6. > > Ciao, > > Olaf Leidinger

Dec. 1, 2003

Re: Processor-Type and -Level

by Marcus Meissner

On Mon, Dec 01, 2003 at 08:22:49PM +0100, Olaf Leidinger wrote: > Hello! > > Once I tried to install the win32 version of gimp-1.3.xx-i686 using wine > and the installer refused to install because gimp was only compiled for > newer processors. The author told me, that he uses the GetSystemInfo > function to get the data he needs. > > Running a modified MS-example on wine I get this result: > > Hardware information: > OEM ID: 0 > Number of processors: 1 > Page size: 4096 > Processor type: 586 > Processor Level: 5 > Processor Revision: 0 > Minimum application address: 10000 > Maximum application address: 7fffffff > Active processor mask: 1 > > > /********** end of some source ***********/ > > To bring a long story to an end: > I had a look at cpu.c from dll/kernel directory and I found this part: > [line 251] > /* FIXME: the two entries below should be computed somehow... */ > cachedsi.lpMinimumApplicationAddress = (void *)0x00010000; > cachedsi.lpMaximumApplicationAddress = (void *)0x7FFFFFFF; > cachedsi.dwActiveProcessorMask = 1; > cachedsi.dwNumberOfProcessors = 1; > cachedsi.dwProcessorType = PROCESSOR_INTEL_PENTIUM; > cachedsi.dwAllocationGranularity = 0x10000; > cachedsi.wProcessorLevel = 5; /* 586 */ > cachedsi.wProcessorRevision = 0; > > So the corresponding values are compiled in. > Either we change wProcessorLevel to 6 or get it from the running system. > I'd prefer the later ;-) > > When I have some free time I could -perhaps- try to fix it but I've > never changed something in the wine source. Does anybody have any > proposals of how to change it in an acceptable manner? No, if you read further down they are adjusted on Linux depending on /proc/cpuinfo. However, on i686 it does not change the processor level. Ciao, Marcus

Dec. 1, 2003

Re: Question about libwine_unicode functions and others in WINE

by Eric Pouech

Steven Edwards wrote: > Hello, > We are looking at porting more code from WINE to ReactOS and I am > having trouble understanding the need for libwine_unicode as a shared > library. Some of the functions that it exports such as CompareString > are implemented in ntdll as RtlCompareString and then also used in > shlwapi as per a recent patch. Wouldnt it better to import the function > from ntdll and hide libwine_unicode or make the parts that we need to > share a static library? In ReactOS we have created NT compatible NLS > files. Could WINE do this also and dump libwine_nicode? We won't drop libwine_unicode (because we use it other pure unix programs, so using only ntdll isn't a solution). However, as the process of separating ntdll and kernel32 isn't over yet, NLS functions haven't looked on so far. So, removing wine_unicode from kernel32 and using only ntdll's exports could be a target. But, this isn't obvious and may require some tweaking (especially at process startup time). > Also I was looking at the HeapAlloc stuff in WINE and code we have > ported from ReactOS such as the FormatMessage function in kernel32. > Doesnt kernel32 HeapAlloc and friends map on top of ntdll RtlHelpAlloc? > Can we submit patches to WINE so that everything just calls > RtlHeapAlloc so we dont have to change the sources? That would be doable yes (at least in kernel32). In other DLLs, it's more arguable, especially if we want to test them on non NT systems. A+ -- Eric Pouech

Dec. 1, 2003

Processor-Type and -Level

by Olaf Leidinger

Hello! Once I tried to install the win32 version of gimp-1.3.xx-i686 using wine and the installer refused to install because gimp was only compiled for newer processors. The author told me, that he uses the GetSystemInfo function to get the data he needs. Running a modified MS-example on wine I get this result: Hardware information: OEM ID: 0 Number of processors: 1 Page size: 4096 Processor type: 586 Processor Level: 5 Processor Revision: 0 Minimum application address: 10000 Maximum application address: 7fffffff Active processor mask: 1 And the same on Win2k I get this output: Hardware information: OEM ID: 0 Number of processors: 1 Page size: 4096 Processor type: 586 Processor Level: 6 Processor Revision: 2560 Minimum application address: 10000 Maximum application address: 7ffeffff Active processor mask: 1 Note - I am using an athlon-xp. /********** some source ***********/ #include <windows.h> #include <stdio.h> int main() { SYSTEM_INFO siSysInfo; // Copy the hardware information to the SYSTEM_INFO structure. GetSystemInfo(&siSysInfo); // Display the contents of the SYSTEM_INFO structure. printf("Hardware information: \n"); printf(" OEM ID: %u\n", siSysInfo.dwOemId); printf(" Number of processors: %u\n", siSysInfo.dwNumberOfProcessors); printf(" Page size: %u\n", siSysInfo.dwPageSize); printf(" Processor type: %u\n", siSysInfo.dwProcessorType); printf(" Processor Level: %u\n", siSysInfo.wProcessorLevel); printf(" Processor Revision: %u\n", siSysInfo.wProcessorRevision); printf(" Minimum application address: %lx\n", siSysInfo.lpMinimumApplicationAddress); printf(" Maximum application address: %lx\n", siSysInfo.lpMaximumApplicationAddress); printf(" Active processor mask: %u\n", siSysInfo.dwActiveProcessorMask); return 1; } /********** end of some source ***********/ To bring a long story to an end: I had a look at cpu.c from dll/kernel directory and I found this part: [line 251] /* FIXME: the two entries below should be computed somehow... */ cachedsi.lpMinimumApplicationAddress = (void *)0x00010000; cachedsi.lpMaximumApplicationAddress = (void *)0x7FFFFFFF; cachedsi.dwActiveProcessorMask = 1; cachedsi.dwNumberOfProcessors = 1; cachedsi.dwProcessorType = PROCESSOR_INTEL_PENTIUM; cachedsi.dwAllocationGranularity = 0x10000; cachedsi.wProcessorLevel = 5; /* 586 */ cachedsi.wProcessorRevision = 0; So the corresponding values are compiled in. Either we change wProcessorLevel to 6 or get it from the running system. I'd prefer the later ;-) When I have some free time I could -perhaps- try to fix it but I've never changed something in the wine source. Does anybody have any proposals of how to change it in an acceptable manner? I know that all the information I need can be read from /proc/cpuinfo - but perhaps there is an easier way then reading it from there as I don't know if it is still there in 2.6. Ciao, Olaf Leidinger

Dec. 1, 2003

RE: Supported Applications List - Screenshots

by Jeremy Newman

On Sun, 2003-11-30 at 01:51, Tom wrote: > I would send them to wine-patches under WineHQ: > Then if Jer wants to pick them up and put them in the que they would be > there.. > Is this correct? Yes, that is correct. Use the current screenshots section as a guide for how I prefer the screenshots to be done. -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

Dec. 1, 2003

Re: cvs access && updating news items

by Jeremy Newman

On Fri, 2003-11-28 at 17:59, Brian Vincent (C) wrote: > If no one objects I'd like to post more stuff to the front > page news section. In some ways it will repeat items that > will be covered in more detail in each WWN issue. The idea > is to keep more current with Wine-related press releases > and maybe generate more traffic/interest in Wine. News items > would definitely include commercial products. Please, feel free to post new items. I never had time, and I'm just not a very creative news author. I'll stick to the backend code and HTML. -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

Dec. 1, 2003

Re: WineX 3.2

by Jeremy Newman

I'd be happy to add you to the links. I want to give someone the chance to comment on this before I do. Any objections? On Sun, 2003-11-30 at 16:14, Ivan Leo Murray-Smith wrote: > As you probably already know, Marek Lipovcan and I build RPMs of WineX for Linux > Red Hat, Suse, Mandrake and compatible distros, and host them (With a bz2 of the > source) on www003.portalis.it/115/ > I think this is a fact that could interest a lot of people, would it be OK for me > to add a link to the site in the Commercial Wine Versions section under the link > to Transgaming in the wine binary download page? > BTW I've just published the MDK and Suse RPM of winex 3.2, but only geeks > read this list, so if you're going to try winex it you'll probably compile from > source > anyway. -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

Dec. 1, 2003

Re: X Error of failed request

by Erik Enge

Mike Hearn <mike(a)theoretic.com> writes: > See if you can get a +font trace when synchronous mode is switched on > (see the config file), and a backtrace. That might help figure out > what the problem is. Have you had a chance to look at the backtrace? Thanks, Erik.

Dec. 1, 2003

Re: FontDlg sample text

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote: > How do I put Unicode there? I need to put in characters that, by > definition, are taken from very varied parts of the unicode charset table. > If that problem is *easilly* solveable, I'll glady do the change. Have a look at one of unicode only locale .nls files from dlls/kernel, for instance dlls/kernel/nls/guj.nls. That should be quite straightforward. > Note, > however, that this is no reason not to commit the patch I sent, as the > scheme currently used has been in place since February. All the current > patch did was enhance the sample text for more charsets. Sure. I agree. -- Dmitry.

Dec. 1, 2003