You're thinking of Excel, which launched on Mac OS. The first release of, e.g. Word was for DOS.
Debugging the Development Process by Steve Maguire has some interesting insight (mostly as asides or side-bars) into the cross-platform nature of Office, in particular Excel, because Maguire was one of the driving forces between getting the core functionality to be cross-platform. Before that there was a constant disparity in features between the Mac and Windows versions.
And here is another quite interesting history of Word, in case you think it's a latecomer to Windows.
I still remember the first time I used IRC (I've used it twice, I think). It was when Unreal came out, and I got stuck in a bit that was really annoying me. The game was new so there were no walkthroughs/hints on the web, so I found an IRC channel for Unreal.
Conversation went something like this:
+++ Tim has arrived <OtherDude> hi <Tim> hi <OtherDude> do you have unreal? <Tim> yes <OtherDude> do you have a cd burner? +++ Tim has left
The most sneaky bit of malware I have heard about recently is the semirootkit included inside some Sony protected CDs.
Have a read here for an investigation (this story may explode in the next few days - it looks really telling).
of course multi-threading for stuff like audio playback is a no-brainer
Its also not something that's generally handled by the processor. There's a separate processor for that. On PCs they call them sound cards.
Well, yes, that would probably be why I went on to say...
Conversely, multi-threading audio playback is not exactly a huge win anyway. The chipsets on these consoles do all the hard stuff - all the audio playback engine is doing is filling buffers and updating playback parameters. Exactly how long do you think that takes anyway?
I'm not entirely sure what your point was. Or are you agreeing with me?
That's probably true. A similar thing happens with movie studios - when the studio head changes, the new head looks very unfavourably on projects that were green-lit by their predecessor. It seems to have nothing to do with the quality of the project, merely that they're showing that they're in charge now. At some studios where the studio head has been changed frequently, this has been a real pain for the people working there - it makes it very hard to plan ahead, and also your career can be curtailed by showing any enthusiasm for a project that the 'other guy' approved of.
It's a source of constant surprise to me that the heads of large businesses act so much like children a lot of the time. (I know, I should have got used to it by now.)
In case it's hard to work out, here's an alternative (and, I suspect, wholly correct explanation):
You've had real 360 dev kits for not very long - you've had to limp along with some half-way house that probably emulates many things until then. Your game is a launch title. This means it has a hard deadline. Either you launch when the Xbox launches, or you don't. This is a pretty binary state of affairs.
You're under intense time pressure. Most of the tools you're using are new/revised, and you have to create assets that are a different level of detail/effort than the previous games you've made, so you need to learn a lot of new tricks again. While you're updating the game engine itself, of course. Everything's changing.
Now, do you want to add to this volatile mix a bunch of multi-threading stuff for core game mechanics, with all the new code/mechanisms this will entail, and issues produced by multi-threaded access to game data, sync issues, race conditions, etc. and jeopardise the launch date of the game?
Or do you want to do the best you can in the time you have available?
I know which I'd choose.
(Aside: I see a lot of comments about audio, etc - of course multi-threading for stuff like audio playback is a no-brainer. Trust me, that's not the sort of thing that game devs are talking about when they say multi-threading games is hard. Conversely, multi-threading audio playback is not exactly a huge win anyway. The chipsets on these consoles do all the hard stuff - all the audio playback engine is doing is filling buffers and updating playback parameters. Exactly how long do you think that takes anyway?)
Exactly, there's nothing special about computer games that means they cannot be multi-threaded.
Yes there is - games require real-time performance, and to get the best out of the hardware. One of the most common uses of multi-threading is to make sure the UI of an app isn't unresponsive due to a large amount of CPU processing that is being done (or something else with high latency, like network code over the internet).
As another poster has pointed out, a lot of the activities a game goes through are very strongly linked (temporally, and with the amount of shared data). Just saying "use threads" is a good way of slowing this stuff down.
You have to use threads sensibly, obviously, but you also have to know that games are 'special', in that some things you'd think could be multi-threaded would actually be a big performance hit.
I very much doubt that. At one stage (Office v6), the Mac and Windows versions had basically exactly the same GUI code (as well as all the other code). That's changed (mainly due to the poor reception from Mac users of Office 6), but I find it hard to believe that MS completely re-implemented Word, Excel, etc, just for the Mac. That is a lot of code to write again (for no particularly good reason).
The only 'trick' I see here incompetence -- on the part of whining developers who write cross-platform code and then complain that Microsoft's platform-optimized code runs faster than theirs.
When you switch from VS to GCC you suddenly find many things you had taken for granted aren't there. Hey, where's the RAD?
I fail to see how providing RAD tools in VS is somehow a shortcoming. Isn't that like saying you should rip most of the features out of Emacs because when you have to use another editor they won't be there anymore?
Why don't my #import's work?
Anyone who switches from VC to GCC and expects #import to work has bigger problems to worry about. Being a muppet, for one.
Another semi-retarded thing about Windows Media Center is that it records TV in a proprietary Microsoft format, DVR-MS. I am told that this is MPEG internally, but you need to export it with a different piece of software (NeroVision Express works) if you want to get a usable file that you could convert to XviD, for example.
The reason for DVR-MS is to enable metadata to be stored in the video file itself (show title, synopsis, cast, etc), and raw mpeg doesn't allow this. This would be ok if MS produced a simple utility to convert DVR-MS to mpeg (there are a few 3rd party progs that sort of do this - if you're lucky) but of course they don't.
What's more, every video format you play in Windows Media Center is handled with a DirectShow filter. That's good, in the sense that when you install new codecs in XP they are automatically picked up by Media Center, so you can play your DivX, XviD, etc. There is one caveat, however, and that is that you can't stream these formats to another system via a Media Center Connector or whatever you call it, like your Xbox 360. I think only Windows Media and MPEG formats are supported.
I think this is only true of the Xbox 360, mainly due to the issue of supporting arbitrary codecs. If you could install standard Windows codecs on the Xbox 360, then bingo - code injection, and all the hardware encryption/protection is bypassed at a stroke.
Of course, there's nothing to stop MS providing DivX codecs etc via a signed download on Xbox Live...but hands up who thinks that will happen?:-)
So, yeah, this "review" is dumb, and you shouldn't expect to be able to bash together a Media Center PC in a weekend and expect it to work.
Well, not just anyone can, but that's basically what I did, and it works - no hardware issues that I'm aware of. I'm not counting damaged S-Video connectors as being Microsoft's fault. But then I was careful to make sure I got approved hardware, and checked the MCE forums to see which TV tuner etc people recommended.
MCE does have issues - some v. annoying, but these seem to be inherent to MCE itself (iyswim), and not due to someone having a squiffy tuner card or something.
I should probably point out that I live in the UK and am receiving all my TV via DVB-T, so it's all in lovely mpeg by the time it arrives, so MCE basically just has to dump the mpeg data to disk when recording - I've certainly never had lip sync issues, anyway. With analog tv capture cards, you may well be watching TV like it's a 1997 DVD player:)
I was watching TV earlier, because I don't have the energy to spend all my free time telling people that I don't watch TV. It's easier to just watch TV.
Slashdot Mirror
Debugging the Development Process by Steve Maguire has some interesting insight (mostly as asides or side-bars) into the cross-platform nature of Office, in particular Excel, because Maguire was one of the driving forces between getting the core functionality to be cross-platform. Before that there was a constant disparity in features between the Mac and Windows versions.
And here is another quite interesting history of Word, in case you think it's a latecomer to Windows.
Your sense of humour appears to have been exceeded.
<SFanning> afk - lawsuit
You missed the explosion! :-)
Never mind, it'll be duped in a day or two...
What's your point?
After all, who can forget the Cock Monster on the roof scene? :-)
Well, yes, that would probably be why I went on to say...
I'm not entirely sure what your point was. Or are you agreeing with me?
It's a source of constant surprise to me that the heads of large businesses act so much like children a lot of the time. (I know, I should have got used to it by now.)
Ok, ok, I'll have the fries. Quit bugging me.
'Long'?
The boingboing post is 450 words long - I'd hardly call that long.
If you take out the words that are just quoting the Forbes article, then it's only 150 words long.
I mean, yeah, compared to the 'can't be arsed' posting style of Dave Winer, which would probably be:
...then I guess it's long.
I blame MTV. Or something.
Of course it's not true.
In case it's hard to work out, here's an alternative (and, I suspect, wholly correct explanation):
You've had real 360 dev kits for not very long - you've had to limp along with some half-way house that probably emulates many things until then. Your game is a launch title. This means it has a hard deadline. Either you launch when the Xbox launches, or you don't. This is a pretty binary state of affairs.
You're under intense time pressure. Most of the tools you're using are new/revised, and you have to create assets that are a different level of detail/effort than the previous games you've made, so you need to learn a lot of new tricks again. While you're updating the game engine itself, of course. Everything's changing.
Now, do you want to add to this volatile mix a bunch of multi-threading stuff for core game mechanics, with all the new code/mechanisms this will entail, and issues produced by multi-threaded access to game data, sync issues, race conditions, etc. and jeopardise the launch date of the game?
Or do you want to do the best you can in the time you have available?
I know which I'd choose.
(Aside: I see a lot of comments about audio, etc - of course multi-threading for stuff like audio playback is a no-brainer. Trust me, that's not the sort of thing that game devs are talking about when they say multi-threading games is hard. Conversely, multi-threading audio playback is not exactly a huge win anyway. The chipsets on these consoles do all the hard stuff - all the audio playback engine is doing is filling buffers and updating playback parameters. Exactly how long do you think that takes anyway?)
Yes there is - games require real-time performance, and to get the best out of the hardware. One of the most common uses of multi-threading is to make sure the UI of an app isn't unresponsive due to a large amount of CPU processing that is being done (or something else with high latency, like network code over the internet).
As another poster has pointed out, a lot of the activities a game goes through are very strongly linked (temporally, and with the amount of shared data). Just saying "use threads" is a good way of slowing this stuff down.
You have to use threads sensibly, obviously, but you also have to know that games are 'special', in that some things you'd think could be multi-threaded would actually be a big performance hit.
I very much doubt that. At one stage (Office v6), the Mac and Windows versions had basically exactly the same GUI code (as well as all the other code). That's changed (mainly due to the poor reception from Mac users of Office 6), but I find it hard to believe that MS completely re-implemented Word, Excel, etc, just for the Mac. That is a lot of code to write again (for no particularly good reason).
Wait...Einstein was from Thailand?!
This is brand new information!
Even more so, when you consider this.
The other problem with rats is that when I call the helpline, most of the time I can't understand their accents.
I fail to see how providing RAD tools in VS is somehow a shortcoming. Isn't that like saying you should rip most of the features out of Emacs because when you have to use another editor they won't be there anymore?
Anyone who switches from VC to GCC and expects #import to work has bigger problems to worry about. Being a muppet, for one.
The reason for DVR-MS is to enable metadata to be stored in the video file itself (show title, synopsis, cast, etc), and raw mpeg doesn't allow this. This would be ok if MS produced a simple utility to convert DVR-MS to mpeg (there are a few 3rd party progs that sort of do this - if you're lucky) but of course they don't.
I think this is only true of the Xbox 360, mainly due to the issue of supporting arbitrary codecs. If you could install standard Windows codecs on the Xbox 360, then bingo - code injection, and all the hardware encryption/protection is bypassed at a stroke.
Of course, there's nothing to stop MS providing DivX codecs etc via a signed download on Xbox Live...but hands up who thinks that will happen? :-)
Well, not just anyone can, but that's basically what I did, and it works - no hardware issues that I'm aware of. I'm not counting damaged S-Video connectors as being Microsoft's fault. But then I was careful to make sure I got approved hardware, and checked the MCE forums to see which TV tuner etc people recommended.
MCE does have issues - some v. annoying, but these seem to be inherent to MCE itself (iyswim), and not due to someone having a squiffy tuner card or something.
I should probably point out that I live in the UK and am receiving all my TV via DVB-T, so it's all in lovely mpeg by the time it arrives, so MCE basically just has to dump the mpeg data to disk when recording - I've certainly never had lip sync issues, anyway. With analog tv capture cards, you may well be watching TV like it's a 1997 DVD player :)
Or, you might say:
Ok, now we know you bought that UID!
It's never been cool to get a first post :-)
Yes - to use one of my favourite expressions, I've seen horseshit that had less horseshit in it.
Let me rephrase it: "If you find a problem that you can't solve, then I don't want to know about the problem."
I'm guessing it doesn't sound like such good advice now.
Configuring the external editor to be a preview app instead of an editor, just so you can actually view your photos in a photo management app?
Well, I think we'll all agree, it doesn't get any more obvious or intuitive than that!
Did you even read the article? (Ok, it was a Dvorak article, but even so... :-)
:-)
Are you really saying that you think the chipset hasn't changed because the machine looks EXACTLY the same from the outside?
The chips are, like, on the inside. Unless I'm missing something.