Re:Anti-aliasing on conventional monitors.
on
Cleartype In Depth
·
· Score: 1
I think the trick is that it does not just "average out". If it did the rendering would be simple: reuse their TrueType hinted renderer but draw the letter 3x wide, then simple convert each 3 output "pixels" into r,g,b values of one pixel.
The problem is that a vertical line that comes out 2 "pixels" wide will only display cyan, magenta, or yellow, not white. The only way to fix this is to adjust it so it is 3 pixels wide. Much like hinting.
The lighting hack is "bump mapping". What you think is bump mapping is called "displacement mapping".
Displacement mapping is a lot harder. You don't just "move the pixels". If you moved the pixel, you would leave a hole where the pixel was! What do you put there?
Displacement mapping is usually done with adaptable subdivision, where the polygon is divided up into triangles, the corners displaced vertically, and they are divided, repeatedly, until the triangle is "small enough" that bump mapping can be used on it (deciding this is the tricky part). This could be done in hardware, and likely it will someday soon, but doing bump mapping in hardware should not be scoffed at.
Uh, that can be done by having a *PARENT* window, much like closing the main window of an application with a file chooser up will hide the file chooser, too (at least under most X window managers:-))
It does not require that the child windows reside inside the parent, which is the annoying part of "MDI" and was done ONLY to avoid swapping in other programs on ancient Windows 3.1 platforms (because moving the windows or closing them would not expose screen area that has to be redrawn by other programs).
MDI is truly an abonimation and it would be nice to get rid of it!
If the user was mailed a *real* movie called foo.mov, isn't the extension hidden on them so the name they see is "foo"?
If this is true, why aren't the files named "foo.exe" rather than "foo.mov.exe" so they look more like movies.
(I think I know the answer, which a lot of people are not going to like: the answer is that "icons" are bunk, the letters ".mov" despite their cryptic nature, are far more compelling than any image to even novice users)
But if anybody has any better answers please tell me.
Also, are they able to make the icon an exact copy of the.mov icon by changing the icon embedded in the.exe? I recommend that MSoft at least show a generic.exe icon if this is the case.
Re:CNN Microsoft poll results (as of 3:46pm centra
on
Microsoft Quickies
·
· Score: 1
Minesweeper existed on character screens long before MicroSoft was even formed.
I certainly hope that the window system is not a "real graphical environment". We don't need widgets built into the system, it is easy (trivial, really) to build them atop the system. Or do you also think that file systems would be better if there were different calls to read image files than to read text files (there were systems that worked this way once upon a time, too).
Cutting and pasting anything is not the graphics system's responsibility. Even X does too much of this. I think in Plan9 cut/paste would be done by reading and writing files, and of course *ANY* data can be put through the file.
Of course, under the Stallman program, you won't even own the music and software you created. You'll be forced to "share" it with everybody else.
I know this is flame bait, but the ignorance of some of these writers is amazing. Stallman does not force everybody to release stuff with the GPL. You can do anything you want with "your" software (your definition of "your").
"Oh but if I include GPL code in my code I'm forced to use the GPL, Oh BOO HOO!!!" you are saying, now, right? But that means you used software belonging to somebody else (again, your definition of "ownership"), yet you don't want to follow the rules they made up for ownership of this software, and thus you want to be able to steal it!
Don't be such a hypocrit (sp?).
Also, I would think Lexus would sue you pretty badly if you happened to own an auto plant and started manufacturing copies of your Lexus. So according to your logic you don't "own" your Lexus.
input methods that allow entering Asian language text into any application
Actually support is rather bad on Win32, which is riddled with programs that only accept ascii (or 8-bit), this is why they added characters in the range 0x80-0xA0 that already existed elsewhere in Unicode. But you are right that support is even worse on Unix, which suffered greatly under the Politcal-Correctness insistence on using "wide characters". The real solution is UTF-8 everywhere so programs don't need char/wide modes, interesting enough this was innovated by Pike himself for the Plan-9 system, and it is shameful that it has not caught on (except for HTML).
"Lightweight" threads mean NO SYSTEM CALL TO CREATE THE THREAD. Last time I checked both NT and Linux used a system call. Much work has been done on lightweight threads, particularily on Solaris, which really likes them. All other research I have heard of is on various Unix systems.
Personally I think lightweight threads are a mistake and that the NT/Linux solution of trying to make the system call lightweight is better. Lightweight threads require non-blocking versions of *all* system calls, which seems to be a real annoyance.
2. For each program they produce which generates document files or communicates across the network they must produce a simple file viewer or packet catcher ( where appropriate ) that is 100% compatible. No bells or whistles at all required. The catch is that this viewer must be under a BSD license and come with the full source code.
This is an excellent idea.
There is nothing wrong with the BSD license for this. Even if that requires you to insert "this portion based on code that is (C) MicroSoft" into your code. It will allow anybody (free and commercial) to read the files.
I don't think obfuscation of the code is a problem. The output only has to be usable. There should be a requirement that the "usability" of this output be agreed to by independent parties.
"encoding" is not necessary, only "decoding". This could actually be a revenue source for MicroSoft. They may come up with extremely clever compression schemes and can keep those secret as long as the result can be decoded. If they are clever they may figure out a scheme that everybody can read, but nobody can produce as good of a file as they can.
This rule should be applied to all companies producing information appliances, not just MicroSoft. Or require it for government purchases.
Looking at Xlib header files, it appears the set of modifier keys they thought about, in numerical order, is Shift, Control, Meta, Alt, Super, Hyper.
So it does look like Meta was invented before Alt, or was considered more basic. However the numbers are all assigned next to each other, with Alt in the middle, so I believe that keyboards existed at that time with both identifiers on the keys.
I don't know about your solution. You have made the code even more complex than before. Bloating it with tests makes it hard to read, and can actually confuse other code readers because they can believe that it is possible for the tests to fail, leading to far more code paths than really exist. For instance I think the assert for the fd would lead people to think this function may be called with a closed fd (yea I know it will abort, but it does confuse me). Also sizeof(unsigned char)==1 by definition of the C language, putting bloat like that in is bad.
My version, the main thing I do is get rid of the "count" argument, which according to the code is always one, and their funciton would not work if it was not 1:
The code also will not work if the "count" argument is any value other than 1. According to the analysis they determined that it never is any value other than 1, but this seems to be rather poor programming. Obviously the writer of this function knew it would always be 1, but he/she should have fixed the code to not use the argument, rather than make such an assumption. Better yet, go through the code and delete the argument. Simplifying the code would go a long way toward detecting stupid mistakes like this.
I very much disagree with the joker who thought the program should check for a read error from dev/random. Stupid stuff like that, which will *NEVER* happen, is what bloats code up with complexity and leads to typos like the above.
It would be really nice if all X servers defaulted to using the "win" button as META! And it would be nice if we started calling the keystrokes "Meta-x" or "Meta-y", etc.
My copy of XFree86 seems to make the "Menu" key send the X XK_Menu keysym. This seems like a reasonable standard, too.
Also I would like to see some company make a "geek" keyboard not by replacing the windows logo with little penguins, but by printing "Meta" on the keys (and "Menu" on the menu key). That would be nice, we could finnally unambiguously communicate about key strokes.
I know there will be lots of flames here saying that the taskbar is not revolutionary, but I agree with you.
EVERY other system before W95 turned miniaturized/hidden windows into an "icon" that had to be placed on the desktop by the user. This "icon" also tended to put a lot of prominance on an image and very little (or none) on the text identifier. W95 realized that these "icons" could be arranged automatically, that a long horizontal shape is more efficient than a rectangle, and that the picture could be deleted (they actually shrank it so small as to be indecipherable, but it proves the idea).
The "start" menu did have precedence with the Apple menu, but Apple did not put *all* programs on it, only "accessories".
The NeXT "dock" was somewhat like a taskbar + start menu, but missed two innovations: it put way too much importance on the picture (there was NO text), and iconized windows were put into the dock only if they were launched from the dock. The NeXT did have the innovation MSoft seems to have missed: when the program is launched the entry can be reused as the icon.
I also think a W95 innovation was the simplification of window borders. Until then everybody drew an "inner edge" on the windows borders and they were much thicker and wasted screen space. I like to think I came up with this first (see the ViewKit I wrote for NeXT in 1987) but I doubt they saw my stuff and copied it.
Another innovation is the use of Alt+Tab to switch windows. This was somewhat stolen from CDE, but CDE only used Alt+Tab to switch between uniconized windows. W95 came up with the pop-up box to allow you to switch to any window.
I would expect the first modifications to a released Windows source code would be hacks to make it interoperate better with Unix:
Add NFS, add a hack so drive letters are not needed (ie/A/ means A:/), make stdin/out work all the time, add a method to get a real shell when you telnet. Probably fixes to the libraries to remove \r characters from text files and things like that. I'm sure there are many others.
Most of these seem more like hacks than real engineering and they can be stuck in there without complete understanding of the code. This would suddenly allow the MicroSoft OS's to cooperate better with the rest of the world, vastly increasing the value of all systems.
Real modifications of Windows, or merging of Windows ideas into Unix, or vice-versa, are going to be later, and may be much less important than these simple changes.
BTW, if you use GPL'ed libraries (this would be the equivalent of the MS Foundation Classes/ActiveX whatever), I'm assuming you have to open the source, right? If so, it may be necessary to kill off this clause and allow the multimedia developers/game writers to keep the IP they have worked to build...
That's why all the relevant libraries are LGPL (or equivalent). Closed-source applications can use them.
I think you misunderstood what I was saying (well I guess I was pretty unclear).
I was comparing lightweight processes with "heavy" threads. "Heavy" threads have OS support, this is what NT uses, it also seems to be the way all other systems are going.
I agree the threads should be in the OS. But the complaint seemed completely wrong to me. The ONLY advantage of "lightweight processes" is that they are LIGHT! Creating one requires ZERO system calls, and thus is faster than any possible OS implementation.
I also agree that non-blocking system calls are not too complex to implement. However if you have any kind of thread support they are NOT necessary. They are only a requirement if you want to allow lightweight threads. It is rather hypocritcal of MicroSoft to make a big deal about both their heavyweight thread support and their non-blocking calls, as these are exactly complements of each other. I would prefer that the non-blocking system calls be removed to simplify the system, but that will never fly with the people who got used to them before threads were introduced.
Posix threads make no requirements that the threads be lightweight. That just defines the interface and can be implemented atop MicroSoft's thread implementation (except for a rather boneheaded missing bit of functionality on MicroSoft's part: there is no atomic operation equivalent to pthread_cond_wait(), but you can do pretty good ignoring this).
but many existing applications would have to be recoded to take advantage of it
No, if it is done right unchanged applications will draw antialiased fonts. There may be some requirements: they must use a TrueColor visual, the bitblit must be Copy, they must select a font that is actually an outline font, etc, but many applications will already satisfy these requirements.
I think any solution that does not make old applications work should not be accepted, ie we don't need another "extension" for this. Even MicroSoft did their anti-aliased font interface correctly, ie "old" applications got it with no rewrite.
The interface to the font storage in X does need to be rewritten, and here I recommend that the implementors go totally ape and rip out ALL the old crap. There is no reason to support any of the old font servers.
Also, what kind of keying is it doing? Is it premultiplied over black or straight? PNG defines it as "straight", ie the way you would composity A with alpha a over B is to do A*a+B*(1-a).
Premultiplied over black means you do A+B*(1-a).
Premultiplied has some advantages: you can make glows (where A > a), programs that ignore the alpha produce an ok image (rather than strange bright colors on the antialiased edges), and all 3-D renderers produce this type of image. Premultiplied images should compress better too, due to the coherence between intensity and alpha.
Premultiplied has disadvantages, too: the color of transparent areas is at a very low resolution (this will show up if you overlap the same color many times), you can't get two antialised images that overlap without unexpected seams due to this, and if you pull a key you have to destroy information that may be useful for making a better key. Also the 3-D renderers are almost always incorrect with the math because they assumme the gamma is 1.0 and removing this assumption is difficult or impossible.
It would seem to me that PNG should have allowed a flag to say which way the image is stored, but they probabably wanted to keep it as simple as possible. Except for glows you can convert premultiplied to non-premultipled by dividing by the alpha (use 0 if the alpha is zero).
Don't torpedo your arguments by being an asshole. In Unix html files are named "*.html"..HtMl is a different file type and must not be matched by the search.
I might as you how I to "find all the files that are named.HTML and not.html" and say that that proves VMS sucks while Unix is great because you have to type a complex command while Unix is simple.
Then tell the VMS person about how we're getting different languages to work together. They will look at you in amazement, wondering why there isn't a standard calling convention that all the languages use.
Actually that was the selling point of Unix, not VMS. I worked at Dec in 1983 with a group that was porting a compiler for CLU (an old OO language) from BSD Unix to VMS, and this was my introduction to Unix (and I was immediately won over!).
One of the big problems is that the CLU compiler and all of BSD used a far faster calling convention than VMS libraries used (this had to do with which side of the call saved the registers). CLU relied on this fast call, since every method used it (there were no inline methods). Dec's solution was to fix the compiler to recognize non-CLU libraries and use a different calling convention.
Another killer for VMS is that on Unix, a "cp" program was 5 lines long. On VMS the equivalent (pip) was the LARGEST program on the system!
Under UNIX, a thread is a lightweight process. As such, the scheduler is process oriented, and threads take much more time and resources to create under UNIX
This is incorrect. Nothing in Unix says that threads must be lightweight processes, there are many implementation possibilities. Solaris is the only design firmly in that camp. Linux is actually quite the opposite, if I remember right, in that both processes and threads are created with the same spawn system call.
Also, the (imho only) advantage of lightweight processes is that the the resources to create a thread are far less than any object that the OS is aware of. This is exactly the opposite of what you said.
The problem with lightweight processes is that support requires complex libraries and redundancy with the OS (which has to support multiple processes anyway) and requires non-blocking versions of all system calls, which are much more complex (interesting enough MicroSoft makes a big stink about their non-blocking support and their multi-threading support, when realistically only one of these needs to be implemented!)
This also proves a GUI theory: "icons" are pretty much useless. The.vbs file displays a different icon, but apparently many people's eyes ignore the icon and zero in on the ".txt", despite the fact that a real.txt file would not have the ".txt" displayed!
Another question: it can't be too hard to change the linking in Windoze for.vbs so they don't run at all (ie have them be considered text files). It seems strange that I have not seen instructions like "change this item in your Registry to fix all the virii." Is this change impossible, or perhaps it would break too many other programs, or what? How about a.vbs wrapper that pops up a question box (and maybe examines the code for stuff that reads/writes files or does anything with mail) before executing it?
Why wasn't that license/copyright information in the.pdf portion of the file?
Whether or not you try to force somebody to click a button, it just seems stupid that they would not also put the legalese in a place where it will be preserved if the file is printed or if the user only keeps the interesting part on their disk.
In my own OSS code I slavisly put the GNU comment block at the top of every single file so that nobody can make the excuse that they did not see it. This is an obvious precaution and I don't see why they did not do it.
Slashdot Mirror
The problem is that a vertical line that comes out 2 "pixels" wide will only display cyan, magenta, or yellow, not white. The only way to fix this is to adjust it so it is 3 pixels wide. Much like hinting.
Displacement mapping is a lot harder. You don't just "move the pixels". If you moved the pixel, you would leave a hole where the pixel was! What do you put there?
Displacement mapping is usually done with adaptable subdivision, where the polygon is divided up into triangles, the corners displaced vertically, and they are divided, repeatedly, until the triangle is "small enough" that bump mapping can be used on it (deciding this is the tricky part). This could be done in hardware, and likely it will someday soon, but doing bump mapping in hardware should not be scoffed at.
It does not require that the child windows reside inside the parent, which is the annoying part of "MDI" and was done ONLY to avoid swapping in other programs on ancient Windows 3.1 platforms (because moving the windows or closing them would not expose screen area that has to be redrawn by other programs).
MDI is truly an abonimation and it would be nice to get rid of it!
If this is true, why aren't the files named "foo.exe" rather than "foo.mov.exe" so they look more like movies.
(I think I know the answer, which a lot of people are not going to like: the answer is that "icons" are bunk, the letters ".mov" despite their cryptic nature, are far more compelling than any image to even novice users)
But if anybody has any better answers please tell me.
Also, are they able to make the icon an exact copy of the .mov icon by changing the icon embedded in the .exe? I recommend that MSoft at least show a generic .exe icon if this is the case.
Minesweeper existed on character screens long before MicroSoft was even formed.
I certainly hope that the window system is not a "real graphical environment". We don't need widgets built into the system, it is easy (trivial, really) to build them atop the system. Or do you also think that file systems would be better if there were different calls to read image files than to read text files (there were systems that worked this way once upon a time, too).
Cutting and pasting anything is not the graphics system's responsibility. Even X does too much of this. I think in Plan9 cut/paste would be done by reading and writing files, and of course *ANY* data can be put through the file.
I know this is flame bait, but the ignorance of some of these writers is amazing. Stallman does not force everybody to release stuff with the GPL. You can do anything you want with "your" software (your definition of "your").
"Oh but if I include GPL code in my code I'm forced to use the GPL, Oh BOO HOO!!!" you are saying, now, right? But that means you used software belonging to somebody else (again, your definition of "ownership"), yet you don't want to follow the rules they made up for ownership of this software, and thus you want to be able to steal it!
Don't be such a hypocrit (sp?).
Also, I would think Lexus would sue you pretty badly if you happened to own an auto plant and started manufacturing copies of your Lexus. So according to your logic you don't "own" your Lexus.
input methods that allow entering Asian language text into any application
Actually support is rather bad on Win32, which is riddled with programs that only accept ascii (or 8-bit), this is why they added characters in the range 0x80-0xA0 that already existed elsewhere in Unicode. But you are right that support is even worse on Unix, which suffered greatly under the Politcal-Correctness insistence on using "wide characters". The real solution is UTF-8 everywhere so programs don't need char/wide modes, interesting enough this was innovated by Pike himself for the Plan-9 system, and it is shameful that it has not caught on (except for HTML).
"Lightweight" threads mean NO SYSTEM CALL TO CREATE THE THREAD. Last time I checked both NT and Linux used a system call. Much work has been done on lightweight threads, particularily on Solaris, which really likes them. All other research I have heard of is on various Unix systems.
Personally I think lightweight threads are a mistake and that the NT/Linux solution of trying to make the system call lightweight is better. Lightweight threads require non-blocking versions of *all* system calls, which seems to be a real annoyance.
This is an excellent idea.
There is nothing wrong with the BSD license for this. Even if that requires you to insert "this portion based on code that is (C) MicroSoft" into your code. It will allow anybody (free and commercial) to read the files.
I don't think obfuscation of the code is a problem. The output only has to be usable. There should be a requirement that the "usability" of this output be agreed to by independent parties.
"encoding" is not necessary, only "decoding". This could actually be a revenue source for MicroSoft. They may come up with extremely clever compression schemes and can keep those secret as long as the result can be decoded. If they are clever they may figure out a scheme that everybody can read, but nobody can produce as good of a file as they can.
This rule should be applied to all companies producing information appliances, not just MicroSoft. Or require it for government purchases.
So it does look like Meta was invented before Alt, or was considered more basic. However the numbers are all assigned next to each other, with Alt in the middle, so I believe that keyboards existed at that time with both identifiers on the keys.
My version, the main thing I do is get rid of the "count" argument, which according to the code is always one, and their funciton would not work if it was not 1:
static unsigned pgpDevRandomAccum(int fd)
{
char buffer[1];
read(fd, buffer, 1);
pgpRandomAddBytes(&pgpRandomPool, buffer, 1);
pgpRandPoolAddEntrophy(256);
}
I hope most people agree that it is a lot easier to spot bugs in my version.
I very much disagree with the joker who thought the program should check for a read error from dev/random. Stupid stuff like that, which will *NEVER* happen, is what bloats code up with complexity and leads to typos like the above.
My copy of XFree86 seems to make the "Menu" key send the X XK_Menu keysym. This seems like a reasonable standard, too.
Also I would like to see some company make a "geek" keyboard not by replacing the windows logo with little penguins, but by printing "Meta" on the keys (and "Menu" on the menu key). That would be nice, we could finnally unambiguously communicate about key strokes.
EVERY other system before W95 turned miniaturized/hidden windows into an "icon" that had to be placed on the desktop by the user. This "icon" also tended to put a lot of prominance on an image and very little (or none) on the text identifier. W95 realized that these "icons" could be arranged automatically, that a long horizontal shape is more efficient than a rectangle, and that the picture could be deleted (they actually shrank it so small as to be indecipherable, but it proves the idea).
The "start" menu did have precedence with the Apple menu, but Apple did not put *all* programs on it, only "accessories".
The NeXT "dock" was somewhat like a taskbar + start menu, but missed two innovations: it put way too much importance on the picture (there was NO text), and iconized windows were put into the dock only if they were launched from the dock. The NeXT did have the innovation MSoft seems to have missed: when the program is launched the entry can be reused as the icon.
I also think a W95 innovation was the simplification of window borders. Until then everybody drew an "inner edge" on the windows borders and they were much thicker and wasted screen space. I like to think I came up with this first (see the ViewKit I wrote for NeXT in 1987) but I doubt they saw my stuff and copied it.
Another innovation is the use of Alt+Tab to switch windows. This was somewhat stolen from CDE, but CDE only used Alt+Tab to switch between uniconized windows. W95 came up with the pop-up box to allow you to switch to any window.
Add NFS, add a hack so drive letters are not needed (ie /A/ means A:/), make stdin/out work all the time, add a method to get a real shell when you telnet. Probably fixes to the libraries to remove \r characters from text files and things like that. I'm sure there are many others.
Most of these seem more like hacks than real engineering and they can be stuck in there without complete understanding of the code. This would suddenly allow the MicroSoft OS's to cooperate better with the rest of the world, vastly increasing the value of all systems.
Real modifications of Windows, or merging of Windows ideas into Unix, or vice-versa, are going to be later, and may be much less important than these simple changes.
That's why all the relevant libraries are LGPL (or equivalent). Closed-source applications can use them.
I was comparing lightweight processes with "heavy" threads. "Heavy" threads have OS support, this is what NT uses, it also seems to be the way all other systems are going.
I agree the threads should be in the OS. But the complaint seemed completely wrong to me. The ONLY advantage of "lightweight processes" is that they are LIGHT! Creating one requires ZERO system calls, and thus is faster than any possible OS implementation.
I also agree that non-blocking system calls are not too complex to implement. However if you have any kind of thread support they are NOT necessary. They are only a requirement if you want to allow lightweight threads. It is rather hypocritcal of MicroSoft to make a big deal about both their heavyweight thread support and their non-blocking calls, as these are exactly complements of each other. I would prefer that the non-blocking system calls be removed to simplify the system, but that will never fly with the people who got used to them before threads were introduced.
Posix threads make no requirements that the threads be lightweight. That just defines the interface and can be implemented atop MicroSoft's thread implementation (except for a rather boneheaded missing bit of functionality on MicroSoft's part: there is no atomic operation equivalent to pthread_cond_wait(), but you can do pretty good ignoring this).
No, if it is done right unchanged applications will draw antialiased fonts. There may be some requirements: they must use a TrueColor visual, the bitblit must be Copy, they must select a font that is actually an outline font, etc, but many applications will already satisfy these requirements.
I think any solution that does not make old applications work should not be accepted, ie we don't need another "extension" for this. Even MicroSoft did their anti-aliased font interface correctly, ie "old" applications got it with no rewrite.
The interface to the font storage in X does need to be rewritten, and here I recommend that the implementors go totally ape and rip out ALL the old crap. There is no reason to support any of the old font servers.
Premultiplied over black means you do A+B*(1-a).
Premultiplied has some advantages: you can make glows (where A > a), programs that ignore the alpha produce an ok image (rather than strange bright colors on the antialiased edges), and all 3-D renderers produce this type of image. Premultiplied images should compress better too, due to the coherence between intensity and alpha.
Premultiplied has disadvantages, too: the color of transparent areas is at a very low resolution (this will show up if you overlap the same color many times), you can't get two antialised images that overlap without unexpected seams due to this, and if you pull a key you have to destroy information that may be useful for making a better key. Also the 3-D renderers are almost always incorrect with the math because they assumme the gamma is 1.0 and removing this assumption is difficult or impossible.
It would seem to me that PNG should have allowed a flag to say which way the image is stored, but they probabably wanted to keep it as simple as possible. Except for glows you can convert premultiplied to non-premultipled by dividing by the alpha (use 0 if the alpha is zero).
I might as you how I to "find all the files that are named .HTML and not .html" and say that that proves VMS sucks while Unix is great because you have to type a complex command while Unix is simple.
Actually that was the selling point of Unix, not VMS. I worked at Dec in 1983 with a group that was porting a compiler for CLU (an old OO language) from BSD Unix to VMS, and this was my introduction to Unix (and I was immediately won over!).
One of the big problems is that the CLU compiler and all of BSD used a far faster calling convention than VMS libraries used (this had to do with which side of the call saved the registers). CLU relied on this fast call, since every method used it (there were no inline methods). Dec's solution was to fix the compiler to recognize non-CLU libraries and use a different calling convention.
Another killer for VMS is that on Unix, a "cp" program was 5 lines long. On VMS the equivalent (pip) was the LARGEST program on the system!
This is incorrect. Nothing in Unix says that threads must be lightweight processes, there are many implementation possibilities. Solaris is the only design firmly in that camp. Linux is actually quite the opposite, if I remember right, in that both processes and threads are created with the same spawn system call.
Also, the (imho only) advantage of lightweight processes is that the the resources to create a thread are far less than any object that the OS is aware of. This is exactly the opposite of what you said.
The problem with lightweight processes is that support requires complex libraries and redundancy with the OS (which has to support multiple processes anyway) and requires non-blocking versions of all system calls, which are much more complex (interesting enough MicroSoft makes a big stink about their non-blocking support and their multi-threading support, when realistically only one of these needs to be implemented!)
Another question: it can't be too hard to change the linking in Windoze for .vbs so they don't run at all (ie have them be considered text files). It seems strange that I have not seen instructions like "change this item in your Registry to fix all the virii." Is this change impossible, or perhaps it would break too many other programs, or what? How about a .vbs wrapper that pops up a question box (and maybe examines the code for stuff that reads/writes files or does anything with mail) before executing it?
Whether or not you try to force somebody to click a button, it just seems stupid that they would not also put the legalese in a place where it will be preserved if the file is printed or if the user only keeps the interesting part on their disk.
In my own OSS code I slavisly put the GNU comment block at the top of every single file so that nobody can make the excuse that they did not see it. This is an obvious precaution and I don't see why they did not do it.