* Preemptive multitasking * 32-bit flat memory model * Win32 API (which was a significant improvement at the time) * Integrated TCP/IP support, rather than relying on an optional extension * Increased maximum supported memory configuration to (IIRC) 256MB from 16MB * Desktop-oriented GUI * Paging rather than segment-swapping improved virtual memory performance substantially * Freecell
Win32 is also an informal name used for the set of operating system that support the Win32 API, i.e. the entire NT family of Windows operating systems, plus Windows 95, 98 and ME.
The i860 was a 32-bit ALU along with a 64-bit FPU. All of its buses were 64-bits wide, or wider.
The same was true of the Pentium. That doesn't make the Pentium a 64-bit processor.
But lets ask Intel: the Intel i860 64-Bit Microprocessor Data Sheet.
Marketing bullshit. Intels engineers knew at the time that they weren't producing a 64-bit processor. But there were 64 bit aspects to it, particularly WRT its SIMD capability of working on two 32 bit words with the same instruction. Its ALU was 32 bits, though, as was its address generation. Pointers held in registers are held in 32 bit registers. By modern definitions of a 64 bit processor, the i860 wasn't one of them. I'll let the source code for gcc's output module for it speak:/* Width of a word, in units (bytes). */ #define UNITS_PER_WORD 4
That's a 32 bit processor, there.
you are clearly just excited about Microsoft
Hardly. Out of personal choice, I'm a Linux user. My opinion is that the world would be a better place if MS had never got into the operating systems market. But that doesn't mean I'm willing to let inaccurate criticism of them pass. Criticise MS for their monopolistic practices. Criticise them for pushing the Win95 family on people despite it being total shit. Criticise them for producing bloated monsters that need ever more and more resources to run. Criticise them for consistently releasing products late. Criticise them for their FUD. Criticise them for failing to release API information and complete protocol documentation. Criticise them for dumbing down their systems to the point where they actually become harder to use in the name of simplicity. But don't criticise them for something that's untrue. I'm convinced that the claims they made about features they planned for Cairo were honest. Just like the features they announced for Longhorn were. They were ambitious, and they were optimistic in their announcements. They failed to deliver. This isn't unusual; most tech companies do this. Apple is very much an exception here, in that they keep details of their new products under careful wraps until just before launch. Few others do this, so don't criticise MS for following the majority.
Actually, factual errors not aside. This is a most peculiar piece of writing I've seen for a while. It ignores the popular myths about how Windows NT came to be, and cuts straight for the truth... then neatly sidesteps it and comes to incorrect conclusions. It's almost like it's been written by somebody who knows the real story as a deliberate disinformation piece. But who'd do that?
From the article: Microsoft initially targeted NT to run on the i860, Intel's new 64-bit RISC processor that was supposed to usher in the future.
The i860 was a 32-bit processor. If it were a 64-bit machine, MS would have struggled to downport NT to 32-bit architectures after initially developing the kernel on it.
Of course, Microsoft and IBM had also long referred to OS/2 3.0 as "NT," for new technology, so the idea behind the i860 as the source of NT's name might be historical revisionism.
Windows NT development started out as OS/2 3.0 development, and was switched to be in the Windows line later when Win3.0 took off. You'd have thought the writer could figure that maybe, perhaps, the i860 kernel that Cutler wrote for NT was originally slated to be for OS/2, and that perhaps therefore OS/2 3.0 was targetted at the i860 as well?
Not saying that this *is* the true meaning behind the NT name, but it's more likely than the "new technology" thing, which is widely regarded as a marketing-inspired backformation. Interestingly, he has used exactly the right argument here that dispels the "WNT=VMS+1" theory, but he doesn't mention that one.
Xenix eventually turned into today's SCO UNIX.
SCO don't sell a product called "UNIX". SCO OpenServer is what used to be called Xenix. "SCO UNIX" is likely to be confused with "SCO Unixware", which is an entirely different product line, originally developed by Novell.
Despite quaint stories about Bill Gates singlehandedly writing DOS on the back of a napkin
Anyone heard these stories? The much more common one is that he was in a hurry for an operating system so bought it form its original author for some pittance or other. That's very commonly known.
Windows 3.0, a DOS application
??? Windows 3 was somewhat more than an application. In almost all ways it qualifies as an operating system (it only lacked a device driver framework, relying on DOS to provide that in its place). But the writer's thesis doesn't work if Windows 3 was an operating system, so it's an application instead. Yeah, right.
At some future point, the world was supposed to trade in the essentially free-to-obtain DOS with a paid $200 copy of OS/2. That would enable PC users to run the software designed for DOS and Windows they already could run, as well as new software native to OS/2 that they did not have and did not yet exist. Hmm.
It's amazing that neither IBM nor Microsoft seemed to worry that this strategy might not work out, but everything is much clearer in hindsight.
Perhaps because that was never anybody's strategy. Nobody expected people to switch to OS/2 for no reason. Windows was a portability thing: if the Windows API were supported on both DOS and OS/2, then applications could be written that targetted either. When people came to buy a new computer, they could see that the more advanced operating system basis of OS/2 could give them superior performance to DOS, and so buy OS/2 instead.
Also, DOS wasn't "nearly free to obtain". I distinctly remember paying £70 for a copy back around the time we're talking about, which makes it pretty similarly priced to the $200 claimed for OS/2.
a world ready to believe that everything Microsoft could plan would be delivered at some point, even though Microsoft had absolutely no history of delivering any significant or original operating system technology.
Other than, you know, DOS and Windows. And this MS who had recently hired Dave Cutler, a very respected OS engineer
I, for one, don't allow my machines to make outgoing UDP connections. Never have, never will.
UDP IS CONNECTIONLESS!:)
That's why I put "connection" in quotes. Yes, UDP is connectionless. Some firewalls, however, maintain a list of virtual UDP connections in order to allow packets into the inside of the firewall when a machine on the inside has previously sent packets to their source.
This article seems to imply that ASLR (or ALSR or whatever it is) can either be disabled by the user system-wide, or that certain systems won't have the features required to enable ASLR.
That article's talking crap. ASLR doesn't require DEP; it just isn't particularly useful at preventing buffer overrun attacks without it. If there were any programs that failed to work when run on the local system when ASLR was enabled, the lack of DEP would not prevent this.
Ok, so two-thirds of the tricks used in worms and virus buffer overflor attacks are negated, but are those two-thirds heavily used attacks, or very minor ones?
There are two ways of exploiting a buffer overflow: you can make code in the buffer execute, or you can make code that already exists in the system execute with parameters from the buffer. The former is prevented by NX protection in most cases. The latter is made substantially more difficult by ASLR.
What exactly can the BIOS do with the hardware that the OS or boot loader can't? Err , nothing as far as I'm aware so whats the deal here?
As I understand it, there's a method that can be used to disable NX protection on some processors. Some BIOSs/motherboards do this. Once it is done, there's no way for the OS to undo it.
You do memory reads and code string matches to determine where modules are loaded
How do you do that when you don't have access to run code on the machine, but are only able to overwrite a stack return address with an address you've chosen?
Note that the address of your exploit code will likely have been randomised along with everything else. Or NX is enabled, and you've only got a return-to-libc attack available to you.
Those are the situations this scheme is designed to protect from, and it's pretty successful.
I have noticed if DEP is turned on in XP when I look at the folder with all my porn and thumbnails are turned on it causes Explorer to crash. I hope they fix this.
Of course this could be because one of those thumbnails is exploting a bug in Explorer's JPEG rendering and trying to execute itself, and DEP is actually preventing it from doing so...
It is a way to get two computers that are already allowed to talk to whoever they want on the internet to talk to each other despite both having firewalls that don't allow incoming connections. It does not cause violation of firewall policy or break firewall rules in any way, it just gets over an unfortunate incompatability in this world of NAT.
The issue only arises because both parties are firewalled.
Exactly. As far as anyone else is concerned, they might as well be communicating via a third party relay. Except there's no need for there to be one.
They're allowed to make outgoing "connections" by the firewall rules. This is just a way of making two outgoing connections connect to each other. If you have a problem with it, you probably shouldn't be allowing your machines to be making outgoing UDP connections.
Other option: don't allow incoming UDP packets, even if there has been an outgoing one, except from trusted IP addresses. I mean, you're only using UDP for DNS, right, and you know the IP address of your resolving DNS server...?
The "firewalls" are stupidly allowing packets to come back in from any source.
No, they're letting packets back in from any source to which a packet has been previously sent. One of the first two packets sent by the clients will be dropped, but the others will all go through fine.
Not that this makes it anything other than a stupid way of setting up a firewall if you're trying to regulate what protocols can be used. And if you aren't, what's the big deal?
And how are you going to receive replies if you tell it to drop the response packets?
By whitelisting the protocols you want to use UDP with, and preferably only for the hosts that you expect to receive responses from, and maybe even the machines on your own network you expect them to go to.
A corporate network should be locked down tight, and frankly most employees have no business messing around with anything that uses UDP. DNS requests should be sent to a trusted DNS resolving server, which should be the only machine allowed to make external DNS requests (and therefore receive responses to them). There may be a central VPN server that needs to accept incoming UDP packets for VPN communications. Other than this, UDP should probably be locked down completely.
There is no firewall here. If there was, there'd likely be a firewall rule that says "drop UDP packets originating or terminating on this list of addresses/ports that has been cleared for use" and nothing would happen. Most firewalls deny packets access unless there is some rule to allow them.
I thought the Criminal Justice and Public Order Act 1994 already amended the Protection of Children Act 1978 to make pseudo images of child porn illegal anyway. Sounds like this would be extending that to "abuse".
This only refers to photo-realistic images. The new proposal would also cover drawings.
It encourages the direct physical abuse of real children by conditioning the paedophile to consider their lustful and abusive mentality "acceptable" or "normal".
Evidence please. The studies I've seen (sorry, don't have links) have concluded that there is insufficient evidence to come to this conclusion, and that the opposite effect (that access to fantasy material allows those with paedophilic urges to experience them purely as fantasy rather than acting them out on a real victim) may actually be more significant.
Even Hentai isn't a fair comparison, because while the material is deeply disturbing "tentacle sex demons" ties in with some Japanese religions and folklore. It is an excellant example of a storyline where you don't want live human actors, but that doesn't mean it should be suppressed by people who don't understand the cultural significance.
By the descriptions I've heard of the proposed legislation, Hentai is very much a fair comparison because a significant proportion of it would become illegal.
Linux kernel and modules are compiled with gcc. Windows "kernel" and "modules" are compiled with MSVC. These compilers use different calling conventions (low-level assembly issues such as register allocation, parameter usage on the stack, etc.), and as such, binaries produced by one wouldn't be compatible with binaries produced by others.
No they don't. They both use the standard conventions for IA32: parameters passed right to left, DWORD aligned, caller clears, callee saves EBX, ESI, EDI and EBP if it modifies them, function return values are stored in EAX (+EDX if they're 64 bit). You can take code compiled with MSVC and call it from GCC trivially, as long as it doesn't use structured exception handling (which is an MS extension that GCC doesn't support).
Slashdot Mirror
What did Windows 95 actually add?
* Preemptive multitasking
* 32-bit flat memory model
* Win32 API (which was a significant improvement at the time)
* Integrated TCP/IP support, rather than relying on an optional extension
* Increased maximum supported memory configuration to (IIRC) 256MB from 16MB
* Desktop-oriented GUI
* Paging rather than segment-swapping improved virtual memory performance substantially
* Freecell
Need I go on?
Win95 was a huge improvement over Win3.1
This article has a confusing title, given that dominance of the Cairo graphics library these days.
Some of us get confused and think articles are talking about NT4 when they mention the graphics library. I guess it's a young v. middle-aged thing.
Win32 is an API, not an OS.
Win32 is also an informal name used for the set of operating system that support the Win32 API, i.e. the entire NT family of Windows operating systems, plus Windows 95, 98 and ME.
The i860 was a 32-bit ALU along with a 64-bit FPU. All of its buses were 64-bits wide, or wider.
/* Width of a word, in units (bytes). */
The same was true of the Pentium. That doesn't make the Pentium a 64-bit processor.
But lets ask Intel: the Intel i860 64-Bit Microprocessor Data Sheet.
Marketing bullshit. Intels engineers knew at the time that they weren't producing a 64-bit processor. But there were 64 bit aspects to it, particularly WRT its SIMD capability of working on two 32 bit words with the same instruction. Its ALU was 32 bits, though, as was its address generation. Pointers held in registers are held in 32 bit registers. By modern definitions of a 64 bit processor, the i860 wasn't one of them. I'll let the source code for gcc's output module for it speak:
#define UNITS_PER_WORD 4
That's a 32 bit processor, there.
you are clearly just excited about Microsoft
Hardly. Out of personal choice, I'm a Linux user. My opinion is that the world would be a better place if MS had never got into the operating systems market. But that doesn't mean I'm willing to let inaccurate criticism of them pass. Criticise MS for their monopolistic practices. Criticise them for pushing the Win95 family on people despite it being total shit. Criticise them for producing bloated monsters that need ever more and more resources to run. Criticise them for consistently releasing products late. Criticise them for their FUD. Criticise them for failing to release API information and complete protocol documentation. Criticise them for dumbing down their systems to the point where they actually become harder to use in the name of simplicity. But don't criticise them for something that's untrue. I'm convinced that the claims they made about features they planned for Cairo were honest. Just like the features they announced for Longhorn were. They were ambitious, and they were optimistic in their announcements. They failed to deliver. This isn't unusual; most tech companies do this. Apple is very much an exception here, in that they keep details of their new products under careful wraps until just before launch. Few others do this, so don't criticise MS for following the majority.
Factual errors aside...
Actually, factual errors not aside. This is a most peculiar piece of writing I've seen for a while. It ignores the popular myths about how Windows NT came to be, and cuts straight for the truth... then neatly sidesteps it and comes to incorrect conclusions. It's almost like it's been written by somebody who knows the real story as a deliberate disinformation piece. But who'd do that?
From the article:
Microsoft initially targeted NT to run on the i860, Intel's new 64-bit RISC processor that was supposed to usher in the future.
The i860 was a 32-bit processor. If it were a 64-bit machine, MS would have struggled to downport NT to 32-bit architectures after initially developing the kernel on it.
Of course, Microsoft and IBM had also long referred to OS/2 3.0 as "NT," for new technology, so the idea behind the i860 as the source of NT's name might be historical revisionism.
Windows NT development started out as OS/2 3.0 development, and was switched to be in the Windows line later when Win3.0 took off. You'd have thought the writer could figure that maybe, perhaps, the i860 kernel that Cutler wrote for NT was originally slated to be for OS/2, and that perhaps therefore OS/2 3.0 was targetted at the i860 as well?
Not saying that this *is* the true meaning behind the NT name, but it's more likely than the "new technology" thing, which is widely regarded as a marketing-inspired backformation. Interestingly, he has used exactly the right argument here that dispels the "WNT=VMS+1" theory, but he doesn't mention that one.
Xenix eventually turned into today's SCO UNIX.
SCO don't sell a product called "UNIX". SCO OpenServer is what used to be called Xenix. "SCO UNIX" is likely to be confused with "SCO Unixware", which is an entirely different product line, originally developed by Novell.
Despite quaint stories about Bill Gates singlehandedly writing DOS on the back of a napkin
Anyone heard these stories? The much more common one is that he was in a hurry for an operating system so bought it form its original author for some pittance or other. That's very commonly known.
Windows 3.0, a DOS application
??? Windows 3 was somewhat more than an application. In almost all ways it qualifies as an operating system (it only lacked a device driver framework, relying on DOS to provide that in its place). But the writer's thesis doesn't work if Windows 3 was an operating system, so it's an application instead. Yeah, right.
At some future point, the world was supposed to trade in the essentially free-to-obtain DOS with a paid $200 copy of OS/2. That would enable PC users to run the software designed for DOS and Windows they already could run, as well as new software native to OS/2 that they did not have and did not yet exist. Hmm.
It's amazing that neither IBM nor Microsoft seemed to worry that this strategy might not work out, but everything is much clearer in hindsight.
Perhaps because that was never anybody's strategy. Nobody expected people to switch to OS/2 for no reason. Windows was a portability thing: if the Windows API were supported on both DOS and OS/2, then applications could be written that targetted either. When people came to buy a new computer, they could see that the more advanced operating system basis of OS/2 could give them superior performance to DOS, and so buy OS/2 instead.
Also, DOS wasn't "nearly free to obtain". I distinctly remember paying £70 for a copy back around the time we're talking about, which makes it pretty similarly priced to the $200 claimed for OS/2.
a world ready to believe that everything Microsoft could plan would be delivered at some point, even though Microsoft had absolutely no history of delivering any significant or original operating system technology.
Other than, you know, DOS and Windows. And this MS who had recently hired Dave Cutler, a very respected OS engineer
I, for one, don't allow my machines to make outgoing UDP connections. Never have, never will.
UDP IS CONNECTIONLESS!
That's why I put "connection" in quotes. Yes, UDP is connectionless. Some firewalls, however, maintain a list of virtual UDP connections in order to allow packets into the inside of the firewall when a machine on the inside has previously sent packets to their source.
Pretty successful? Others think naught.
So why, then, is it included in multiple BSD systems and SELinux?
This article seems to imply that ASLR (or ALSR or whatever it is) can either be disabled by the user system-wide, or that certain systems won't have the features required to enable ASLR.
That article's talking crap. ASLR doesn't require DEP; it just isn't particularly useful at preventing buffer overrun attacks without it. If there were any programs that failed to work when run on the local system when ASLR was enabled, the lack of DEP would not prevent this.
Don't you love how market forces work for the good of the consumer
Market forces tend to work pretty well for the largest group of consumers. The rest of us suffer.
Ok, so two-thirds of the tricks used in worms and virus buffer overflor attacks are negated, but are those two-thirds heavily used attacks, or very minor ones?
There are two ways of exploiting a buffer overflow: you can make code in the buffer execute, or you can make code that already exists in the system execute with parameters from the buffer. The former is prevented by NX protection in most cases. The latter is made substantially more difficult by ASLR.
What exactly can the BIOS do with the hardware that the OS or boot loader can't? Err , nothing as far as I'm aware so whats the deal here?
As I understand it, there's a method that can be used to disable NX protection on some processors. Some BIOSs/motherboards do this. Once it is done, there's no way for the OS to undo it.
What all this has to do with ASLR is beyond me.
You do memory reads and code string matches to determine where modules are loaded
How do you do that when you don't have access to run code on the machine, but are only able to overwrite a stack return address with an address you've chosen?
Note that the address of your exploit code will likely have been randomised along with everything else. Or NX is enabled, and you've only got a return-to-libc attack available to you.
Those are the situations this scheme is designed to protect from, and it's pretty successful.
I have noticed if DEP is turned on in XP when I look at the folder with all my porn and thumbnails are turned on it causes Explorer to crash. I hope they fix this.
Of course this could be because one of those thumbnails is exploting a bug in Explorer's JPEG rendering and trying to execute itself, and DEP is actually preventing it from doing so...
It is a way to get two computers that are already allowed to talk to whoever they want on the internet to talk to each other despite both having firewalls that don't allow incoming connections. It does not cause violation of firewall policy or break firewall rules in any way, it just gets over an unfortunate incompatability in this world of NAT.
The issue only arises because both parties are firewalled.
Exactly. As far as anyone else is concerned, they might as well be communicating via a third party relay. Except there's no need for there to be one.
They're allowed to make outgoing "connections" by the firewall rules. This is just a way of making two outgoing connections connect to each other. If you have a problem with it, you probably shouldn't be allowing your machines to be making outgoing UDP connections.
Nothing to see here. Move on.
Other option: don't allow incoming UDP packets, even if there has been an outgoing one, except from trusted IP addresses. I mean, you're only using UDP for DNS, right, and you know the IP address of your resolving DNS server...?
The "firewalls" are stupidly allowing packets to come back in from any source.
No, they're letting packets back in from any source to which a packet has been previously sent. One of the first two packets sent by the clients will be dropped, but the others will all go through fine.
Not that this makes it anything other than a stupid way of setting up a firewall if you're trying to regulate what protocols can be used. And if you aren't, what's the big deal?
And how are you going to receive replies if you tell it to drop the response packets?
By whitelisting the protocols you want to use UDP with, and preferably only for the hosts that you expect to receive responses from, and maybe even the machines on your own network you expect them to go to.
A corporate network should be locked down tight, and frankly most employees have no business messing around with anything that uses UDP. DNS requests should be sent to a trusted DNS resolving server, which should be the only machine allowed to make external DNS requests (and therefore receive responses to them). There may be a central VPN server that needs to accept incoming UDP packets for VPN communications. Other than this, UDP should probably be locked down completely.
No, it is "punching" a hole in the firewall.
There is no firewall here. If there was, there'd likely be a firewall rule that says "drop UDP packets originating or terminating on this list of addresses/ports that has been cleared for use" and nothing would happen. Most firewalls deny packets access unless there is some rule to allow them.
Note that making photoshopped kiddy-porn pictures is already illegal in the UK. This would extend it to posession, and to drawings.
I thought the Criminal Justice and Public Order Act 1994 already amended the Protection of Children Act 1978 to make pseudo images of child porn illegal anyway. Sounds like this would be extending that to "abuse".
This only refers to photo-realistic images. The new proposal would also cover drawings.
the person looking for this material is a victim.
So clearly they must be punished.
Err... no, that's not right. If they're the victim (and I agree, BTW), we should be helping them. Not sending them to prison for multiple years.
It encourages the direct physical abuse of real children by conditioning the paedophile to consider their lustful and abusive mentality "acceptable" or "normal".
Evidence please. The studies I've seen (sorry, don't have links) have concluded that there is insufficient evidence to come to this conclusion, and that the opposite effect (that access to fantasy material allows those with paedophilic urges to experience them purely as fantasy rather than acting them out on a real victim) may actually be more significant.
Even Hentai isn't a fair comparison, because while the material is deeply disturbing "tentacle sex demons" ties in with some Japanese religions and folklore. It is an excellant example of a storyline where you don't want live human actors, but that doesn't mean it should be suppressed by people who don't understand the cultural significance.
By the descriptions I've heard of the proposed legislation, Hentai is very much a fair comparison because a significant proportion of it would become illegal.
On the average Windows box, you then repeat this process ever 6 months because it got fricked up somehow.
Or you learn how to use system restore points.
4 years and no reinstalls.
Because lots of lawyers consider such support illegal?
Which lawyers? Can you point me to their analyses?
Linux kernel and modules are compiled with gcc. Windows "kernel" and "modules" are compiled with MSVC. These compilers use different calling conventions (low-level assembly issues such as register allocation, parameter usage on the stack, etc.), and as such, binaries produced by one wouldn't be compatible with binaries produced by others.
No they don't. They both use the standard conventions for IA32: parameters passed right to left, DWORD aligned, caller clears, callee saves EBX, ESI, EDI and EBP if it modifies them, function return values are stored in EAX (+EDX if they're 64 bit). You can take code compiled with MSVC and call it from GCC trivially, as long as it doesn't use structured exception handling (which is an MS extension that GCC doesn't support).