[RichardI]

I have received my pre-ordered copy of TW '08 for the Mac. It is at my house now. It's interesting that the MacGameStore site still lists it as "coming soon".

Maybe I'll do a real-life review when I get 'er installed on my iMac. [edit] I got it installed OK, tried to run the game 4 times - 4 freezes. Locked up tighter than, well whatever.
This is the only program I have ever had that completely crashes OSX. Unbelievable.
So, don't be in a hurry....

Rich

[Tesseract]

RichardI, on October 16th 2007, 06:07 AM, said:

It's interesting that the MacGameStore site still lists it as "coming soon".

It's an Apple Store exclusive, so AIUI, MGS is buying it from the Apple Store and reselling it at a slightly higher price. So it'll take a little longer for MGS to get its stock. This may seem odd, but it's pretty much the only way for people outside North America to get these ciderised EA games.

Quote

I got it installed OK, tried to run the game 4 times - 4 freezes. Locked up tighter than, well whatever.
This is the only program I have ever had that completely crashes OSX. Unbelievable.

While it's technically OS X's fault if a user program can crash it or lock it up, still… so much for compatibility testing?

[Janichsan]

Tesseract, on October 16th 2007, 06:34 AM, said:

While it's technically OS X's fault if a user program can crash it or lock it up, still… so much for compatibility testing?

I'm feeling lucky that I don't have any (serious) problems with BF2142, but I have the impression that EA and Transgaming have done a really sloppy job. There are so many reports for all of the ciderised EA games that they do not run at all, it's not funny.

[bismilah]

Tesseract, on October 16th 2007, 06:34 AM, said:

While it's technically OS X's fault if a user program can crash it or lock it up, still… so much for compatibility testing?

with Cider games I would say culprit is Cider (or Cedega) and windows DLLs. OSX is innocent here, imo

[Tesseract]

On a modern system, if a program running on an OS can cause the OS itself to malfunction, then that is a bug in the OS. My original point was that EA/Transgaming should have avoided triggering said bug, BTW.

[Janichsan]

Tesseract, on October 20th 2007, 08:10 AM, said:

On a modern system, if a program running on an OS can cause the OS itself to malfunction, then that is a bug in the OS.

Not necessarily. When you tamper around with stuff you are no supposed to tamper with, you can crash your computer spectacularily. The last kernel panic I had was caused by myself, by trying to write a multithreading program without actually knowing what I doing.

Believe me: every OS - even the most the modern and safe ones - can be brought down by crappy programming.

[Nicholas]

But the OS should protect against things like that though...

Playing Devils Advocate here : I believe 'Woods 08 is OSX 10.5 compatible only. And the reason for this assumption ? Well, its simple : 'Woods 08 has only been seen when previewing OSX 10.5, especially with the preview film (the bit when showing off Spaces).

[Tesseract]

Janichsan, on October 20th 2007, 07:32 PM, said:

Not necessarily. When you tamper around with stuff you are no supposed to tamper with, you can crash your computer spectacularily. The last kernel panic I had was caused by myself, by trying to write a multithreading program without actually knowing what I doing.

Unless you were writing a kernel extension, that was a bug in the kernel. Actually, it was even if you were: it would then just be a kernel bug that you introduced.

Quote

Believe me: every OS - even the most the modern and safe ones - can be brought down by crappy programming.

Right, every OS has bugs.

Nicholas, on October 20th 2007, 08:05 PM, said:

But the OS should protect against things like that though...

Exactly. The whole point of having separate kernel and user modes, and memory protection, is to remove the need to trust user programs. The kernel is meant to put each program in a sandbox where it can't directly affect other programs. They have to go through interfaces provided by the kernel. It's the kernel's job to make sure that the things that user programs ask it to do are safe (for some definition of "safe", which generally includes things like not corrupting memory belonging to the kernel or other programs).

So when you call read() with an invalid buffer pointer, the kernel doesn't try to write to it and cause a segfault (or worse, overwrite some random memory), it detects that it is invalid and the syscall returns EFAULT. Any syscall or sequence of syscalls should be similarly safe, such that the worst that can happen is that the calling program corrupts its own data or is terminated.

[bobbob]

Tesseract, on October 20th 2007, 06:25 AM, said:

The kernel is meant to put each program in a sandbox where it can't directly affect other programs. They have to go through interfaces provided by the kernel.

It's more than just that. You know Parallels and VMware? Hardware virtualisation? The OS already does that for user-space programs. The CPU, RAM, devices, etc. are virtualised for them. A program can use any instruction, attempt to set any mode, attempt to use any register, read or write to any address, etc, and the OS is the thing that either lets it, or stops it from harming anything.

[Tesseract]

bobbob, on October 21st 2007, 05:13 AM, said:

It's more than just that. You know Parallels and VMware? Hardware virtualisation? The OS already does that for user-space programs. The CPU, RAM, devices, etc. are virtualised for them.

Eh. Sort of. They are abstracted, certainly, but virtualised generally means that the interface looks the same as accessing the resource directly. Para-virtualisation is a closer parallel, where the guest knows that it is running on a hypervisor and calls on it explicitly.

You're right that a VMM has the same job description as an OS kernel, even if its interface looks like bare metal rather than syscalls. The popularity of virtualisation thus indicates that mainstreams OSes don't do their jobs well enough.