Simply, I'd say that porting is impossible. It's mostly in C, but most people wouldn't call what I write C. It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386. As already mentioned, it uses a MMU, for both paging (not to disk yet) and segmentation. It's the segmentation that makes it REALLY 386 dependent (every task has a 64Mb segment for code & data - max 64 tasks in 4Gb. Anybody who needs more than 64Mb/task - tough cookies).
And now it is running on, what, 20 different architectures? With or without MMU, running hundreds...thousands of tasks of up to gigabytes in size. Of course, of that version nothing will have remained. Not even the name, because that came later.
This would be true if - they would always release security fixes as soon as possible - they would know that there was a problem but they had no fix available yet
However, in reality: - all security fixes are delayed to patchday. 918899 was compiled on June 25th and all that time between June 25th and patchday the customers were vulnerable - the problem was known and fixed a couple of days before patchday.
Also, remember that it is not only that the fault exposes the user to new threats (which they may not have realized), but the patch just locked out users from certain webpages, including those of certain applications that use a browser interface. The immediate damage from installing the patch (locking out users from their daily application) is much higher than the theoretical risk of being hit by some worm that may be in the wild but is not as quickly spreading as things like code red.
Also note that the patch mentioned in KB923762, which is available only by calling Microsoft and explicitly asking for it, was compiled on August 4th!
So, they KNEW about this problem at the time they sent out 918899 to the world via Windows Update! They already had the fix available, but they chose to neither include it in 918899 nor to withhold 918899 from release on August 8th.
It caused some damage at work. We had to ask for the KB923762 fix, which took 3 days to get (because we buy computers with Windows installed, so we cannot call Microsoft but have to go via Dell). IMHO it is gross neglect by Microsoft to knowingly release a defective update for which a better version already is available.
The first issue went out with the defect documented in KB835734, for which a critical fix should have went out immediately! But nothing was done except providing a nearly nonvisible update, and this issue has caused nearly untamable mailstorms damaging customer reputation, ringing up traffic bills, and causing lots of grief. At least they demonstrated that not everyone can write a fetchmail clone.
The typical customer for this package has no means at all to point out what was happening, and the system integrators usually only come by to look maybe the next day or so. (when they tried remote access over the same internet connection, it would be stuffed with traffic)
At least now they recall it before it is too late.
A problem with Linux encrypted partitions is that there are several formats, and no migration path. As usual, when new and better solutions are developed, the Linux developer scene does not really care about backward compatability. The new method is sooo good that the old one should be left in the dust and its adopters must backup and restore. Developers who suggest backup and restore must be unaware of the current market situation w.r.t. backup solutions and their capacity vs that of IDE disks...
Recently I decided to move two disks from my main system, encrypted under SuSE 9.2, to another box that I want to dedicate to background storage. I remembered that I had read about some issue in 9.3, but I believed that it had been long solved so I installed SUSE 10.0 on this new box.
There was NO WAY I could get the disks mounted. I tried all the tricks found in several articles on Internet, but I kept getting errors. The SuSE knowledge base stated that everything would be fine when I just upgraded the OS, but I don't believe that because I tried the solutions equivalent to what would happen when upgrading. I don't want to risk it.
Finally, the only solution was to install 9.2 on the new box, and the disks worked OK. Then, I have bought more disks (as was the plan) and copied the data from encrypted to unencrypted disks. Next step will be to install 10.0 again, but I am not so sure if I will encrypt the disks again as the 10.0 system is (I believe) not LUKS so probably at 11.0 I will again face the same problem because the "all new and better LUKS" is now the supported system.
I will not even think about what would happen when I would want to change the distribution from SuSE to RedHat or Ubuntu or whatever. Chances must be about zero that I can still access the data.
There is not even a tool that would in-place decrypt (or encrypt, for that matter) the data on a partition. Even when one wants to take the risk that it interrupts halfway and destroys everything. So you always need a source and destination device with enough space.
Please keep this in mind before you encrypt your terabyte volumes...
I fully agree with that. The producers need some protection against distributors of illegal copies.
However, they should at the same time be more exposed to the price point they decide. Now, they can decide to spend a million more on the salary of the actor, and recoup that via a higher price on the product, without the consumer having any say in that.
The consumer can only buy at the set price, and the content producers can inflate this over and over. When the consumer decides the price is too high and no longer buys the product, the producer does not (as he would in a normal economy) try to cut costs and reduce the price, NO. Instead he goes to the government and cries "it is all because of that Internet that we sell less than before, you have to do something!".
That is not a healthy situation. It means the normal process that sets the price of the product is switched off, the price can remain at a high level with lots of overhead and profit in the producing company, and the consumer is the victim both because his rights are restricted more and more, and because he pays too much for entertainment.
You'd be surprised what desperate people who have time to practice beforehand can accomplish. Just because they're "murderous" doesn't mean that they're stupid or uncreative.
That is precisely why you should not "fight a WAR" against terrorism! Terrorism exists because people are desperate because of the situation they are in, and fighting a war against them is certainly not going to improve that situation.
I think the guy that coined the term "war against terrorism" is quite stupid. In fact, I think he is more of a hazard to the free world than most terrorists are.
It is of course not possible to compare GHz numbers 1:1... I was talking in terms of the typical P4 systems we have on desktops, and Centrino is different. And so are the XEONs.
We normally buy low-to-mid range stuff (Dell OptiPlex), not gaming hardware. But speeds are increasing every time you buy a new batch of systems, for the same price and the same power consumption. It is not like you could order 1 GHz P4 systems at much reduced price and power and make considerable money that way. The systems will cost just as much, and an unloaded 3 GHz processor does not consume the power it takes at full load (with today's power saving systems).
We use Citrix (Metaframe XP) and it works fine, but I don't understand how you can simply discard my argument about desktop resources.
You write: On a quad-proc server with 2Ghz CPUs and 8Gb of RAM (HP Proliant DL380 G2's and G3's) or thereabouts, we routinely run 50 users per machine... sometimes up to 75.
This means that 50-75 users are competing over 8 GHz of CPU power and 8GB of RAM. Would they have used their local workstation resources, they would have got 150 GHz of CPU and 50 GB of RAM to handle their load. Sure you can make a claim that it works for you, and I believe it, but you will have to admit that you are (forcibly) doing the job with a lot less resources than available, and are relying on solutions for the problem of even distribution of resources that simply do not exist when applications are running locally.
Our Citrix systems are running satisfactorily, and it is good to read that newer versions have finally taken the most sensible way of solving the hogging problem (when a user process is chowing down a CPU for too long, it gets reduced in priority automatically so that other users can run the applications, something that Unix/Linux has done since day 1 and I always wondered why Windows did not do this!). Maybe we should look into upgrading as well.
However, my standpoint remains: Citrix is a nice solution, it can well be used to solve remote access to applications that were not built with that aspect in mind, and we do use it for that. But it should not be the hammer that is used to drive in anything, even when it is a screw instead of a nail. Applications that require little maintenance and configuration, can be automatically installed, and have reasonable performance over the network can just as well be run locally, and will enjoy the extra resources available from today's PCs. Examples: Web browsers, Mail clients, SAP GUI and similar, Office suites, etc. Other applications, like those that evolved from Visual Foxpro-like development environments, are better placed on Citrix servers.
We do the same, except that we have set up the systems with some security. The normal user cannot write to the harddisk except in his own profile, which is the part that gets written back to the server when you log out. It does not contain "My documents" (this is moved to the network drive) but (really) sometimes we find people saving documents in interesting folders within their profile. However, this does not mean they are lost, it just increases the network traffic (and their waittime) when they login and logout.
At least, they cannot easily blame us for losing data. There is no user data on a desktop system that ins't also on the server. We just swap and format workstations at will, and nothing is ever lost.
Well, the profile mostly IS just a directory with a bunch of files on the network drive. What makes it suck is: - there are so many files - there is no server-side support using an rsync-like protocol
This means that for every login it has to walk the entire tree and copy newer files in their entirety. This takes a long time over links that have more than a millisecond of RTT. I.e. VPN, WAN links, in fact everything besides a LAN.
There are independent solutions for this problem, but Microsoft really should have done something about it and built it right into Windows 2000+
What you forget with your Citrix solution is that you move the problem from the network to the CPU and memory. When you have an entire office full of modern PCs (say with 512-1024 MB of RAM and a 2-3 GHz class CPU) you are wasting a large amount of real estate when you run ICA Client on all those and make the people work on one or a few Citrix servers where they all have to compete for a few CPUs and a lot less memory.
Citrix is nice, but it is not the answer to everything. When the users run intensive or inefficient applications, it can be a severe performance problem. The solution he has in mind does not have that problem, because his applications run locally so they utilize the local resources available on the desktop.
People actually use wakeup on lan on desktops?
Yes, we use WOL to wakeup windows workstations in the weekend (or the night, in emergency cases) and install/update software or hotfixes. So, the user is not bothered with waittime reboots after application installs.
But it doesn't! The box model could already be fixed in IE6 by using the proper doctype switch, and:hover could be added using csshover.htc
IE7 still has CSS positioning bugs that other browsers don't. The site at work http://www.uw.nl/ works with all (modern) browsers I could find to test it. It has conditional stylesheets to make it work with IE5 and IE6, but it works as-is in all others.
This site's menu system (which is created with css:hover tricks) does not display correctly in IE7. It shows many positioning and stacking bugs that are also seen in IE6 when omitting the conditional stylesheet.
I'll wait until IE7 is finally released, to see if they fix any of the bugs in the upcoming betas. If not, it is probably possible to get it right by including another conditional stylesheet (this time targeting only IE7) but it is a sad thing that these measures are required. Why can't they render just like everyone else?
IBM's VM also started as a software product that had to cope with virtualisation problems in the hardware. Just like what is happening now, they added specific support to the hardware to make VM perform better. This all happened before the development of today's architectures, but in the early days of microcomputing, IBM had the position that Microsoft has today: they were the big company that had 90% of the market, and in the eyes of the newcomers all they did was by definition the wrong thing. So nobody would bother to look at 360 mainframes, VM and how it was done before designing their own processor. (this would be similar to telling a Linux geek to look at how certain problems are solved in Windows... it is Windows, it is Microsoft, so it has to be the wrong solution)
Citrix? Not an open source product and not lost it to an open source product, but they made a product that has been largely made superflouos because MS built it right into the OS.
But that was true for many systems in those days! With my TRS-80 system, I used separately bought TEAC drives instead of the original Tandy drives. Not only did they store more date (being 40-track double sided instead of 35-track single sided), they were also "only" $400 each, so much cheaper than the genuine drives that went for like $600.
(I just ordered some new harddisks, 800GB more space for much less than what a 360K floppy drive cost in those days)
I don't know about the reasons for failures of desktop lines, but in those days I built my own electronics devices and it was often true that Motorola had the nicest databooks, but no silicon on the shelf. You could spend hours reading what the 68HC11 microcontroller was capable of, but you would spend months waiting when you wanted to order them. Same for certain 56K devices.
I can understand that a computer manufacturer would not want to design around Motorola devices, then find that they have to hold production for months because the factory cannot deliver.
At first I had included this note in my reply (the 68000 really being 16 bit) but I left it out for readability. But you are right about that. However, to the programmer it appeared to be fully 32-bit and it could in later models be easily extended to be 32-bit without effect on software. (compare that to the 386 which needed new software that used 32-bit opcodes)
Of course the main reason the 68000 became a dead end, is that it was not used in the PC and no development money went into it. The 68000 could have been re-designed the same way the x86 was, but there was no money to be made so no reason to do it.
I don't want to defend the 68000 too much. I have used Atari ST machines for several years and I fully realize that although it looks beautiful at first, there are serious drawbacks, like: - the two kinds of registers (D and A) are a nuisance - the fixed opcode size means the cpu needs to read more opcode (program) data, consuming memory and bus bandwidth better left for data
When the PC became such a success and IBM found itself more and more out of the loop, they tried that approach. With the introduction of the PS/2, a new bus (MCA) was introduced and everything was more or less closed again.
It became a miserable failure, because the genie was already out of the bottle and the clone manufacturers could just ignore IBM and go on making their clones without having to incorporate more than the keyboard and mouse connector. The early issue of "is this clone really compatible with IBM" had turned around to "is IBM still compatible with the PC world", and after a while they turned back to making compatible systems.
The IBM PC was designed when desktop systems were still 8-bit. IBM wanted to design an 8-bit system, but certain people recommended to go for 16-bit, and a compromise was found in the 8088 that had a 16-bit architecture but an 8-bit bus. So the hardware could be built for 8 bits, and the software still could use 16 bits. This fell within the design criteria and cost objectives.
The 68000, on the other hand, was one step up. This was a 32-bit processor with a 16-bit external bus. Costs would certainly have been higher when using that. An 8-bit external version (68008) appeared only later, probably when Motorola saw the success of the 8088.
In 1981, the 68000 was seen in "supermicro" systems, definately in a higher price class than the IBM PC. They were used as departmental computers with several terminals. Use of the 68000 in desktop systems became popular in later years, but then IBM was already bound to Intel and used the 80286 in their AT.
Actually, the keyboard of the original 5150 was subject of a lot of critisism! Reviewers did not like the layout *at all*. For example, the swapped positions of Ctrl and Caps Lock, and the introduction of the Alt key and the strange form of Enter and the numeric keypad (combined with cursor arrows) really put them off.
The keyboards of the later AT and PS/2 systems corrected that. IMHO the early PS/2 keyboard is the best of all.
The fuss was about a computer that could be used in a business, vs the hobby computers that were popular before that. Most of the hobby computers could not stand up to professional daily use, and the IBM PC could. Personal computing went from hobby computing to being a business tool.
Well, in those days other chip manufacturers used a single interrupt line and either polling or vectoring. Priority was determined by the software or by a hardware daisy chain (e.g. in Zilog's vectoring system, which worked beautifully).
Intel used a special chip that was dedicated to interrupt vectoring, the 8259. It had 8 inputs of fixed priority, int 0 being the highest and int 7 being lowest.
The 5150 had one of these, and the ints 0 to 7 were partly hardwired and partly on the ISA bus. A stupid design mistake was made: interrupts were edge-triggered on the 0->1 edge of the input. This was a programmable option in the 8259, which could also operate in a level-sensitive mode. This mistake meant that interrupt lines could not be shared between cards. (other manufacturers of the time used active-low level-sensitive mode, which meant it was possible to share interrupt lines)
When the AT appeared, and the number of available lines was felt too limited, a second 8259 was connected to int 2 of the first, and its input were designated 8..15. Input 9 was connected to the bus pin that originally was number 2. Hence the 2/9. The priorities of inputs 8..15 became relative to int 2, thus the complete priority sequence becomes:
0,1,[8,2/9,10,11,12,13,14,15],3,4,5,6,7
Some of those (0,1,8,13,14) are used on the motherboard. The remainder is on the ISA bus.
Later, when MCA and PCI were developed, engineers corrected their mistake and used level-sensitive interrupts that could be shared. But in the name of backward compatability, the strange interrupt numbering and handling has always remained there. (current systems have 24 levels and more freedom in programming the whole thing to the OS developer's liking)
Slashdot Mirror
Simply, I'd say that porting is impossible. It's mostly in C, but most
people wouldn't call what I write C. It uses every conceivable feature
of the 386 I could find, as it was also a project to teach me about the
386. As already mentioned, it uses a MMU, for both paging (not to disk
yet) and segmentation. It's the segmentation that makes it REALLY 386
dependent (every task has a 64Mb segment for code & data - max 64 tasks
in 4Gb. Anybody who needs more than 64Mb/task - tough cookies).
And now it is running on, what, 20 different architectures?
With or without MMU, running hundreds...thousands of tasks of up to
gigabytes in size. Of course, of that version nothing will have
remained. Not even the name, because that came later.
This would be true if
- they would always release security fixes as soon as possible
- they would know that there was a problem but they had no fix available yet
However, in reality:
- all security fixes are delayed to patchday. 918899 was compiled on June 25th and all that time between June 25th and patchday the customers were vulnerable
- the problem was known and fixed a couple of days before patchday.
Also, remember that it is not only that the fault exposes the user to new threats (which they may not have realized), but the patch just locked out users from certain webpages, including those of certain applications that use a browser interface.
The immediate damage from installing the patch (locking out users from their daily application) is much higher than the theoretical risk of being hit by some worm that may be in the wild but is not as quickly spreading as things like code red.
Also note that the patch mentioned in KB923762, which is available only by calling Microsoft and explicitly asking for it, was compiled on August 4th!
So, they KNEW about this problem at the time they sent out 918899 to the world via Windows Update!
They already had the fix available, but they chose to neither include it in 918899 nor to withhold 918899 from release on August 8th.
It caused some damage at work. We had to ask for the KB923762 fix, which took 3 days to get (because we buy computers with Windows installed, so we cannot call Microsoft but have to go via Dell).
IMHO it is gross neglect by Microsoft to knowingly release a defective update for which a better version already is available.
The first issue went out with the defect documented in KB835734, for which a critical fix should have went out immediately!
But nothing was done except providing a nearly nonvisible update, and this issue has caused nearly untamable mailstorms damaging customer reputation, ringing up traffic bills, and causing lots of grief. At least they demonstrated that not everyone can write a fetchmail clone.
The typical customer for this package has no means at all to point out what was happening, and the system integrators usually only come by to look maybe the next day or so.
(when they tried remote access over the same internet connection, it would be stuffed with traffic)
At least now they recall it before it is too late.
Worse: once you have added ADSL, you are stuck with the ISDN (the ISDN-2 that you mean) forever, even when its functions are then useless for you.
This would be like having to buy Plasma-DVD's for your Plasma TV and not being able to view them on an LCD.
A problem with Linux encrypted partitions is that there are several formats, and no migration path.
As usual, when new and better solutions are developed, the Linux developer scene does not really care about backward compatability. The new method is sooo good that the old one should be left in the dust and its adopters must backup and restore.
Developers who suggest backup and restore must be unaware of the current market situation w.r.t. backup solutions and their capacity vs that of IDE disks...
Recently I decided to move two disks from my main system, encrypted under SuSE 9.2, to another box that I want to dedicate to background storage.
I remembered that I had read about some issue in 9.3, but I believed that it had been long solved so I installed SUSE 10.0 on this new box.
There was NO WAY I could get the disks mounted. I tried all the tricks found in several articles on Internet, but I kept getting errors.
The SuSE knowledge base stated that everything would be fine when I just upgraded the OS, but I don't believe that because I tried the solutions equivalent to what would happen when upgrading. I don't want to risk it.
Finally, the only solution was to install 9.2 on the new box, and the disks worked OK. Then, I have bought more disks (as was the plan) and copied the data from encrypted to unencrypted disks. Next step will be to install 10.0 again, but I am not so sure if I will encrypt the disks again as the 10.0 system is (I believe) not LUKS so probably at 11.0 I will again face the same problem because the "all new and better LUKS" is now the supported system.
I will not even think about what would happen when I would want to change the distribution from SuSE to RedHat or Ubuntu or whatever.
Chances must be about zero that I can still access the data.
There is not even a tool that would in-place decrypt (or encrypt, for that matter) the data on a partition. Even when one wants to take the risk that it interrupts halfway and destroys everything. So you always need a source and destination device with enough space.
Please keep this in mind before you encrypt your terabyte volumes...
I fully agree with that. The producers need some protection against distributors of illegal copies.
However, they should at the same time be more exposed to the price point they decide. Now, they can decide to spend a million more on the salary of the actor, and recoup that via a higher price on the product, without the consumer having any say in that.
The consumer can only buy at the set price, and the content producers can inflate this over and over. When the consumer decides the price is too high and no longer buys the product, the producer does not (as he would in a normal economy) try to cut costs and reduce the price, NO.
Instead he goes to the government and cries "it is all because of that Internet that we sell less than before, you have to do something!".
That is not a healthy situation. It means the normal process that sets the price of the product is switched off, the price can remain at a high level with lots of overhead and profit in the producing company, and the consumer is the victim both because his rights are restricted more and more, and because he pays too much for entertainment.
You'd be surprised what desperate people who have time to practice beforehand can accomplish. Just because they're "murderous" doesn't mean that they're stupid or uncreative.
That is precisely why you should not "fight a WAR" against terrorism!
Terrorism exists because people are desperate because of the situation they are in, and fighting a war against them is certainly not going to improve that situation.
I think the guy that coined the term "war against terrorism" is quite stupid. In fact, I think he is more of a hazard to the free world than most terrorists are.
It is of course not possible to compare GHz numbers 1:1... I was talking in terms of the typical P4 systems we have on desktops, and Centrino is different. And so are the XEONs.
We normally buy low-to-mid range stuff (Dell OptiPlex), not gaming hardware. But speeds are increasing every time you buy a new batch of systems, for the same price and the same power consumption. It is not like you could order 1 GHz P4 systems at much reduced price and power and make considerable money that way. The systems will cost just as much, and an unloaded 3 GHz processor does not consume the power it takes at full load (with today's power saving systems).
We use Citrix (Metaframe XP) and it works fine, but I don't understand how you can simply discard my argument about desktop resources.
You write:
On a quad-proc server with 2Ghz CPUs and 8Gb of RAM (HP Proliant DL380 G2's and G3's) or thereabouts, we routinely run 50 users per machine... sometimes up to 75.
This means that 50-75 users are competing over 8 GHz of CPU power and 8GB of RAM. Would they have used their local workstation resources, they would have got 150 GHz of CPU and 50 GB of RAM to handle their load.
Sure you can make a claim that it works for you, and I believe it, but you will have to admit that you are (forcibly) doing the job with a lot less resources than available, and are relying on solutions for the problem of even distribution of resources that simply do not exist when applications are running locally.
Our Citrix systems are running satisfactorily, and it is good to read that newer versions have finally taken the most sensible way of solving the hogging problem (when a user process is chowing down a CPU for too long, it gets reduced in priority automatically so that other users can run the applications, something that Unix/Linux has done since day 1 and I always wondered why Windows did not do this!).
Maybe we should look into upgrading as well.
However, my standpoint remains: Citrix is a nice solution, it can well be used to solve remote access to applications that were not built with that aspect in mind, and we do use it for that. But it should not be the hammer that is used to drive in anything, even when it is a screw instead of a nail.
Applications that require little maintenance and configuration, can be automatically installed, and have reasonable performance over the network can just as well be run locally, and will enjoy the extra resources available from today's PCs. Examples: Web browsers, Mail clients, SAP GUI and similar, Office suites, etc.
Other applications, like those that evolved from Visual Foxpro-like development environments, are better placed on Citrix servers.
We do the same, except that we have set up the systems with some security.
The normal user cannot write to the harddisk except in his own profile, which is the part that gets written back to the server when you log out.
It does not contain "My documents" (this is moved to the network drive) but (really) sometimes we find people saving documents in interesting folders within their profile.
However, this does not mean they are lost, it just increases the network traffic (and their waittime) when they login and logout.
At least, they cannot easily blame us for losing data. There is no user data on a desktop system that ins't also on the server.
We just swap and format workstations at will, and nothing is ever lost.
Well, the profile mostly IS just a directory with a bunch of files on the network drive.
What makes it suck is:
- there are so many files
- there is no server-side support using an rsync-like protocol
This means that for every login it has to walk the entire tree and copy newer files in their entirety.
This takes a long time over links that have more than a millisecond of RTT. I.e. VPN, WAN links, in fact everything besides a LAN.
There are independent solutions for this problem, but Microsoft really should have done something about it and built it right into Windows 2000+
What you forget with your Citrix solution is that you move the problem from the network to the CPU and memory.
When you have an entire office full of modern PCs (say with 512-1024 MB of RAM and a 2-3 GHz class CPU) you are wasting a large amount of real estate when you run ICA Client on all those and make the people work on one or a few Citrix servers where they all have to compete for a few CPUs and a lot less memory.
Citrix is nice, but it is not the answer to everything. When the users run intensive or inefficient applications, it can be a severe performance problem.
The solution he has in mind does not have that problem, because his applications run locally so they utilize the local resources available on the desktop.
People actually use wakeup on lan on desktops?
Yes, we use WOL to wakeup windows workstations in the weekend (or the night, in emergency cases) and install/update software or hotfixes.
So, the user is not bothered with waittime reboots after application installs.
29 minutes? More like 1600...
But it doesn't! :hover could be added using csshover.htc
:hover tricks) does not display correctly in IE7. It shows many positioning and stacking bugs that are also seen in IE6 when omitting the conditional stylesheet.
The box model could already be fixed in IE6 by using the proper doctype switch, and
IE7 still has CSS positioning bugs that other browsers don't. The site at work http://www.uw.nl/ works with all (modern) browsers I could find to test it.
It has conditional stylesheets to make it work with IE5 and IE6, but it works as-is in all others.
This site's menu system (which is created with css
I'll wait until IE7 is finally released, to see if they fix any of the bugs in the upcoming betas. If not, it is probably possible to get it right by including another conditional stylesheet (this time targeting only IE7) but it is a sad thing that these measures are required. Why can't they render just like everyone else?
IBM's VM also started as a software product that had to cope with virtualisation problems in the hardware.
Just like what is happening now, they added specific support to the hardware to make VM perform better.
This all happened before the development of today's architectures, but in the early days of microcomputing, IBM had the position that Microsoft has today: they were the big company that had 90% of the market, and in the eyes of the newcomers all they did was by definition the wrong thing. So nobody would bother to look at 360 mainframes, VM and how it was done before designing their own processor.
(this would be similar to telling a Linux geek to look at how certain problems are solved in Windows... it is Windows, it is Microsoft, so it has to be the wrong solution)
Where have I seen this before?
Citrix?
Not an open source product and not lost it to an open source product, but they made a product that has been largely made superflouos because MS built it right into the OS.
But that was true for many systems in those days!
With my TRS-80 system, I used separately bought TEAC drives instead of the original Tandy drives.
Not only did they store more date (being 40-track double sided instead of 35-track single sided), they were also "only" $400 each, so much cheaper than the genuine drives that went for like $600.
(I just ordered some new harddisks, 800GB more space for much less than what a 360K floppy drive cost in those days)
I don't know about the reasons for failures of desktop lines, but in those days I built my own electronics devices and it was often true that Motorola had the nicest databooks, but no silicon on the shelf.
You could spend hours reading what the 68HC11 microcontroller was capable of, but you would spend months waiting when you wanted to order them.
Same for certain 56K devices.
I can understand that a computer manufacturer would not want to design around Motorola devices, then find that they have to hold production for months because the factory cannot deliver.
At first I had included this note in my reply (the 68000 really being 16 bit) but I left it out for readability. But you are right about that.
However, to the programmer it appeared to be fully 32-bit and it could in later models be easily extended to be 32-bit without effect on software.
(compare that to the 386 which needed new software that used 32-bit opcodes)
Of course the main reason the 68000 became a dead end, is that it was not used in the PC and no development money went into it.
The 68000 could have been re-designed the same way the x86 was, but there was no money to be made so no reason to do it.
I don't want to defend the 68000 too much. I have used Atari ST machines for several years and I fully realize that although it looks beautiful at first, there are serious drawbacks, like:
- the two kinds of registers (D and A) are a nuisance
- the fixed opcode size means the cpu needs to read more opcode (program) data, consuming memory and bus bandwidth better left for data
It was generally seen as a bad PDP-11 copy.
When the PC became such a success and IBM found itself more and more out of the loop, they tried that approach.
With the introduction of the PS/2, a new bus (MCA) was introduced and everything was more or less closed again.
It became a miserable failure, because the genie was already out of the bottle and the clone manufacturers could just ignore IBM and go on making their clones without having to incorporate more than the keyboard and mouse connector. The early issue of "is this clone really compatible with IBM" had turned around to "is IBM still compatible with the PC world", and after a while they turned back to making compatible systems.
The IBM PC was designed when desktop systems were still 8-bit. IBM wanted to design an 8-bit system, but certain people recommended to go for 16-bit, and a compromise was found in the 8088 that had a 16-bit architecture but an 8-bit bus. So the hardware could be built for 8 bits, and the software still could use 16 bits. This fell within the design criteria and cost objectives.
The 68000, on the other hand, was one step up. This was a 32-bit processor with a 16-bit external bus. Costs would certainly have been higher when using that.
An 8-bit external version (68008) appeared only later, probably when Motorola saw the success of the 8088.
In 1981, the 68000 was seen in "supermicro" systems, definately in a higher price class than the IBM PC. They were used as departmental computers with several terminals.
Use of the 68000 in desktop systems became popular in later years, but then IBM was already bound to Intel and used the 80286 in their AT.
Actually, the keyboard of the original 5150 was subject of a lot of critisism!
Reviewers did not like the layout *at all*. For example, the swapped positions of Ctrl and Caps Lock, and the introduction of the Alt key and the strange form of Enter and the numeric keypad (combined with cursor arrows) really put them off.
The keyboards of the later AT and PS/2 systems corrected that. IMHO the early PS/2 keyboard is the best of all.
The fuss was about a computer that could be used in a business, vs the hobby computers that were popular before that.
Most of the hobby computers could not stand up to professional daily use, and the IBM PC could.
Personal computing went from hobby computing to being a business tool.
Well, in those days other chip manufacturers used a single interrupt line and either polling or vectoring. Priority was determined by the software or by a hardware daisy chain (e.g. in Zilog's vectoring system, which worked beautifully).
Intel used a special chip that was dedicated to interrupt vectoring, the 8259. It had 8 inputs of fixed priority, int 0 being the highest and int 7 being lowest.
The 5150 had one of these, and the ints 0 to 7 were partly hardwired and partly on the ISA bus.
A stupid design mistake was made: interrupts were edge-triggered on the 0->1 edge of the input. This was a programmable option in the 8259, which could also operate in a level-sensitive mode. This mistake meant that interrupt lines could not be shared between cards.
(other manufacturers of the time used active-low level-sensitive mode, which meant it was possible to share interrupt lines)
When the AT appeared, and the number of available lines was felt too limited, a second 8259 was connected to int 2 of the first, and its input were designated 8..15.
Input 9 was connected to the bus pin that originally was number 2. Hence the 2/9.
The priorities of inputs 8..15 became relative to int 2, thus the complete priority sequence becomes:
0,1,[8,2/9,10,11,12,13,14,15],3,4,5,6,7
Some of those (0,1,8,13,14) are used on the motherboard. The remainder is on the ISA bus.
Later, when MCA and PCI were developed, engineers corrected their mistake and used level-sensitive interrupts that could be shared.
But in the name of backward compatability, the strange interrupt numbering and handling has always remained there.
(current systems have 24 levels and more freedom in programming the whole thing to the OS developer's liking)