I worked for a company in 1999 that was already doing this for a while, before there really was much in the way of publicly available GeoIP data. The database they started with was built in the mid 90's by wardialing the major ISP's access numbers in different area codes, so when they started out they were targeting purely by area code. By the time that I worked for them, they had refined it down to zip code.
Of course, that company was eventually bought by Double Click, which is now owned by Google, so if they were the first to use geographic targeting, then this patent may not be totally bogus. However, there is a pretty long window between 1997 and 2004 where other companies were doing the same thing. If I remember right, you only have about a one year window after an invention is publicly disclosed to file for the patent. Given that, the claims described in the patent don't seem sufficiently different from what my former employer was doing to qualify as a new invention.
The point wasn't that the seemingly innocuous domain could be attacked with this method. What I was trying to point out is that the seemingly innocuous web site could be used as a vector for an attack on the victim site.
As I explained, the difference between JavaScript and Flash is what they consider to be "its own domain". JavaScript considers its own domain to be the domain of the page it's running in. Flash considers its own domain to be the domain the flash object is served from. It doesn't seem like it should be a big difference, but it is. Let me flesh out my example a bit more.
Suppose you have an account on the victim site. Suppose you are also a semi frequent visitor of the seemingly innocuous site that I host. If I want to steal your account on the victim site, and the victim site allows arbitrary file uploads, I can upload a flash movie to the victim site. The next time you visit my site, I embed the movie, hosted on the victim site, somewhere in my site that you can't see it. Because Flash considers the victim site to be in its own domain, it is free to contact the victim site however it wants without checking the contents of the crossdomain.xml file. I have just been able to compromise your account without you noticing, and without convincing you to do anything you wouldn't normally do. Performing the same attack with JavaScript, without having to engineer you into visiting a page you don't normally visit on the victim site, would be a much more difficult proposition.
You missed the point. Flash is not equally bad as JavaScript, it's far worse.
Suppose I'm an attacker, and I upload a malicious javascript file to www.victimsite.example. I then reference it in a site I control www.seemingly-innocuous.example, the javascript file runs in the www.seemingly-innocuous.example domain sandbox. Even though the file was loaded from www.victimsite.example, it can't actually access anything on the victim's site. In order for that to happen I would have to also upload a malicious html document to www.victimsite.example, and convince unwary surfers to visit this new page.
Now I decide to switch to flash. I upload a malicious SWF to www.victimsite.example, and embed it into a page at www.seemingly-innocuous.example. Unlike the JavaScript example, my malicious SWF now runs in the www.victimsite.example domain security sandbox, and can make any requests it wants to the victimsite.example domain without the visitor to my seemingly innocuous domain being any the wiser.
It is a big deal, and it is nothing at all like JavaScript. But it's also not remotely new. I'm having a hard time finding anything in this article that hasn't been widely know for some time now. It even mentions attacks that have been going on for years.
I wonder if it would be possible to store this hidden volume directly inside the free space of an NTFS volume instead of inside a TrueCrypt encrypted volume?
You can, I'm pretty sure, but then it's not truly hidden anymore - there's no obvious file hanging out, but anyone who did a forensic analysis of the drive would likely notice that instead of being full of unmapped fragments of old files, the unused space on your disk is full of random garbage. There is also a big catch - if you ever write to the NTFS volume while the hidden volume is not mounted, you will corrupt the hidden volume.
it would have to be something that is there by default like having a separate partition or container file for each user with the encryption tied-in to their user account so when logging in their login credentials are the encryption key and the volume is auto mounted transparently
This sounds to me like the system that Mac OS X comes with, called FileVault. It asks whether you want to enable it when the account is created. If you say yes, it creates an encrypted file that gets mounted on top of your home directory automatically when you log in. It's installed by default with every new Mac. Not very good for deniability, though - it's pretty obvious if you are using it.
Not sure about the older mice, but it seems to me that every USB mouse made by Apple has been roughly equally bad for different reasons. Scratch that, the hockey puck was by far the worst. But the Apple Pro Mouse and Mighty Mouse still rank up there as the second and third worst mice I have ever used by a fair margin.
This is something that has been bothering me for a while now. It's been a couple years since sound servers were in any way necessary. The sole purpose of ESD was to work around the fact that only one application could open/dev/dsp at a time. It was a horrible, nasty hack that was unfortunately necessary at one point in our history. Nobody really wanted it to be a long term solution, we just wanted something that would work until the people ho wrote the sound drivers got their sh*t together.
Yet here we are, years later, and not only have we never tried to phase out these horrid abominations, we keep adding new and more complicated ones. I have no words for how absurd this is. Why is it that we can't just fix the issues in the drivers where they belong rather than piling heap after steaming heap on top of them? And even when they do actually fix the issues, nobody ever tries to dig us back out of the pile...
My father is originally from rural Nebraska, and any time we visit that side of the family it's pretty much all gravel roads for miles in any direction. Even I, having learned to drive on the southern California freeways, never had a problem driving over 30MPH on the gravel roads there. That said, I do remember my dad complaining an awful lot about having to get the windshield fixed or replaced after visiting his family when I was younger.
You're mixing two different animals with different problems, and no, I'm not talking about your unicorns and kittens.
Oil is almost universally used for transportation because it is portable, relatively energy dense, and easily refillable anywhere in the world. The fact that we already have a vast infrastructure in place to deal with it provides an additional barrier of entry to any new technology.
Oil is relatively non-existent in municipal energy production. The vast majority of our municipal power production comes from coal, followed I believe by nuclear. Each have their own problems, but geopolitical concerns about funding people we don't like - or who don't like us - are not among them.
All of the technologies that you mention in your post, as well as the kites in TFA, address the issue of municipal power generation. Changes in municipal power generation don't do anything to address our dependence on foreign oil, unless we can come up with a replacement for oil that is comparable to oil in portability, energy density, and ability to refuel on the go. Batteries are not there yet, and may never be. Plugin hybrids will help, but not solve, the problem. Hydrogen may be a viable solution someday but there are a large number of significant technical hurdles ahead of us on that road. Biofuels may be a solution, and unlike any of the others that I mentioned, have the bonus of not relying on municipal power generation. But biofuels will never be competitive as long as we insist on getting them from corn.
A single button was the right choice in 1984. Nothing stops you from connecting a multi-button mouse to your Mac, and all of the buttons and scroll wheel work swimmingly.
And 1984 was 25 years ago...
While it's true that connecting a multi-button mouse to a Mac just works, I don't really consider that to be a valid argument if you use a MacBook, which seem to me to be an order of magnitude more popular than their desktop systems. And Control+Click is not an acceptable replacement either.
I have a MacBook on loan from my work, but it is the only Mac of several computers that I use. While I've found myself using the MacBook more and more, I still do most of my work on Windows or Linux computers, either through VirtualBox, Remote Desktop, or SSH+X11 forwarding. In any of those cases I need a real second (and often third) mouse button, and I would rather not have to always carry an external mouse around with me. Control+Click doesn't work because 1) Control+Click actually means something different than right click in Linux and Windows, and 2) Control+Click doesn't allow me to emulate a middle mouse button by clicking both buttons.
Apple finally - albeit silently, and IMO poorly - admitted they were wrong about having two buttons with the Mighty Mouse. If they would ever extend that to their laptops, I might consider buying one for myself, although I still think the Pro models have an absurdly low screen resolution for such a high powered laptop.
The glossy screen hasn't bothered me too much on the MacBook that I've been using for work recently, but the big thing keeping me from buying my own (aside from the current state of my bank account) is the lack of a decent resolution on anything smaller than the 17" model.
Well, that and the mouse, but Mighty Mouse aside, I can't imagine Apple ever sucking up their pride enough to actually change that.
Your two years doesn't even have to be all the way up to sign up for a new one. I don't know exactly what their cut off is, though. I've known people who got new phones and contracts with six months remaining on their previous contract. I've heard of people who have done it with a year still remaining on the previous contract with a little bit of negotiation.
I don't know about the iPhone specifically, but if you are far enough into your current contract (typically at least a year) AT&T will always let you sign a "new two-year AT&T wireless service contract". You don't have to be a new customer to sign a new contract.
As somebody relatively new to the Mac world, I have a random question. Given how standardized all of the other Meta key commands seem to be from one application to the next, why can't any two programs agree on the same key combination to switch tabs?
Chrome uses Meta+Alt+Arrow. Safari uses Meta+Shift+{}. Firefox uses Ctrl+Tab. Coming from a non-Mac background, Firefox is the only one that makes any sense to me, although I'll admit it's a little odd in that it is the only one that doesn't use the Meta key. And it's a little hard to keep that straight with Meta+Tab / Meta + `. But at least it doesn't require double chording or taking my hand off the mouse.
But really, can't you guys just all agree on the one true way and be done with it? Must I be condemned to constantly hit the wrong key combination every time I switch windows.
I wondered about that too. I also noticed that it specifically mentioned urine concentrations. Now, I'm far from an expert on the subject, but as I understand it this means that my kidneys are doing their job, and filtering the stuff out of my blood stream. It seems to me that how much of this shows up in my urine is less interesting than how long it sits in my body before my kidneys take care of it, and what problems it's causing there.
That small amounts of BPA are capable of leaching out of bottles and into the liquids that they contain has been known for years. What's less well understood (at least the last time I really bothered to read up on this at all) is what it actually does, if anything, once it's there.
I have no problem with people who have such an attitude. My problem with that attitude arises when the same person starts pretending he actually does know something about the computer. If he doesn't care to learn anything about how the computer works, then when they have a problem, they should admit it and say "The computer doesn't work." If they feel the need to be more specific than that, them they should learn what it actually means.
If his watch stops working and he takes it in to a watch repair shop to get it fixed, what does he tell them?
When I first started using Linux, the sound on Linux had some severe drawbacks. Aside from having a compatible card and just getting it working in the first place, the way to output sound was to write to/dev/dsp, and only application could open the sound device at a time. Around that time, somebody created "esd", which was a terrible hack. The idea was that esd would be the one application that could write to the sound device, and everything that wanted to output sound would write to a virtual device created by esd. Of course, this only worked for applications that were esd aware, and all manner of hacks and misdirection had to be done to get ever other app in the world to communicate with esd instead of/dev/dsp.
Some time later, ALSA replaced OSS as the standard sound driver on Linux. Besides having much wider device support and being far easier to actually get to work, ALSA also removed most of the software shortcomings of OSS, making sound daemons like esd no longer necessary. Now, you would think that people would have been overjoyed to no longer have to use as awful hack like esd, but somehow the opposite happened. Now, instead of just esd, we have esd, aRTS, PulseAudio, Jack, and probably several others that I am not aware of. And what's even better, depending on your setup, you may even have the fortune of using multiple of them at the same time. As of 8.10, Ubuntu uses PulseAudio by default, so if you use KDE, your sound goes through four different layers to actually get to your sound card: Application -> aRTS -> PulseAudio -> ALSA. Woo!
Why do we still have to resort to these ridiculous hacks to fix something that's no longer broken?
I understand the problem you are describing, but I fail to see how this solution addresses it. If there is already a disconnect between the programmer doing the copying and the programmer doing the allocating, then making the programmer doing the copying repeat himself is not going to fix the problem.
The only problem this function solves is buffer over flows caused by a programmer calculating a number of bytes to copy at runtime (e.g. by reading it from a Content-Length header) and failing to check the calculated value against what he believes is the actual size of the buffer. If the value that he believes to be the size of the buffer is wrong, changing from memcpy to memcpy_s will not catch the mistake. In other words, changing from memcpy to memcpy_s will only protect against sloppy programmers, and if they don't understand what the function is supposed to be protecting them from (which is likely) they'll probably just use the same value for copy_size and dst_size anyway (or switch to memmove), which will completely defeat the purpose of blacklisting memcpy in the first place.
Not to mention, if you're doing any pointer arithmetic and writing to an offset some number of bytes past *buffer, then passing the size of *buffer doesn't really help, unless the function is smart enough to know that (I don't see how it could be unless we pass that as a parameter as well), or the user is smart enough to calculate the remaining size of *buffer. If the user is one of the sloppy programmers that this function is meant to protect against in the first place, I think that is highly unlikely, don't you?
The great thing about Duke 3D was the combination of silliness and strategy. Quake had I think 7 different weapons that you could use, but with few exceptions there wasn't any real strategy to them. There were different balances of power, rate of fire, and splash damage, but it was all just variations of "fire projectile at the other guy."
The single player game was amusing, with Duke's comments and the props giving a more light-hearted feel to the environment than most other FPS's, but what made the game really shine was its multi-player. Weapons like the pipe bomb, laser trip mines and shrink-o-matic and items like the jet pack and steroid pills added a new level of strategy to multiplayer gameplay that had not been seen in FPS games up until that time. And the silliness of some of the weapons added to the fun. I still remember almost falling out of my chair laughing while trying to avoid getting stepped on after getting hit with the shrink-o-matic at point blank range.
I'm fairly certain that most end users couldn't tell you whether an application is multithreaded, or would care even if they knew.
I've been using Firefox on a Mac for a month or two now, and haven't noticed it sucking. But then, I think most of the software that came installed on the Mac sucks, so maybe I just haven't finished my kool-aid yet.
Slashdot Mirror
I worked for a company in 1999 that was already doing this for a while, before there really was much in the way of publicly available GeoIP data. The database they started with was built in the mid 90's by wardialing the major ISP's access numbers in different area codes, so when they started out they were targeting purely by area code. By the time that I worked for them, they had refined it down to zip code.
Of course, that company was eventually bought by Double Click, which is now owned by Google, so if they were the first to use geographic targeting, then this patent may not be totally bogus. However, there is a pretty long window between 1997 and 2004 where other companies were doing the same thing. If I remember right, you only have about a one year window after an invention is publicly disclosed to file for the patent. Given that, the claims described in the patent don't seem sufficiently different from what my former employer was doing to qualify as a new invention.
The point wasn't that the seemingly innocuous domain could be attacked with this method. What I was trying to point out is that the seemingly innocuous web site could be used as a vector for an attack on the victim site.
As I explained, the difference between JavaScript and Flash is what they consider to be "its own domain". JavaScript considers its own domain to be the domain of the page it's running in. Flash considers its own domain to be the domain the flash object is served from. It doesn't seem like it should be a big difference, but it is. Let me flesh out my example a bit more.
Suppose you have an account on the victim site. Suppose you are also a semi frequent visitor of the seemingly innocuous site that I host. If I want to steal your account on the victim site, and the victim site allows arbitrary file uploads, I can upload a flash movie to the victim site. The next time you visit my site, I embed the movie, hosted on the victim site, somewhere in my site that you can't see it. Because Flash considers the victim site to be in its own domain, it is free to contact the victim site however it wants without checking the contents of the crossdomain.xml file. I have just been able to compromise your account without you noticing, and without convincing you to do anything you wouldn't normally do. Performing the same attack with JavaScript, without having to engineer you into visiting a page you don't normally visit on the victim site, would be a much more difficult proposition.
You missed the point. Flash is not equally bad as JavaScript, it's far worse.
Suppose I'm an attacker, and I upload a malicious javascript file to www.victimsite.example. I then reference it in a site I control www.seemingly-innocuous.example, the javascript file runs in the www.seemingly-innocuous.example domain sandbox. Even though the file was loaded from www.victimsite.example, it can't actually access anything on the victim's site. In order for that to happen I would have to also upload a malicious html document to www.victimsite.example, and convince unwary surfers to visit this new page.
Now I decide to switch to flash. I upload a malicious SWF to www.victimsite.example, and embed it into a page at www.seemingly-innocuous.example. Unlike the JavaScript example, my malicious SWF now runs in the www.victimsite.example domain security sandbox, and can make any requests it wants to the victimsite.example domain without the visitor to my seemingly innocuous domain being any the wiser.
It is a big deal, and it is nothing at all like JavaScript. But it's also not remotely new. I'm having a hard time finding anything in this article that hasn't been widely know for some time now. It even mentions attacks that have been going on for years.
You can, I'm pretty sure, but then it's not truly hidden anymore - there's no obvious file hanging out, but anyone who did a forensic analysis of the drive would likely notice that instead of being full of unmapped fragments of old files, the unused space on your disk is full of random garbage. There is also a big catch - if you ever write to the NTFS volume while the hidden volume is not mounted, you will corrupt the hidden volume.
This sounds to me like the system that Mac OS X comes with, called FileVault. It asks whether you want to enable it when the account is created. If you say yes, it creates an encrypted file that gets mounted on top of your home directory automatically when you log in. It's installed by default with every new Mac. Not very good for deniability, though - it's pretty obvious if you are using it.
Not sure about the older mice, but it seems to me that every USB mouse made by Apple has been roughly equally bad for different reasons. Scratch that, the hockey puck was by far the worst. But the Apple Pro Mouse and Mighty Mouse still rank up there as the second and third worst mice I have ever used by a fair margin.
This is something that has been bothering me for a while now. It's been a couple years since sound servers were in any way necessary. The sole purpose of ESD was to work around the fact that only one application could open /dev/dsp at a time. It was a horrible, nasty hack that was unfortunately necessary at one point in our history. Nobody really wanted it to be a long term solution, we just wanted something that would work until the people ho wrote the sound drivers got their sh*t together.
Yet here we are, years later, and not only have we never tried to phase out these horrid abominations, we keep adding new and more complicated ones. I have no words for how absurd this is. Why is it that we can't just fix the issues in the drivers where they belong rather than piling heap after steaming heap on top of them? And even when they do actually fix the issues, nobody ever tries to dig us back out of the pile...
My father is originally from rural Nebraska, and any time we visit that side of the family it's pretty much all gravel roads for miles in any direction. Even I, having learned to drive on the southern California freeways, never had a problem driving over 30MPH on the gravel roads there. That said, I do remember my dad complaining an awful lot about having to get the windshield fixed or replaced after visiting his family when I was younger.
You're mixing two different animals with different problems, and no, I'm not talking about your unicorns and kittens.
Oil is almost universally used for transportation because it is portable, relatively energy dense, and easily refillable anywhere in the world. The fact that we already have a vast infrastructure in place to deal with it provides an additional barrier of entry to any new technology.
Oil is relatively non-existent in municipal energy production. The vast majority of our municipal power production comes from coal, followed I believe by nuclear. Each have their own problems, but geopolitical concerns about funding people we don't like - or who don't like us - are not among them.
All of the technologies that you mention in your post, as well as the kites in TFA, address the issue of municipal power generation. Changes in municipal power generation don't do anything to address our dependence on foreign oil, unless we can come up with a replacement for oil that is comparable to oil in portability, energy density, and ability to refuel on the go. Batteries are not there yet, and may never be. Plugin hybrids will help, but not solve, the problem. Hydrogen may be a viable solution someday but there are a large number of significant technical hurdles ahead of us on that road. Biofuels may be a solution, and unlike any of the others that I mentioned, have the bonus of not relying on municipal power generation. But biofuels will never be competitive as long as we insist on getting them from corn.
And 1984 was 25 years ago...
While it's true that connecting a multi-button mouse to a Mac just works, I don't really consider that to be a valid argument if you use a MacBook, which seem to me to be an order of magnitude more popular than their desktop systems. And Control+Click is not an acceptable replacement either.
I have a MacBook on loan from my work, but it is the only Mac of several computers that I use. While I've found myself using the MacBook more and more, I still do most of my work on Windows or Linux computers, either through VirtualBox, Remote Desktop, or SSH+X11 forwarding. In any of those cases I need a real second (and often third) mouse button, and I would rather not have to always carry an external mouse around with me. Control+Click doesn't work because 1) Control+Click actually means something different than right click in Linux and Windows, and 2) Control+Click doesn't allow me to emulate a middle mouse button by clicking both buttons.
Apple finally - albeit silently, and IMO poorly - admitted they were wrong about having two buttons with the Mighty Mouse. If they would ever extend that to their laptops, I might consider buying one for myself, although I still think the Pro models have an absurdly low screen resolution for such a high powered laptop.
Eh, I know what it does. It's essentially one gigantic IRC chat room.
What I'm having a hard time figuring out is why so many people think it's such a big deal.
Lasers!
(duh...)
The glossy screen hasn't bothered me too much on the MacBook that I've been using for work recently, but the big thing keeping me from buying my own (aside from the current state of my bank account) is the lack of a decent resolution on anything smaller than the 17" model.
Well, that and the mouse, but Mighty Mouse aside, I can't imagine Apple ever sucking up their pride enough to actually change that.
Your two years doesn't even have to be all the way up to sign up for a new one. I don't know exactly what their cut off is, though. I've known people who got new phones and contracts with six months remaining on their previous contract. I've heard of people who have done it with a year still remaining on the previous contract with a little bit of negotiation.
I don't know about the iPhone specifically, but if you are far enough into your current contract (typically at least a year) AT&T will always let you sign a "new two-year AT&T wireless service contract". You don't have to be a new customer to sign a new contract.
I must be living under a rock. I hadn't heard of this before today....
So now Microsoft is helping me search for low fares on Southwest? Neet!
As somebody relatively new to the Mac world, I have a random question. Given how standardized all of the other Meta key commands seem to be from one application to the next, why can't any two programs agree on the same key combination to switch tabs?
Chrome uses Meta+Alt+Arrow. Safari uses Meta+Shift+{}. Firefox uses Ctrl+Tab. Coming from a non-Mac background, Firefox is the only one that makes any sense to me, although I'll admit it's a little odd in that it is the only one that doesn't use the Meta key. And it's a little hard to keep that straight with Meta+Tab / Meta + `. But at least it doesn't require double chording or taking my hand off the mouse.
But really, can't you guys just all agree on the one true way and be done with it? Must I be condemned to constantly hit the wrong key combination every time I switch windows.
I wondered about that too. I also noticed that it specifically mentioned urine concentrations. Now, I'm far from an expert on the subject, but as I understand it this means that my kidneys are doing their job, and filtering the stuff out of my blood stream. It seems to me that how much of this shows up in my urine is less interesting than how long it sits in my body before my kidneys take care of it, and what problems it's causing there.
That small amounts of BPA are capable of leaching out of bottles and into the liquids that they contain has been known for years. What's less well understood (at least the last time I really bothered to read up on this at all) is what it actually does, if anything, once it's there.
I have no problem with people who have such an attitude. My problem with that attitude arises when the same person starts pretending he actually does know something about the computer. If he doesn't care to learn anything about how the computer works, then when they have a problem, they should admit it and say "The computer doesn't work." If they feel the need to be more specific than that, them they should learn what it actually means.
If his watch stops working and he takes it in to a watch repair shop to get it fixed, what does he tell them?
When I first started using Linux, the sound on Linux had some severe drawbacks. Aside from having a compatible card and just getting it working in the first place, the way to output sound was to write to /dev/dsp, and only application could open the sound device at a time. Around that time, somebody created "esd", which was a terrible hack. The idea was that esd would be the one application that could write to the sound device, and everything that wanted to output sound would write to a virtual device created by esd. Of course, this only worked for applications that were esd aware, and all manner of hacks and misdirection had to be done to get ever other app in the world to communicate with esd instead of /dev/dsp.
Some time later, ALSA replaced OSS as the standard sound driver on Linux. Besides having much wider device support and being far easier to actually get to work, ALSA also removed most of the software shortcomings of OSS, making sound daemons like esd no longer necessary. Now, you would think that people would have been overjoyed to no longer have to use as awful hack like esd, but somehow the opposite happened. Now, instead of just esd, we have esd, aRTS, PulseAudio, Jack, and probably several others that I am not aware of. And what's even better, depending on your setup, you may even have the fortune of using multiple of them at the same time. As of 8.10, Ubuntu uses PulseAudio by default, so if you use KDE, your sound goes through four different layers to actually get to your sound card: Application -> aRTS -> PulseAudio -> ALSA. Woo!
Why do we still have to resort to these ridiculous hacks to fix something that's no longer broken?
That's about what I thought. While I appreciate the difficulty in actually taking the picture, I don't really find it to be very impressive.
I understand the problem you are describing, but I fail to see how this solution addresses it. If there is already a disconnect between the programmer doing the copying and the programmer doing the allocating, then making the programmer doing the copying repeat himself is not going to fix the problem.
The only problem this function solves is buffer over flows caused by a programmer calculating a number of bytes to copy at runtime (e.g. by reading it from a Content-Length header) and failing to check the calculated value against what he believes is the actual size of the buffer. If the value that he believes to be the size of the buffer is wrong, changing from memcpy to memcpy_s will not catch the mistake. In other words, changing from memcpy to memcpy_s will only protect against sloppy programmers, and if they don't understand what the function is supposed to be protecting them from (which is likely) they'll probably just use the same value for copy_size and dst_size anyway (or switch to memmove), which will completely defeat the purpose of blacklisting memcpy in the first place.
Not to mention, if you're doing any pointer arithmetic and writing to an offset some number of bytes past *buffer, then passing the size of *buffer doesn't really help, unless the function is smart enough to know that (I don't see how it could be unless we pass that as a parameter as well), or the user is smart enough to calculate the remaining size of *buffer. If the user is one of the sloppy programmers that this function is meant to protect against in the first place, I think that is highly unlikely, don't you?
or better:
#define memcpy(x,y,z) memcpy_s(x,y,z,z)
The great thing about Duke 3D was the combination of silliness and strategy. Quake had I think 7 different weapons that you could use, but with few exceptions there wasn't any real strategy to them. There were different balances of power, rate of fire, and splash damage, but it was all just variations of "fire projectile at the other guy."
The single player game was amusing, with Duke's comments and the props giving a more light-hearted feel to the environment than most other FPS's, but what made the game really shine was its multi-player. Weapons like the pipe bomb, laser trip mines and shrink-o-matic and items like the jet pack and steroid pills added a new level of strategy to multiplayer gameplay that had not been seen in FPS games up until that time. And the silliness of some of the weapons added to the fun. I still remember almost falling out of my chair laughing while trying to avoid getting stepped on after getting hit with the shrink-o-matic at point blank range.
I'm fairly certain that most end users couldn't tell you whether an application is multithreaded, or would care even if they knew.
I've been using Firefox on a Mac for a month or two now, and haven't noticed it sucking. But then, I think most of the software that came installed on the Mac sucks, so maybe I just haven't finished my kool-aid yet.