This is precisely why I don't play FPS games on public servers anymore if I can avoid it: If it's not someone cheating, it's someone accusing me of cheating. I only play with people I know nowadays.
Executable stack could be a hard argument, but at least for memory protection options as well as PE section permission flags (only.text is marked executable by default), it's pretty clearly spelled out what each flag means. Just "the implementation of this protection varies with the processor," or in other words, it hasn't been universally enforced.
And I'm guessing that a lot of the apps that break aren't actually executing things off the stack.
I agree about C, though. There are runtime-checking C variants, but I don't think they're very popular.
Microsoft actually goes to great lengths to ensure that certain applications will work under each new version of Windows. Otherwise, customers would have good reason not to buy the newer version of Windows. When an app breaks, it's almost always a matter of that app digging its own grave by doing something bizarre, short-sighted and incompatible.
Hardware wasn't capable of enforcing it, at least not on x86. The no-execute bit is something new they're adding for AMD64.
I could go off on a tangent about how this sort of thing has happened before with 9x vs. NT and DWORD stack alignment, but that'd be increasingly unrelated. My point is it's the app's fault for not playing by the rules.
Windows apps suffer from buffer overflows, Slashdot bags on Microsoft for having buffer overflows.
Windows adds NX security to prevent buffer overflows, Slashdot bags on Microsoft for breaking a few apps in the process (apps which were arguably broken in the first place, just the spec was never enforced).
I understand there's a slight bias on this site, but Jesus Christ you guys.
The only reason we're "having to find ways to separate code from data" is because of the lack of a per-page executable bit. Which AMD has fixed, end of story.
Because see, the rest of the world abandoned segments years ago, or never used them to begin with. x86 is the only mainstream architecture that has anything resembling "segment registers", and they're only vestigial organs from the days when you needed them to make 20-bit addresses. Segments are nothing more than an unnecessarily-limited version of paging.
To illustrate this, your idea about "two segments, code and data" would never work because there's not one code segment. When you throw DLLs into the mix (not the least of which are the system interface ones like KERNEL32.DLL), you're going to have code mixed with data scattered throughout the 2GB user process space and only guaranteed to be separated on 4K page boundaries. And you can't separate them into different code segments, either, since they all assume it's okay to near-call each other.
You can, in theory, artificially enforce the segregation of code and data so that all code sections are relocated beneath an arbitrary address. But there's probably a reason they haven't done this already in Win32 (PE relocations might not be flexible enough to handle it, not to mention the compatibility issues it might raise).
"Calls that switch tasks"? You don't seem to understand the way modern operating systems work. None of that is visible to the user process.
In summary, this is a permissions issue, not an architectural one. "Separating code from data so the two can't be confused" may have been the 1970s solution, but nowadays it's considered an ugly hack. The right solution is to just add the necessary permission bits.
So you're seriously suggesting that we go back to segments, NEAR vs. FAR access, and pointers becoming 48-bit because you need the selector index along with the actual address. Let's set aside for a moment what a horrible idea that is, and say that there's simply no way you could adapt Win32 to that. For starters, all DLL calls are done using near calls. All pointers are assumed near. Some pointers are shoved into data structures that are fixed at 4 bytes. I could go on. You'd have to rewrite the entire API from the ground up.
Meanwhile, Win32 already has VirtualProtect calls to set pages non-executable, since it was designed to work with multiple processors. Those particular page modes just happen to do nothing on the x86 (presumably until the new WinXP version).
No offense, but I like AMD's solution better. Segments are ancient history; we got rid of them for a reason.
How exactly did this end up modded to 5? Accessing the code segment on the 8086 is as trivial as using a CS: prefix. And by the time "flat addressing" came out in the 386, you also had this nice little thing called the MMU which controls read or write access on a per-page basis.
The real issue here is that the x86 MMU only lets you control whether pages are readable or writable, not executable. (And before any Mac folks get all smug, the PowerPC has this exact same problem.) So you can't just set your data and stack pages to be non-executable. You also can't easily take advantage of the code segment limit, because you don't always have one contiguous area of code, thanks to shared libraries, DLLs, etc.
OpenBSD solved this problem by setting the code segment limit to 0x20000000 (if I remember right?). All addresses above that are non-executable and all addresses below it are executable. Then they recompiled all the system binaries and shared libraries so the code sections fall underneath that address, and data sections fall above it.
But there's probably a reason this solution wouldn't work for Win32, maybe something compatibility related. So now AMD has fixed the underlying problem once and for all by adding per-page executable bits to the Athlon64 and Opteron, and supposedly Intel is planning on doing the same.
MacOS equals nine didn't traditionally have things like multiuser security, process separation, paged memory management, or... anything. SUID binaries? In a way, they all were. Hell, you could freeze the OS just by holding the mouse button down.
(the fact that early SNES games didn't take full advantage of the system didn't help, either)
What? There was nothing even remotely like F-Zero when it came out. And Castlevania 4 pushed the SNES hardware harder than almost anything else. Sure the Genesis had a faster CPU, but the SNES had more power where it counted: With all the wacky video shit it could do. There was no shortage of games taking advantage of that.
That's not a magic bullet. My ISP, and I suspect a lot of others, block all outgoing SMTP traffic that doesn't go through their own server. If you're relaying your email to an outside SMTP server, well, you're just pushing the problem up a step - where is it getting its Internet access from?
Personally, I'm all in favor of taxing SMTP traffic, and heavily. Talk about a way to make a lot of people adopt an alternative quickly.
"Unreal tournament... well... not much from there."
Perseverance?
In a multiplayer FPS, you can get killed, spectacularly, a lot. But what do you do when you die? You don't sit there and type "omg cheat0r". You condition yourself to admit defeat, shake it off, respawn, and keep playing, all within a split second. Anything less, and you end up wasting valuable time. (Or you end up in a song.)
Slashdot Mirror
I'm also wary of MMORPGs for the same reason.
Are you suggesting I'm getting paid to say this? I wish! Where do I sign up for that special forces team?
And I'm guessing that a lot of the apps that break aren't actually executing things off the stack.
I agree about C, though. There are runtime-checking C variants, but I don't think they're very popular.
This according to Raymond Chen, anyway.
Hardware wasn't capable of enforcing it, at least not on x86. The no-execute bit is something new they're adding for AMD64.
I could go off on a tangent about how this sort of thing has happened before with 9x vs. NT and DWORD stack alignment, but that'd be increasingly unrelated. My point is it's the app's fault for not playing by the rules.
Windows adds NX security to prevent buffer overflows, Slashdot bags on Microsoft for breaking a few apps in the process (apps which were arguably broken in the first place, just the spec was never enforced).
I understand there's a slight bias on this site, but Jesus Christ you guys.
I don't know about you guys, but I'm just stoked that "feckless" is an actual word. That's the big story here.
Because see, the rest of the world abandoned segments years ago, or never used them to begin with. x86 is the only mainstream architecture that has anything resembling "segment registers", and they're only vestigial organs from the days when you needed them to make 20-bit addresses. Segments are nothing more than an unnecessarily-limited version of paging.
To illustrate this, your idea about "two segments, code and data" would never work because there's not one code segment. When you throw DLLs into the mix (not the least of which are the system interface ones like KERNEL32.DLL), you're going to have code mixed with data scattered throughout the 2GB user process space and only guaranteed to be separated on 4K page boundaries. And you can't separate them into different code segments, either, since they all assume it's okay to near-call each other.
You can, in theory, artificially enforce the segregation of code and data so that all code sections are relocated beneath an arbitrary address. But there's probably a reason they haven't done this already in Win32 (PE relocations might not be flexible enough to handle it, not to mention the compatibility issues it might raise).
"Calls that switch tasks"? You don't seem to understand the way modern operating systems work. None of that is visible to the user process.
In summary, this is a permissions issue, not an architectural one. "Separating code from data so the two can't be confused" may have been the 1970s solution, but nowadays it's considered an ugly hack. The right solution is to just add the necessary permission bits.
Meanwhile, Win32 already has VirtualProtect calls to set pages non-executable, since it was designed to work with multiple processors. Those particular page modes just happen to do nothing on the x86 (presumably until the new WinXP version).
No offense, but I like AMD's solution better. Segments are ancient history; we got rid of them for a reason.
The real issue here is that the x86 MMU only lets you control whether pages are readable or writable, not executable. (And before any Mac folks get all smug, the PowerPC has this exact same problem.) So you can't just set your data and stack pages to be non-executable. You also can't easily take advantage of the code segment limit, because you don't always have one contiguous area of code, thanks to shared libraries, DLLs, etc.
OpenBSD solved this problem by setting the code segment limit to 0x20000000 (if I remember right?). All addresses above that are non-executable and all addresses below it are executable. Then they recompiled all the system binaries and shared libraries so the code sections fall underneath that address, and data sections fall above it.
But there's probably a reason this solution wouldn't work for Win32, maybe something compatibility related. So now AMD has fixed the underlying problem once and for all by adding per-page executable bits to the Athlon64 and Opteron, and supposedly Intel is planning on doing the same.
Now do you understand what this story is about?
SuprNova.
Of course. Notice how it rolls over to Friday the 13th?
MacOS equals nine didn't traditionally have things like multiuser security, process separation, paged memory management, or... anything. SUID binaries? In a way, they all were. Hell, you could freeze the OS just by holding the mouse button down.
84 76 59 68 82
What? There was nothing even remotely like F-Zero when it came out. And Castlevania 4 pushed the SNES hardware harder than almost anything else. Sure the Genesis had a faster CPU, but the SNES had more power where it counted: With all the wacky video shit it could do. There was no shortage of games taking advantage of that.
You overestimate how many people really, really care about this sort of thing.
That's not a magic bullet. My ISP, and I suspect a lot of others, block all outgoing SMTP traffic that doesn't go through their own server. If you're relaying your email to an outside SMTP server, well, you're just pushing the problem up a step - where is it getting its Internet access from?
Personally, I'm all in favor of taxing SMTP traffic, and heavily. Talk about a way to make a lot of people adopt an alternative quickly.
But that's me.
Mike was taken aback. "No way!"
"Yes," Larson said. "You're only missing one thing."
"What's that?" Mike asked quizzically.
"FIFTEEN THOUSAND FREE FUCKING DOLLARS!"
Mike beamed.
Puerile joke: Always funny.
Funny and ontopic reference: Never funny.
Understand now?
Damn, everything's emulated nowadays! Did they add a MAME driver for it, or what?
Or let's... not. That'd be cool, too.
Perseverance?
In a multiplayer FPS, you can get killed, spectacularly, a lot. But what do you do when you die? You don't sit there and type "omg cheat0r". You condition yourself to admit defeat, shake it off, respawn, and keep playing, all within a split second. Anything less, and you end up wasting valuable time. (Or you end up in a song.)
At least, that's what I learned.
Earthlink DSL had a nationwide scheduled downtime last night. Sure it wasn't that?