So even if you dislike this feature, it is useful, although as you mention it'd be even better if there's a way to disable it (perhaps a popup menu on paste that allows you to choose the paste type).
There has "always" been a Paste Special option in Office for you to select the format you want. In addition to HTML pasting, this can be useful if you're pasting between odd code pages or something like that. I thought everyone needing this feature had found it in the Edit menu, it's not like it's hidden or something... You want to paste, with additional settings. That makes it special.
In addition, there are "Smart Tags" in Office XP and later, which gives you a button close to newly pasted stuff where you can choose to preserve original formatting, use the target formatting or some other stuff. It's quite much like the context-menu you envision, but it does its default setting first, THEN asking you if you want to change it.
So, it's been possible to paste text-only with only a few more clicks for ages, and the latest releases make it even easier. Of course, it's also possible to reroute the normal shortcuts like Ctrl+V and Shift+Ins to use a "paste-text-only" substitute.
Cygwin is emulating a POSIX environment inside Win32. That has some pros if you want to call Win32 APIs. The Interix-based Services for UNIX are, IIRC, more of another subsystem that only gets to Win32 (CSRSS) to do console operations. Except for that, it's using the native NT APIs directly. Those allow some stuff that is not made available in Win32. I don't know for sure if they actually use them in a way that matters.
What kind of damage to a CD do you have in mind? No matter how "protected" 3.5 (or 5.25) disks were, the failure rate per disk was, IMHO, far higher, and if we count failures per byte it just gets silly. Of course, this is when the ECC of the optical formats is taken into consideration. If you want protection, I think I prefer separate cases any day, but I wouldn't call a CD fragile. (BTW, what do you think makes them so damn cheap to manufacture that AOL can shell out loads?)
Is there really any "single" hard drive being able to give 125 Mbytes/sec out of anything but the cache? Isn't current SATA topping out at 150? But it's certainly in the same "range" instead of an order of magnitude better.
When CD-ROMs started getting reasonably common for PCs, there were plans for DVDs. Maybe you were happy because you haven't heard of them, but they were planned. That's pretty normal.
Do you mean another, unknown, large body entering the solar system? If not, it's just as easy to predict. Any proper simulation of the orbit to this accuracy will do it with a multi-body stepping method.
Because its orbit is dull. It's about a year, slightly more eccentric than Earth's and slightly out of the plane of Earth's orbit. It's like sending probes to Mars and point them up in the sky to observe the stars from there. Of course, it's possible, but if we want to observe stars, we've better ways of doing it.
I'm sorry, but you're mostly wrong. 9x had issues on its own, and when run with anything more recent then IE 4.x, I can promise you the web parts were buggy as hell. Regarding IE 3.x I don't know, because no-one in his right mind used or supported it.
If you look at recent bugs, they're very often tracked back to NT 4.x or IE 5.x, the oldest things still supported. Likewise for Windows Media Player. They have been there all along. With XP SP2, we have even started seeing issues that were handled by their proactive (and incomplete) measures there making bugs no-bugs in SP2, while they still cause vulnerabilities in older releases.
If you use old features in your new software, it's generally less bug-ridden. They might even have learned something -- large parts of the new Longhorn stuff might be "managed" (somewhat safer) and other parts are hopefully done in a more thoughtful manner than before. Very little made XP more insecure than 2000 and very little made Windows 2003 more insecure than 2000. Quite the opposite.
On the other hand, they hade to go to some lengths to keep the basic spirit of a real-mode, no memory protection API into a very different mode. They broke a few apps that really ill-behaved, but also kept large chunks of shared memory space that was critical to both the system and other applications.
If they hadn't been able to introduce virtual memory à la 3.x in 3.x, the mirror-equivalent of OS/2 Warp, which would have replaced Windows 95, would have been stable! Maybe...
Larry is often quite sensible in his blog, but his ramblings about IBM and Linux support here are quite unfounded. I think that MS would have lost and the x86 platform would have lost on it. As Linux was and is based on x86, it would also have been affected, but not as much by the lack of IBM "support". I agree more with the theory that this scenario would have been more beneficial for Apple and Sun, to name two. But, really, if we want to create fun alternate-histories, even within the area of software development, I can think of quite a few more interesting ones. There are also quite a few more interesting blog notes in Larry's blog than the one linked to here.
Even a microkernel will suffer if you have frequent calls between cores. A context switch on the waiting core is just as expensive as it's always been, but you may lower the total amount of needed switches a little.
Also, unless both cores have a completely shared cache architecture, you don't want to break that locality in each and every system call.
That's called OLE/ActiveX in Windows. You can access basically anything you ever would like to do in the Office apps from any scripting language. No, it's not a GUI thing in itself, but all the richness of the GUI is exposed in a scriptable way. And the point is that you don't have to do it from within a macro in said application, you can do it from just about anything, including a web page!
(If the exposer of the object model was stupid enough to mark it safe for web scripting without thinking about what that really means. GRRGH.)
And I know it's not even close as common to use this as piping is for a *NIX user. But it's there and you can even write your own 3D engine in C++ by creating Word drawing objects and move them around. (That was fun in 1998 or smth... The framerate slownewss you can get is simply unbelievable!)
If the franchise will go on, I would in fact think it would be a good thing if they deem Enterprise "non-canonical", i.e. any attempt to even try to maintain consistency with such an attempt to break all consistency should be avoided. Enterprise DID NOT HAPPEN. Now, let's go on...
Let's say the probability is 50 % the first mission fails. If we just accepted that, our estimated life loss at each launch would be 3.5.
The probability of one mission failing, another one sent up, and that one also failing, is 50 % * 50 %, 25 %. However, we may risk losing 14 lives in that case. The estimated life loss for each mission (not each rescue mission, but each "main" mission) is still 3.5. If the probability of failure is any less than 50 % (a jokingly high number), the estimated life loss is improved by trying to go up with another shuttle. It may not even need a full crew, and then the numbers, from the life loss point of view, are improved further. Also remember that there might be a chance to repair the wrecked shuttle, or at least give it additional inertia to keep it in orbit longer. That would save one precious shuttle.
A manned rescue mission might not always be ideal, but just from the point of not losing more lives, it's hard to make it a failure.
Is a manual launch possible to any orbit with enough precision to place it actually close to the suttle experiencing trouble? Such a simple thing as if the shuttle has started spinning could be tricky to adjust for in a manual craft. This should be an extraordinary event and for those I think that there are a subset where a manned rescue mission can solve things an unmanned mission can't.
This is more like MS putting out its secret destruct code that will stop any net-connected, non-firewealled (weeeeehoooo!) Win95 computer from ever accepting a new hard drive, no matter if original 95 would have supported the interface.
Isn't the point of the canary values even mentioned in the post to actually catch stack overruns? They are a far more expensive thing to do, but I was under the impression that they still are used quite extensively in SP2. Basically, if you put in a random value (varying between each function call, ideally, probably between each machine session or so in SP2) between the stack buffer and the return pointer, and that value is checked before RET is called, it gets much harder to overrun the buffer, beat the RET check and get the code to jump back to the wrong place.
Naturally, the only real solution is to avoid the overruns by sensible code. But, if one would be ready to believe that this level of checking would be enough to put native compiled code written by idiots on par with Java or.NET code written by idiots in the area of buffer overrun, it would be a cheap choice, performance-wise.
I just know it! The Scimitar didn't actually explode, it just opened a timewarp and Data got his head teared off, Archer will retrieve it and put it in a cave close to Redmond (San Francisco already taken, sorry), to be retrieved and put onto B4 just-in-time for another TNG movie!
In fact, the most expensive stuff was writing text to the screen. By manipulating the B000 (monochrome) or B800 (color) memory segments directly, even from C or Turbo Pascal, you could get far superior performance in stuff like scrolling in text editors and other screen refreshes, which affects the user experience quite significantly. I can imagine assembly was more useful for something like Lotus where the actual calculations could be sloooow back in the days, though. Just wanted to point out that I think that hardware manipulation for central routines was more common than writing it in assembly.
Quite a few install programs for the first year or two of Windows 95 used those interfaces to create program groups (i.e, Start menu folders). Newer software from small firms using old installshield versions and similar stuff probably did the same still around 98-99. Suddenly, it doesn't seem that old.
Embryonic and fetal development is quite interesting as it's both very similar between species at one level, but there are clear differences. For example, the placental interface to the mother is very different between different mammals so you can't just say that the whole process is conserved. This leads to the conclusion that actual research on human cells is a more direct way.
For the sake of it, are you also saying that HeLa cell cultures shouldn't be used before extensive animal tests? For research, human non-tumorous cells would often provide a better model than common labaratory animals -- and be far cheaper if the culturing methods were properly developed.
Nah, it's not completely relative. Remember the twin paradox, one of the twins is changing his acceleration and by doing so, they are no longer equivalent and it's completely logical that the two twins will age differently.
In this context, it's all changed by the fact if we can watch the "blazar" and its speed, and then watch the exhausts from it.
Slashdot Mirror
In addition, there are "Smart Tags" in Office XP and later, which gives you a button close to newly pasted stuff where you can choose to preserve original formatting, use the target formatting or some other stuff. It's quite much like the context-menu you envision, but it does its default setting first, THEN asking you if you want to change it.
So, it's been possible to paste text-only with only a few more clicks for ages, and the latest releases make it even easier. Of course, it's also possible to reroute the normal shortcuts like Ctrl+V and Shift+Ins to use a "paste-text-only" substitute.
Cygwin is emulating a POSIX environment inside Win32. That has some pros if you want to call Win32 APIs. The Interix-based Services for UNIX are, IIRC, more of another subsystem that only gets to Win32 (CSRSS) to do console operations. Except for that, it's using the native NT APIs directly. Those allow some stuff that is not made available in Win32. I don't know for sure if they actually use them in a way that matters.
What kind of damage to a CD do you have in mind? No matter how "protected" 3.5 (or 5.25) disks were, the failure rate per disk was, IMHO, far higher, and if we count failures per byte it just gets silly. Of course, this is when the ECC of the optical formats is taken into consideration. If you want protection, I think I prefer separate cases any day, but I wouldn't call a CD fragile. (BTW, what do you think makes them so damn cheap to manufacture that AOL can shell out loads?)
Is there really any "single" hard drive being able to give 125 Mbytes/sec out of anything but the cache? Isn't current SATA topping out at 150? But it's certainly in the same "range" instead of an order of magnitude better.
When CD-ROMs started getting reasonably common for PCs, there were plans for DVDs. Maybe you were happy because you haven't heard of them, but they were planned. That's pretty normal.
Do you mean another, unknown, large body entering the solar system? If not, it's just as easy to predict. Any proper simulation of the orbit to this accuracy will do it with a multi-body stepping method.
Because its orbit is dull. It's about a year, slightly more eccentric than Earth's and slightly out of the plane of Earth's orbit. It's like sending probes to Mars and point them up in the sky to observe the stars from there. Of course, it's possible, but if we want to observe stars, we've better ways of doing it.
If you look at recent bugs, they're very often tracked back to NT 4.x or IE 5.x, the oldest things still supported. Likewise for Windows Media Player. They have been there all along. With XP SP2, we have even started seeing issues that were handled by their proactive (and incomplete) measures there making bugs no-bugs in SP2, while they still cause vulnerabilities in older releases.
If you use old features in your new software, it's generally less bug-ridden. They might even have learned something -- large parts of the new Longhorn stuff might be "managed" (somewhat safer) and other parts are hopefully done in a more thoughtful manner than before. Very little made XP more insecure than 2000 and very little made Windows 2003 more insecure than 2000. Quite the opposite.
If they hadn't been able to introduce virtual memory à la 3.x in 3.x, the mirror-equivalent of OS/2 Warp, which would have replaced Windows 95, would have been stable! Maybe...
Larry is often quite sensible in his blog, but his ramblings about IBM and Linux support here are quite unfounded. I think that MS would have lost and the x86 platform would have lost on it. As Linux was and is based on x86, it would also have been affected, but not as much by the lack of IBM "support". I agree more with the theory that this scenario would have been more beneficial for Apple and Sun, to name two. But, really, if we want to create fun alternate-histories, even within the area of software development, I can think of quite a few more interesting ones. There are also quite a few more interesting blog notes in Larry's blog than the one linked to here.
Also, unless both cores have a completely shared cache architecture, you don't want to break that locality in each and every system call.
(If the exposer of the object model was stupid enough to mark it safe for web scripting without thinking about what that really means. GRRGH.)
And I know it's not even close as common to use this as piping is for a *NIX user. But it's there and you can even write your own 3D engine in C++ by creating Word drawing objects and move them around. (That was fun in 1998 or smth... The framerate slownewss you can get is simply unbelievable!)
If the franchise will go on, I would in fact think it would be a good thing if they deem Enterprise "non-canonical", i.e. any attempt to even try to maintain consistency with such an attempt to break all consistency should be avoided. Enterprise DID NOT HAPPEN. Now, let's go on...
The probability of one mission failing, another one sent up, and that one also failing, is 50 % * 50 %, 25 %. However, we may risk losing 14 lives in that case. The estimated life loss for each mission (not each rescue mission, but each "main" mission) is still 3.5. If the probability of failure is any less than 50 % (a jokingly high number), the estimated life loss is improved by trying to go up with another shuttle. It may not even need a full crew, and then the numbers, from the life loss point of view, are improved further. Also remember that there might be a chance to repair the wrecked shuttle, or at least give it additional inertia to keep it in orbit longer. That would save one precious shuttle.
A manned rescue mission might not always be ideal, but just from the point of not losing more lives, it's hard to make it a failure.
Is a manual launch possible to any orbit with enough precision to place it actually close to the suttle experiencing trouble? Such a simple thing as if the shuttle has started spinning could be tricky to adjust for in a manual craft. This should be an extraordinary event and for those I think that there are a subset where a manned rescue mission can solve things an unmanned mission can't.
This is more like MS putting out its secret destruct code that will stop any net-connected, non-firewealled (weeeeehoooo!) Win95 computer from ever accepting a new hard drive, no matter if original 95 would have supported the interface.
Naturally, the only real solution is to avoid the overruns by sensible code. But, if one would be ready to believe that this level of checking would be enough to put native compiled code written by idiots on par with Java or .NET code written by idiots in the area of buffer overrun, it would be a cheap choice, performance-wise.
I know, the only thing worse than a bad joke is a serious explanation of why it's bad.
I just know it! The Scimitar didn't actually explode, it just opened a timewarp and Data got his head teared off, Archer will retrieve it and put it in a cave close to Redmond (San Francisco already taken, sorry), to be retrieved and put onto B4 just-in-time for another TNG movie!
And spelling Deanna Diana is just... disrespectful! Only Cochrane is allowed to get her name wrong!
In fact, the most expensive stuff was writing text to the screen. By manipulating the B000 (monochrome) or B800 (color) memory segments directly, even from C or Turbo Pascal, you could get far superior performance in stuff like scrolling in text editors and other screen refreshes, which affects the user experience quite significantly. I can imagine assembly was more useful for something like Lotus where the actual calculations could be sloooow back in the days, though. Just wanted to point out that I think that hardware manipulation for central routines was more common than writing it in assembly.
Quite a few install programs for the first year or two of Windows 95 used those interfaces to create program groups (i.e, Start menu folders). Newer software from small firms using old installshield versions and similar stuff probably did the same still around 98-99. Suddenly, it doesn't seem that old.
For the sake of it, are you also saying that HeLa cell cultures shouldn't be used before extensive animal tests? For research, human non-tumorous cells would often provide a better model than common labaratory animals -- and be far cheaper if the culturing methods were properly developed.
A whole book sent across the country in less time than it takes to read it???
And by doing this, you just proved that the point of theory of relativity is not the relative part, but rather the absolute part. It's spelled c.
In this context, it's all changed by the fact if we can watch the "blazar" and its speed, and then watch the exhausts from it.