Linux users CRYING cause they don't have STEAM! PATHETIC!!!!

On 2007-08-01, Christopher Hunter <chrisehunter.DeleteThis@NOSPAMblueyonder.co.uk> wrote:
> Hadron wrote:
>
>> What windows users favourite games are you talking about? Considering
>> that most wont run on Linux?
>
> They do under Cedega, Wine or one of the other emulator applications. In
> many cases they run /better/ under an emulator than under Windows.

Wine is not an emulator. It reroutes calls that are windows specific to
calls that exist on a target machine, m'kay?

That way you _don't_ _emulate_ architecture of windows, it's libs and
drivers (which would be a significant overhead even if OSS community had
the details how to do that), but use _existing_ OS and hardware
facilities.

--
What a strange game.
The only winning move is not to play.

How about a nice game of chess?

In article <slrnfb0qse.3oc.nrubA.RemoveThis@afrodita.home.lan>,
Davorin Vlahovic <nrubA.RemoveThis@ylf.krs.ref.rh> wrote:
> Wine is not an emulator. It reroutes calls that are windows specific to
> calls that exist on a target machine, m'kay?

(Pedantic mode on)

Actually, it is an emulator. If you go back and check out old versions
of the Wine documentation, and follow them forward, you can find the
interesting story behind that.

Originally, WINE stood for "WINdows Emulator". That was in the official
documentation for every release. It was that way for quite a while.
When Microsoft was trying to get a trademark on "Windows", there was
some concern among the developers that they might get in trouble over
the name. That's when someone came up with the idea of WINE meaning
"Wine Is Not an Emulator". However, that didn't go anywhere. The
official documentation continued to say WINE stood for "WINdows
Emulator".

It continued this way for a long time. Eventually, the official
documentation changed to say that WINE was either "WINdows Emulator" or
"Wine Is Not an Emulator", and told the reader to use whichever the
reader preferred.

What finally got them to drop the emulator part was concern that it
would mislead some people into thinking that WINE was a *hardware*
emulator. When most people think of emulators, they think of things
like Bochs, when emulator the hardware of one CPU on another. These
emulators are usually very slow. If people thought of WINE as an
emulator, they'd think that it must therefore be very slow, and avoid it.

So, for what would be called market positioning reasons in a commercial
product, they stopped *calling* it an emulator.

However, it is important to note that throughout all this, there was no
change in how it actually worked. It was an emulator before the
documentation change, and so it remained an emulator afterwards, and
still is to this day.

--
--Tim Smith

On Tue, 31 Jul 2007 22:24:08 -0500, DFS wrote:

> waterskidoo wrote:
>
>> Low overhead (bloat) compared to Windows.
>> Games can be written to take advantage of preemptive switches in
>> the kernel. IOW, in theory the kernel can be tuned for gaming.
>
> uh huh. And "in theory" Linux should be on everyone's computer, 'cause
> according to Linux bozos it runs rings around Windows. In reality... well,
> just open your eyes.

In reality, Linux *does* run rings around Windows. That said, because
they are not the same, nor do they operate the same, one must apply
appropriate usage patterns to each to get the best out of them.

As a simple example, in Windows the usual procedure to edit a document is
to launch your word processor, edit the document, close your word
processor; if you need to do another document 10 minutes later, repeat the
process.

That's fine as far as it goes, but it requires certain design
considerations which give the foreground app a degree of "snap" when
loading - and those decisions have an impact on the system as a whole.
Windows' designers chose to provide fast loads at a reduction of overall
performance; Linux' design took the opposite approach - keep overall
performance up, while app loads may take longer.

Thus to get the maximal response in Linux is to not pretend it is
Windows, but to accept that it is a different OS with different
performance characteristics and treat it as such; in the example above, it
is better to simply leave the word processor running in the background,
perhaps on another virtual desktop, so that it is immediately available.
Unless your machine is severely memory-limited, you'll never notice,
except when you need the app again.

Treating the OSen the same, using the same interaction patterns, makes no
more sense than trying to drive a pickup and a sports car the same way;
they have different characteristics, different designs, different areas
where their performance comes to the foreground.

Davorin Vlahovic <nrubA.RemoveThis@ylf.krs.ref.rh> writes:

> On 2007-08-01, Christopher Hunter <chrisehunter.RemoveThis@NOSPAMblueyonder.co.uk> wrote:
>> Hadron wrote:
>>
>>> What windows users favourite games are you talking about? Considering
>>> that most wont run on Linux?
>>
>> They do under Cedega, Wine or one of the other emulator applications. In
>> many cases they run /better/ under an emulator than under Windows.
>
> Wine is not an emulator. It reroutes calls that are windows specific to
> calls that exist on a target machine, m'kay?

Wine *is* an emulator in that it *emulates* the equivalent win32 API
calls. m'kay? This has been done to death with.

> That way you _don't_ _emulate_ architecture of windows, it's libs and
> drivers (which would be a significant overhead even if OSS community had
> the details how to do that), but use _existing_ OS and hardware
> facilities.

Sorry? Do you believe for ONE minute that the built in calls to external
win32 have exact equivalents on the host? Well, they don't. The in
between DLL emulates what it thinks the win32 api would do with the
passed parameters. Its why it needs to be changed so soften as yet
another "state" of the win32 is discovered not to be covered in the
emulation layer.

And please don't quote the "Wine Is Not An Emulator". That is an urban
myth. And also don't make me google up the Wine developers referring to
it as an emulator too. It already made a few people here cry.

DFS <nospam.TakeThisOut@dfs_.com> did eloquently scribble:
> waterskidoo wrote:

>> Low overhead (bloat) compared to Windows.
>> Games can be written to take advantage of preemptive switches in
>> the kernel. IOW, in theory the kernel can be tuned for gaming.

> uh huh. And "in theory" Linux should be on everyone's computer, 'cause
> according to Linux bozos it runs rings around Windows. In reality... well,
> just open your eyes.

OK, let's see some examples of windows not having linux run rings around it.
(don't even think about mentioning "but linux doesn't have many games", for
this exercise linux IS the kernel + core operating system elements.

(or LGX as some liked to call it)

How does linux NOT run rings around vista?
A 2Ghz Linux could probably outperform a 3Ghz vista box.
(but then, we can't know this because microsoft's EULA prevents comparitive
benchmarks)


--
______________________________________________________________________________
| spike1.TakeThisOut@freenet.co.uk | "I'm alive!!! I can touch! I can taste! |
|Andrew Halliwell BSc(hons)| I can SMELL!!! KRYTEN!!! Unpack Rachel and |
| in | get out the puncture repair kit!" |
| Computer Science | Arnold Judas Rimmer- Red Dwarf |
------------------------------------------------------------------------------

In article <46afbe15$0$12193$4c368faf@roadrunner.com>,
emailaddress.RemoveThis@nomailthanks.com says...
> Christopher Hunter wrote:
> > It's funny to see the astonished looks on the faces of Windows users when
> > you show them multiple instances of their favourite games all running
> > simultaneously on the sides of a 3D cube, when their over-priced, over
> > specified Windows computer can only (just) manage one instance!
>
> If you're talking 3D games I'd love to see that myself, u got a link?

Of course he doesn't. Look at the newsgroups list - he obviously comes
from the morons' one.

- Gerry Quinn

On 2007-08-01, Hadron <hadronquark DeleteThis @googlemail.com> wrote:
> Davorin Vlahovic <nrubA DeleteThis @ylf.krs.ref.rh> writes:
>
>> On 2007-08-01, Christopher Hunter <chrisehunter DeleteThis @NOSPAMblueyonder.co.uk> wrote:
>>> Hadron wrote:
>>>
>>>> What windows users favourite games are you talking about? Considering
>>>> that most wont run on Linux?
>>>
>>> They do under Cedega, Wine or one of the other emulator applications. In
>>> many cases they run /better/ under an emulator than under Windows.
>>
>> Wine is not an emulator. It reroutes calls that are windows specific to
>> calls that exist on a target machine, m'kay?
>
> Wine *is* an emulator in that it *emulates* the equivalent win32 API
> calls. m'kay?

No.

>> That way you _don't_ _emulate_ architecture of windows, it's libs and
>> drivers (which would be a significant overhead even if OSS community had
>> the details how to do that), but use _existing_ OS and hardware
>> facilities.
>
> Sorry? Do you believe for ONE minute that the built in calls to external
> win32 have exact equivalents on the host? Well, they don't.

Most of them have it. Ie. reading the contents of a file or a directory,
sending/receiving data over the net, screen handling, etc, etc. Not to
mention _not_ emulating the execution unit (CPU) for opcode
execution - only the system calls are intercepted.

> And please don't quote the "Wine Is Not An Emulator". That is an urban
> myth. And also don't make me google up the Wine developers referring to
> it as an emulator too. It already made a few people here cry.

Softies

Anyway, even if someone is a wine developer it doesn't have to mean that
he/she (ok, who am I kidding - he) knows what an emulator is.

The way you're thinking about it, windows is a windows emulator because
it all gets intercepted sooner or later by the win32api subsystem that
"transcribes" the calls into nt api calls (see the ntdll.dll and the nt*
calls).

http://en.wikipedia.org/wiki/Image:Windows_2000_architecture.svg

Take a good look at environment subsystems part of the diagram.

Windows are of modular design (wasted by lousy management) so for a
win32 app it doesn't really matter what kind of kernel is behind the
win32 subsystem. It might as well be Linux But in that case it
doesn't mean it's an emulation. Which in this case it is not. Think of
it as an environment subsystem on Linux.


--
What a strange game.
The only winning move is not to play.

How about a nice game of chess?

Davorin Vlahovic <nrubA.RemoveThis@ylf.krs.ref.rh> writes:

> On 2007-08-01, Hadron <hadronquark.RemoveThis@googlemail.com> wrote:
>> Davorin Vlahovic <nrubA.RemoveThis@ylf.krs.ref.rh> writes:
>>
>>> On 2007-08-01, Christopher Hunter <chrisehunter.RemoveThis@NOSPAMblueyonder.co.uk> wrote:
>>>> Hadron wrote:
>>>>
>>>>> What windows users favourite games are you talking about? Considering
>>>>> that most wont run on Linux?
>>>>
>>>> They do under Cedega, Wine or one of the other emulator applications. In
>>>> many cases they run /better/ under an emulator than under Windows.
>>>
>>> Wine is not an emulator. It reroutes calls that are windows specific to
>>> calls that exist on a target machine, m'kay?
>>
>> Wine *is* an emulator in that it *emulates* the equivalent win32 API
>> calls. m'kay?
>
> No.

is that all you have?

>
>>> That way you _don't_ _emulate_ architecture of windows, it's libs and
>>> drivers (which would be a significant overhead even if OSS community had
>>> the details how to do that), but use _existing_ OS and hardware
>>> facilities.
>>
>> Sorry? Do you believe for ONE minute that the built in calls to external
>> win32 have exact equivalents on the host? Well, they don't.
>
> Most of them have it. Ie. reading the contents of a file or a directory,
> sending/receiving data over the net, screen handling, etc, etc. Not to
> mention _not_ emulating the execution unit (CPU) for opcode
> execution - only the system calls are intercepted.

No most of them do not have it. The entire state and flag set are
different. Screen handling? Are you joking? They have totally different
APIs. Ditto for sound.

Sure the opcodes are not emulated. But "Emulation" means a lot mode than
that.


>> And please don't quote the "Wine Is Not An Emulator". That is an urban
>> myth. And also don't make me google up the Wine developers referring to
>> it as an emulator too. It already made a few people here cry.
>
> Softies
>
> Anyway, even if someone is a wine developer it doesn't have to mean that
> he/she (ok, who am I kidding - he) knows what an emulator is.

Oh please. You have one meaning. There are others.

>
> The way you're thinking about it, windows is a windows emulator because
> it all gets intercepted sooner or later by the win32api subsystem that
> "transcribes" the calls into nt api calls (see the ntdll.dll and the nt*
> calls).

No. Thats not how I am thinking of it.

The system calls are intercepted and WINE emulates what the equivalent
win32 code would do. What is so hard for you to understand here?

>
> http://en.wikipedia.org/wiki/Image:Windows_2000_architecture.svg
>
> Take a good look at environment subsystems part of the diagram.

So?

>
> Windows are of modular design (wasted by lousy management) so for a
> win32 app it doesn't really matter what kind of kernel is behind the

??????????????????

> win32 subsystem. It might as well be Linux But in that case it
> doesn't mean it's an emulation. Which in this case it is not. Think of
> it as an environment subsystem on Linux.

What *are* you talking about?

I think you should go back and start from scratch and you seem to be
scratching around in the dark.

Just FYI:

The programs are windows code.

They call system calls/win32 : these are intercepted.

At this stage WINE pretends to be the win32/system APIs in Windows. It
*emulates* what the windows code would do - it doesn't know what the
windows code really does other than the usual reverse engineering.

And before you embarrass yourself as much as Spike1 and some others did:

http://www.faqs.org/faqs/windows-emulation/wine-faq/

On Wed, 01 Aug 2007 13:45:31 +0200, Hadron wrote:

> And please don't quote the "Wine Is Not An Emulator". That is an urban
> myth.

Uh... no, it's not. Wine does in fact stand for "Wine Is Not An Emulator"
because Wine is not an emulator.

> And also don't make me google up the Wine developers referring to
> it as an emulator too. It already made a few people here cry.

Let me do that for you... From the Wine About page:

"Wine is a translation layer (a program loader) capable of running Windows
applications on Linux and other POSIX compatible operating systems.
Windows programs running in Wine act as native programs would, running
without the performance or memory usage penalties of an emulator, with a
similar look and feel to other applications on your desktop."


From the Wine FAQ:

"Why do some people write WINE and not Wine?

They are using the acronym "Wine Is Not an Emulator", the original name
for the project. While recursive acronyms are clever, there really is no
point to the capital letters. They look ugly, so please use the simpler,
current name of the project: Wine. It's what we use."

On 2007-08-01, Benjamin Gawert <bgawert RemoveThis @gmx.de> wrote:
> * Tim Smith:
>>> Yes, sure. That has been believed by the community for almost a decade
>>> now. Still most game developers don't give a damn on that niche system.
>>
>> It's a particularly bad niche for a games developer, because not only
>> are they starting with a small market (Linux desktop uses), a rather
>> vocal component of that market is strongly opposed to any closed source
>> software, so the game developer (if their game is not open source) will
>> have to put up with a lot of being badmouthed by people who consider
>> their presence an affront to the purity of Linux.
>
> Right, that's another problem. I find it ridiculous how the community
> attacks gfx vendors like ATI/AMD and Nvidia because they don't want to
> open source their drivers. Heck, they (the community) should be happy
> that both companies develop for their operating system. Instead, they
> are attacking them.

There are different philosophies WRT to Linux and Linux systems.
Some people are purists and want complete Open Source software and
will not acknowledge closed source at all.
I respect the opinions of these people and although I wish that
it were like that I realize it is not and might never be.
However, without people like that, it will never stand a chance
of happening so like I said I do appreciate and respect their
efforts. As for me, if it's Linux that's all I care about.
I use Windows as well (XP) and respect OSX too.
I use what works for me in a particular application.
Most times it's Linux, but sometimes Windows is the only
solution.

On 2007-08-01, Hadron <hadronquark RemoveThis @googlemail.com> wrote:
>>>> Wine is not an emulator. It reroutes calls that are windows specific to
>>>> calls that exist on a target machine, m'kay?
>>>
>>> Wine *is* an emulator in that it *emulates* the equivalent win32 API
>>> calls. m'kay?
>>
>> No.
>
> is that all you have?

No, thought you'd have scanned through the whole post before answering
it. Guess I was wrong.

>> Most of them have it. Ie. reading the contents of a file or a directory,
>> sending/receiving data over the net, screen handling, etc, etc. Not to
>> mention _not_ emulating the execution unit (CPU) for opcode
>> execution - only the system calls are intercepted.
>
> No most of them do not have it. The entire state and flag set are
> different. Screen handling? Are you joking? They have totally different
> APIs. Ditto for sound.

Because of different APIs there is a need to rework the way of calling
the targeting system's APIs through win APIs but the principles stay the
same - catch an event, draw border, move window, fill background,
repaint...

> Sure the opcodes are not emulated. But "Emulation" means a lot mode than
> that.

The thing is not a lot is being "emulated". There's just a relativly
thin layer that glues together many things. GDI? Part of Xlib.
Direct3D? OpenGL. DirectSound? ALSA.

>> The way you're thinking about it, windows is a windows emulator because
>> it all gets intercepted sooner or later by the win32api subsystem that
>> "transcribes" the calls into nt api calls (see the ntdll.dll and the nt*
>> calls).
>
> No. Thats not how I am thinking of it.

Well, I'm not clairvoyant. But, never the less, my point stands even if
it's not the way you're thinking of it.

> The system calls are intercepted and WINE emulates what the equivalent
> win32 code would do. What is so hard for you to understand here?

Suppose you're right. What is Xlib then? Is it an emulation? Because,
you know, it catches some API calls and transcribes them to X Window
System protocol.

Let's go a step further - what is GTK/Qt? It too catches some API calls
and transcribes them to Xlib/X Window System protocol.

Is GTK or Qt also emulation?

>> http://en.wikipedia.org/wiki/Image:Windows_2000_architecture.svg
>>
>> Take a good look at environment subsystems part of the diagram.
>
> So?

So tell me the diff between Win32 subsystem on windows and WINE on
Linux. As far as I can see, these two things do the same work. Using
your definition Win32 apps aren't native on windows either.

>> win32 subsystem. It might as well be Linux But in that case it
>> doesn't mean it's an emulation. Which in this case it is not. Think of
>> it as an environment subsystem on Linux.
>
> What *are* you talking about?
>
> I think you should go back and start from scratch and you seem to be
> scratching around in the dark.

I'm ok where I am, thank you very much.

> Just FYI:
>
> The programs are windows code.

No, those programs are x86 32bit protected mode code, executed the same
way it would be executed on any x86 CPU in protected mode.

> They call system calls/win32 : these are intercepted.

System calls? No, win32 _subsystem_ calls Windows has around 200
system calls, but only about 20 are documented.

What you're thinking of are library calls, just like printf is a libc
library call. They do exactly the same things WINE does.

> At this stage WINE pretends to be the win32/system APIs in Windows. It
> *emulates* what the windows code would do - it doesn't know what the
> windows code really does other than the usual reverse engineering.

So, at what stage Xlib starts pretending to be a X Window System protocol
API?

> And before you embarrass yourself as much as Spike1 and some others did:
>
> http://www.faqs.org/faqs/windows-emulation/wine-faq/

Couldn't care less.
--
What a strange game.
The only winning move is not to play.

How about a nice game of chess?

On 2007-08-01, Tim Smith <reply_in_group RemoveThis @mouse-potato.com> wrote:
> In article <slrnfb0qse.3oc.nrubA RemoveThis @afrodita.home.lan>,
> Davorin Vlahovic <nrubA RemoveThis @ylf.krs.ref.rh> wrote:
>> Wine is not an emulator. It reroutes calls that are windows specific to
>> calls that exist on a target machine, m'kay?
>
> (Pedantic mode on)
>
> Actually, it is an emulator.

Actually, I guess we have a "row" over what is exactly an emulator

IMHO, ReactOS (http://www.reactos.org/en/index.html) would be a
Windows emulator/implementation, but Wine would not. Wine could be a
part of an emulator, but it's not emulator as it is.

At best it's a compatibility layer.
--
What a strange game.
The only winning move is not to play.

How about a nice game of chess?

[snips]

On Wed, 01 Aug 2007 18:12:14 -0500, DFS wrote:

>> As a simple example, in Windows the usual procedure to edit a
>> document is to launch your word processor, edit the document, close
>> your word processor; if you need to do another document 10 minutes
>> later, repeat the process.
>
> Close. What I've observed is the vast majority of times the Windows user
> navigates to a folder in Windows Explorer (open full-screen) and dbl-clicks
> the document

Which opens the word processor. Yes, exactly what I said - open the WP,
edit the document, close the WP.

> people will relate to. I don't agree with it - it's a waste of
> resources to leave apps running all day

If your OS is piss-poor at resource management or you're using a
resource-starved machine, sure. If you're using a typical desktop, for
typical desktop purposes, it imposes sufficiently low overhead that you'd
just never notice.

> and it's a hassle to remember where to go to find them

Ubuntu, by default, shows all apps from all desktops on the taskbar and
only uses two virtual desktops; pressing CTRL-TAB once to get to the other
desktop hardly seems a hassle.