Hi,
here are my findings about compiling and using wine on an "early 2009" Mac Mini with NVidia graphics, without Fink or Macports. I hope it'll help other people. The good news first: + compilation essentially works. + Pharaoh (1.2 update, nocd) works in desktop mode. - old (16bit?) apps cause winevdm to crash, e.g. PharaohDemo's setup.exe Details follow. Bugs will be submitted separately.
The setup is: + "early 2009" NVidia 9400 Mac Mini with OS 10.5.6 + XCode from DVD install disk. I did not install the whole thing, just a few packages, e.g. + gcc4.2 + DeveloperToolsCLI, + DevSDK, X11SDK, OpenGLSDK + CoreAudioSDK etc., without e.g. - gcc4.0 - MacOSX10.5 - DeveloperTools (actually, this one contains the Xcode.app but now complains that it cannot install into a non-empty directory - any ideas?) + Mac OS 10.5.7 update (includes X11 manpages) + XQuartz' X11.2.33.2
Not installing gcc-4.0, I changed the stale symlink /usr/bin/gcc->gcc-4.0 to gcc-4.2. I used neither Fink nor MacPorts. I found /usr/bin/ in MacOS full of OSS already. Like a Debian (hence Ubuntu) system, every tool has its manpage!
Fink was not used because I was told it's obsolete. Macports was nuked after it started to configure and compile software as root, which violates my software acceptance policy. Another time I'll try pre-compiled binaries from Mike Kronenberg to see if that makes a difference, but as I plan to do as much regression testing as on Linux, I'll stick with git and compiling myself.
---------------- Compiling
checking png.h usability... no checking png.h presence... no checking for png.h... no png is in /usr/X11/include plus /usr/X11/lib/libpng*, not /usr/include Alas, configure tests for png long before testing for X. Will submit bug.
---- checking mach-o/dyld_images.h usability... no checking mach-o/dyld_images.h presence... yes configure: WARNING: mach-o/dyld_images.h: present but cannot be compiled configure: WARNING: mach-o/dyld_images.h: check for missing prerequisite headers? configure: WARNING: mach-o/dyld_images.h: see the Autoconf documentation configure: WARNING: mach-o/dyld_images.h: section "Present But Cannot Be Compiled" configure: WARNING: mach-o/dyld_images.h: proceeding with the preprocessor's result configure: WARNING: mach-o/dyld_images.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel@winehq.org ## configure: WARNING: ## ------------------------------------ ##
Ruben Hillewaere already mentioned this in http://www.winehq.org/pipermail/wine-devel/2009-May/075287.html
In file included from conftest.c:67: /usr/include/mach-o/dyld_images.h:65: error: expected specifier-qualifier-list before 'bool' Perhaps a mising bool typedef?
---- configure --verbose summary configure: libhal 32-bit development files not found, no dynamic device support. configure: libgnutls 32-bit development files not found, no schannel support. configure: libsane 32-bit development files not found, scanners won't be supported. configure: libgphoto2 32-bit development files not found, digital cameras won't be supported. configure: liblcms 32-bit development files not found, Color Management won't be supported. configure: libcapi20 32-bit development files not found, ISDN won't be supported. configure: WARNING: libjpeg 32-bit development files not found, JPEG won't be supported. configure: WARNING: libpng 32-bit development files not found, PNG won't be supported. configure: Finished. Do 'make depend && make' to compile Wine.
Pretty much what I know from Ubuntu (except for jpeg+hal), where I never bothered to install the lcms or sane or SSL developer packages.
---- compilation warnings In file included from opengl_ext.h:28, from opengl_ext.c:5: /usr/X11/include/GL/gl.h:1387:1: warning: "GL_GLEXT_PROTOTYPES" redefined In file included from opengl_ext.c:5: opengl_ext.h:27:1: warning: this is the location of the previous definition Looks like a bug I'll submit to the XQuartz project.
audiounit.c: In function `SynthUnit_CreateDefaultSynthUnit': audiounit.c:351: warning: `AUGraphNewNode' is deprecated (declared at /System/Library/Frameworks/AudioToolbox.framework/Headers/AUGraph.h:674) This is bug #11242
Wine build complete. ---------------- Running ./wine winecfg wine: created the configuration directory '/Users/xyz/.wine'
---- FreeType library issue resolved Wine cannot find the FreeType font library. To enable Wine to use TrueType fonts please install a version of FreeType greater than or equal to 2.0.5. http://www.freetype.org Building font metrics. This may take some time... Font metrics: 0.0% done fixme:font:LFD_InitFontInfo DBCS fonts like '-daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0' are not working correctly now. [... hundreds of messages like this ...] err:font:XFONT_BuildMetrics failed to load -misc-stheiti-medium-r-normal--100-*-100-100-p-0-ibm-cp866 Font metrics: 100.0% done [... repeated anew for every process started ...]
"dlopen() searches the following the following until it finds a compatible Mach-O file: $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH Note: There are no configuration files to control dlopen searching."
Set one of those to /usr/X11/lib, because that's where libfreetype* resides in MacOS. There's no need to turn to MacPorts. LD_LIBRARY_PATH=/usr/X11/lib ./wine notepad lets wine finds hundreds of fonts.
BTW, Macports' wrapper uses DYLD_FALLBACK_LIBRARY_PATH The ./wine wrapper itself sets DYLD_LIBRARY_PATH to its internal .so dir.
Maybe it would not be a good idea to add this directory to the official ./wine wrapper, as it could cause conflicts with Fink or Macports sets of libraries?
---- err:process:__wine_kernel_init boot event wait timed out I get this one *sometimes* on a Linux box as well...
---- no 16 bit apps? winevdm crashes with identical messages on: - Pumuckl Klabauterjagd - Minigolf 1997 (not in AppDB) - Meine Traumburg (dito) - PharaoDemo's setup.exe PharaoDemo:setup.exe "The program winevdm.exe has encountered a serious error ..." Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (1017:00000c1d). Probably a lot of installers will be affected. Is this caused by the mach-o/dyld_images.h warning from configure? Is there no 16bit support on Intel MacOS yet?
---- Pharaoh console log Copying my Linux Pharaoh (1.2 update, nocd) directory over to the Mac, I was pleased to see the title screen and the application running.
err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: "2.0 NVIDIA-1.5.44" The string probably originates from XQuartz' X11.2.33.2. The wine source code expects a space after NVIDIA. Is it actually meningful to return the Apple 1.5 major+minor to a windows program? (On Linux, the numbers are much higher, e.g. "2.1.2 NVIDIA 173.14.09" or "2.1.0 NVIDIA 97.55" -- 2 samples from Google).
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 16 vertex samplers and 16 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x32f664,0x00000000), stub! fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 well known from Linux.
fixme:wave:wodDsCreate DirectSound not implemented fixme:wave:wodDsCreate The (slower) DirectSound HEL mode will be used instead. probably ok. Pharaoh plays the music.
---- full screen mode Full-screen does not work with Pharaoh. The application exits after: err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1024x768x16 @0! (NoRes) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 800x600x16 @0! (NoRes) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 640x480x16 @0! (NoRes) The LCD's native resolution is higher than those.
Hope this helps, Jörg Höhle
On Fri, May 22, 2009 at 5:39 AM, Joerg-Cyril.Hoehle@t-systems.com wrote:
Set one of those to /usr/X11/lib, because that's where libfreetype* resides in MacOS. There's no need to turn to MacPorts. LD_LIBRARY_PATH=/usr/X11/lib ./wine notepad lets wine finds hundreds of fonts.
BTW, Macports' wrapper uses DYLD_FALLBACK_LIBRARY_PATH The ./wine wrapper itself sets DYLD_LIBRARY_PATH to its internal .so dir.
Maybe it would not be a good idea to add this directory to the official ./wine wrapper, as it could cause conflicts with Fink or Macports sets of libraries?
There is a reason you may want to roll your own freetype. I don't believe the freetype that ships with even the latest Xorg dpkg contains support for the patented bytecode stuff or subpixel rendering enabled. I could be wrong about needing to do it (perhaps I have an old version floating around), but I rolled my own freetype with it enabled and enabled the proper keys in Wine and can hardly see a difference in Safari or Wine iexplore rendering winehq.org
You should be legally covered on by virtue of being a Mac user as Apple owns a nice patent chest and also owns one part of the patent pie.
Steven Edwards wrote:
There is a reason you may want to roll your own freetype. I don't believe the freetype that ships with even the latest Xorg dpkg contains support for the patented bytecode stuff or subpixel rendering enabled. I could be wrong about needing to do it (perhaps I have an old version floating around), but I rolled my own freetype with it enabled and enabled the proper keys in Wine and can hardly see a difference in Safari or Wine iexplore rendering winehq.org
Very interesting. Indeed I forgot to mention that fonts do not look good in regular wine GUI windows using my native compile and XQuartz' FreeType. Putting two wine desktops side by side on the Mac display, a) ssh -X to a linux box (i.e. wine running on Linux, X display on the Mac) b) Mac native shows the disaster, solely running winecfg: - The Linux fonts in winecfg look sharp (1 pixel wide), while e.g. the Mac's 'W' looks bulky. Both the Tahoma sample text and the regular system text are affected. - Text needs more horizontal room (is this lack of grid-fitting?), so e.g. the copyright text in winecfg overflows into the "registered owner" input box area as it needs one more line of text to display the same words.
OTOH, Mike Kronenberg's 1.1.20 winecfg looks as good as the Linux one.
What keys in Wine do you mean precisely? My Mac has subpixel rendering disabled on my LCD, but it uses shades of grey (hinting or anti-aliasing?) for most fonts. Neither Terminal.app use hinting, nor winecfg: plain black&white. I don't have any particular registry key set in Linux.
Regards, Jörg Höhle
Hi,
On Mon, May 25, 2009 at 7:19 AM, Joerg-Cyril.Hoehle@t-systems.com wrote:
What keys in Wine do you mean precisely? My Mac has subpixel rendering disabled on my LCD, but it uses shades of grey (hinting or anti-aliasing?) for most fonts. Neither Terminal.app use hinting, nor winecfg: plain black&white. I don't have any particular registry key set in Linux.
See bug 10342 for more information. Your freetype needs to be compiled with
#define FT_CONFIG_OPTION_SUBPIXEL_RENDERING
I did not bother to check with the existing FreeType in the latest Xorg or Xcode or where ever it is, under OS X, I just assumed its not enabled and I rolled my own for other reasons anyway. To enable SubPixel support you need to change the value for HCU\Control Panel\Desktop\FontSmoothing from 0 to 1(I think) or 2. Setting the option to 1 seems to change the algorithm used, I think that's using Gray Scale hinting, there is a lot of traffic on the bug so I might have just missed where it clarifies. Setting the option to 2 (to me at least) looks best.
http://steven-edwards.kicks-ass.org/~sedwards/Safari-vs-Wine-without-Subpixe... http://steven-edwards.kicks-ass.org/~sedwards/Safari-vs-Wine-with-Subpixel.p...
-
Joerg-Cyril.Hoehle＠t-systems.com -
Steven Edwards