All regular versions of Windows prior to Windows 2000 used cooperative multitasking.
Wrong, Win95 had preemptive multitasking from it's birth.
However, large parts of it were still carried over from 16bit win3.x (yes, 32bit API calls often thunked down to old 16bit code, especially GDI). And there were some pretty big global locks (just like Linux and BSD had Big Kernel Locks back then) for the 16bit parts; I can't remember if it was all win16 code or just the GDI, but deadlocks around those parts would take down the entire OS. Doesn't mean it wasn't preemptive, though.
In addition to that, for performance and compatibility reasons, the Interrupt Flag wasn't virtualized for v86 tasks (DOS programs), since it was ridiculously expensive to do before v86+ introduced IF virtualization on the Pentium (and it was undocumented for quite a while)... this meant a DOS program could CLI (CLear Interrupt enable) followed by and endless loop, and that would hang the OS.
Not sure about the floppy slowness, but I certainly remember it. NT didn't have it, by the way:-)
Didn't help that Win9x process separation was pretty bad (DLLs loaded into global sharable memory, kernel structures overwritable from ring3, et cetera). Can't blame them for designing it that way, all things considered (limited hardware capabilities, DOS and win3.x compatibility (to the extent of lots of 32bit stuff thunking down to both 16bit win3.x code and DOS calls!)), I blame them mostly for doing WinME and not unifying already at Win2000.
The new chunks will be ignored by legacy software, but they'll be able to still display the "lossfull" image using the bits they understand. Newer software will be able to read the whole image in its full glory.
Yeah, I will get modded down for saying that, but there are good reasons why we should not want homosexuals in the military.
Following that line of thought, shouldn't you be happy having homosexuals in the military? You know, larger chance of them getting killed? You right wing nutters, your lack of coherent thought process never ceases to amaze me.
At the very basic level, it's as simple as stuffing code in a buffer and executing it. Yeah, iOS has had ASLR for a while, but since the the host program is cooperating...:)
I call BS. You can't even get through the BIOS bullshit on a Dell in 15 seconds.
Depends on the system, really. Apple systems have the advantage of using EFI instead of BIOS, which cuts out a lot of legacy crap. There's (u)EFI non-Apple PCs around as well, though, even if they're not widespread yet. And yes, Windows has been able to boot that way since at least Vista64.
I don't really get the obsession with boot time for PCs (whether they're going to run OS X, Linux, Windows or whatever) - I boot such devices relatively slowly, and use either standby or hibernate throughout the day.
So rather than lock on just a small section, if using the STL you end up having to go with more coarse-grained locks because otherwise subtle bugs emerge under load.
You honestly don't believe that handling thread synchronization at container/primitive level is the right thing to do, do you?
You honestly don't think it's good architecture even needing a lot of locking in parallel code, do you?
It's definitely less, because a simple string class that only allocates a string buffer, appends to it, frees itself when it goes out of scope, and is guaranteed to always has a proper none-null value (even if it's only 1 byte, and that byte is itself null) is easy to "maintain". There's really no maintenance once it's done.
You have just described a string class that will result in heap fragmentation and performs horribly under multithreaded scenarios. Well done.
Furthermore, if you've spent less than an hour on this, I simply refuse to belive you have the functionality needed for real-life applications, especially not since such a core class should be fully unit tested and documented.
In other words, how much of your companys time have you wasted, and for what gain? Especially considering you'll have to pull in libc and libc++ anyway because 3rd party libraries depend on it? Not mentioning the overhead in converting back and forth between string representations?
(Note that I'm assuming standard environments here, not embedded systems.)
And I definitely do not agree with "for the dead only good or nothing". BS! First we don't extend the courtesy to all (how much good words you hear about Hitler).
Aww shucks, good point but now Godwin's law will be invoked - had you written Stalin instead...
GPU rendering is one thing, the other LARGE part of the engine that handles everything else still runs on the CPU. Just how efficient can Adobe make the FVM?
Oh, I'm not afraid of Java being targeted by others - I'm afraid of what stupid moves Oracle might pull in their typical short-sighted near-future-revenue kind of way. IMHO suing Google over android/dalvik isn't exactly helping java.
My post above is missing a "afraid" between "I'm" and "mentioning", btw.
So if you wanted to be shielded from the drudgery of memory management in C++ why weren't you using the features of the language that provide you automatic memory management to make this less of a pain?
Because it doesn't provide full automatic memory management (smart pointers don't handle cycles), and because you have to write reams and reams of angle brackets to use them.
Oh, and angle brackets are SO scary? It's not like you don't need them all over the place in Java when you use collections... and (finally!) with C++11, we have type inference, lowering the need for those angle brackets substantially.
I can't speak for.net, but in Java you have very little need for it. It's better to close your files and connections, but they'll be garbage-collected for you if you don't.
They might get garbage-collected... eventually... once the non-deterministic garbage collector feels like it. If you're not putting a lot of pressure on the GC, doyc knows when that's going to happen. Programming Java without calling the correct disposal methods (which means a lot of try/catch/finally goob) is really bad practice, just as not using the IDispoable pattern (and littering code with 'using') in C#.
C++? Deterministic destruction, even in face of exceptions, by use of RAII.
Slashdot Mirror
Sounds like actual, genuine multitasking to me
All regular versions of Windows prior to Windows 2000 used cooperative multitasking.
Wrong, Win95 had preemptive multitasking from it's birth.
However, large parts of it were still carried over from 16bit win3.x (yes, 32bit API calls often thunked down to old 16bit code, especially GDI). And there were some pretty big global locks (just like Linux and BSD had Big Kernel Locks back then) for the 16bit parts; I can't remember if it was all win16 code or just the GDI, but deadlocks around those parts would take down the entire OS. Doesn't mean it wasn't preemptive, though.
In addition to that, for performance and compatibility reasons, the Interrupt Flag wasn't virtualized for v86 tasks (DOS programs), since it was ridiculously expensive to do before v86+ introduced IF virtualization on the Pentium (and it was undocumented for quite a while)... this meant a DOS program could CLI (CLear Interrupt enable) followed by and endless loop, and that would hang the OS.
Not sure about the floppy slowness, but I certainly remember it. NT didn't have it, by the way :-)
Didn't help that Win9x process separation was pretty bad (DLLs loaded into global sharable memory, kernel structures overwritable from ring3, et cetera). Can't blame them for designing it that way, all things considered (limited hardware capabilities, DOS and win3.x compatibility (to the extent of lots of 32bit stuff thunking down to both 16bit win3.x code and DOS calls!)), I blame them mostly for doing WinME and not unifying already at Win2000.
Using the same installation is sufficient, and takes a lot less time to verify. Nice try, though.
It blows my mind.
That's meth for ya.
The new chunks will be ignored by legacy software, but they'll be able to still display the "lossfull" image using the bits they understand. Newer software will be able to read the whole image in its full glory.
>
Umm, since when has PNG been lossy? O_o
Better if they sacrifice attractive males - more virgin females for the rest of us.
Home of the fucked-over, land of the betrayed. There, ftfy.
Yeah, I will get modded down for saying that, but there are good reasons why we should not want homosexuals in the military.
Following that line of thought, shouldn't you be happy having homosexuals in the military? You know, larger chance of them getting killed? You right wing nutters, your lack of coherent thought process never ceases to amaze me.
At the very basic level, it's as simple as stuffing code in a buffer and executing it. Yeah, iOS has had ASLR for a while, but since the the host program is cooperating... :)
...who says there aren't already apps out there doing this? :)
I call BS. You can't even get through the BIOS bullshit on a Dell in 15 seconds.
Depends on the system, really. Apple systems have the advantage of using EFI instead of BIOS, which cuts out a lot of legacy crap. There's (u)EFI non-Apple PCs around as well, though, even if they're not widespread yet. And yes, Windows has been able to boot that way since at least Vista64.
I don't really get the obsession with boot time for PCs (whether they're going to run OS X, Linux, Windows or whatever) - I boot such devices relatively slowly, and use either standby or hibernate throughout the day.
So rather than lock on just a small section, if using the STL you end up having to go with more coarse-grained locks because otherwise subtle bugs emerge under load.
You honestly don't believe that handling thread synchronization at container/primitive level is the right thing to do, do you?
You honestly don't think it's good architecture even needing a lot of locking in parallel code, do you?
It's definitely less, because a simple string class that only allocates a string buffer, appends to it, frees itself when it goes out of scope, and is guaranteed to always has a proper none-null value (even if it's only 1 byte, and that byte is itself null) is easy to "maintain". There's really no maintenance once it's done.
You have just described a string class that will result in heap fragmentation and performs horribly under multithreaded scenarios. Well done.
Furthermore, if you've spent less than an hour on this, I simply refuse to belive you have the functionality needed for real-life applications, especially not since such a core class should be fully unit tested and documented.
In other words, how much of your companys time have you wasted, and for what gain? Especially considering you'll have to pull in libc and libc++ anyway because 3rd party libraries depend on it? Not mentioning the overhead in converting back and forth between string representations?
(Note that I'm assuming standard environments here, not embedded systems.)
Past tense, dude. Fortunately.
Revisionist history, gotta love it.
And I definitely do not agree with "for the dead only good or nothing". BS! First we don't extend the courtesy to all (how much good words you hear about Hitler).
Aww shucks, good point but now Godwin's law will be invoked - had you written Stalin instead...
And if you do run into a wall, Xcode is free and the kernel source is available.
And the kernel is how big a part of the entire system?
Nice try, though.
> and isn't about judging and killing other people in the name of some imaginary person
in fact, if you search for "do not judge" in google, first result is buddh...er.. ok, beginners luck. I'll try "do not kill"... FUUUUUUU
"Do as I say, not as I do".
GPU rendering is one thing, the other LARGE part of the engine that handles everything else still runs on the CPU. Just how efficient can Adobe make the FVM?
Not even Microsoft uses WPF
Visual Studio?
Oh, I'm not afraid of Java being targeted by others - I'm afraid of what stupid moves Oracle might pull in their typical short-sighted near-future-revenue kind of way. IMHO suing Google over android/dalvik isn't exactly helping java.
My post above is missing a "afraid" between "I'm" and "mentioning", btw.
It might be GPL'd, but what about involved patents? Considering how Oracle is playing, I'm mentioning the P word isn't entirely FUD :(
Might want to try actually reading TFA?
Java 7 is, unfortunately, extremely lack-luster. That, combined with whOracle in charge, doesn't bode well IMHO.
If only MS actively supported cross-platform .NET, so we had an alternative to Java...
So if you wanted to be shielded from the drudgery of memory management in C++ why weren't you using the features of the language that provide you automatic memory management to make this less of a pain?
Because it doesn't provide full automatic memory management (smart pointers don't handle cycles), and because you have to write reams and reams of angle brackets to use them.
Oh, and angle brackets are SO scary? It's not like you don't need them all over the place in Java when you use collections... and (finally!) with C++11, we have type inference, lowering the need for those angle brackets substantially.
I can't speak for .net, but in Java you have very little need for it. It's better to close your files and connections, but they'll be garbage-collected for you if you don't.
They might get garbage-collected... eventually... once the non-deterministic garbage collector feels like it. If you're not putting a lot of pressure on the GC, doyc knows when that's going to happen. Programming Java without calling the correct disposal methods (which means a lot of try/catch/finally goob) is really bad practice, just as not using the IDispoable pattern (and littering code with 'using') in C#.
C++? Deterministic destruction, even in face of exceptions, by use of RAII.