OSX is the reason I stopped using windows with a linux server in the other room. Re: (Score:2) by ZachPruckowski ( 918562 ) writes: Going from Linux to Mac is pretty straightforward. OS X has an X11 install (it's available on the install disk, but not installed by default), glibc, python, php, and stuff.

• Install Linux On Mac
• Mac Cosmetics Programs
• Install Linux On Mac Os

Winecfg (Wine configuration)(1,668)Initial release4 July 1993; 26 years ago ( 1993-07-04)4.0.2 (August 23, 2019; 56 days ago ( 2019-08-23))4.18 (October 18, 2019; 0 days ago ( 2019-10-18))Written in,. (development). (experimental),21 MB (compressed tar.)Available inEnglishWebsiteWine ( for Wine Is Not an ) is a that aims to allow ( and ) developed for to run on. Wine also provides a, known as Winelib, against which developers can Windows applications to help them to Unix-like systems.Wine provides its Windows which translates Windows into -compliant, recreating the of Windows systems, and providing alternative implementations of Windows, system services through wineserver and various other components (such as, the, and ). Wine is predominantly written using reverse-engineering, to avoid issues.The selection of 'Wine is Not an Emulator' as the name of the Wine Project was the result of a naming discussion in August 1993 and credited to David Niemi.

There is some confusion caused by an early FAQ using Windows Emulator and other invalid sources that appear after the Wine Project name being set. No or occurs when running a Windows under Wine. 'Emulation' would refer to of code intended for one (such as ) by software running on a different processor (such as ).While the name sometimes appears in the forms WINE and wine, the project developers have agreed to standardize on the form Wine.Wine is primarily developed for Linux and, and there are (As of November 2018 ) well-maintained packages available for both platforms.In a 2007 survey by desktoplinux.com of 38,500 Linux desktop users, 31.5% of respondents reported using Wine to run Windows applications. This plurality was larger than all programs combined, as well as larger than the 27.9% who reported not running Windows applications.

Bob Amstadt, the initial project leader, and Eric Youngdale started the Wine project in 1993 as a way to run Windows applications on. It was inspired by two ' products, the for the operating system, and the, which was an attempt to get the fully reimplemented in the public domain as an standard but rejected due to pressure from in 1996. Wine originally targeted for, but as of 2010 focuses on and versions which have become the standard on newer operating systems. The project originated in discussions on in in June 1993. Has led the project since 1994.The project has proven time-consuming and difficult for the developers, mostly because of incomplete and incorrect of the Windows API. While Microsoft extensively documents most Win32, some areas such as and have no publicly available specification from Microsoft, and Windows also includes undocumented low-level functions, undocumented behavior and obscure that Wine must duplicate precisely in order to allow some applications to work properly. Consequently, the Wine team has many function calls and file formats in such areas as.

The Wine project originally released Wine under the same as the X Window System, but owing to concern about versions of Wine not contributing their changes back to the core project, work as of March 2002 has used the LGPL for its licensing.Wine officially entered beta with version 0.9 on 25 October 2005. Version 1.0 was released on 17 June 2008, after 15 years of development. Version 1.2 was released on 16 July 2010, version 1.4 on 7 March 2012, version 1.6 on 18 July 2013.

And version 1.8 on 19 December 2015. Development versions are released roughly every two weeks.Wine-staging is a relatively independently maintained set of relatively aggressive not deemed ready by WineHQ developers for merging into the wine repository, but still considered useful by the wine-compholio fork. It mainly covers experimental functions and bug fixes. Since January 2017, patches in wine-staging begins to be actively merged into the WineHQ upstream as wine-compholio transferred the project to Alistair Leslie-Hughes, a key WineHQ developer.

Corporate sponsorship The main corporate sponsor of Wine is, which employs Julliard and many other Wine developers to work on Wine and on, CodeWeavers' supported version of Wine. CrossOver includes some application-specific tweaks not considered suitable for the WineHQ version, as well as some additional proprietary components.The involvement of for a time assisted the project, chiefly by employing Julliard and others to work on it. Corel had an interest in porting, its, to Linux (especially ). Corel later cancelled all Linux-related projects after Microsoft made major investments in Corel, stopping their Wine effort.Other corporate sponsors include, which hired CodeWeavers to fix Wine so ran well enough to be ported directly to Linux using the same binary as on Windows; Google later paid for improvements to Wine's support for.

Wine is also a regular beneficiary of Google's program. Design The goal of Wine is to implement the fully or partially that are required by programs that the users of Wine wish to run on top of a Unix-like system.Basic architecture The programming interfaces of the Microsoft Windows family of OSes consist largely of (DLLs).

These contain a huge number of wrapper sub-routines for the system calls of the kernel, the NTOS kernel-mode program (ntoskrnl.exe). A typical Windows program calls some Windows DLLs, which in turn calls user-mode gdi/user32 libraries, which in turn uses the kernel32.dll (win32 subsystem) responsible for dealing with the kernel through system calls. The system-call layer is considered private to Microsoft programmers as documentation is not publicly available, and published interfaces all rely on subsystems running on top of the kernel.

Besides these, there are a number of programming interfaces implemented as services that run as separate processes. Applications communicate with user-mode services through RPCs.Wine implements the Windows (ABI) entirely in, rather than as a. Wine mostly mirrors the hierarchy, with services normally provided by the kernel in Windows instead provided by a known as the wineserver, whose task is to implement basic Windows functionality, as well as integration with the, and translation of into native Windows exceptions. Although Wineserver implements some aspects of the, it is not possible to use native Windows drivers with it, due to Wine's underlying architecture. This prevents certain applications and games from working, for example those using StarForce copy-protection which requires to be installed.Libraries and applications Wine allows for loading both Windows DLLs and Unix for its Windows programs. Its builtin implementation of the most basic, namely, uses the shared object method because they must use functions in the host operating system as well. Higher-level libraries, such as WineD3D, are free to use the DLL format.

In many cases users can choose to load a DLL from Windows instead of the one implemented by wine. Doing so can provide functionalities not yet implemented by wine, but may also cause malfunctions if it relies on something else not present in wine.Wine tracks its state of implementation through automated done at every git commit. Graphics and gaming While most office software does not make use of complex GPU-accelerated graphics APIs, computer games do. To run these games properly, Wine would have to forward the drawing instructions to the host OS, and even translate them to something the host can understand.is a collection of Microsoft APIs for rendering, audio and input. As of 2019, Wine 4.0 contains a DirectX 12 implementation for, and DirectX 11.2 for OpenGL. Wine 4.0 also allows Wine to run Vulkan applications by handing draw commands to the host OS, or in the case of macOS, by translating them into the. XAudio As of February 2019, Wine 4.3 uses the library (and Wine 4.13 included a fix for it) to implement the audio API (and more).

XInput and Raw Input Wine, since 4.0 (2019), supports through its builtin implementations of these libraries. They are built as Unix shared objects as they need to access the controller interfaces of the underlying OS, specifically through. Direct2D Wine 4.0 supports Direct2D 1.2. Direct3D Much of Wine's DirectX effort goes into building WineD3D, a translation layer from Direct3D and API calls into. As of 2019, this component supports up to DirectX 11. As of December 12, 2016, wine is good enough to run with D3D11. Besides being used in Wine, WineD3D DLLs are also useful in the Windows Operating System itself, allowing for older graphic cards to run games using newer DirectX versions and for old DDraw-based games to render correctly.Some work is ongoing to move the Direct3D backend to Vulkan API.

Direct3D 12 support in 4.0 is provided by a 'vkd3d' subproject, and WineD3D has in 2019 been experimentally ported to use the Vulkan API.Wine, when patched, can alternatively run Direct3D 9 without translation via the a State Tracker for DX9. The Gallium3D layer allows for direct pass-through of drawing commands.

User interface. A screenshot showing how Wine can be configured to mimic different versions of Windows, going as far back as Windows 2.0 as shown.Wine is usually invoked from the command-line interpreter: wine program.exe.

Winecfg There is the utility winecfg that starts a graphical user interface with controls for adjusting basic options. It is a GUI configuration utility included with Wine.

Winecfg makes configuring Wine easier by making it unnecessary to edit the registry directly, although, if needed, this can be done with the included registry editor (similar to Windows ).Third-party applications. Some applications require more tweaking than simply installing the application in order to work properly, such as manually configuring Wine to use certain. The Wine project does not integrate such into the Wine codebase, instead preferring to focus solely on improving Wine's implementation of the. While this approach focuses Wine development on long-term compatibility, it makes it difficult for users to run applications that require workarounds. Consequently, many third-party applications have been created to ease the use of those applications that don't work within Wine itself. The Wine wiki maintains a page of current and obsolete third-party applications.

Winetricks is a to install some basic components (typically Microsoft DLLs and fonts) and tweak settings required for some applications to run correctly under Wine. It can fully automate the install of a number of apps and games, including applying any needed workarounds. Winetricks has a. The Wine project will accept bug reports for users of Winetricks, unlike most third-party applications. It is maintained by Wine developer Austin English. is an open GUI for advanced setup of Wine.

Wine-Doors is an application-management tool for the desktop which adds functionality to Wine. Wine-Doors is an alternative to WineTools which aims to improve upon WineTools' features and extend on the original idea with a more modern design approach. is a utility to install all versions of Internet Explorer, including versions 4 to 6 and version 7 (in beta). Wineskin is a utility to manage Wine engine versions and create wrappers for. is an application to ease the installation of Windows applications (primarily games). There is also a corresponding Macintosh version called. is an open source application to easily install Windows games on Linux.

is a proprietary Wine GUI configuration manager that runs winelib applications. It also supports installation of third-party utilities, installation of applications and games, and the ability to use custom configurations. Bordeaux currently runs on Linux, FreeBSD, PC-BSD, Solaris, OpenSolaris, and macOS computers.Functionality The developers of the portions of Wine have continued to implement new features such as to increase game support. Wine can also use native DLLs directly, thus increasing functionality, but then a license for Windows is needed unless the DLLs were distributed with the application itself.Wine also includes its own open-source implementations of several Windows programs, such as, and.(AppDB) is a community-maintained on-line database about which Windows programs works with Wine and how well they work.Backward compatibility Wine ensures good with legacy Windows applications, including those written for.

Wine can mimic different Windows versions required for some programs, going as far back as Windows version 2.0. However, Windows 1.x and Windows 2.x support was removed from Wine development version 1.3.12. If DOSBox is installed on the system (see below on ), Wine development version 1.3.12 and later nevertheless show the 'Windows 2.0' option for the Windows version to mimic, but Wine still won't run most Windows 2.0 programs because MS-DOS and Windows functions are not currently integrated.Backward compatibility in Wine is superior to that of Windows, as newer versions of Windows can force users to upgrade legacy Windows applications. In many cases, Wine can offer better legacy support than newer versions of Windows with 'Compatibility Mode'.

Wine can run Windows programs on a 64-bit operating system, which uses an (64-bit) CPU, a functionality not found in 64-bit versions of Microsoft Windows. Allows 16-bit Windows applications to run on 64-bit versions of Windows.Wine partially supports Windows, and the user can choose which backend to use to manage the console (choices include raw streams, and ). When using the raw streams or curses backends, Windows applications will run in a Unix terminal.64-bit applications Preliminary support for Windows applications was added to Wine 1.1.10, in December 2008.

As of April 2019, the support is considered stable. The two versions of wine are built separately, and as a result only building wine64 produces an environment only capable of running x86-64 applications.As of April 2019, Wine has stable support for a build, which allows both 32-bit and 64-bit Windows applications to run inside the same Wine instance.

To perform such a build, one must first build the 64-bit version, and then build the 32-bit version referencing the 64-bit version. Just like Microsoft's WoW64, the 32-bit build process will add parts necessary for handling 32-bit programs to the 64-bit build.

This functionality is seen from at least 2010. MS-DOS Early versions of Microsoft Windows run on top of and Windows programs may depend on MS-DOS programs being runnable. Wine does not have good support for MS-DOS, but starting with development version 1.3.12, Wine tries running MS-DOS programs in if DOSBox is available on the system.

However, due to a bug, current versions of Wine incorrectly identify Windows 1.x and Windows 2.x programs as MS-DOS programs, attempting to run them in DOSBox (which does not work). Winelib Wine provides Winelib, which allows its shared-object implementations of the Windows API to be used as actual libraries for a Unix program.

This allows for Windows code to be built into native Unix executables. Since October 2010, Winelib also works on the platform. Non-x86 architectures Support for Solaris was dropped in version 1.5.26.ARM, Windows CE, and Windows RT Wine provides some support for (as well as ARM64/AArch64) processors and the Windows flavors that run on it.

As of April 2019, Wine can run ARM/Win32 applications intended for unlocked devices (but not Windows RT programs). Support (either x86 or ARM) is missing, but an unofficial, proof-of-concept version called WineCE allows for some support. Wine for Android. WINE running on AndroidOn 3 February 2013 at the FOSDEM talk in Brussels, demonstrated an early demo of Wine running on Google's operating system.Experimental builds of WINE for Android (x86 and ARM) were released in late 2017. It has been routinely updated by the official developers ever since. The default builds does not implement cross-architecture emulation via, and as a result ARM versions will only run ARM applications that use the Win32 API.

Microsoft applications Wine, by default, uses specialized Windows builds of and to substitute for Microsoft's. Wine has built-in implementations of. It is possible to download and run Microsoft's installers for those programs through winetricks or manually.Wine is not known to have good support for most versions of Internet Explorer. Of all the reasonably recent versions, Internet Explorer 8 for Windows XP is the only version that reports a usable rating on Wine's AppDB, out-of-the-box.

Winetricks offer auto-installation for Internet Explorer 6 through 8, so these versions can be reasonably expected to work with its built-in workarounds.An alternative for installing Internet Explorer directly is to use the now-defunct. It is not compatible with the latest versions of Wine, and the development of IEs4Linux is inactive.Other versions of Wine The core Wine development aims at a correct implementation of the Windows API as a whole and has sometimes lagged in some areas of compatibility with certain applications. Direct3D, for example, remained unimplemented until 1998, although newer releases have had an increasingly complete implementation. CrossOver. Main article:CodeWeavers markets CrossOver specifically for running and other major Windows applications, including some games. CodeWeavers employs to work on Wine and contributes most of its code to the Wine project under the LGPL.

CodeWeavers also released a new version called CrossOver Mac for Intel-based computers on 10 January 2007.CrossOver now includes the functionality of both the CrossOver Games and CrossOver Pro lines therefore CrossOver Games and CrossOver Pro are no longer available as single products.CrossOver Games was optimized for running Windows. Unlike CrossOver, it didn't focus on providing the most stable version of Wine. Instead, experimental features are provided to support newer games.

Cedega / WineX. Main article:Findev has also produced Cider, a library for Macintoshes. Instead of being an end-user product, Cider (like Winelib) is a allowing developers to adapt their games to run natively on without any changes in source code.WINE@Etersoft The company Etersoft has been developing a proprietary version of Wine since 2006. WINE@Etersoft supports popular Russian applications (for example, 1C:Enterprise by ). For 2010, Etersoft was going to issue WINE@Etersoft CAD, which is oriented towards such as, and.Darwine. Main article:Darwine is a port of the Wine libraries to and to macOS for both the PowerPC and Intel x86 architectures. All patches for x86 version were merged back into the main branch of Wine in 2009.

Development on the PPC version was abandoned. Mike Kronenberg previously created the WineHelper for Darwine to add a GUI and macOS style app for interacting with Wine, which was later replaced by WineBottler.

Darwine now provides macOS compatible packages compiled from the Wine repository. Pipelight The Pipelight Team has produced a custom version of Wine (wine-compholio) that acts as a for Windows NPAPI plugins within Linux browsers. This tool permits Linux users to run, the Microsoft equivalent of, and the, along with a variety of other NPAPI plugins. The project provides an extensive set of patches against the upstream Wine project, some of which occasionally get approved and added to upstream Wine. Pipelight is largely obsolete, as modern browsers no longer support NPAPI plugins and Silverlight has been deprecated by Microsoft. Main article:On 21 August 2018, announced a new variation of Wine, named Proton, designed to integrate with the Linux version of the company's software (including Steam installations built into their Linux-based operating system and computers).

Valve's goal for Proton is to enable Steam users on Linux to play games which lack a native Linux port (particularly back-catalog games), and ultimately, through integration with Steam as well as improvements to game support relative to mainline Wine, to give users 'the same simple plug-and-play experience' that they would get if they were playing the game natively on Linux. Proton entered public beta immediately upon being announced.Valve had already been collaborating with CodeWeavers since 2016 to develop improvements to Wine's gaming performance, some of which have already been merged to the upstream Wine project.

Some of the specific improvements incorporated into Proton include -based Direct3D 9, 10, 11, and 12 implementations via, and multi-threaded performance improvements via esync, improved handling of fullscreen games, and better automatic game controller hardware support.Proton is fully open-source and available via GitHub. Other projects using Wine source code Other projects using Wine source code include:., a project to write an operating system compatible with versions 5.x and up (which includes and its successors) down to the level. ReactOS uses Wine source code considerably, but because of architectural differences, ReactOS code (such as DLLs written specifically for it, like ntdll, user32, kernel32, gdi32, and advapi) is not generally reused in Wine. In July 2009, Aleksey Bragin, the ReactOS project lead, started a new ReactOS branch called, and it was officially announced in January 2010. Arwinss is an alternative implementation of the core Win32 components, and uses mostly unchanged versions of Wine's user32.dll and gdi32.dll. WineBottler, a wrapper around Wine in the form of a normal Mac Application. Manages multiple wine configurations for different programs in the form of 'bottles.'

. Wineskin, an open source Wine GUI configuration manager for. Wineskin creates a wrapper around Wine in the form of a normal Mac Application. The wrapper can also be used to make a distributable 'port' of software., a project to run Win32 binaries on or convert them to OS/2 native format. 23 August 2019. Retrieved 24 August 2019.

18 October 2019. Retrieved 18 October 2019. ^. Retrieved 31 October 2018.

^. From the original on 10 January 2017. Retrieved 10 January 2017. Retrieved 10 January 2017. Retrieved 29 June 2008. Retrieved 15 April 2017. Retrieved 16 June 2012.

Retrieved 15 April 2017. Retrieved 15 April 2017. Retrieved 15 April 2017. Mckenzie, James (26 December 2009). WineHQ Forums. (PDF). Retrieved 15 January 2019.

Old meaning of the name even used until 1997. Wine Wiki FAQ. Official Wine Wiki. Archived from on 21 June 2011. Retrieved 13 July 2008. Retrieved 31 October 2018. Retrieved 31 October 2018.

21 August 2007. Archived from on 24 May 2012. Retrieved 8 October 2007. Vaughan-Nichols, Steven J. (22 August 2007). 2007 Desktop Linux Survey results. Archived from on 11 February 2010.

Amstadt, Bob (29 September 1993).:. Retrieved 13 July 2008. Computergram International. Archived from on 8 July 2012. Retrieved 13 July 2008.

Byron A Jeff (25 August 1993).:. Retrieved 21 September 2007.

Install Linux On Mac

Loli-Queru, Eugenia (29 October 2001). OSnews (Interview).

Retrieved 30 June 2008. Usually we start from whatever documentation is available, implement a first version of the function, and then as we find problems with applications that call this function we fix the behavior until it is what the application expects, which is usually quite far from what the documentation states. White, Jeremy (6 February 2002). Retrieved 27 April 2010. Alexandre Julliard (18 February 2002).

Retrieved 27 April 2010. 25 October 2005. Retrieved 9 December 2010. 17 June 2008. Retrieved 1 September 2008.

Julliard, Alexandre (16 July 2010). Retrieved 7 March 2012. 18 July 2013. Retrieved 18 July 2013. 19 December 2015. Retrieved 19 December 2015. Retrieved 22 April 2019.

White, Jeremy (27 January 2011). Retrieved 28 January 2011. Vaughan-Nichols, Steven J. (25 February 2002). Retrieved 3 January 2009. Kegel, Dan (14 February 2008). Wine-devel (Mailing list).

Retrieved 3 January 2009. Retrieved 7 September 2008. ^. Retrieved 22 April 2019. See the ' article. Retrieved 22 April 2019. ^.

25 February 2019. 12 December 2016. Dossena, Federico. Federico Dossena. Retrieved 22 April 2019. Christoph Bumiller. There are a couple of differences to d3d1x:.

it's written in C instead of C and not relying on horrific multiple inheritance with. So far I've tried Skyrim, Civilization 5, Anno 1404 and StarCraft 2 on the nvc0 and r600g drivers, which work pretty well, at up to x2 the fps I get with wined3d (NOTE: no thorough benchmarking done yet).

Retrieved 29 April 2017. Nick Congleton (26 October 2016). Retrieved 29 April 2017. Official Wine Wiki. Retrieved 3 January 2009. Retrieved 11 January 2015.

VitalyLipatov (30 March 2011). Retrieved 2 August 2011. Official Wine Wiki. Retrieved 3 January 2009. Retrieved 27 April 2010.

Archived from on 20 August 2008. Retrieved 27 April 2010. OpenIndiana-announce mailing list.

Retrieved 1 October 2010. Bordeaux group site.

Archived from on 7 October 2010. Retrieved 1 October 2010. Official Wine Wiki. Archived from on 1 January 2009.

Retrieved 3 January 2009. 12 April 2016. Retrieved 29 April 2017. (PDF). Retrieved 9 December 2010.

Strohmeyer, Robert (6 April 2007). Retrieved 9 December 2010.

Andre Da Costa (20 April 2016). Retrieved 9 April 2019. Retrieved 22 August 2015. Savill, John (11 February 2002). Retrieved 9 December 2010. Wine User Guide. Retrieved 22 May 2010.

Lankhorst, Maarten (5 December 2008). Wine-devel (Mailing list).

Retrieved 15 December 2008. ^. Retrieved 23 April 2019. Official Wine Wiki. Archived from on 25 April 2010.

Retrieved 20 April 2010. Retrieved 15 February 2013. Retrieved 15 February 2013. Retrieved 15 October 2010. The Official Wine Wiki. Retrieved 22 April 2019. 3 February 2013.

Retrieved 23 April 2019. WineHQ AppDB. Retrieved 23 April 2019.

22 June 2012. Vincent, Brian (3 February 2004).

Wine Weekly News (208). Archived from on 31 December 2006. Retrieved 3 January 2009. Archived from on 26 December 2008. Retrieved 3 January 2009. Retrieved 3 January 2009. Archived from on 19 August 2012.

Retrieved 9 March 2012. 6 January 1990. Retrieved 27 April 2010. Archived from on 10 January 2011. Retrieved 2 January 2011. (in Russian).

21 April 2010. Retrieved 27 April 2010. ^.

Retrieved 20 March 2013. Archived from on 22 August 2013.

Retrieved 4 April 2014. Retrieved 4 April 2014.

Smith, Jerry (2 July 2015). Microsoft Edge Blog. Retrieved 10 February 2019. ^.

Valve Software. Retrieved 22 August 2018. Retrieved 22 August 2018. Retrieved 22 August 2018.

Retrieved 6 October 2019. Retrieved 22 August 2018. Retrieved 22 August 2018. Archived from on 13 November 2008. Retrieved 25 May 2009. 17 July 2009.

Retrieved 27 April 2010. 20 February 2010. Retrieved 27 April 2010. Retrieved 27 April 2010. Retrieved 7 November 2012. Matt Moen (26 January 2005). Retrieved 23 October 2009.

Mac Cosmetics Programs

Wine Wiki FAQ. Official Wine Wiki. 7 August 2009. Archived from on 21 June 2011. Retrieved 24 August 2009.

5 January 2006. Retrieved 9 July 2019. Michal Necasek. Archived from on 12 April 2010.

Bernhard Rosenkraenzer. Archived from on 11 January 2016. Retrieved 21 October 2016. Retrieved 11 December 2011. Gamespot (Article by James Hills)., 3 July 2009 (Article by ). Puoti, Ivan Leo (18 February 2005).

Wine-devel (Mailing list). Retrieved 23 January 2006.Further reading.

– interview with Jeremy White of., May 25, 2004. Appointment of the as legal counsel to represent the Wine project.

Install Linux On Mac Os

– a work by Dan KegelExternal links Wikimedia Commons has media related to.

I have the urge to commit my 24' Core 2 Duo iMac to a single Linux operating system, thus giving up the goodness of my beloved Mac OS X. I am not a stranger to Linux, but I am a stranger to running Mac apps on Linux. On my PowerPC I can use SheepShaver to run Classic apps.

The Mac-on-Linux project can run OS X apps, but it requires a PowerPC, not an x86. Virtualizing and emulating are inefficient, especially given the wonderful results the WINE project has had in getting Windows apps to run on Linux. What I would like is an equivalent: a software compatibility layer that will allow Linux to run Mac OS X apps at native performance. I believe there is some additional complexity in accomplishing this. Mac OS X apps aren't just Mac OS X apps. They are Carbon. They are Cocoa.

They are universal binaries. They are PPC code with Altivec. Does such a project exist yet? If not, why not?

Wine is an open source implementation of the Windows API, though it can use Microsoft dlls if you supply them.Correct. I'm operating under the assumption that Cocoa and Carbon use Unix APIs at some level, since they sit on top of a Unix core. So as Wine is an implementation of the Win32 API, the Win32 API is just a fairly low-level API that lets you make windows and buttons and pull-down menus, access the filesystem, access task and memory management, etc., but if you want any of the niceties of newer Windows applications, like toolbars, reconfigurable menus, fancy controls, Windows media, etc., you need Windows/Microsoft DLLs that aren't a core part of the Win32 API proper. Sure, Wine provides open source implementations of some of these, but in most cases you need them provided from the application or from a copy of Windows. The analogy is not quite the same, with Cocoa and Carbon, but I think you get my point. Carbon is a sort of bizarre chimera library, which was intended to provide a compatible set of APIs between classic Mac OS and Mac OS X.

So that once OS X was on the way, you could carbonize an app under Classic and have it just work on OS X. Brilliant idea, but it means Carbon isn't a close relative of anything.

It's a huge library and framework (since it spanned multiple operating systems), and would basically have to be engineered from scratch.In contrast, Cocoa is what used to be OPENSTEP; it's just. A wine-like system for OSX would actually be a lot easier to accomplish.There is already something iBCS, which lets Linux run binaries from other x86 unix-like systems (SCO, Xenix etc. Old stuff), and various BSD's have the ability to execute Linux binaries.You only need to emulate the kernel interfaces, and then the user mode programs/libraries should run atop a Linux kernel just like they run on OSX's existing kernel.

Then you can begin reimplementing the proprietary libraries one by one. Those libraries which are BSD licensed you can directly port the source.All in all, a much easier job than wine. Wine doesn't really emulate Windows libraries, it runs them directly. Wine implements the Windows API.

Wine does not use any software from Microsoft. Windows programs are just run with the Wine implementation instead of the Microsoft implementation.The Cocoa API is based on the OpenStep API, which has a gnustep.org. We've had a FOSS implementation of the OpenStep API for years: GNUstep. GNUstep has even implemented some of the Cocoa additions.

Producing a Cocoa compatibility layer should be much easier than producing a Windows compatibility layer. Producing a Cocoa compatibility layer should be much easier than producing a Windows compatibility layer. There are a few more things required than just GNUstep. GNUstep gives source compatibility and is now fairly good at reading nib files. In order to run OS X pure-Cocoa applications you would also need a Mach-O binary loader. Linux uses ELF as the format for binaries, and so the loader can not start and link OS X applications. Next you would need to compile the Apple (NeXT) Objective-C runtime library on Linux.

This is pretty easy (the code is ASPL), but currently GNUstep has problems running with the NeXT libobjc (it uses the GNU one by default).If you did this, you could run applications that just used Cocoa. Unfortunately, a lot of OS X applications also use Carbon. There is no open source version of Carbon, although a few people have written GNUstep wrappers for the parts of Carbon which are toll-free bridged with Cocoa. You would also not be able to run anything that depends on WebKit (unless you use GNUstep's SimpleWebKit as a stop-gap), QuickTime, or any of a number of other frameworks that have not yet been added to GNUstep.WINE has had a lot of time and effort put into it because there are a huge number of proprietary Windows-only applications that would be useful on other platforms already deployed. There are far fewer essential applications for the Mac (90%+ of computer users don't use any OS X apps, after all), and so no one has bothered.

For the few apps that would be worth supporting, it is probably easier to re-write them from scratch than it is to write a general purpose compatibility layer.