With the all-important difference that fgets() allows (indeed, requires) you to specify the buffer size, and gets() doesn't. fgets(buf, sizeof(buf), stdin) will stop reading when the buffer fills up if it hasn't hit a new-line yet; gets(buf) won't, and there's no way to convince it to.
Ah, yes, brain fart. I was thinking "fscanf()" when seeing "fgets()".
Re:Promoting for the XBox...
on
XBox Delayed
·
· Score: 1
Notice even that the original dates for each system's release were also 3 days apart, but with the upper-hand being given the Nintendo (Nov 5th vs. Nov 8th).
Just to pick pits, but fgets() is no safer than gets(). gets() is simply a more specific version of fgets(), using stdin as the file handle. The only way to make gets() and fgets() safe is to not use them. The same goes for other calls, as well, like scanf()/fscanf()/sscanf(). I know it's easier said than done, and I have been guilty of writing such code in the past, as well, but to truly be safe, you can't use these functions at all. Ever. Some people might think that it's safe to use fgets or fscanf when they're not dealing directly with user input. This is not correct. By definition, these functions read from a filehandle (stdin, a real file, a pipe, whatever). That means that you're reading data outside of your program that can potentially be changed. You might think, "Oh, but it's safe to use these to read a config file, because only root has access to that," but what happens if root makes a mistake in the config file that you didn't anticpate?
The point is, not all unsafe functions have a safe counterpart (strictly referring to ansi c functions, for the sake of argument, but this could probably be extended as a truism). In some cases, the only safe option is to do something else instead.
Nope. The "subtle bug" he's referring to is that the string should be length 9 (for the terminating NULL). However, there's an even more subtle bug, in that the string:
char foo[8];
is allocated on the stack, making it a much more enticing target for a buffer overflow.
It seems like every time you get input from the outside, you would only accept it in segments of a known length, and whatever was longer would just wait for the next "get" or whatever. At least this is the case in my (obviously limited) socket programming experience. So when some program is hit with a buffer overflow error, does the team of programmers smack their collective head and say "d'oh"?
The problem lies not in the realm of receiving the information, but actually processing it. What do you think happens after you've received all the necessary data chunks for the requested URL? They're put together and treated like a string, then parsed out for various pieces of data (the path to the file being requested, the type of file based on MIME types, any data parameters (passed from a form, for instance), and any other interesting information your server may be looking for). Now, with insecure coding practices, it's very easy to get a buffer overflow simply by doing something as innocuous as a call to sprintf() (because sprintf doesn't do any bounds checking). The really dangerous part, however, is when the target string is on the stack. Now, when that buffer overflows, a carefully constructed overflow string can easily put executable code into the stack and change the return address on the stack to point to the beginning of that executable code. This is sometimes referred to as "smashing the stack". If instead you're dealing with heap-allocated buffers, it's harder to get code executed, but you can still just as easily cause an access violation and kill the server anyway.
I'm not trying to pick on sprintf directly, because there are a ton of other potentially unsafe (any unbounded string operation, for instance) or always unsafe (gets, fgets, any function that expects a string to be formatted in a certain way, etc) functions that are used commonly. In fact, too many people use these functions without even knowing that they're opening themselves up to major problems.
One way to mitigate the possibility of having a buffer overflow in your application is by always using bounded string ops (snprintf, strncpy, etc) (note that strncat is a special case, in that the 'n' refers to the amount of chars to be appended, not the size of the target buffer). Another way is to simply not use the completely unsafe functions, like *gets(). These won't guarantee that you'll be safe, but it's a start. There are plenty of resources out there, so if you're interested, I suggest you do some reading.
So, you are only allowed 10 machines on your network which have the ability to talk to XP?
Uh... XP is not a Server operating system, so why would you be running services off of it, other than maybe a personal file share?
Thats just as silly as only being able to run it on a single CPU machine.
Only XP Home is limited to a single CPU machine. Of course, since XP Home is meant to replace win9x, I don't see the problem -- win9x doesn't support multiple CPUs, and so neither does XP Home. XP Pro will allow you to install on dual-proc machines just fine. Just like Windows 2000 Pro, incidentally. For n-way higher than 2, you should either use the Windows 2000 server family, or wait for the Windows 2002.NET server family.
So the only businesses that actually make money on the internet are now barred from using Microsoft's web server?
Sigh. You're quite wrong. Let me list the ways:
FrontPage != IIS. This bears repeating, so -- FrontPage != IIS.
The EULA in question applies to FrontPage. In fact, it doesn't even apply to FrontPage the application, but the FrontPage Web Components
That means that you can't use the MSN Stock Ticker, the MSNBC headlines, Expedia maps, and so on.
However, when was the last time you actually went to a porn page for stock quotes, news headlines, driving directions or hotel accomodations, etc?
You're simply jerking your knee. The original story is now hours old, and many of the comments have made it abundantly clear that this is not a restriction on the usage of FrontPage as an IDE, or IIS as a web server, or Windows 2000 as a server, or whatever other Slashdot-ism you want to bring up.
Re:At what point...
on
2.2 GHz Xeon
·
· Score: 2, Insightful
The difference here is that you're talking about a constant 24fps or 30fps (film vs. NTSC -- those numbers aren't exactly right, because most film projectors open the shutter 2-3 times per frame, making an apparent 48-72fps, while NTSC is interlaced, making an apparent 60fps) with motion blurring and other movement artifacts that make frames flow together. For a video game (quake, for instance), you're talking an average fps, meaning that if you're getting an average of 30fps, you're very likely going to drop down into the teens when you run into heavy action. 60fps is the "sweet spot", since you should still stay above 30fps even in heavy action. That said, there are no motion blur effects with video games (well, yet anyway -- when 3dfx tried to do that, they ended up getting an average of 3-4fps), which means that you need a higher fps just to see smooth motion. In other words, the point of having 100+fps in a video game, average case, is to make the worst case still look smooth.
Anyway, once you can achieve an average fps of 100+, it's time to start turning that detail level up. A GeForce 3 may scream with nearly 200fps in Q3A, in 640x480x16bpp with all the details turned down, and even get a decent 80fps or so with higher detail, but the next-gen games are going to be clocking in much lower, simply due to the fact that they are so graphically rich. What that means is that video accelerators will need to continue to improve, so that we can hit the 100+fps mark on these newer, higher-detail games, so that the generation after that can go back down to 30fps with even more detail, and so on.
Having glanced at the bug, I'd guess (without digging into any Mozilla code) that the problem is not that Mozilla dialogs are not Windows dialogs (which, as the bug points out, they are), but that Mozilla buttons and other widgets are not Windows buttons and widgets.
Let me reiterate by stating that I have not looked at the Mozilla source, but it is my understanding that a button, or listbox, or textbox, or label or any other widget is in XUL is defined by XUL. They are not just wrappers for native widgets (they probably should be, with a user-drawn attribute and all the necessary handling code), for if they were, then a default button on a dialog would be a default button on a dialog. As it is, a "button" on a XUL dialog appears to be a bitmap that happens to react to mouseovers, mouseclicks, and possibly keyboard presses, and a "default button" is a fore-mentioned "button" that the dialog knows should accept keyboard input when no other "button" has focus.
If I'm wrong about this, feel free to correct me. Maybe I'll dig into the Mozilla win32 code this evening and find out for myself. But if I'm right, the only real way to fix this that I know of is to actually use wrapped native widgets, at least for a default button.
Or, you could simply go to MSDN and get all that documentation for free. Sure, you have to know that it's there before you can use it, but once you've learned about it, it doesn't cost a thing.
Isn't this similar to how Unix does things? Instead of monolithic applications (*cough* MS *cough*), we have a number of smaller apps that can be linked to do something else (i.e. awk, sed, grep, find etc).
Although you may not realize it, Microsoft apps also tend to be many smaller pieces linked into a whole. Everything is a COM object. MSXML is an object that can parse XML, mshtml handles HTML. Word is a container for a bunch of COM objects (the word processor, the spell checker, the smart tags, etc), Excel is a container for a bunch of COM objects, IE is a container, and so on. Just because each one of these components is not a separate program does not mean that they cannot be reused or linked together.
The standard UNIX "method" is to take all those "single-purpose" apps like awk, or sed, or grep, and glue them together with shell script, or perl script, or tcl script, or some other scripting language. The same method applies to Windows as well. You can access COM objects via WSH (using JScript, VBScript, PerlScript, or any other language that has an implementation of a COM interface that can plug into the Windows Scripting Host), and then you can glue those objects all together into a larger whole. What's more, though, is that you can utilize these objects within actual compiled code, as well. C, C++, VB, C#, any language with a CLR target, ASP/ASP+ (in C#, VBScript, JScript, PerlScript,...) all can reuse thse objects, unlike in the UNIX model wherein a C app would have to fork to spawn a new process and exec something like grep or sed, make a system() call, or "borrow" code from those tools. And in the code-borrowing case, you're limited to the language that the code was written in (and close relatives, as you can use C code in C++ and ObjC for instance).
Obviously, projects like KDE's KOM/KParts architectures borrow heavily from this idea, and succeed well. But these projects have much farther to go before they'll reach the level of binary reuse and interoperability that Windows has had for years. And yes, I know about CORBA, but compared to COM or KOM/KParts, or even Mozilla's XPCOM, it's cludgy, bloated, and nasty, and is a much heavier paradigm (for instance, it requires an object broker).
I'm assuming XBox is running the modified wince (ouch) that Dreamcast was supposed to ship with
Actually, the XBox is running a stripped-down version of Windows 2000 (for instance, no virtual memory management, and it allows direct hardware access without having to use OpenGL or DX, though both of those are also available, with DX being a bit more tuned for the hardware since it's Microsoft's API of choice and Microsoft's hardware).
That's where the beauty of a high-level graphics interface (a la OpenGL, or DirectX) comes into play -- as long as all the chipset manufacturers are providing similar functions, such as vertex and pixel shading, hardware T&L, FSAA, and so on, it doesn't quite matter just how those features are implemented. The API you're using will abstract it enough for you. Yes, I know you can write manufacturer extensions to OpenGL, and to use them means special-casing some of your code, but it's often worth the small amount of extra work to take advantage of those extensions. As an example of games being able to take advantage of new hardware features while still being backwards-compatible with older cards, look at Id's work (Quake 3 Arena, in particular, but everything since glQuake makes a good example).
nVidia may be the de facto 3D accelerator standard, but ATI is still plugging away with their new Radeon card. The only problem I see is that it's pretty hard to compete with a company on a 6-month release cycle when you're on a year+ cycle (even if half of the other company's releases are just refreshes of their last chipset, there's still a total increase in speed or features). Add to that nVidia's excellent driver support (what other chipset manufacturer can claim a 10%-30% speed increase solely by upgrading drivers? who else can say that they can release a single driver binary and cover their entire product line -- from the original TNT1 to the GeForce3, everything in between, and future chipsets?), and ATI has an uphill battle in the hardware acceleration market. At least they have a healthy income from OEM partners to help finance their higher-end work.
Perhaps the ability to write mods (actionquake, ctf, tf) was what made Quake 2 great...
Actually, the ability to write mods first started with Quake 1, in the form of QuakeC. Some of the most classic game types started out with Quake 1 -- CTF (first implementation written by Zoid), TF (from the TeamFortress software guys, added the game types you see now as Dominion and Assault in UT), the proliferation of weapon packs, Total Conversions (like the Alien Quake TC, which coined the term "Foxed" when they were shut down by Fox), and so on. All Quake 2 had going for it above and beyond Quake 1 was Player-pluggable models, and the usage of dynamically linked libraries in whatever language you wished instead of using QuakeC for the scripting.
Re:I hope they model it after q2 and not q3.
on
Quake 4 Announced
·
· Score: 3, Informative
Counterstrike, one of the most popular multiplayers games at this time, is based on the q2 engine (heavily modified by Valve), so this says something about the enduring appeal of q2, and its associated engine.
Actually, Counter-strike is just a modification for Half-Life, which itself was originally based on the Quake 1 engine, but Valve heavily modified it (skeletal animation, scripting, etc) and rolled in some updates from Quake 2 as well. Thus, the Half-Life engine is really an amalgam of Q1 and Q2, with a lot of Valve thrown in as well. Which, btw, would explain why it's also very dated-looking (which doesn't have to be such a bad thing, as long as the games are still fun).
What the hell does Outlook have to do at all wiht Code Red?
Let's assume for a second that you were talking about Taco's reference to SirCam. Now, a couple things come to mind.
It's not Microsoft's fault that users actively executed an attachment -- That's the user's own damned problem.
Microsoft has done quite a bit to protect users from themselves (from popping up a warning on every attachment, to actively stripping malicious attachments in Outlook XP).
Microsoft has addressed this issue in service packs for earlier versions, by actively stripping attachments and/or disallowing the execution of an attachment.
While Microsoft's license does disavow them from any responsibility for your ineptitude, they do still put out hot fixes and service packs.
There's no excuse for the SirCam virus, because the hf's and sp's that prevent such a thing have existed for years now.
Please take some personal responsibility when you do something stupid (like execute an attachment), just as others should take the same responsibility when they screw up. Yelling, "There should be a law!" just makes you look like a dumb liberal that needs the government to protect him from himself.
what, this new OS I bought won't let me trade MP3s?
Uh... what? Who ever said that? How could Microsoft even stop such a thing? I don't get it.
(And for the record, I am using XP RC1, so I'd think I would know whether or not mp3-sharing has been blocked.) (Not that it's possible to block such a thing, short of disallowing the installation of sharing apps, which is also not possible.)
Not long ago, Lowtax had "Go the Fuck Away" week on Somthing Awful. He can barely afford the normal SA traffic (and by "barely", I mean "usually can't"). He's been fucked over by multiple ad networks, gone for 6+ months without getting a paycheck, and yet continues to put out "teh funney". And then Slashdot links to SA. Goodbye, SA, it was nice knowing you.
Was linking to SA really necessary? I'm sure there are other reviews out there that could have been linked, reviews on major gaming sites that expect this kind of thing. I won't say it's "bad journalism", because Slashdot has little to do with actual journalism. I will say it was a bad judgement call on Hemos' part to leave those links in the submitted story.
Actually, the games from Westwood were Dune 2 (the birthplace of RTS games), and its refresh, Dune 2000. There was another Dune game before Dune 2, however (thus the name "Dune 2"). It was an adventure/strategy game. I don't remember who the developer was, but it wouldn't surprise me if it were also Westwood. Anyway, the graphics were quite good for the time, and it was a rather fun game to play. There's a new adventure game based on Dune in the works, and hopefully it will follow in the footsteps of that original Dune game.
And no, it wasn't an FPS, and Id didn't develop it. Dune would suck as an FPS, because most fighting was done via knives (steel or crys).
I didn't want to go so low that the guy couldn't understand what I was talking about. I mean, $400 - $30 = the PS2 is practically free! (well, by his math, anyway)
As we all know, Sony sells these things at a loss in order to make money on game licensing
This is a myth. They sell at a slight profit, whose margin increases monthly
Let's see some figures proving this, eh? It's a well-known fact that the gaming console market is all about loss-leaders. Sell the razors below cost, make the money on the blades. Yes, Sony may make a profit on the PSOne hardware now, but that's been out for what, 6 years? 7 years? The PS2 is still a loss for them, and they're going to be forced to take even more of a loss to be able to compete price-wise with the GameCube.
it runs x86 software
And do you want the third world to be using closed-source proprietory binary-only software?
Instead, let's have the third-world run closed, proprietary, one-vendor hardware. That sounds like a much better alternative! And while we're at it, let's not leverage the existing HUGE library of x86 code (open and closed), and rewrite everything for the PS2 architecture.
Much of the PS2 cost goes into ultra-high performance graphics acceleration
And yet it still comes in as a whole system - new - for less than the cost of a decent graphics card for a PC. Cost counts; sometimes a cheap sledgehammer is better than an expensive nutcracker.
This must be that "new math" I keep hearing about. The current state-of-the-art consumer-grade video accelerator, the GeForce 3, is retailing below $400, now (check pricewatch. $350 is the average price for a reference board). So, the PS2 is still selling at $400, which means $400 - $350 = the PS2 is cheaper? What? Not to mention the fact that you qualified your statement with "decent graphics card", which means you'd consider a GeForce2 MX, Radeon, or Kyro II board, which go for between $100 and $200. $400 - $200 = Damn, the PS2 is even cheaper now!. I'm sorry, but no. "New Math" doesn't work, and the PS2 is not cheaper than a decent PC graphics accelerator (it's by far more expensive!).
Well, the problem here is that StarOffice is a far cry from Microsoft Office, in terms of usability, stability, compatibility (with MS Office documents, that is), and even speed. The only thing StarOffice has going for it is that it runs on non-Microsoft operating systems, but as you've seen that's not enough to make a difference. If you want to see StarOffice more widely adopted, help make it a better application (or push Sun to make it a better application), as it's currently pretty bad.
.NET is Microsoft's platform for XML Web services, the next generation of software that connects our world of information, devices and people in a unified, personalized way.
In other words,.NET is about XML Web Services. So of the items you listed, only #2 is.NET. The rest are supporting.NET, but are not.NET themselves. #1 is.NET development tools (Visual Studio.NET, the CLR, C#), #3 (Passport) is an instance of an XML Web Service, and #4 (Hailstorm) is both an instance of an XML Web Service and a platform for easily building XML Web Services.
Of course, just because those components are not.NET does not mean that suitable replacements will not need to be made if Ximian is really going to try to make a.NET "clone"
Its bullshit. Firstly, they can't enforce it -- I can use their "shared source" code with any GPL program I want to and they can't do a fucking thing to stop me.
Uh... let's try a bit of word substitution: Its bullshit. Firstly, they can't enforce it -- I can use their "GPL" code with any non-GPL program I want to and they can't do a fucking thing to stop me. Cuts both ways, doesn't it? Of course, the real key here is that this is an SDK, so "use" means "linking against", not "running Office". It's not distributed with the operating system, and so pursuant to the terms of the GPL, you can't link to it anyway (since it's not open). What Microsoft is saying is just reaffirming the GPL. Some of the other licenses mentioned are questionable, but that's just Microsoft covering their asses.
When I buy a piece of software, I own it in the same sense that I own a book -- I can do whatever the fuck I want with it,...
No, you don't. When you "buy" a piece of software, you own a license to use that software. You DON'T own the software in any way, shape or form (try reading a EULA sometime, eh?). Thus, your book analogy is irrelevant. Of course, any analogy you make to physical property is not going to be appropriate, though you could get close by thinking of "buying" software as renting a house -- you can use the house all you want, but you'll generally need permission from your landlord before modifying anything, and the landlord reserves the right to kick you out. And as far as enforcement goes, you're both right and wrong. If you're just a little individual developer playing around with this SDK, then they'll probably not look at you twice -- until you go and release your software under a GPL license while linking against their SDK. Microsoft has lawyers, and they're not afraid to use them.
Slashdot Mirror
Ah, yes, brain fart. I was thinking "fscanf()" when seeing "fgets()".
Notice even that the original dates for each system's release were also 3 days apart, but with the upper-hand being given the Nintendo (Nov 5th vs. Nov 8th).
Just to pick pits, but fgets() is no safer than gets(). gets() is simply a more specific version of fgets(), using stdin as the file handle. The only way to make gets() and fgets() safe is to not use them. The same goes for other calls, as well, like scanf()/fscanf()/sscanf(). I know it's easier said than done, and I have been guilty of writing such code in the past, as well, but to truly be safe, you can't use these functions at all. Ever. Some people might think that it's safe to use fgets or fscanf when they're not dealing directly with user input. This is not correct. By definition, these functions read from a filehandle (stdin, a real file, a pipe, whatever). That means that you're reading data outside of your program that can potentially be changed. You might think, "Oh, but it's safe to use these to read a config file, because only root has access to that," but what happens if root makes a mistake in the config file that you didn't anticpate?
The point is, not all unsafe functions have a safe counterpart (strictly referring to ansi c functions, for the sake of argument, but this could probably be extended as a truism). In some cases, the only safe option is to do something else instead.
Nope. The "subtle bug" he's referring to is that the string should be length 9 (for the terminating NULL). However, there's an even more subtle bug, in that the string:
char foo[8];
is allocated on the stack, making it a much more enticing target for a buffer overflow.
The problem lies not in the realm of receiving the information, but actually processing it. What do you think happens after you've received all the necessary data chunks for the requested URL? They're put together and treated like a string, then parsed out for various pieces of data (the path to the file being requested, the type of file based on MIME types, any data parameters (passed from a form, for instance), and any other interesting information your server may be looking for). Now, with insecure coding practices, it's very easy to get a buffer overflow simply by doing something as innocuous as a call to sprintf() (because sprintf doesn't do any bounds checking). The really dangerous part, however, is when the target string is on the stack. Now, when that buffer overflows, a carefully constructed overflow string can easily put executable code into the stack and change the return address on the stack to point to the beginning of that executable code. This is sometimes referred to as "smashing the stack". If instead you're dealing with heap-allocated buffers, it's harder to get code executed, but you can still just as easily cause an access violation and kill the server anyway.
I'm not trying to pick on sprintf directly, because there are a ton of other potentially unsafe (any unbounded string operation, for instance) or always unsafe (gets, fgets, any function that expects a string to be formatted in a certain way, etc) functions that are used commonly. In fact, too many people use these functions without even knowing that they're opening themselves up to major problems.
One way to mitigate the possibility of having a buffer overflow in your application is by always using bounded string ops (snprintf, strncpy, etc) (note that strncat is a special case, in that the 'n' refers to the amount of chars to be appended, not the size of the target buffer). Another way is to simply not use the completely unsafe functions, like *gets(). These won't guarantee that you'll be safe, but it's a start. There are plenty of resources out there, so if you're interested, I suggest you do some reading.
Uh ... XP is not a Server operating system, so why would you be running services off of it, other than maybe a personal file share?
Only XP Home is limited to a single CPU machine. Of course, since XP Home is meant to replace win9x, I don't see the problem -- win9x doesn't support multiple CPUs, and so neither does XP Home. XP Pro will allow you to install on dual-proc machines just fine. Just like Windows 2000 Pro, incidentally. For n-way higher than 2, you should either use the Windows 2000 server family, or wait for the Windows 2002 .NET server family.
Sigh. You're quite wrong. Let me list the ways:
You're simply jerking your knee. The original story is now hours old, and many of the comments have made it abundantly clear that this is not a restriction on the usage of FrontPage as an IDE, or IIS as a web server, or Windows 2000 as a server, or whatever other Slashdot-ism you want to bring up.
The difference here is that you're talking about a constant 24fps or 30fps (film vs. NTSC -- those numbers aren't exactly right, because most film projectors open the shutter 2-3 times per frame, making an apparent 48-72fps, while NTSC is interlaced, making an apparent 60fps) with motion blurring and other movement artifacts that make frames flow together. For a video game (quake, for instance), you're talking an average fps, meaning that if you're getting an average of 30fps, you're very likely going to drop down into the teens when you run into heavy action. 60fps is the "sweet spot", since you should still stay above 30fps even in heavy action. That said, there are no motion blur effects with video games (well, yet anyway -- when 3dfx tried to do that, they ended up getting an average of 3-4fps), which means that you need a higher fps just to see smooth motion. In other words, the point of having 100+fps in a video game, average case, is to make the worst case still look smooth.
Anyway, once you can achieve an average fps of 100+, it's time to start turning that detail level up. A GeForce 3 may scream with nearly 200fps in Q3A, in 640x480x16bpp with all the details turned down, and even get a decent 80fps or so with higher detail, but the next-gen games are going to be clocking in much lower, simply due to the fact that they are so graphically rich. What that means is that video accelerators will need to continue to improve, so that we can hit the 100+fps mark on these newer, higher-detail games, so that the generation after that can go back down to 30fps with even more detail, and so on.
Having glanced at the bug, I'd guess (without digging into any Mozilla code) that the problem is not that Mozilla dialogs are not Windows dialogs (which, as the bug points out, they are), but that Mozilla buttons and other widgets are not Windows buttons and widgets.
Let me reiterate by stating that I have not looked at the Mozilla source, but it is my understanding that a button, or listbox, or textbox, or label or any other widget is in XUL is defined by XUL. They are not just wrappers for native widgets (they probably should be, with a user-drawn attribute and all the necessary handling code), for if they were, then a default button on a dialog would be a default button on a dialog. As it is, a "button" on a XUL dialog appears to be a bitmap that happens to react to mouseovers, mouseclicks, and possibly keyboard presses, and a "default button" is a fore-mentioned "button" that the dialog knows should accept keyboard input when no other "button" has focus.
If I'm wrong about this, feel free to correct me. Maybe I'll dig into the Mozilla win32 code this evening and find out for myself. But if I'm right, the only real way to fix this that I know of is to actually use wrapped native widgets, at least for a default button.
Or, you could simply go to MSDN and get all that documentation for free. Sure, you have to know that it's there before you can use it, but once you've learned about it, it doesn't cost a thing.
Although you may not realize it, Microsoft apps also tend to be many smaller pieces linked into a whole. Everything is a COM object. MSXML is an object that can parse XML, mshtml handles HTML. Word is a container for a bunch of COM objects (the word processor, the spell checker, the smart tags, etc), Excel is a container for a bunch of COM objects, IE is a container, and so on. Just because each one of these components is not a separate program does not mean that they cannot be reused or linked together.
The standard UNIX "method" is to take all those "single-purpose" apps like awk, or sed, or grep, and glue them together with shell script, or perl script, or tcl script, or some other scripting language. The same method applies to Windows as well. You can access COM objects via WSH (using JScript, VBScript, PerlScript, or any other language that has an implementation of a COM interface that can plug into the Windows Scripting Host), and then you can glue those objects all together into a larger whole. What's more, though, is that you can utilize these objects within actual compiled code, as well. C, C++, VB, C#, any language with a CLR target, ASP/ASP+ (in C#, VBScript, JScript, PerlScript, ...) all can reuse thse objects, unlike in the UNIX model wherein a C app would have to fork to spawn a new process and exec something like grep or sed, make a system() call, or "borrow" code from those tools. And in the code-borrowing case, you're limited to the language that the code was written in (and close relatives, as you can use C code in C++ and ObjC for instance).
Obviously, projects like KDE's KOM/KParts architectures borrow heavily from this idea, and succeed well. But these projects have much farther to go before they'll reach the level of binary reuse and interoperability that Windows has had for years. And yes, I know about CORBA, but compared to COM or KOM/KParts, or even Mozilla's XPCOM, it's cludgy, bloated, and nasty, and is a much heavier paradigm (for instance, it requires an object broker).
Actually, the XBox is running a stripped-down version of Windows 2000 (for instance, no virtual memory management, and it allows direct hardware access without having to use OpenGL or DX, though both of those are also available, with DX being a bit more tuned for the hardware since it's Microsoft's API of choice and Microsoft's hardware).
That's where the beauty of a high-level graphics interface (a la OpenGL, or DirectX) comes into play -- as long as all the chipset manufacturers are providing similar functions, such as vertex and pixel shading, hardware T&L, FSAA, and so on, it doesn't quite matter just how those features are implemented. The API you're using will abstract it enough for you. Yes, I know you can write manufacturer extensions to OpenGL, and to use them means special-casing some of your code, but it's often worth the small amount of extra work to take advantage of those extensions. As an example of games being able to take advantage of new hardware features while still being backwards-compatible with older cards, look at Id's work (Quake 3 Arena, in particular, but everything since glQuake makes a good example).
nVidia may be the de facto 3D accelerator standard, but ATI is still plugging away with their new Radeon card. The only problem I see is that it's pretty hard to compete with a company on a 6-month release cycle when you're on a year+ cycle (even if half of the other company's releases are just refreshes of their last chipset, there's still a total increase in speed or features). Add to that nVidia's excellent driver support (what other chipset manufacturer can claim a 10%-30% speed increase solely by upgrading drivers? who else can say that they can release a single driver binary and cover their entire product line -- from the original TNT1 to the GeForce3, everything in between, and future chipsets?), and ATI has an uphill battle in the hardware acceleration market. At least they have a healthy income from OEM partners to help finance their higher-end work.
The Aliens Quake TC was Foxed before OLGA was shut down, so by prior art, Aliens Quake can claim the "Foxed" term.
Actually, the ability to write mods first started with Quake 1, in the form of QuakeC. Some of the most classic game types started out with Quake 1 -- CTF (first implementation written by Zoid), TF (from the TeamFortress software guys, added the game types you see now as Dominion and Assault in UT), the proliferation of weapon packs, Total Conversions (like the Alien Quake TC, which coined the term "Foxed" when they were shut down by Fox), and so on. All Quake 2 had going for it above and beyond Quake 1 was Player-pluggable models, and the usage of dynamically linked libraries in whatever language you wished instead of using QuakeC for the scripting.
Actually, Counter-strike is just a modification for Half-Life, which itself was originally based on the Quake 1 engine, but Valve heavily modified it (skeletal animation, scripting, etc) and rolled in some updates from Quake 2 as well. Thus, the Half-Life engine is really an amalgam of Q1 and Q2, with a lot of Valve thrown in as well. Which, btw, would explain why it's also very dated-looking (which doesn't have to be such a bad thing, as long as the games are still fun).
What the hell does Outlook have to do at all wiht Code Red?
Let's assume for a second that you were talking about Taco's reference to SirCam. Now, a couple things come to mind.
- It's not Microsoft's fault that users actively executed an attachment -- That's the user's own damned problem.
- Microsoft has done quite a bit to protect users from themselves (from popping up a warning on every attachment, to actively stripping malicious attachments in Outlook XP).
- Microsoft has addressed this issue in service packs for earlier versions, by actively stripping attachments and/or disallowing the execution of an attachment.
- While Microsoft's license does disavow them from any responsibility for your ineptitude, they do still put out hot fixes and service packs.
- There's no excuse for the SirCam virus, because the hf's and sp's that prevent such a thing have existed for years now.
Please take some personal responsibility when you do something stupid (like execute an attachment), just as others should take the same responsibility when they screw up. Yelling, "There should be a law!" just makes you look like a dumb liberal that needs the government to protect him from himself.Uh ... what? Who ever said that? How could Microsoft even stop such a thing? I don't get it.
(And for the record, I am using XP RC1, so I'd think I would know whether or not mp3-sharing has been blocked.) (Not that it's possible to block such a thing, short of disallowing the installation of sharing apps, which is also not possible.)
Not long ago, Lowtax had "Go the Fuck Away" week on Somthing Awful. He can barely afford the normal SA traffic (and by "barely", I mean "usually can't"). He's been fucked over by multiple ad networks, gone for 6+ months without getting a paycheck, and yet continues to put out "teh funney". And then Slashdot links to SA. Goodbye, SA, it was nice knowing you.
Was linking to SA really necessary? I'm sure there are other reviews out there that could have been linked, reviews on major gaming sites that expect this kind of thing. I won't say it's "bad journalism", because Slashdot has little to do with actual journalism. I will say it was a bad judgement call on Hemos' part to leave those links in the submitted story.
Actually, the games from Westwood were Dune 2 (the birthplace of RTS games), and its refresh, Dune 2000. There was another Dune game before Dune 2, however (thus the name "Dune 2"). It was an adventure/strategy game. I don't remember who the developer was, but it wouldn't surprise me if it were also Westwood. Anyway, the graphics were quite good for the time, and it was a rather fun game to play. There's a new adventure game based on Dune in the works, and hopefully it will follow in the footsteps of that original Dune game.
And no, it wasn't an FPS, and Id didn't develop it. Dune would suck as an FPS, because most fighting was done via knives (steel or crys).
I didn't want to go so low that the guy couldn't understand what I was talking about. I mean, $400 - $30 = the PS2 is practically free! (well, by his math, anyway)
Let's see some figures proving this, eh? It's a well-known fact that the gaming console market is all about loss-leaders. Sell the razors below cost, make the money on the blades. Yes, Sony may make a profit on the PSOne hardware now, but that's been out for what, 6 years? 7 years? The PS2 is still a loss for them, and they're going to be forced to take even more of a loss to be able to compete price-wise with the GameCube.
Instead, let's have the third-world run closed, proprietary, one-vendor hardware. That sounds like a much better alternative! And while we're at it, let's not leverage the existing HUGE library of x86 code (open and closed), and rewrite everything for the PS2 architecture.
This must be that "new math" I keep hearing about. The current state-of-the-art consumer-grade video accelerator, the GeForce 3, is retailing below $400, now (check pricewatch. $350 is the average price for a reference board). So, the PS2 is still selling at $400, which means $400 - $350 = the PS2 is cheaper? What? Not to mention the fact that you qualified your statement with "decent graphics card", which means you'd consider a GeForce2 MX, Radeon, or Kyro II board, which go for between $100 and $200. $400 - $200 = Damn, the PS2 is even cheaper now!. I'm sorry, but no. "New Math" doesn't work, and the PS2 is not cheaper than a decent PC graphics accelerator (it's by far more expensive!).
Well, the problem here is that StarOffice is a far cry from Microsoft Office, in terms of usability, stability, compatibility (with MS Office documents, that is), and even speed. The only thing StarOffice has going for it is that it runs on non-Microsoft operating systems, but as you've seen that's not enough to make a difference. If you want to see StarOffice more widely adopted, help make it a better application (or push Sun to make it a better application), as it's currently pretty bad.
From http://www.microsoft.com/net
In other words,Of course, just because those components are not .NET does not mean that suitable replacements will not need to be made if Ximian is really going to try to make a .NET "clone"
Uh ... let's try a bit of word substitution: Its bullshit. Firstly, they can't enforce it -- I can use their "GPL" code with any non-GPL program I want to and they can't do a fucking thing to stop me. Cuts both ways, doesn't it? Of course, the real key here is that this is an SDK, so "use" means "linking against", not "running Office". It's not distributed with the operating system, and so pursuant to the terms of the GPL, you can't link to it anyway (since it's not open). What Microsoft is saying is just reaffirming the GPL. Some of the other licenses mentioned are questionable, but that's just Microsoft covering their asses.
No, you don't. When you "buy" a piece of software, you own a license to use that software. You DON'T own the software in any way, shape or form (try reading a EULA sometime, eh?). Thus, your book analogy is irrelevant. Of course, any analogy you make to physical property is not going to be appropriate, though you could get close by thinking of "buying" software as renting a house -- you can use the house all you want, but you'll generally need permission from your landlord before modifying anything, and the landlord reserves the right to kick you out. And as far as enforcement goes, you're both right and wrong. If you're just a little individual developer playing around with this SDK, then they'll probably not look at you twice -- until you go and release your software under a GPL license while linking against their SDK. Microsoft has lawyers, and they're not afraid to use them.