Re:But does it have a useable file-save dialogue?
on
GNOME 2.16 Released
·
· Score: 1
Unfortunatly the marching morons from Windows INSIST that the directories must be first. Putting them in alphabetical order with the rest of the files is "not user friendly". This is in the modern world where "whatever Windows does" is equivalent to "user friendly".
If it were not for that ordering problem, it would be possible to stat in the background after displaying the list.
Making all text (such as labels) be selectable and copyable would be a good idea, but I'm worried that it would conflict too much with what people are used to from Windows. Clicking on any label would move the focus and current selection to that label, which is annoying if you are used to clicking there to raise windows. I did some experiments earlier with making "output text" and I thought I could require the user to drag to select text and that clicking would do nothing and it would not take the focus, but it appears to not work, without the feedback on button press showing the insertion bar nobody could figure out what is happening, and they could not use shift+arrows to adjust the selection. So a simple click would have to move the insertion bar (and thus the focus) to the label. Also I don't see any easy way to allow you to select the text in a menu item or button or anything else that you would normally click on.
I agree with some of your other things. It is absolutely insane that a Unix based system does not have a trivial command-line method of "do what double-click in the file browser does". If this was added, a program could make clicking on files it is displaying do the correct operation. But instead it requires linking in an enormous library and database. Comon, make a program, call it "open" or "start" or whatever, and that should *be* the what happens when you double-click a file. In fact users could change this program and change what the file browser does.
While you are at it, try to follow the Unix conventions, and make programs to bring up file choosers and error messages and so on. I don't want to link in GTK if I just want to ask the user a yes/no question. And this would provide a powerful and easy way to customize the system. If file choosers were programs you exec'ed, I think Linux would change from having the worst file choosers to having the best ones in about 3 months.
I don't know what you mean by the "right mouse button on the keyboard", like the others here. I'm guessing you mean something on laptops? If that button is not acting like the right mouse button, there is something wrong with X.
Actually I think the current electorial system is even worse for groups in large states. A far larger number of people than the population of Montana, such as the set of Republicans in California, is effectively disenfranchised (because all the electorial votes will go Democrat even if only 51% of the state wants the Democrat president).
The problem with your argument is that your counter-example of the derived works requirement is invalid.
Microsoft explicitly gives permission for you to install and run other software on the Windows system. This exception is actually worded explicitly into the copyright given to OEM's who copy the system. In fact part of the anti-trust argument is that Microsoft was failing to give sufficient freedom in what extra software was added to Windows by OEM's.
True there probably is no such wording in anything given to home users, but they own the system and can do anything they want to it, whether Microsoft wants them to or not. And they cannot distribute the result because they would be violating the copyright on Windows itself, so it is quite irrelevant if their redistribution includes some added code of their own.
If YOU own the copyright to the code, it does not matter if you previously released it under the GPL. It is your code and you can release it again any way you want. Many people do dual licensing, or discontinue supporting their GPL version. There is nothing wrong with that.
It seems to me that OCR would fix this pretty easily. People worry about the fact that OCR cannot understand the captchas, but that hardly is necessary. All an OCR spam-recognizer has to do is determine that there *is* text in the image, it does not have to read it. Images consisting of a lot of text are definately an indicator of spam.
Other resonders have gone into detail about the actual facts, but the general and safe consensus is that you cannot distribute your program if it is linked with a GPL library unless you distribute your source code as well, with the GPL license.
Because of this, virtually every useful library is available under the LGPL or a similar license, because the authors know that their code will not be used otherwise. Even somebody who intends to write a GPL program may balk because they want the ability to change their own license in the future.
The idea that there could be a non-GPL "alternative implementation" of a GPL library I think mean you can do anything with your source code. Not sure what would be the law, but I highly suspect the following rules would apply:
1. The "alternative implementation" must actually exist, and be available to the users of your program (though it might not be free).
2. If your program is statically linked it must be linked with the alternative implementation, not the GPL one.
3. If your program is dynamically linked, there must be a pretty convincing argument that you tested and indend it to work with the alternative implementation, for instance it can't have any code that says "if (gpl_version) do_function_missing from_alternative()".
IE is not designed to *exclusively* communicate with a particular GPL Web Server. That's a really obvious difference that makes your example bogus.
Although it certainly is not clear what is "linking" there are some obvious limits:
1. From the GPL, if it is one file on disk, it definately *is* "linked".
2. Conversely, if the two pieces are both useful on their own, and their halves of the communication mechanism are useful on their own, they are definately *is not* "linked". Your IE/WebServer example falls into this catagory.
Everything inbetween is a gray area, with all kinds of shades of gray. But the above two are the definate extremes beyond which it is silly to ask questions about.
I think that was Arther C Clarke. It was a rather funny short story. Basically all food was manufactured, and everybody forgot what it was a copy of. The board of directors of the food company that is rapidly loosing sales to this new food that everybody likes has to be explained by a scientist from their labs the meaning of the word "carnivore". After this long explaination which also revealed the history of the manufactured foods, the scientist says they have completed their examination of the competitors food, and says "now I need to define a new word. That word is 'cannibal'".
You might investigate what the word "joke" means. I think even Microsoft gets them. Not sure how you manage in life without understanding the concept.
If you have not figured it out, this is all very good for Microsoft. I think they should be very happy with the high level of jokes here. If Microsoft truly turned around and stopped acting hostile to everybody else in the world, the number of jokes would probably skyrocket, they may even make them themselves.
I assumme you are talking about pollution from the spaceships necessary to do this. The actual transfer of matter from the moon to the earth in the quantities that we could do even if we put 100% of all human's efforts into doing it is unlikely to effect things one bit.
My guess is that if some highly unlikely situation makes it profitable for independent prospectors to build their own ships and go to the moon to mine it, and there is a gold rush of some sort of these, then we should worry. Until then, however, it would be better to fix our billions of air conditioners and do other less glamorous things.
What the hell are you talking about? I have NEVER seen a media player on Linux that did not allow the window to be resized! In fact, I have had the opposite problem, it is far too *easy* to resize the window, and it is often obscure or impossible to restore it to the correct non-scaled (ie no filtering and/or distortion) size.
This is really hard to explain. What I want (and the original poster wants) is for that to NOT be a numeric keypad, we want to use it as additional function keys (in my case I use the arrows as "nudge" arrows to move graphics by less than one pixel). This sounds like what you want as well.
Due to the need to be back compatable with existing programs, the unintuitive result is that the best way to do this is to force NumLock to be ON at all times. Any other solution either makes it difficult for a program to identify the numeric keys (requiring a new api that is not supported by existing toolkits), or would make old programs act like NumLock is on anyway.
Therefore, for the exact reason you, I, and the original poster wants, we need NumLock ON. It may seem that this is "further away" from it being function keys, but in fact it is better, for complex reasons.
I also want programs to use the numeric keypad "arrows" for something else, and this means I want NumLock "on" at all times, the opposite of what you state. It is literally impossible to make the numeric keypad arrows have special functions without breaking every existing piece of software unless you act like NumLock is on. I will try to explain this counter-intunitive result:
The keyboard api (in both Windows and Linux) returns two pieces of information, the "key" and the "text". All function keys such as arrows have blank text. Currently if NumLock is off, the numeric keypad returns the exact same symbols and blank text as the normal arrows.
Let's write a "simple" text editor for a program that is unconcerned about NumLock and the keypad and just wants to work as the user expects:
handle_key() {
if (key_text() != 0) {
insert(key_text());
} else {// it's a function key!
switch (key()) {
case UP: move_cursor_up(); break;
case DOWN: move_cursor_down(); break;...
}
}
}
Now what should the numeric keypad keys return if we want it to act like NumLock is off?
1. The arrow symbols and blank text (what Windows does now if NumLock is off). This fails as it is impossible to distinguish them from the normal arrows, so the desired function of making the numeric arrows do something different is impossible.
2. Special "different" arrow symbols and blank text (for some keys this is what Windows does if you assumme the "alt" bit is part of they key number). This fails as the above program will not see the arrow keys. Even if you modify the simple program, you will fail if a second keypad is added.
3. Arrow symbols plus text (ie "4" for the left-arrow+4). This fails the above in that the code will insert the text, acting like NumLock is on when it is supposed to act like it is off. Also fails to distinguish more than one keypad.
How about if we act like NumLock is on?
1. Special "different" number key symbols and the correct text. This works. The simple code above will insert the text, yet it is easy for a program to distinguish the keys if it wants to treat the keypad as differnt types of arrows. Adding another keypad can define more symbols, that will not break the simple program, and won't break the "complex" program (it will probably think the second keypad are normal numerics).
For this reason my software (fltk) always acts as though NumLock is on by changing the key events (Linux version changes the arguments to XLookupKeysym, the Windows verison uses the alt bit of the event to detect keypad and converts the arrows back into numbers, and some nasty other tests for those keys where the alt bit does not work)
I hope that was clear. The "intuitive" result is not always right. We definately should get rid of NumLock and act like it is ON at all times!
That does not quite explain it. For both Apple and Microsoft, a "new computer" already includes the operating system, so sales of this is irreleveant to sales of new computers.
Can't think of any real explanation. One is that Microsoft just never thought of it. Or that the bean counters thought that the availability of a "family pack" would reduce sales (like you, I suspect it would actually raise revenue, by a tiny insignificant amount...). Or that Microsoft relies on corporate customers that would only buy 1/5 as many copies and assummes all home users will pirate (though wouldn't a "for home use only" stop those same corporate customers?). If you want the Microsoft-is-evil explanation, perhaps Microsoft knows that everybody will be forced to upgrade, while Apple knows that people can keep using the old system and interoperate just as much as before. Or the pro-Microsoft version of this, which is that Apple users don't need to upgrade because there is no commercial software for it anyway.
You are however allowed to make your own license that says "this code is covered as per the terms of the GPL (see below) with the following additional restrictions and following additional exception" and then list any number of modifications (either additional restrictions like "no military use" or exceptions to copyright such as "you can link this code without giving away the source", following by an attachement of the unmodified GPL. This is done all the time.
Heck, even the much-touted OpenGL example World of Warcraft actually makes heavy use of DirectX under Windows. Just not for graphics.
Obviously seperating sound and joystick input from the graphics output is no big deal.
Even a program that does not use any api called "DirectX" is probably using the FAT file system or NTFS when it's files are written to disk. If Microsoft had named this DirectX-file then that program would be using DirectX! Amazing!
As others said, there very likely is another allocated piece of memory right there, so you will just overwrite that, and not get an error.
Even if those memory locations are not allocated, memory protection is not per byte, but per page, so you won't get an error. Also many memory allocators will put information (such as how much memory is free and available here and where is the next free block) into the "unallocated" memory, so writing over it will cause the memory allocator to crash.
Actually every commercial program that displayed anything other than stdout wrote directly to the hardware. This was due to the insanely bad design of the "bios".
How bad? How many calls do you think are needed to draw a letter on the screen?
Anybody with any brains would probably choose something on the order of 1/80, ie draw up to 80 characters (the length of a line) at once, with a call that says "at this x,y, draw these n bytes").
Now CPM and MSDOS were not done by smart people, so they already forced the api to be one character at a time. So you might think they ignored the real way to do this, and provided a BIOS call that drew one letter, so the MSDOS call could go straight to it.
But NO, they instead managed to figure out how to require two (count em!) calls to draw a letter. There was a call to draw a letter at the current cursor position but not move the cursor!. There was another call to move the cursor. Not only that, each of these calls was (as evidenced by the supplied BIOS listing) 40 or more assembler instructions long!
MSDOS's stdout "driver" literally did these two calls alternately for each byte they wanted to draw (plus it checked for backspace and return and line feed). This caused the "dir" type output to be hundreds of times slower than any even remotely intelligent design would do. Compare to any contemporary CP/M machine, even ones that drew on a remote terminal over a 9600 baud serial line, would reveal that MSDOS stdout was unreasonably slow for the hardware, and this was almost entirely due to the BIOS.
No programmer in their right mind would pass up the opportunity to get a 100-fold speed increase by writing directly to the memory. Besides it was actually much easier to program.
MSDOS did not help, as it's "driver" did not provide any escape sequences, so you *had* to use the BIOS or direct hardware to do anything other than teletype output. If there had been any escape sequences, I'm sure many people would have interrupted the MSDOS api and provided "turbo output" drivers that sped it up a hundered times, and enough programs would have used the escape sequences that it would have become a standard api. Adding an API that took many characters at once (as was added in MSDOS 2.0) and passed them through an escape sequence interpreter would have provided nearly the same speed as the direct hardware api. These escape sequences, which probably would have been in binary and very simple (one thing Microsoft does well), would have instantly become the standard for bulletin board dialup, and we would not have been stuck with the rather awful ANSI sequences that were designed by committee.
The direct hardware api really hurt development of the PC for a long time. When it first came out there was lots of additional hardware, such as a 100x80 character screen that we tested where I worked, bitmapped graphics terminals (with mice!) and schemes to use one PC to drive lots of terminals or over phone connections, and also attempts like TopView to provide a (character based) windowed and multitasking api, there were also many semi-clones with much better graphics capabilities such as mroe than 256 glyphs at once, bitmapped graphics, and smooth scrolling, all of these were killed by the fact that they required the programs to use some api that could be redirected. This was also responsible for the 640K limit, the 8088 had a natural limit of 1M, but 640K was where the video hardware was placed and it could not be moved out of the way. Not until Windows came out and gave programmers a good reason to use an api did graphics hardware actually start to advance.
No way. One of the primary design criteria was that it be easy to port CP/M programs (written in assembler) to the machine. The 8088 had to be chosen because of it's compatable instruction set to the 8080. This also fixed the design of MSDOS to match CP/M.
Yea, it's much better to use an abbreviation that means "Multiple Scolorsis" to anybody 30 or over, or that indicates that a woman does not want anybody to know if she is married from her name.
Face it, the abbreviation "M$" is immediatly readable and identifiable. "Microsoft" is too long and is probably the only other acceptable way of writing it.
Slashdot Mirror
Unfortunatly the marching morons from Windows INSIST that the directories must be first. Putting them in alphabetical order with the rest of the files is "not user friendly". This is in the modern world where "whatever Windows does" is equivalent to "user friendly".
If it were not for that ordering problem, it would be possible to stat in the background after displaying the list.
Making all text (such as labels) be selectable and copyable would be a good idea, but I'm worried that it would conflict too much with what people are used to from Windows. Clicking on any label would move the focus and current selection to that label, which is annoying if you are used to clicking there to raise windows. I did some experiments earlier with making "output text" and I thought I could require the user to drag to select text and that clicking would do nothing and it would not take the focus, but it appears to not work, without the feedback on button press showing the insertion bar nobody could figure out what is happening, and they could not use shift+arrows to adjust the selection. So a simple click would have to move the insertion bar (and thus the focus) to the label. Also I don't see any easy way to allow you to select the text in a menu item or button or anything else that you would normally click on.
I agree with some of your other things. It is absolutely insane that a Unix based system does not have a trivial command-line method of "do what double-click in the file browser does". If this was added, a program could make clicking on files it is displaying do the correct operation. But instead it requires linking in an enormous library and database. Comon, make a program, call it "open" or "start" or whatever, and that should *be* the what happens when you double-click a file. In fact users could change this program and change what the file browser does.
While you are at it, try to follow the Unix conventions, and make programs to bring up file choosers and error messages and so on. I don't want to link in GTK if I just want to ask the user a yes/no question. And this would provide a powerful and easy way to customize the system. If file choosers were programs you exec'ed, I think Linux would change from having the worst file choosers to having the best ones in about 3 months.
I don't know what you mean by the "right mouse button on the keyboard", like the others here. I'm guessing you mean something on laptops? If that button is not acting like the right mouse button, there is something wrong with X.
It sure was. And long before Microsoft "innovated" it, too!
Actually I think the current electorial system is even worse for groups in large states. A far larger number of people than the population of Montana, such as the set of Republicans in California, is effectively disenfranchised (because all the electorial votes will go Democrat even if only 51% of the state wants the Democrat president).
Yet every time it is proposed that registration be done at the DMV where documentation could be checked, Republicans shoot it down.
The problem with your argument is that your counter-example of the derived works requirement is invalid.
Microsoft explicitly gives permission for you to install and run other software on the Windows system. This exception is actually worded explicitly into the copyright given to OEM's who copy the system. In fact part of the anti-trust argument is that Microsoft was failing to give sufficient freedom in what extra software was added to Windows by OEM's.
True there probably is no such wording in anything given to home users, but they own the system and can do anything they want to it, whether Microsoft wants them to or not. And they cannot distribute the result because they would be violating the copyright on Windows itself, so it is quite irrelevant if their redistribution includes some added code of their own.
Huh?
If YOU own the copyright to the code, it does not matter if you previously released it under the GPL. It is your code and you can release it again any way you want. Many people do dual licensing, or discontinue supporting their GPL version. There is nothing wrong with that.
It seems to me that OCR would fix this pretty easily. People worry about the fact that OCR cannot understand the captchas, but that hardly is necessary. All an OCR spam-recognizer has to do is determine that there *is* text in the image, it does not have to read it. Images consisting of a lot of text are definately an indicator of spam.
Other resonders have gone into detail about the actual facts, but the general and safe consensus is that you cannot distribute your program if it is linked with a GPL library unless you distribute your source code as well, with the GPL license.
Because of this, virtually every useful library is available under the LGPL or a similar license, because the authors know that their code will not be used otherwise. Even somebody who intends to write a GPL program may balk because they want the ability to change their own license in the future.
The idea that there could be a non-GPL "alternative implementation" of a GPL library I think mean you can do anything with your source code. Not sure what would be the law, but I highly suspect the following rules would apply:
1. The "alternative implementation" must actually exist, and be available to the users of your program (though it might not be free).
2. If your program is statically linked it must be linked with the alternative implementation, not the GPL one.
3. If your program is dynamically linked, there must be a pretty convincing argument that you tested and indend it to work with the alternative implementation, for instance it can't have any code that says "if (gpl_version) do_function_missing from_alternative()".
IE is not designed to *exclusively* communicate with a particular GPL Web Server. That's a really obvious difference that makes your example bogus.
Although it certainly is not clear what is "linking" there are some obvious limits:
1. From the GPL, if it is one file on disk, it definately *is* "linked".
2. Conversely, if the two pieces are both useful on their own, and their halves of the communication mechanism are useful on their own, they are definately *is not* "linked". Your IE/WebServer example falls into this catagory.
Everything inbetween is a gray area, with all kinds of shades of gray. But the above two are the definate extremes beyond which it is silly to ask questions about.
I think that was Arther C Clarke. It was a rather funny short story. Basically all food was manufactured, and everybody forgot what it was a copy of. The board of directors of the food company that is rapidly loosing sales to this new food that everybody likes has to be explained by a scientist from their labs the meaning of the word "carnivore". After this long explaination which also revealed the history of the manufactured foods, the scientist says they have completed their examination of the competitors food, and says "now I need to define a new word. That word is 'cannibal'".
There are "hard core gamers" who want to be able to reboot their Windows machine into Linux, so lack of a Linux driver certainly is a factor.
You might investigate what the word "joke" means. I think even Microsoft gets them. Not sure how you manage in life without understanding the concept.
If you have not figured it out, this is all very good for Microsoft. I think they should be very happy with the high level of jokes here. If Microsoft truly turned around and stopped acting hostile to everybody else in the world, the number of jokes would probably skyrocket, they may even make them themselves.
I assumme you are talking about pollution from the spaceships necessary to do this. The actual transfer of matter from the moon to the earth in the quantities that we could do even if we put 100% of all human's efforts into doing it is unlikely to effect things one bit.
My guess is that if some highly unlikely situation makes it profitable for independent prospectors to build their own ships and go to the moon to mine it, and there is a gold rush of some sort of these, then we should worry. Until then, however, it would be better to fix our billions of air conditioners and do other less glamorous things.
If somebody claimed a Windows vulnerability but insisted on demoing it using Wine, then no, I would not believe them.
What the hell are you talking about? I have NEVER seen a media player on Linux that did not allow the window to be resized! In fact, I have had the opposite problem, it is far too *easy* to resize the window, and it is often obscure or impossible to restore it to the correct non-scaled (ie no filtering and/or distortion) size.
This is really hard to explain. What I want (and the original poster wants) is for that to NOT be a numeric keypad, we want to use it as additional function keys (in my case I use the arrows as "nudge" arrows to move graphics by less than one pixel). This sounds like what you want as well.
Due to the need to be back compatable with existing programs, the unintuitive result is that the best way to do this is to force NumLock to be ON at all times. Any other solution either makes it difficult for a program to identify the numeric keys (requiring a new api that is not supported by existing toolkits), or would make old programs act like NumLock is on anyway.
Therefore, for the exact reason you, I, and the original poster wants, we need NumLock ON. It may seem that this is "further away" from it being function keys, but in fact it is better, for complex reasons.
I also want programs to use the numeric keypad "arrows" for something else, and this means I want NumLock "on" at all times, the opposite of what you state. It is literally impossible to make the numeric keypad arrows have special functions without breaking every existing piece of software unless you act like NumLock is on. I will try to explain this counter-intunitive result:
// it's a function key! ...
The keyboard api (in both Windows and Linux) returns two pieces of information, the "key" and the "text". All function keys such as arrows have blank text. Currently if NumLock is off, the numeric keypad returns the exact same symbols and blank text as the normal arrows.
Let's write a "simple" text editor for a program that is unconcerned about NumLock and the keypad and just wants to work as the user expects:
handle_key() {
if (key_text() != 0) {
insert(key_text());
} else {
switch (key()) {
case UP: move_cursor_up(); break;
case DOWN: move_cursor_down(); break;
}
}
}
Now what should the numeric keypad keys return if we want it to act like NumLock is off?
1. The arrow symbols and blank text (what Windows does now if NumLock is off). This fails as it is impossible to distinguish them from the normal arrows, so the desired function of making the numeric arrows do something different is impossible.
2. Special "different" arrow symbols and blank text (for some keys this is what Windows does if you assumme the "alt" bit is part of they key number). This fails as the above program will not see the arrow keys. Even if you modify the simple program, you will fail if a second keypad is added.
3. Arrow symbols plus text (ie "4" for the left-arrow+4). This fails the above in that the code will insert the text, acting like NumLock is on when it is supposed to act like it is off. Also fails to distinguish more than one keypad.
How about if we act like NumLock is on?
1. Special "different" number key symbols and the correct text. This works. The simple code above will insert the text, yet it is easy for a program to distinguish the keys if it wants to treat the keypad as differnt types of arrows. Adding another keypad can define more symbols, that will not break the simple program, and won't break the "complex" program (it will probably think the second keypad are normal numerics).
For this reason my software (fltk) always acts as though NumLock is on by changing the key events (Linux version changes the arguments to XLookupKeysym, the Windows verison uses the alt bit of the event to detect keypad and converts the arrows back into numbers, and some nasty other tests for those keys where the alt bit does not work)
I hope that was clear. The "intuitive" result is not always right. We definately should get rid of NumLock and act like it is ON at all times!
That does not quite explain it. For both Apple and Microsoft, a "new computer" already includes the operating system, so sales of this is irreleveant to sales of new computers.
Can't think of any real explanation. One is that Microsoft just never thought of it. Or that the bean counters thought that the availability of a "family pack" would reduce sales (like you, I suspect it would actually raise revenue, by a tiny insignificant amount...). Or that Microsoft relies on corporate customers that would only buy 1/5 as many copies and assummes all home users will pirate (though wouldn't a "for home use only" stop those same corporate customers?). If you want the Microsoft-is-evil explanation, perhaps Microsoft knows that everybody will be forced to upgrade, while Apple knows that people can keep using the old system and interoperate just as much as before. Or the pro-Microsoft version of this, which is that Apple users don't need to upgrade because there is no commercial software for it anyway.
You are however allowed to make your own license that says "this code is covered as per the terms of the GPL (see below) with the following additional restrictions and following additional exception" and then list any number of modifications (either additional restrictions like "no military use" or exceptions to copyright such as "you can link this code without giving away the source", following by an attachement of the unmodified GPL. This is done all the time.
You answered your own question right here:
Heck, even the much-touted OpenGL example World of Warcraft actually makes heavy use of DirectX under Windows. Just not for graphics.
Obviously seperating sound and joystick input from the graphics output is no big deal.
Even a program that does not use any api called "DirectX" is probably using the FAT file system or NTFS when it's files are written to disk. If Microsoft had named this DirectX-file then that program would be using DirectX! Amazing!
As others said, there very likely is another allocated piece of memory right there, so you will just overwrite that, and not get an error.
Even if those memory locations are not allocated, memory protection is not per byte, but per page, so you won't get an error. Also many memory allocators will put information (such as how much memory is free and available here and where is the next free block) into the "unallocated" memory, so writing over it will cause the memory allocator to crash.
Actually every commercial program that displayed anything other than stdout wrote directly to the hardware. This was due to the insanely bad design of the "bios".
How bad? How many calls do you think are needed to draw a letter on the screen?
Anybody with any brains would probably choose something on the order of 1/80, ie draw up to 80 characters (the length of a line) at once, with a call that says "at this x,y, draw these n bytes").
Now CPM and MSDOS were not done by smart people, so they already forced the api to be one character at a time. So you might think they ignored the real way to do this, and provided a BIOS call that drew one letter, so the MSDOS call could go straight to it.
But NO, they instead managed to figure out how to require two (count em!) calls to draw a letter. There was a call to draw a letter at the current cursor position but not move the cursor!. There was another call to move the cursor. Not only that, each of these calls was (as evidenced by the supplied BIOS listing) 40 or more assembler instructions long!
MSDOS's stdout "driver" literally did these two calls alternately for each byte they wanted to draw (plus it checked for backspace and return and line feed). This caused the "dir" type output to be hundreds of times slower than any even remotely intelligent design would do. Compare to any contemporary CP/M machine, even ones that drew on a remote terminal over a 9600 baud serial line, would reveal that MSDOS stdout was unreasonably slow for the hardware, and this was almost entirely due to the BIOS.
No programmer in their right mind would pass up the opportunity to get a 100-fold speed increase by writing directly to the memory. Besides it was actually much easier to program.
MSDOS did not help, as it's "driver" did not provide any escape sequences, so you *had* to use the BIOS or direct hardware to do anything other than teletype output. If there had been any escape sequences, I'm sure many people would have interrupted the MSDOS api and provided "turbo output" drivers that sped it up a hundered times, and enough programs would have used the escape sequences that it would have become a standard api. Adding an API that took many characters at once (as was added in MSDOS 2.0) and passed them through an escape sequence interpreter would have provided nearly the same speed as the direct hardware api. These escape sequences, which probably would have been in binary and very simple (one thing Microsoft does well), would have instantly become the standard for bulletin board dialup, and we would not have been stuck with the rather awful ANSI sequences that were designed by committee.
The direct hardware api really hurt development of the PC for a long time. When it first came out there was lots of additional hardware, such as a 100x80 character screen that we tested where I worked, bitmapped graphics terminals (with mice!) and schemes to use one PC to drive lots of terminals or over phone connections, and also attempts like TopView to provide a (character based) windowed and multitasking api, there were also many semi-clones with much better graphics capabilities such as mroe than 256 glyphs at once, bitmapped graphics, and smooth scrolling, all of these were killed by the fact that they required the programs to use some api that could be redirected. This was also responsible for the 640K limit, the 8088 had a natural limit of 1M, but 640K was where the video hardware was placed and it could not be moved out of the way. Not until Windows came out and gave programmers a good reason to use an api did graphics hardware actually start to advance.
No way. One of the primary design criteria was that it be easy to port CP/M programs (written in assembler) to the machine. The 8088 had to be chosen because of it's compatable instruction set to the 8080. This also fixed the design of MSDOS to match CP/M.
Yea, it's much better to use an abbreviation that means "Multiple Scolorsis" to anybody 30 or over, or that indicates that a woman does not want anybody to know if she is married from her name.
Face it, the abbreviation "M$" is immediatly readable and identifiable. "Microsoft" is too long and is probably the only other acceptable way of writing it.