According to AOL itself, Quantum Computer Services (which later changed names to America Online) released its first online service, Q-link, for some unnamed Commodore computer. The first product with the AOL name was for Apple ][ and Macintosh. I don't know if I, as a Mac user, should be happy or embarrassed by this. (:
ah, yes, the darn SimpleText can't open the file because it's too big problem (akin to not being able to open a file in Notepad, though I believe it does automatically offer to open it in Wordpad). That's why the drag-and-drop is so useful, especially how it ties into the "this application can open these file types" list. While that limitation is annoying, I'll usually just drag a file to the BBEdit icon, which I'll keep either in the dock (in OS X) or in a tabbed folder (in OS 9).
By the way...has Microsoft ever addressed the limitation in NT 4 where, if you drag an icon to a program on the task bar, it tells you you can't do that, and suggests some alternative? By including that warning, it's like they are saying, "Hey, we know you'd like to do that, and we know it's probably a good idea, but we still aren't going to let you!" I'd feel better if it was just something they looked over, rather than something they just refused to implement.
Another point about type/creator codes that Windows and Linux users may not know:
In addition to each file storing the type and creator code, but each application stores a list of file types that it can open. This is used by the Finder to allow a user to drag-and-drop a document icon to an application icon (including an application other than the one that originally created the document), as well as to build a list of possible applications when a user tries to open a document for which the creator is not available.
This honestly is one of the subtle features that adds to the ease of use of the Mac. Many of you will be skeptical, but I am certain that if you had the opportunity to work with a Mac in an open-minded fashion, you'd come to appreciate how smart this approach is.
Linux, on the other hand, doesn't have a single standard for email or office productivity.
An interesting point, and one that brings attention to yet another consequence of the Microsoft monopoly: As Microsoft forces their applications to become the de facto standard, it gives virus/worm writers and script kiddies a single application they need to attack. As we have seen, this amplifies the effect these malicious code bits can have.
I posted yesterday a suggestion the Microsoft implement security levels for their macros and scripts; Instead of saying, "Do you want to run this macro?", ask, "Do you want to give this macro access to your address book?" With the attention that Outlook viruses have gotten, that should be enough to raise the suspicion of even casual users.
P.S. I'm waiting on the O'reilly book, Writing Viruses with Visual Basic Script.
What I think Microsoft, or anybody who has a macro language for their application, needs to implement is a "sandbox" or different security levels. Right now, it's all or nothing; Office may warn that the document contains a macro, and ask for permission to run it, but from there it becomes an "all or nothing" deal. The majority of legitimate macros will work only with the document in which they reside. They'll change the formatting, move paragraphs around maybe. It doesn't seem likely that a legitimate virus will need access to the file system, but if it does, the user should be prompted for permission. There should be a series of questions; i.e., "This document contains a macro. Do you want to grant it permission to run?" "...Do you want to grant it permission to delete the file 'whatever.doc' from you computer?" "...Do you want to grant it permission to access your address book?" While it might sound like an endless stream of such questions would get cumbersome, I maintain that the majority of legitimate macros will operate only within the current document, and won't want to access the file system or address book, so the annoyance would be infrequent.
Compare this to signed applets in Java. They work much the same way.
Slashdot Mirror
According to AOL itself, Quantum Computer Services (which later changed names to America Online) released its first online service, Q-link, for some unnamed Commodore computer. The first product with the AOL name was for Apple ][ and Macintosh. I don't know if I, as a Mac user, should be happy or embarrassed by this. (:
How 'bout, those who use an OS other than Windows are too smart to use AOL?
Seriously, though, I'm not convinced that the reason people aren't switching to Linux or *BSD has anything to do with AOL.
ah, yes, the darn SimpleText can't open the file because it's too big problem (akin to not being able to open a file in Notepad, though I believe it does automatically offer to open it in Wordpad). That's why the drag-and-drop is so useful, especially how it ties into the "this application can open these file types" list. While that limitation is annoying, I'll usually just drag a file to the BBEdit icon, which I'll keep either in the dock (in OS X) or in a tabbed folder (in OS 9). By the way...has Microsoft ever addressed the limitation in NT 4 where, if you drag an icon to a program on the task bar, it tells you you can't do that, and suggests some alternative? By including that warning, it's like they are saying, "Hey, we know you'd like to do that, and we know it's probably a good idea, but we still aren't going to let you!" I'd feel better if it was just something they looked over, rather than something they just refused to implement.
Another point about type/creator codes that Windows and Linux users may not know:
In addition to each file storing the type and creator code, but each application stores a list of file types that it can open. This is used by the Finder to allow a user to drag-and-drop a document icon to an application icon (including an application other than the one that originally created the document), as well as to build a list of possible applications when a user tries to open a document for which the creator is not available.
This honestly is one of the subtle features that adds to the ease of use of the Mac. Many of you will be skeptical, but I am certain that if you had the opportunity to work with a Mac in an open-minded fashion, you'd come to appreciate how smart this approach is.
An interesting point, and one that brings attention to yet another consequence of the Microsoft monopoly: As Microsoft forces their applications to become the de facto standard, it gives virus/worm writers and script kiddies a single application they need to attack. As we have seen, this amplifies the effect these malicious code bits can have.
I posted yesterday a suggestion the Microsoft implement security levels for their macros and scripts; Instead of saying, "Do you want to run this macro?", ask, "Do you want to give this macro access to your address book?" With the attention that Outlook viruses have gotten, that should be enough to raise the suspicion of even casual users.
P.S. I'm waiting on the O'reilly book, Writing Viruses with Visual Basic Script.
What I think Microsoft, or anybody who has a macro language for their application, needs to implement is a "sandbox" or different security levels. Right now, it's all or nothing; Office may warn that the document contains a macro, and ask for permission to run it, but from there it becomes an "all or nothing" deal. The majority of legitimate macros will work only with the document in which they reside. They'll change the formatting, move paragraphs around maybe. It doesn't seem likely that a legitimate virus will need access to the file system, but if it does, the user should be prompted for permission. There should be a series of questions; i.e., "This document contains a macro. Do you want to grant it permission to run?" "...Do you want to grant it permission to delete the file 'whatever.doc' from you computer?" "...Do you want to grant it permission to access your address book?" While it might sound like an endless stream of such questions would get cumbersome, I maintain that the majority of legitimate macros will operate only within the current document, and won't want to access the file system or address book, so the annoyance would be infrequent. Compare this to signed applets in Java. They work much the same way.