Actually the BIOS required two calls to draw each character, because the call that drew a character did not move the cursor.
The call that drew a string of characters did not exist in the original BIOS. I think also it did not allow you to set the color of the characters in any useful way and was thus useless. The original MSDOS did not provide an interface to draw a string of text so nothing used this call and many clone Bios's had it broken.
MSDOS did add "ansi.sys" that made escape sequences usable from MSDOS 2.0. However it was implemented atop the BIOS and was unbelievably slow. There were several open-source replacements for ansi.sys that wrote directly to the hardware and actually made regular MSDOS command prompt much faster, but because they were not part of default installation (neither was ansi.sys) nobody used these. Ansi.sys also had the problem that it could reprogram the function keys and actually forced the few programs still using MSDOS for input to give up and use the BIOS or the hardware.
If I remember right the keyboard interface could report the state of the shift keys, the problem was that certain key combinations produced nothing, ie you could not tell if they had been typed by using the BIOS. Also the AT keyboard showed further BIOS stupidity: apparently somebody at IBM panicked and thought some software would crash if presented with codes from the keyboard it had not seen before, so they added a new call that you had to use if you wanted to see F11, F12, or any of the new arrow keys. And of course MSDOS was not changed to use this new call.
All pretty horrible, actually. And we still live with it now. Ever wonder why there are arrows printed on your numeric keys? And what is "scroll lock" or "sys req"...
No, if the quote is correct, Gates himself decided to map the video hardware at that point and remove about 1/3 of the potential memory from the machine design.
MSDOS itself has no 640K limit. If it was written to "accomodate hardware limitations" it probably would.
I still believe that it is IBM that screwed up and Gates probably wanted the hardware higher. The "640K" was probably said when he really means "1Meg" because the average person thought 640K was the physical limit.
I'm pretty certain the 8086 was chosen because of it's ability to emulate the 8080 instruction set (I think the instructions matched but it was not binary compatable, you needed to reassemble). There was a lot of CP/M software that was written in assembler and IBM considered it vital to port this. CP/M compatability also dictated a lot of MSDOS 1.0 design, including "FCB"s used to read/write files and the layout of the initial block of memory when a program was run, and the 128 byte limit on command line arguments that I think is still in XP.
Actually MSDOS did pretty good fooling the FCB's into having an in-dos portion so disk access was faster. And they did very good with the rewrite for MSDOS 2.0 where they replaced the FCB's with Unix-style read/write/seek. Unfortunately everything since MSDOS 2.0 has sucked pretty bad.
I think it was not quite additive, instead the carry out of bit 16 was not used, the resulting address always had the top 4 bits matching the top 4 of the segment. This was done on purpose to allow the segment to be a "virtual" page number, they would only have to trap the loadings of segment registers to make the 80286 do virtual memory. This idea was unfortunately killed because all the programs that hard-coded the 4-bit offset, you were not supposed to assumme the segments overlapped at all.
So adding seqment 0FFFF and offset 0FFFF resulted in FFFEF.
It would help if this post was not full of serious errors. Are you sure you are not trying to make defenders of Bill Gates look like idiots?
Bill Gates wrote BASIC, not "DOS". At that time the equivalent of DOS was CP/M. MicroSoft purchased the beginnings of MSDOS from another company that it later sued out of business, and that was a copy of CP/M. Claiming Bill Gates had anything to do with the creation of any early version of DOS is just so totally wrong it both demeans you and him.
If it was not for Bill Gates what would we have on the PC? Well I expect we would have some other monopoly selling some other PC operating system. Maybe even IBM. And Bill Gates would be here on SlashDot complaining about the evil monopolist who is running that company and rooting for the government's anti-trust suit. Don't think that Bill Gates did anything other than be in the right place at the right time, what happened would have happened exactly the same without him!
And there would be a GUI just as sophisticated as Windows, and Office software just the same (maybe better if the monopoly had held off some more, maybe worse if the monopoly had been claimed earlier, perhaps by Lotus). And lots of programmers would have started in whatever was on this monopoly system and does that make it good?
Unbelivable that you think that without MicroSoft there would be no alternative. The problem is that with MicroSoft there is no alternative, and people like you are so brainwashed you cannot picture that MicroSoft killed it's competition and that that competition was entirely capable of doing what MicroSoft did!
I won't go into the "windows drove Mac development forward" comment. You obviously have a very warped version of history. Try reading, even Gate's book is more accurate!
No, it was hardware that limited it. The processor could not address more than 1 megabyte. This was not just a limitation of address lines, the actual internal instructions could not (there was a plan to change the overlap between "segment" and "offsets" to enlarge this but too much software relied on the existing overlap and MSDOS did lack any way to control it).
Much worse than th 1Meg barrier was the fact that IBM stuck the video memory right about in the middle, leaving 640K below, and perhaps 200K above. This was unbelievabley stupid. They could have at least mapped it at one end. Better yet a switch to turn the mapping on/off, which would also have prevented the huge number of direct-mapping programs that frozer hardware design for years.
The high memory managers were written by Lotus, I think. They were pretty awful and relied on copying small blocks from higher addresses by changing the segment overlap and writing them into the "hole" above the video memory and below 1Meg.
Definately the problems were with the hardware and BIOS software designers at IBM, not with the people at MicroSoft.
With the current technology there was NO reason for a 640K barrier. The chip could address 1 megabyte. Anybody with some sense would have put the memory-mapped video up at the top end of the memory, or at the bottom. For the 25x80x2 byte memory this would leave a block of size 1020K. They could have placed the color and b&w memory maps in the same place as well as real users (but not the enginners at IBM testing the machines, alas) did not use both cards!
The writers of the "bios" completely killed all advances in display technology until Windows came out by their stupid design. They probably asked MicroSoft what basic needed to draw on the screen and MicroSoft said "we need to move the cursor, and draw letters at the cursor" and those idiots at IBM dutifuly made a call that moved the cursor and another call that placed a letter at the cursor and did not move it!!! Even the stupidest person in the world would be hard-pressed to invent an interface that required two calls per letter to the screen, I would have expected one. Anybody with the remotests experience with Unix or CP/M would have made a call that drew many characters at once, and interpreted some VT52 escape sequences. The end result is that every program memory-mapped the video, locking down the arrangement and design forever until new processors could actually trap the writes in order to redirect them.
MicroSoft's biggest mistakes was not putting anything into the.exe files to say how far apart the segments were, thus killing the usefulness of the 80286 which could have addressed 24 bits if all the programs did not have to assumme they were in 20 bit mode. But IBM also used interrupts that the 80286 had reserved for floating point emulation for the "bios" and also killed it. We would have had better machines five or more years earlier if it was not for this.
MicroSoft's other mistake was firing or burying the smart people who made MSDOS 2.0, where they tried to add Unix emulation. I believe there would be not Linux and MicroSoft would rule everything if they had just tried to be a little more Unix like so that all the engineers did not hate them.
The removable drive in the NeXT was not a CD-ROM, it was a read/write optical drive. Actually pretty good, all other machines just had floppies or zip drives at that time.
Where NeXT botched it in the drive department was not providing a hard disk by default. The machine was useless without one, the optical drive as the main storage was orders of magnitude too slow. And you could not remove it because it was a normal Unix and many configuration files were stored on it. Swapping with another disk worked like the Mac where it continuously froze the machine and popped up a "insert this disk" indicator.
Also you could get a floppy drive, at least my machine had one, but it may have been an option (I also had a hard drive). It read/wrote MSDOS format disks.
Of course that is not the only NeXT mistake, but I think the lack of a hard drive was much more important than the removable media choices.
The point is that the RIAA can and will make all *recording* devices illegal. The will probably be done by introducing a new format, using the SSSCA to make manufacturing devices using old formats like CD and DVD illegal, and desigining the new format so it is impossible to record without a technique requiring mechanical pressing or otherwise massive scale manufacturing. Yes old formats will be with us, but for the majority of users there will be no workable method to get them into speakers and out as sound.
This is the only method that will really "stop" piracy. As long as recording devices are legal, a "pirate" can work on stripping enough of the copy controls that the recording device is fooled into thinking the sound is a new live recording. But if there is no device that will record any sound and turn it into a form that the average user can play, it will completely control copies!
Well, it will stop the average user from being a "pirate". Piracy for money will always be worth enough that somebody will break into a factory, steal one of the machines, and pirate millions of copies. In fact piracy will become more lucrative and profitable and will probably be greater than before because the real disks will have their prices inflated to the maximum the market will bear.
It also has the side effect that you *cannot* record music without a recording industry contract! This is of course the real purpose of this, but they are going to scream "pirate" for years until everybody has been brainwashed to go along with this.
Try those names under fopen() or open() and you will see that they don't work.
Stop posting the fact that they "do it" when it is not true. Unless the actual calls that the vast majority of programs use actually work with these names and links, they are NOT implemented.
Another simple example is turning a 1-byte grayscale image into a 4-byte "color" image as needed by some hardware by multiplying each input byte by 0x1010101. I have measured this and it definately is faster than storing the 4 characters one after another into the output buffer.
Re:Wacky conspiracy theories
on
BeOS For Linux
·
· Score: 2
Without MicroSoft's tactics, there certainly would have been machines at BestBuy that dual-booted. They could put in the adds "includes BeOS, a $150 value, free!". In practicality most people would immedately reformat that partition as another Windows disk (in fact the company making the machine would do well to make this easy), but a *few* people would have tried BeOS.
At that time the video was MUCH better than Windows (probably still is) and I'm sure some games would have come out with BeOS versions (on the same disk as the Windows copy) and people could immediately see the better performance. That would have opened the gates to people using BeOS more and more, and applications being written for it.
BeOS may very well have failed and been wiped from the disk by every user too, but at least it could have tried!
But MicroSoft stopped this from ever happening. This is a fact and trying to pretend otherwise because "everybody here hates MicroSoft" is not going to change it.
They don't have to make drive letters not work. All they have to do is make it so a drive letter is not required to name a file on the system.
This can easily be done by making a file system with mount points (and some non-Unix easy way to control it, such as having all devices that exist automatically create the mount points called / and mount themselves unless configured otherwise).
They can continue to have ":" be a reserved character and recognize any attempt to open : and remap that to//. This will retain back compatability. Also reserving the colon will allow service names much like the KDE file naming convention, though I think in the future service names will disappear just like drive letters as there is no need for the end user to know them.
But in fact back-compatability is easily maintained. I believe the reason MicroSoft does not fix this (and does not provide real symbolic links that can be used with their libc without a program having to understand them) is because that would allow easy Unix compatability by rearranging the MSDOS filesystem to look like a Unix one.
I have switched to Konqueror as well and am very happy with it.
I don't know what Galeon does but the cookie management in Konq seems great and does not require use of menus. When a site sends a cookie it pops up a request and you can choose to accept, reject, or ignore the cookie, and you can select to do that for all cookies ever sent again from that site.
It would be nice if the java/javascript did the same thing. The first time any java/javascript is sent you are popped up a box and asked yes/no and remember whether to do it that way from now on from that site.
Also for hackers it would be nice if they displayed a glob name of "what sources to reject" that defaulted to site/* but an advanced user could edit to make a more careful selection of what pages to do that cookie preference on.
You seem to be confused. Microsoft is not selling things that make WMP work on Linux. The "bits and pieces" needed from MicroSoft are exactly the same pieces you need to make WMP work on Windows. They cost no more or less.
The cost is $20 for CrossOver plugin. Also if you paid attention CrossOver is neither "free" or "open source" so whatever argument you are trying to hammer together is not even attacking your intended target.
You are right, I meant ctrl+c everywhere I said ctrl+x.
The Alt/Ctrl stuff can be entirely blamed on MicroSoft. When Motif and CDE was being designed windows used the ctrl+insert and other keys as the "standard" for cut & paste. Though windows still supports that, ask any user and you will see just how popular that is! But Motif and CDE copied that, and also "copied" the other popular interface, which was the Macintosh, which used Apple+X, Apple+V, etc.
Take a look at a contemporary Mac and PC keyboard and you will see it is obvious why the Alt key was chosen. In fact virtually every program written for MSDOS and Windows then used Alt+letter as shortcuts.
For unknown reasons MicroSoft decided in their own programs (once they decided the shift-ins stuff was not user friendly) to use ctrl+letter. Plausible reasons were to avoid interfering with foreign letter input that used Alt, to avoid interfering with the existing MSDOS programs using Alt as a shortcut, or with Windows (also useless) use of Alt to navigate to the menubar, or possibly an evil attempt to make life painful for programmers used to Emacs and to make going between a Mac and a PC difficult. In any case for at least a few years Windows was as much a mess as Unix.
It looks like all new Unix programs have decided to copy Windows, so only older Motif stuff like Netscape use alt. I personally try to make both work, that avoids problems with all users.
Unfortunately having seen OS/X I'm not sure if things are solved. OS/X apps already appear to assumme that Ctrl+x and Apple+x can be different shortcuts (try the ctrl keys, it works like Emacs in their text editor) and that Apple+x is used more often. This is going to be a pain for anybody trying to port between OS/X and Windows and having a consistent interface. Linux, with ports in both directions, may end up just as messy as before.
However I do put all the blame on MicroSoft for choosing ctrl as the menu binding rather than Alt.
No, they are probably complaining about the simple inability to cut & paste text.
It is true that selection and middle-mouse click will work between all X applications.
However Windows users are used to ctrl+x and ctrl+v. Most X apps initially supported this by simply making ctrl+x do nothing (because the text was already selected) and making ctrl+v do the same as middle-mouse click. This is how current KDE applications work.
This worked pretty good, but it turns out most Windows users were also used to selecting the text they wanted to replace and then typing ctrl+v to replace it. This unfortunately changed the clipboard and the paste did not work. They do have a point that this is confusing to anybody coming from Windows.
There are several kludges an app could do to detect this and do what the user expects, but it appears the solution adopted, first by Motif programs like Mozilla and then by GTK and several other toolkits, was to have 2 clipboards, one for the selection and another for the most recent ctrl+x. In many ways this is an ideal solution, as in fact the middle mouse is really equivalent to drag & drop and is best combined with that mechanism, not the clipboard.
The problem now is that KDE apps (and quite a few others, I'm sure) do not understand this. Typing ctrl+v still pastes the selection. Since this is usually the same as the clipboard except for the "select and replace" Windows reflex it probably isn't any worse than before. However the opposite way is a pain, as ctrl+x in KDE does nothing and ctrl+v in a newer program then pastes and older ctrl+x, which I am sure drives the user nuts.
Yes the next version of KDE will fix this.
PS: the newest versions of FLTK match GTK as well, it had the same problem as KDE.
I don't think we want any kind of "widgets" in X. If X had been designed this way we would all be using the Athena widget set that was in existence when X first appeared, and the X interface would have been laughably primitive, and all kinds of weird behavior that was considered a good idea in 1983 (like how the scrollbars worked) would be still with us.
The fact that X is able to emulate GUI designs made FIFTEEN YEARS after X itself was designed is a good indication that not putting the GUI in the server is an excellent idea.
Where X falls down is that it cannot do any kind of advanced graphics without huge, complex overlaying code libraries that force people to be locked into certain toolkits. Drawing an image that is already in memory should be a trivial operation but requires perhaps 300 lines of code if you are not using shared memory, perhaps 1000 if you want the maximum speed. Any reasonable interface would need 1 line of code. Formatting a UTF-8 string into a box correctly would require more code on top of Xlib than the size of most applications, when again it should be 1 line. And every solution I see seems to be tied into a "toolkit" or "com"-like library and thus unlikely to be used by anybody that does not want all the other bloat of that toolkit or library, and I am beginning to despair that nobody will address this properly.
They are used extensively in film graphics. All other major renderers, not just RenderMan, have shader languages. Ie vMantra, Maya, LightWave, etc.
Shaders do not "replace" texture maps. One of the most-used functions in a shader is to look up a given uv coordinate in a texture map and use the resulting color to control the shader. In fact most of the shaders we write involve manipulating texture maps, which were (as you said) painted by hand. We can do much more interesting things with textures other than just using them to color the surface!
I agree about the pack/unpack mess. I think all useful image formats could be described by these items: number of bits per sample (limited to powers of 2), number of samples per pixel, delta between each pixel (so they can be further apart than the number of samples or you can trivially mirror it with negative numbers), delta between each line (allows a "window" to be cut out of a larger image, allows flipping upside-down, and allows 90 degree rotations by adjusting both deltas). There is no need to describe what the samples are, that can be determined from the count and what function you are calling, we can insist on RGBA order for normal images.
I agree that this is what is necessary. It should also incorporate text drawing and fonts and 2-D image drawing and various other things used by GUI toolkits, so that we don't have to go through the pain of having to make totally seperate windows and use totally seperate code for different parts of the application.
I don't see much signs of this happening, however. Huge amounts of drawing code have been built into toolkits (like Qt and KDE and the Gnome libs and on Windows into MFC and various DLLs) that should really be in the graphics interface, and the people who know how they work are not willing to cooporate together and move all this work to a more sensible place.
Fortunately, if this problem exists, it is entirely under control of the window managers, which both pick the font to use and also draw the window edges. That is, this is not a built-in problem with X.
Seems to work ok in KDE with it's default settings. Likely a lot of the problem is pixmapped themes that cannot scale. It looks like WindowsXP avoids this by not allowing pixmapping of the borders of the titlebar, only of the buttons (which end up centered if the bar grows).
Unfortunately such a menubar does not work when you have point-to-type focus. Point-to-type is also a vast improvement in efficiency (so much so that I have NEVER seen anybody who uses it go back, even on Windows machines where you can turn it on with a registry setting).
Possibly moving the focused windows up to the top edge so that they are joined onto the menubar, or some kind of hysteresis so that if you drag fast enough across the gap the focus does not change, or some idea nobody has thought of, would solve this. But until somebody does this I doubt you will see much interest in top-of-screen menubars from either the Linux or Windows advanced programmers.
You seem to be confused. The Win32 api that Qt uses is approximately equivalent to the Xlib api that it uses on Linux.
Though the Win32 api provides a "scrollbar" and some other widgets, Qt does not use them. Nor does any high-level toolkit on any system other than MFC.
If you ever tried to implement a toolkit you will quickly discover that it is vastly easier to write a widget from scratch than to try to adapt your interface to an existing interface. It is also vital if you are interested in cross-platform compatability to do this.
The "registry-like" solution would be *many* *tiny* files. This would use the file system as the registry and you could still fix things with vi.
The main reason this is not done (by MicroSoft either) is the awful performance of the typical file system that assummes files are several K in size on average.
There are some new file systems that address this. Also a "special" file system like/proc could solve the problem.
Slashdot Mirror
The call that drew a string of characters did not exist in the original BIOS. I think also it did not allow you to set the color of the characters in any useful way and was thus useless. The original MSDOS did not provide an interface to draw a string of text so nothing used this call and many clone Bios's had it broken.
MSDOS did add "ansi.sys" that made escape sequences usable from MSDOS 2.0. However it was implemented atop the BIOS and was unbelievably slow. There were several open-source replacements for ansi.sys that wrote directly to the hardware and actually made regular MSDOS command prompt much faster, but because they were not part of default installation (neither was ansi.sys) nobody used these. Ansi.sys also had the problem that it could reprogram the function keys and actually forced the few programs still using MSDOS for input to give up and use the BIOS or the hardware.
If I remember right the keyboard interface could report the state of the shift keys, the problem was that certain key combinations produced nothing, ie you could not tell if they had been typed by using the BIOS. Also the AT keyboard showed further BIOS stupidity: apparently somebody at IBM panicked and thought some software would crash if presented with codes from the keyboard it had not seen before, so they added a new call that you had to use if you wanted to see F11, F12, or any of the new arrow keys. And of course MSDOS was not changed to use this new call.
All pretty horrible, actually. And we still live with it now. Ever wonder why there are arrows printed on your numeric keys? And what is "scroll lock" or "sys req"...
MSDOS itself has no 640K limit. If it was written to "accomodate hardware limitations" it probably would.
I still believe that it is IBM that screwed up and Gates probably wanted the hardware higher. The "640K" was probably said when he really means "1Meg" because the average person thought 640K was the physical limit.
Actually MSDOS did pretty good fooling the FCB's into having an in-dos portion so disk access was faster. And they did very good with the rewrite for MSDOS 2.0 where they replaced the FCB's with Unix-style read/write/seek. Unfortunately everything since MSDOS 2.0 has sucked pretty bad.
So adding seqment 0FFFF and offset 0FFFF resulted in FFFEF.
Bill Gates wrote BASIC, not "DOS". At that time the equivalent of DOS was CP/M. MicroSoft purchased the beginnings of MSDOS from another company that it later sued out of business, and that was a copy of CP/M. Claiming Bill Gates had anything to do with the creation of any early version of DOS is just so totally wrong it both demeans you and him.
If it was not for Bill Gates what would we have on the PC? Well I expect we would have some other monopoly selling some other PC operating system. Maybe even IBM. And Bill Gates would be here on SlashDot complaining about the evil monopolist who is running that company and rooting for the government's anti-trust suit. Don't think that Bill Gates did anything other than be in the right place at the right time, what happened would have happened exactly the same without him!
And there would be a GUI just as sophisticated as Windows, and Office software just the same (maybe better if the monopoly had held off some more, maybe worse if the monopoly had been claimed earlier, perhaps by Lotus). And lots of programmers would have started in whatever was on this monopoly system and does that make it good?
Unbelivable that you think that without MicroSoft there would be no alternative. The problem is that with MicroSoft there is no alternative, and people like you are so brainwashed you cannot picture that MicroSoft killed it's competition and that that competition was entirely capable of doing what MicroSoft did!
I won't go into the "windows drove Mac development forward" comment. You obviously have a very warped version of history. Try reading, even Gate's book is more accurate!
Much worse than th 1Meg barrier was the fact that IBM stuck the video memory right about in the middle, leaving 640K below, and perhaps 200K above. This was unbelievabley stupid. They could have at least mapped it at one end. Better yet a switch to turn the mapping on/off, which would also have prevented the huge number of direct-mapping programs that frozer hardware design for years.
The high memory managers were written by Lotus, I think. They were pretty awful and relied on copying small blocks from higher addresses by changing the segment overlap and writing them into the "hole" above the video memory and below 1Meg.
With the current technology there was NO reason for a 640K barrier. The chip could address 1 megabyte. Anybody with some sense would have put the memory-mapped video up at the top end of the memory, or at the bottom. For the 25x80x2 byte memory this would leave a block of size 1020K. They could have placed the color and b&w memory maps in the same place as well as real users (but not the enginners at IBM testing the machines, alas) did not use both cards!
The writers of the "bios" completely killed all advances in display technology until Windows came out by their stupid design. They probably asked MicroSoft what basic needed to draw on the screen and MicroSoft said "we need to move the cursor, and draw letters at the cursor" and those idiots at IBM dutifuly made a call that moved the cursor and another call that placed a letter at the cursor and did not move it!!! Even the stupidest person in the world would be hard-pressed to invent an interface that required two calls per letter to the screen, I would have expected one. Anybody with the remotests experience with Unix or CP/M would have made a call that drew many characters at once, and interpreted some VT52 escape sequences. The end result is that every program memory-mapped the video, locking down the arrangement and design forever until new processors could actually trap the writes in order to redirect them.
MicroSoft's biggest mistakes was not putting anything into the .exe files to say how far apart the segments were, thus killing the usefulness of the 80286 which could have addressed 24 bits if all the programs did not have to assumme they were in 20 bit mode. But IBM also used interrupts that the 80286 had reserved for floating point emulation for the "bios" and also killed it. We would have had better machines five or more years earlier if it was not for this.
MicroSoft's other mistake was firing or burying the smart people who made MSDOS 2.0, where they tried to add Unix emulation. I believe there would be not Linux and MicroSoft would rule everything if they had just tried to be a little more Unix like so that all the engineers did not hate them.
Where NeXT botched it in the drive department was not providing a hard disk by default. The machine was useless without one, the optical drive as the main storage was orders of magnitude too slow. And you could not remove it because it was a normal Unix and many configuration files were stored on it. Swapping with another disk worked like the Mac where it continuously froze the machine and popped up a "insert this disk" indicator.
Also you could get a floppy drive, at least my machine had one, but it may have been an option (I also had a hard drive). It read/wrote MSDOS format disks.
Of course that is not the only NeXT mistake, but I think the lack of a hard drive was much more important than the removable media choices.
This is the only method that will really "stop" piracy. As long as recording devices are legal, a "pirate" can work on stripping enough of the copy controls that the recording device is fooled into thinking the sound is a new live recording. But if there is no device that will record any sound and turn it into a form that the average user can play, it will completely control copies!
Well, it will stop the average user from being a "pirate". Piracy for money will always be worth enough that somebody will break into a factory, steal one of the machines, and pirate millions of copies. In fact piracy will become more lucrative and profitable and will probably be greater than before because the real disks will have their prices inflated to the maximum the market will bear.
It also has the side effect that you *cannot* record music without a recording industry contract! This is of course the real purpose of this, but they are going to scream "pirate" for years until everybody has been brainwashed to go along with this.
Stop posting the fact that they "do it" when it is not true. Unless the actual calls that the vast majority of programs use actually work with these names and links, they are NOT implemented.
Another simple example is turning a 1-byte grayscale image into a 4-byte "color" image as needed by some hardware by multiplying each input byte by 0x1010101. I have measured this and it definately is faster than storing the 4 characters one after another into the output buffer.
At that time the video was MUCH better than Windows (probably still is) and I'm sure some games would have come out with BeOS versions (on the same disk as the Windows copy) and people could immediately see the better performance. That would have opened the gates to people using BeOS more and more, and applications being written for it.
BeOS may very well have failed and been wiped from the disk by every user too, but at least it could have tried!
But MicroSoft stopped this from ever happening. This is a fact and trying to pretend otherwise because "everybody here hates MicroSoft" is not going to change it.
Devices would create a mount point called /<device> and <letter>: would be turned into /<device>/<current dir for disk>
This can easily be done by making a file system with mount points (and some non-Unix easy way to control it, such as having all devices that exist automatically create the mount points called / and mount themselves unless configured otherwise).
They can continue to have ":" be a reserved character and recognize any attempt to open : and remap that to //. This will retain back compatability. Also reserving the colon will allow service names much like the KDE file naming convention, though I think in the future service names will disappear just like drive letters as there is no need for the end user to know them.
But in fact back-compatability is easily maintained. I believe the reason MicroSoft does not fix this (and does not provide real symbolic links that can be used with their libc without a program having to understand them) is because that would allow easy Unix compatability by rearranging the MSDOS filesystem to look like a Unix one.
I don't know what Galeon does but the cookie management in Konq seems great and does not require use of menus. When a site sends a cookie it pops up a request and you can choose to accept, reject, or ignore the cookie, and you can select to do that for all cookies ever sent again from that site.
It would be nice if the java/javascript did the same thing. The first time any java/javascript is sent you are popped up a box and asked yes/no and remember whether to do it that way from now on from that site.
Also for hackers it would be nice if they displayed a glob name of "what sources to reject" that defaulted to site/* but an advanced user could edit to make a more careful selection of what pages to do that cookie preference on.
The cost is $20 for CrossOver plugin. Also if you paid attention CrossOver is neither "free" or "open source" so whatever argument you are trying to hammer together is not even attacking your intended target.
The Alt/Ctrl stuff can be entirely blamed on MicroSoft. When Motif and CDE was being designed windows used the ctrl+insert and other keys as the "standard" for cut & paste. Though windows still supports that, ask any user and you will see just how popular that is! But Motif and CDE copied that, and also "copied" the other popular interface, which was the Macintosh, which used Apple+X, Apple+V, etc.
Take a look at a contemporary Mac and PC keyboard and you will see it is obvious why the Alt key was chosen. In fact virtually every program written for MSDOS and Windows then used Alt+letter as shortcuts.
For unknown reasons MicroSoft decided in their own programs (once they decided the shift-ins stuff was not user friendly) to use ctrl+letter. Plausible reasons were to avoid interfering with foreign letter input that used Alt, to avoid interfering with the existing MSDOS programs using Alt as a shortcut, or with Windows (also useless) use of Alt to navigate to the menubar, or possibly an evil attempt to make life painful for programmers used to Emacs and to make going between a Mac and a PC difficult. In any case for at least a few years Windows was as much a mess as Unix.
It looks like all new Unix programs have decided to copy Windows, so only older Motif stuff like Netscape use alt. I personally try to make both work, that avoids problems with all users.
Unfortunately having seen OS/X I'm not sure if things are solved. OS/X apps already appear to assumme that Ctrl+x and Apple+x can be different shortcuts (try the ctrl keys, it works like Emacs in their text editor) and that Apple+x is used more often. This is going to be a pain for anybody trying to port between OS/X and Windows and having a consistent interface. Linux, with ports in both directions, may end up just as messy as before.
However I do put all the blame on MicroSoft for choosing ctrl as the menu binding rather than Alt.
It is true that selection and middle-mouse click will work between all X applications.
However Windows users are used to ctrl+x and ctrl+v. Most X apps initially supported this by simply making ctrl+x do nothing (because the text was already selected) and making ctrl+v do the same as middle-mouse click. This is how current KDE applications work.
This worked pretty good, but it turns out most Windows users were also used to selecting the text they wanted to replace and then typing ctrl+v to replace it. This unfortunately changed the clipboard and the paste did not work. They do have a point that this is confusing to anybody coming from Windows.
There are several kludges an app could do to detect this and do what the user expects, but it appears the solution adopted, first by Motif programs like Mozilla and then by GTK and several other toolkits, was to have 2 clipboards, one for the selection and another for the most recent ctrl+x. In many ways this is an ideal solution, as in fact the middle mouse is really equivalent to drag & drop and is best combined with that mechanism, not the clipboard.
The problem now is that KDE apps (and quite a few others, I'm sure) do not understand this. Typing ctrl+v still pastes the selection. Since this is usually the same as the clipboard except for the "select and replace" Windows reflex it probably isn't any worse than before. However the opposite way is a pain, as ctrl+x in KDE does nothing and ctrl+v in a newer program then pastes and older ctrl+x, which I am sure drives the user nuts.
Yes the next version of KDE will fix this.
PS: the newest versions of FLTK match GTK as well, it had the same problem as KDE.
The fact that X is able to emulate GUI designs made FIFTEEN YEARS after X itself was designed is a good indication that not putting the GUI in the server is an excellent idea.
Where X falls down is that it cannot do any kind of advanced graphics without huge, complex overlaying code libraries that force people to be locked into certain toolkits. Drawing an image that is already in memory should be a trivial operation but requires perhaps 300 lines of code if you are not using shared memory, perhaps 1000 if you want the maximum speed. Any reasonable interface would need 1 line of code. Formatting a UTF-8 string into a box correctly would require more code on top of Xlib than the size of most applications, when again it should be 1 line. And every solution I see seems to be tied into a "toolkit" or "com"-like library and thus unlikely to be used by anybody that does not want all the other bloat of that toolkit or library, and I am beginning to despair that nobody will address this properly.
They are used extensively in film graphics. All other major renderers, not just RenderMan, have shader languages. Ie vMantra, Maya, LightWave, etc.
Shaders do not "replace" texture maps. One of the most-used functions in a shader is to look up a given uv coordinate in a texture map and use the resulting color to control the shader. In fact most of the shaders we write involve manipulating texture maps, which were (as you said) painted by hand. We can do much more interesting things with textures other than just using them to color the surface!
I agree about the pack/unpack mess. I think all useful image formats could be described by these items: number of bits per sample (limited to powers of 2), number of samples per pixel, delta between each pixel (so they can be further apart than the number of samples or you can trivially mirror it with negative numbers), delta between each line (allows a "window" to be cut out of a larger image, allows flipping upside-down, and allows 90 degree rotations by adjusting both deltas). There is no need to describe what the samples are, that can be determined from the count and what function you are calling, we can insist on RGBA order for normal images.
I don't see much signs of this happening, however. Huge amounts of drawing code have been built into toolkits (like Qt and KDE and the Gnome libs and on Windows into MFC and various DLLs) that should really be in the graphics interface, and the people who know how they work are not willing to cooporate together and move all this work to a more sensible place.
Seems to work ok in KDE with it's default settings. Likely a lot of the problem is pixmapped themes that cannot scale. It looks like WindowsXP avoids this by not allowing pixmapping of the borders of the titlebar, only of the buttons (which end up centered if the bar grows).
Possibly moving the focused windows up to the top edge so that they are joined onto the menubar, or some kind of hysteresis so that if you drag fast enough across the gap the focus does not change, or some idea nobody has thought of, would solve this. But until somebody does this I doubt you will see much interest in top-of-screen menubars from either the Linux or Windows advanced programmers.
Though the Win32 api provides a "scrollbar" and some other widgets, Qt does not use them. Nor does any high-level toolkit on any system other than MFC.
If you ever tried to implement a toolkit you will quickly discover that it is vastly easier to write a widget from scratch than to try to adapt your interface to an existing interface. It is also vital if you are interested in cross-platform compatability to do this.
The main reason this is not done (by MicroSoft either) is the awful performance of the typical file system that assummes files are several K in size on average.
There are some new file systems that address this. Also a "special" file system like /proc could solve the problem.