Whatever happened to Mac OS X and iOS ports of LOG?

[jamie]

No problem

Just always find it amusing to read about mac and linux limitations.. people posting they so love their macs while in the same post describing how they had to "emulate" this or that on some windows emulator (wine it's called I believe)... I mean, just get a pc... it's cheaper, easier to upgrade and runs way more applications...

you mean operating system,,,, A PC is what the OS is running on...... Sorry there are better things to spend money on then a MS license. Anyways i believe there is a mac os version out now Im prob necroing this thread.

Wine is not a emulator it translates Direct X api calls to Open GL / AL calls that linux and mac os can understand. Sence they are both POSIX based operating systems.

Well, you seems to enjoy a good arguing
So, I challenge your point of view that PC is just the hardware. The PC was primarly a groundbreaking concept in the 80/90s whcih superseded the workstation-sever model. The PC model consist on of the idea of a local, self-administrated computing device which is a open platform, hardware and software wise. The user (not the admin) was empowered to select hardware and software like he want from independent producers. And it that sense, neither a Mac nor a Linux-PC could be called a PC in some point of view. Mac has restricted Hardware freedom (even when running on mostly PC hardware) and linux distros restrict software selection freedom (even when running on arbitrary PC hardware) by not having stable platform apis (distro fragmentation) and problematic binary ISV software support. Basically, because the linux distro concept is still modeled on the old workstation-server role model from the 60/70s ...the user focussed PC concept was never really adopted in Linux.

So, it makes sense to speak from PCs as synonym for the PC+Windows combo.

(also, despite what Wine is saying, Wine is partly an emulator which mimicks windows behaviour)

A PC is made up of multiple physical components that are all fitted together in a certain way to make up the base computer unit. Now once this is done and it can be switched on, you will then have what's called a dumb computer.

They are called dumb computers at this stage because although all the parts are working correctly electrically, they don't know what to do. But why, what's missing? When the hardware is fully assembled and operating, the computer needs an operating system.

An Operating System (OS) is software for a computer that manages the hardware and the way different programs use the hardware. The OS also regulates the ways a user can control the computer.

An operating system is software, but it's needed to control and tell all the PC's hardware what to do and at what time to do it. Different operating systems examples are like 'Windows xx' and 'Linux', either can be installed as well as a multitude of additional software to perform the operator's desired functions.


About wine emulates part of a windows no.

Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, Mac OSX, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.

[FlashSoul]

Wine (originally an acronym for "Wine Is Not an Emulator")

Nope. Wine originally meant "WINdows Emulator". "Wine Is Not an Emulator" appeared later.

[jamie]

Wine (originally an acronym for "Wine Is Not an Emulator")

Nope. Wine originally meant "WINdows Emulator". "Wine Is Not an Emulator" appeared later.

The name Wine initially was an acronym for WINdows Emulator. Its meaning later shifted to the recursive backronym, Wine Is Not an Emulator in order to differentiate the software from other emulators. While the name sometimes appears in the forms WINE and wine, the project developers have agreed to standardize on the form Wine.
The phrase "Wine Is Not an Emulator" is a reference to the fact that no processor code execution emulation occurs when running a Windows app under Wine. "Emulation" usually refers to the execution of compiled code intended for one processor (say, x86) by interpreting/recompiling software running on a different processor (say, PowerPC). Such emulation is almost always much slower than execution of the same code by the processor for which the code was compiled. In Wine, the Windows app's compiled x86 code runs at full native speed on the computer's x86 processor, just as it does when running under Windows. And Windows API calls and services also are not emulated, but rather substituted with Linux equivalents that are compiled for x86 and run at full, native speed.

[badhabit]

Wine (originally an acronym for "Wine Is Not an Emulator")

Nope. Wine originally meant "WINdows Emulator". "Wine Is Not an Emulator" appeared later.

The name Wine initially was an acronym for WINdows Emulator. Its meaning later shifted to the recursive backronym, Wine Is Not an Emulator in order to differentiate the software from other emulators. While the name sometimes appears in the forms WINE and wine, the project developers have agreed to standardize on the form Wine.
The phrase "Wine Is Not an Emulator" is a reference to the fact that no processor code execution emulation occurs when running a Windows app under Wine. "Emulation" usually refers to the execution of compiled code intended for one processor (say, x86) by interpreting/recompiling software running on a different processor (say, PowerPC). Such emulation is almost always much slower than execution of the same code by the processor for which the code was compiled. In Wine, the Windows app's compiled x86 code runs at full native speed on the computer's x86 processor, just as it does when running under Windows. And Windows API calls and services also are not emulated, but rather substituted with Linux equivalents that are compiled for x86 and run at full, native speed.

Well, while Wine might not emulate CPU instructions it is emulating Windows behaviour & architecture where it is not natively availalable (on a unixoid systems). It's not just a plain straight forward implementation of the directX, win32 etc APIs.

According to Wikipedia: In computing, an emulator is hardware or software or both that duplicates (or emulates) the functions of a first computer system (the guest) in a different second computer system (the host), so that the emulated behavior closely resembles the behavior of the real system. Wine tries to mimick the behaviour of a windows system with APIs on unixoide system as close as possible, therefore it's more than a API re-implementation.

And about the PC, my point was that the PC concept and the success of the PC can by seen unseparateable connected with a stable and open software platform provided by a OS. DOS/windows built a successful one, and was the software analogon to the open platform idea of IBM for the PC hardware. This is a different approach than unix based OSs which have and had a integrated software, non-platform concept. (http://www.joelonsoftware.com/articles/APIWar.html)

[jamie]

Nope. Wine originally meant "WINdows Emulator". "Wine Is Not an Emulator" appeared later.[/quote]


The name Wine initially was an acronym for WINdows Emulator. Its meaning later shifted to the recursive backronym, Wine Is Not an Emulator in order to differentiate the software from other emulators. While the name sometimes appears in the forms WINE and wine, the project developers have agreed to standardize on the form Wine.
The phrase "Wine Is Not an Emulator" is a reference to the fact that no processor code execution emulation occurs when running a Windows app under Wine. "Emulation" usually refers to the execution of compiled code intended for one processor (say, x86) by interpreting/recompiling software running on a different processor (say, PowerPC). Such emulation is almost always much slower than execution of the same code by the processor for which the code was compiled. In Wine, the Windows app's compiled x86 code runs at full native speed on the computer's x86 processor, just as it does when running under Windows. And Windows API calls and services also are not emulated, but rather substituted with Linux equivalents that are compiled for x86 and run at full, native speed.[/quote]
Well, while Wine might not emulate CPU instructions it is emulating Windows behaviour & architecture where it is not natively availalable (on a unixoid systems). It's not just a plain straight forward implementation of the directX, win32 etc APIs.

According to Wikipedia: In computing, an emulator is hardware or software or both that duplicates (or emulates) the functions of a first computer system (the guest) in a different second computer system (the host), so that the emulated behavior closely resembles the behavior of the real system. Wine tries to mimick the behaviour of a windows system with APIs on unixoide system as close as possible, therefore it's more than a API re-implementation.

And about the PC, my point was that the PC concept and the success of the PC can by seen unseparateable connected with a stable and open software platform provided by a OS. DOS/windows built a successful one, and was the software analogon to the open platform idea of IBM for the PC hardware. This is a different approach than unix based OSs which have and had a integrated software, non-platform concept. (http://www.joelonsoftware.com/articles/APIWar.html)[/quote]

Still wrong.

Yes Direct X is not 100 percent nativly supported under linux. (some people have a working branch in open source drivers. though alot of reverse engineering. You fail to realize is that everything that is done in wine is also done on the real hardware its just translating Windows function calls into something UNIX based systems understand. ALL Features would have to be supported whether it be video or input and whatnot on the host os. The diffrence between emulation and Translation are diff rent. Emulation Does what it says it does it emulates. Translation is like having a translator you don't speak Spanish but someone else does. They are your middle man between you to. If direct x or direct input call a function the same function is carried out on linux or MAC os the software is just telling them HOW TO DO IT. It's not a hard concept.

[badhabit]

[...] its just translating Windows function calls into something UNIX based systems understand. [...]

Thanks, that's my point, this qualifies wine as emulator. Translating several "windowish" things to linux syntax as this aspects are in no way native to a unix environment. Also, emulation/non-emulation can't be separated on the question of feature completeness.

[jamie]

[...] its just translating Windows function calls into something UNIX based systems understand. [...]

Thanks, that's my point, this qualifies wine as emulator. Translating several "windowish" things to linux syntax as this aspects are in no way native to a unix environment. Also, emulation/non-emulation can't be separated on the question of feature completeness.

its not a emulator.. The same exact functions are carried out. They just have 2 different ways of doing that function all wine does is tell it how to execute that function in a different language. so if you have a direct x function call to a a sharder its carried out in the the host os as a gl/sl shader that it understands. There is nothing emulated period as it would have to be supported. if what ever your calling is not supported it wont execute.

Emulation on the other hand emulates functions calls that would normally not be plausible on the host os. Arcade roms are perfect example of this as the underlining hard ware cannot me reproduced on the host os. which is diffrent from just making a function call between 2 different api's that support the same functions.

[badhabit]

[...] its just translating Windows function calls into something UNIX based systems understand. [...]

Thanks, that's my point, this qualifies wine as emulator. Translating several "windowish" things to linux syntax as this aspects are in no way native to a unix environment. Also, emulation/non-emulation can't be separated on the question of feature completeness.

its not a emulator.. The same exact functions are carried out. They just have 2 different ways of doing that function all wine does is tell it how to execute that function in a different language. so if you have a direct x function call to a a sharder its carried out in the the host os as a gl/sl shader that it understands. There is nothing emulated period as it would have to be supported. if what ever your calling is not supported it wont execute.

Emulation on the other hand emulates functions calls that would normally not be plausible on the host os. Arcade roms are perfect example of this as the underlining hard ware cannot me reproduced on the host os. which is diffrent from just making a function call between 2 different api's that support the same functions.

Several DirectX api calls have no trivial translation to native OpenGL calls, they are approximated or emulated. Neither has the windowish "C:\something" path naming a direct translation in unix... or the case-insensitivity. Case-insensitvity is completely unplausible and unnatural on a unix system, still it's emulated in wine.

Wine is a emulation, it mimicks the behaviour (and bugs) of a windows system. By providing functionality which is for normal unix usage completely unplausible, unnecesary or even faulty.

[jamie]

Thanks, that's my point, this qualifies wine as emulator. Translating several "windowish" things to linux syntax as this aspects are in no way native to a unix environment. Also, emulation/non-emulation can't be separated on the question of feature completeness.[/quote]


its not a emulator.. The same exact functions are carried out. They just have 2 different ways of doing that function all wine does is tell it how to execute that function in a different language. so if you have a direct x function call to a a sharder its carried out in the the host os as a gl/sl shader that it understands. There is nothing emulated period as it would have to be supported. if what ever your calling is not supported it wont execute.

Emulation on the other hand emulates functions calls that would normally not be plausible on the host os. Arcade roms are perfect example of this as the underlining hard ware cannot me reproduced on the host os. which is diffrent from just making a function call between 2 different api's that support the same functions.[/quote]

Several DirectX api calls have no trivial translation to native OpenGL calls, they are approximated or emulated. Neither has the windowish "C:\something" path naming a direct translation in unix... or the case-insensitivity. Case-insensitvity is completely unplausible and unnatural on a unix system, still it's emulated in wine.

Wine is a emulation, it mimicks the behaviour (and bugs) of a windows system. By providing functionality which is for normal unix usage completely unplausible, unnecesary or even faulty.[/quote]


When users think of emulators, they think of programs like Dosbox or zsnes. These applications run as virtual machines and are slow, having to emulate each processor instruction. Wine does not do any CPU emulation - hence the name "Wine Is Not an Emulator."
Some people argue that since Wine introduces an extra layer above the system a Windows application will run slowly. While technically true, Wine is no different from any other software library in this regard; even newer versions of Windows must load extra resources to support older applications.
Importantly, the combination of Wine and Unix can sometimes be faster than Windows itself. This is especially true when the system has good drivers and the application isn't exposing any Performance Related Bugs.

Once again WINE is NOT an emulator. OK thanks...

Fyi linux and mac os have the ability to support case inventive file systems.

[badhabit]

When users think of emulators, they think of programs like Dosbox or zsnes. These applications run as virtual machines and are slow, having to emulate each processor instruction. Wine does not do any CPU emulation - hence the name "Wine Is Not an Emulator."
Some people argue that since Wine introduces an extra layer above the system a Windows application will run slowly. While technically true, Wine is no different from any other software library in this regard; even newer versions of Windows must load extra resources to support older applications.
Importantly, the combination of Wine and Unix can sometimes be faster than Windows itself. This is especially true when the system has good drivers and the application isn't exposing any Performance Related Bugs.

Once again WINE is NOT an emulator. OK thanks...

Fyi linux and mac os have the ability to support case inventive file systems.

Seems primarly you think emulation means only hardware emulation...but that's not the general meaning of emulation.
Also, the formulation that wine is an extra layer which is not required for general software usage on a linux system is an indication of a emulation (the same is true for the shim layer in windows 7 which emulates XP, 2000 etc behaviour). That there are technical case-insensitive filesystem avaialble is nice but irrelevant. The practical non-existing usage of such file systems proves the point that case-insensitvity is a alien concept for a unix environment.

So, once and for all: Wine IS for a good part an emulator, if you like it or not
PS: performance differences (in both directions!) are also indications for a (imperfect) emulated characteristic/functionality