That's the problem. You still need whole files, and bittorrent blocks can span files. What can easily happend (and often does) is that no single file is complete until you get towards the very end. You have 80 partial files.
Umm.. no. BitTorrent works on the block level, not the file level. You end with with only parts of files. A partial rar is usless. You need the parity to be on the block level, not the file level.
Actually, if you read the actual research paper, you can see WHY it's faster. Basically, it combines two technologies. A bittorrent like protocol, and file parity generation (such as PAR). This allows you to generate additional pieces you didn't download and reduce the amount of code you need to download by about 20-30%.
This also solves "the last block" problem where everyone is waiting for the last block, since if you have 99% of the blocks you can generate what's left.
So you're saying the help system should be web server running on the local computer?
Funny, but MS did just that with Windows 2000 Server, and then after Code Red everyone said they were morons for enabling a web server by default.
Now, why should I have the overhead of a web server running all the time for help files I use only some of the time, if rarely ever?
Ok, so maybe you didn't mean a web server, but what other mechanism, that is cross browser supported, could be used to pass these files to a random browser? Temp files? You've got to be kidding. Kludge.
While that may be true, it doesn't mean that any browser *WILL* implement them. ActiveX, for example, is an open standard maintained by the Open Group.
Netscape briefly toyed with the concept of an online help engine, but abandoned it pretty quickly.
And off course, the MS help system couldn't work with any ol' browser you choose as default.
Actually, there's a very good reason for this, apart from any potential side benefit MS gains.
First, making the help system browser agnostic would mean that help files would have to be individual HTML pages, graphics, etc.. taking up an outrageous amount of disk space (especially when you consider sector slop). It would also mean people could go in and easily tamper with help files (assuming they had the right permissions). It also makes it very inconvenient to pass help files around (such as in the case of ebooks)..chm files are also compressed, and no other browser that i'm aware of provides a way to view pages in a compressed archive.
Second, there is no standard mechanism to support context sensative help in browsers. That is, no way for the OS to tell any given browser to go a specific page and section. The # feature of URL's is close, but not anywhere near granular enough. Thus, the context sensative feature couldn't work across all browsers, thus reducing the very "helpfulness" of the help files (I can already hear the snickers of derision).
Third, there are features of help files that are not supported by all browsers (or even any other browser) such as table of contents and indexing, not to mention search features. All these would require more advanced services and browser plug-ins specific to each browser.
Could you hack your way around most of these problems? Probably, but then it would be a collection of hacks that could break at any time.
Frankly, I think the MS help system is one of the best things MS has ever done. Forcing them to dismantle it to make it cross browser compatible would be a travesty.
Well, Lycoris was much more "major" a few years ago. Originally it was called Redmond Linux, and was using very Microsoft-esque imagery and logos. They were billing themselves as a clone of Windows on Linux.
Then, they abruptly changed their tune. Most likely they got some C&D's from Microsoft and they decided to change their name to Lycoris. While they were still going for a Windows-esque look and feel, they seemed to have lost some momentum, primarily after Lindows started to take off.
Make sure you remove the alternative user input on *ALL* Office programs (that means anything that appears in Add/Remove Programs, including OneNote, Publisher, FrontPage, whatever).
I have to wonder if what you're seeing is because the documents were generated by a third party program. It may be that the documents used formatting that worked under Word 95 but wasn't supported in Word 97 because Word 95 would have never created the documents that way.
That was most likely a different issue. Your printer drivers changed when you upgraded from Win 3.11 to Win95. This caused word to relayout the document.
I'll bet if you ran the exact same version of Word in Win95 you'd have seen the same results.
OSA loads COM and OLE DLL's into memory. These are DLL's provided by *WINDOWS*, not office. It did, once upon a time, help Office start faster because (in the Win9x and earlier days) OLE took forever to load. This hasn't been true since at least Windows 2000, and OSA is essentially useless and just wastes resources with no benefit.
In fact, Office 2003 no longer loads OSA on startup because of this. (The article is using Office 2003, btw).
Don't believe me? Try it yourself on an Office 2000 or XP installation. Do your benchmarks and then Remove the OSA shortcut from startup a test again, you won't see any meaningful differences that can't be accounted for by margin for error.
That depends entirely on why you are delivering them. While the newer versions of Acrobat have some facility for collaboration and group editing, it's not very friendly.
A very common scenario is that a document is sent around to 20 or so people and everyone makes their edits, then the edits are recombined into a master document and the process begins again.
Huh? I've *NEVER* seen a case where a later version of Word couldn't open an older version of Word's documents identically to the original.
The other way around is of course a problem. MS does aleviate this somewhat with document filters to load later versions but not all formatting can be back converted if the feature doesn't exist.
Apart from the fact that his load times don't seem to mesh with anyone elses (2-5 seconds is typical load time for Word, even on slow hardware). Here are some other nifty things that make this article entirely pointless.
First, he doesn't really know how to measure the amount of memory a program is using. He combines virtual memory and In process memory, but they can't be combined. Virtual memory is a closer approximation to the total memory being used. In memory memory is just the part of Virtual memory that is current in memory (it's sitll in virtual memory even if it's in real memory).
He uses the size of the installation on disk as some kind of indicator about how "bloated" the application is. This ignores the fact that Office comes with a great deal of clip-art, templates, and other non-application files. The actual amount of diskspace used by the application code for Office on my machine is 298 MB, but that includes the full office suite (including programs that have no equivelent in OOo such as InfoPath, Access and OneNote).
I liked this quote:
"The first thing I did was to install OO.o It took only 7.5 minutes and took up 164MB (94.82 according to Windows)."
94.82? WTF? Did he mean 194.82? Even that seems a bit large.
He gives lots of indications that his system is borked. His comment about normal.dot is a sure sign that something is wrong.
22 minutes to load a 4.9MB text file? That's completely outside the range of believable.
Whether or not OpenOffice uses COM for it's primary component model is irrelevant. It still uses COM, and therefore it still loads the DLL's into memory, thus it suffers the same "performance hit" that Office does or doesn't have.
The author was using Office 2003. Office 2003 removed the feature you're talking about. Why? Because it hasn't really effected load times in years.
And yes, Word 2003 takes 2 seconds to load the first time on hardware similar to the authors. It takes about 5 seconds to load on my dog slow Pentium 750 Laptop.
30 seconds is either an outright fabrication or he has something else in his system that is severely effecting the startup, yet somehow doesn't seem to effect OOo (which starts faster on his system than it starts on my Athlon 64 3500+. Strange that.).
Why does this rumor persist? Office has never loaded any part of itself into memory at startup. Ever.
What you are referring to (and was removed from Office 2003 because it's no longer really useful) was the Office Startup Assistant (OSA). What this did was autoload the *COM* DLL's into memory (these are system DLL's that many applications use, not just Office) to improve startup. These DLL's, back in the Windows 3.1, 95, 98 era took a long time to load, but this isn't the case anymore.
This feature hasn't really effected startup times for at least 5 or 6 years (which is why I always removed it from the startup) because Windows already loads the COM subsystem into memory for other things.
While it's still true that this speeds up office load times, it also speeds up OOo load time because OOo also relies on COM for some things.
Strange. Exchange doesn't use the Send and Receive mechanism. That's used for POP and Imap mail. This suggests a serious misconfiguration on the part of your administrator.
I cant point outlook to my webdav folder and tell it to work with the calendar that I access on multiple machines.
Umm.. yes, actually, you can. Well, actually, Outlook can use Exchange, which provides a WebDAV interface to mail and other data (including calendering). This makes your schedule available via WebDAV and via Outlook as well.
Remote Desktop and Remote Assistance, Shadow Copy Service, WebDAV (Web Client) Support, Concurrent Console Users (Fast User Switching), Camera and scanning wizard, System Restore Points, Driver Rollback, Side by Side DLL support, Windows Firewall, DualView (ability to have the display on both the screen and a projector or TV), Synchronization Manager, Automatic Update (this was later added to Win2k), and a bunch of other stuff I can't think of right now.
Slashdot Mirror
That's the problem. You still need whole files, and bittorrent blocks can span files. What can easily happend (and often does) is that no single file is complete until you get towards the very end. You have 80 partial files.
Wow, do you always like to show your ignorance and gullibility at believing rumors?
/ 020318oplivingston.html
; en-us;Q316666
http://www.infoworld.com/articles/op/xml/02/03/18
http://support.microsoft.com/default.aspx?scid=kb
Umm.. no. BitTorrent works on the block level, not the file level. You end with with only parts of files. A partial rar is usless. You need the parity to be on the block level, not the file level.
Actually, if you read the actual research paper, you can see WHY it's faster. Basically, it combines two technologies. A bittorrent like protocol, and file parity generation (such as PAR). This allows you to generate additional pieces you didn't download and reduce the amount of code you need to download by about 20-30%.
This also solves "the last block" problem where everyone is waiting for the last block, since if you have 99% of the blocks you can generate what's left.
It's an interesting approach.
But apparently your reading comprehension isn't "just fine".
Duh. What exactly do you think "temp files" was in my message?
So you're saying the help system should be web server running on the local computer?
Funny, but MS did just that with Windows 2000 Server, and then after Code Red everyone said they were morons for enabling a web server by default.
Now, why should I have the overhead of a web server running all the time for help files I use only some of the time, if rarely ever?
Ok, so maybe you didn't mean a web server, but what other mechanism, that is cross browser supported, could be used to pass these files to a random browser? Temp files? You've got to be kidding. Kludge.
That's really your ownly two choices.
While that may be true, it doesn't mean that any browser *WILL* implement them. ActiveX, for example, is an open standard maintained by the Open Group.
Netscape briefly toyed with the concept of an online help engine, but abandoned it pretty quickly.
And off course, the MS help system couldn't work with any ol' browser you choose as default.
.chm files are also compressed, and no other browser that i'm aware of provides a way to view pages in a compressed archive.
Actually, there's a very good reason for this, apart from any potential side benefit MS gains.
First, making the help system browser agnostic would mean that help files would have to be individual HTML pages, graphics, etc.. taking up an outrageous amount of disk space (especially when you consider sector slop). It would also mean people could go in and easily tamper with help files (assuming they had the right permissions). It also makes it very inconvenient to pass help files around (such as in the case of ebooks).
Second, there is no standard mechanism to support context sensative help in browsers. That is, no way for the OS to tell any given browser to go a specific page and section. The # feature of URL's is close, but not anywhere near granular enough. Thus, the context sensative feature couldn't work across all browsers, thus reducing the very "helpfulness" of the help files (I can already hear the snickers of derision).
Third, there are features of help files that are not supported by all browsers (or even any other browser) such as table of contents and indexing, not to mention search features. All these would require more advanced services and browser plug-ins specific to each browser.
Could you hack your way around most of these problems? Probably, but then it would be a collection of hacks that could break at any time.
Frankly, I think the MS help system is one of the best things MS has ever done. Forcing them to dismantle it to make it cross browser compatible would be a travesty.
Well, Lycoris was much more "major" a few years ago. Originally it was called Redmond Linux, and was using very Microsoft-esque imagery and logos. They were billing themselves as a clone of Windows on Linux.
Then, they abruptly changed their tune. Most likely they got some C&D's from Microsoft and they decided to change their name to Lycoris. While they were still going for a Windows-esque look and feel, they seemed to have lost some momentum, primarily after Lindows started to take off.
Microsoft has a knowledge base article on how to remove it. I always get rid of it because I don't use any language input features.
http://support.microsoft.com/?kbid=282599
Make sure you remove the alternative user input on *ALL* Office programs (that means anything that appears in Add/Remove Programs, including OneNote, Publisher, FrontPage, whatever).
I have to wonder if what you're seeing is because the documents were generated by a third party program. It may be that the documents used formatting that worked under Word 95 but wasn't supported in Word 97 because Word 95 would have never created the documents that way.
That was most likely a different issue. Your printer drivers changed when you upgraded from Win 3.11 to Win95. This caused word to relayout the document.
I'll bet if you ran the exact same version of Word in Win95 you'd have seen the same results.
Call whatever you like. You're wrong.
OSA loads COM and OLE DLL's into memory. These are DLL's provided by *WINDOWS*, not office. It did, once upon a time, help Office start faster because (in the Win9x and earlier days) OLE took forever to load. This hasn't been true since at least Windows 2000, and OSA is essentially useless and just wastes resources with no benefit.
In fact, Office 2003 no longer loads OSA on startup because of this. (The article is using Office 2003, btw).
Don't believe me? Try it yourself on an Office 2000 or XP installation. Do your benchmarks and then Remove the OSA shortcut from startup a test again, you won't see any meaningful differences that can't be accounted for by margin for error.
That depends entirely on why you are delivering them. While the newer versions of Acrobat have some facility for collaboration and group editing, it's not very friendly.
A very common scenario is that a document is sent around to 20 or so people and everyone makes their edits, then the edits are recombined into a master document and the process begins again.
Huh? I've *NEVER* seen a case where a later version of Word couldn't open an older version of Word's documents identically to the original.
The other way around is of course a problem. MS does aleviate this somewhat with document filters to load later versions but not all formatting can be back converted if the feature doesn't exist.
Apart from the fact that his load times don't seem to mesh with anyone elses (2-5 seconds is typical load time for Word, even on slow hardware). Here are some other nifty things that make this article entirely pointless.
First, he doesn't really know how to measure the amount of memory a program is using. He combines virtual memory and In process memory, but they can't be combined. Virtual memory is a closer approximation to the total memory being used. In memory memory is just the part of Virtual memory that is current in memory (it's sitll in virtual memory even if it's in real memory).
He uses the size of the installation on disk as some kind of indicator about how "bloated" the application is. This ignores the fact that Office comes with a great deal of clip-art, templates, and other non-application files. The actual amount of diskspace used by the application code for Office on my machine is 298 MB, but that includes the full office suite (including programs that have no equivelent in OOo such as InfoPath, Access and OneNote).
I liked this quote:
"The first thing I did was to install OO.o It took only 7.5 minutes and took up 164MB (94.82 according to Windows)."
94.82? WTF? Did he mean 194.82? Even that seems a bit large.
He gives lots of indications that his system is borked. His comment about normal.dot is a sure sign that something is wrong.
22 minutes to load a 4.9MB text file? That's completely outside the range of believable.
Whether or not OpenOffice uses COM for it's primary component model is irrelevant. It still uses COM, and therefore it still loads the DLL's into memory, thus it suffers the same "performance hit" that Office does or doesn't have.
Unfortunately, no. His times were not for his large document as his large document times were listed as 22 *MINUTES* to load.
The author was using Office 2003. Office 2003 removed the feature you're talking about. Why? Because it hasn't really effected load times in years.
And yes, Word 2003 takes 2 seconds to load the first time on hardware similar to the authors. It takes about 5 seconds to load on my dog slow Pentium 750 Laptop.
30 seconds is either an outright fabrication or he has something else in his system that is severely effecting the startup, yet somehow doesn't seem to effect OOo (which starts faster on his system than it starts on my Athlon 64 3500+. Strange that.).
Why does this rumor persist? Office has never loaded any part of itself into memory at startup. Ever.
What you are referring to (and was removed from Office 2003 because it's no longer really useful) was the Office Startup Assistant (OSA). What this did was autoload the *COM* DLL's into memory (these are system DLL's that many applications use, not just Office) to improve startup. These DLL's, back in the Windows 3.1, 95, 98 era took a long time to load, but this isn't the case anymore.
This feature hasn't really effected startup times for at least 5 or 6 years (which is why I always removed it from the startup) because Windows already loads the COM subsystem into memory for other things.
While it's still true that this speeds up office load times, it also speeds up OOo load time because OOo also relies on COM for some things.
Strange. Exchange doesn't use the Send and Receive mechanism. That's used for POP and Imap mail. This suggests a serious misconfiguration on the part of your administrator.
Hmm.. there must be something wrong because Outlook 2003 is faster than any previous version everywhere i've used it.
I cant point outlook to my webdav folder and tell it to work with the calendar that I access on multiple machines.
Umm.. yes, actually, you can. Well, actually, Outlook can use Exchange, which provides a WebDAV interface to mail and other data (including calendering). This makes your schedule available via WebDAV and via Outlook as well.
No, Shadow Copy was introduced with XP. WebDAV (Web Client) support also came with XP. IE had WebDAV support, but not the Web Client service.
2000 had preliminary SxS support, but XP is where it was really implmented.
While it's true that lots of drivers had DualView features, it wasn't a standard feature of the OS until XP.
And, of course, the whole point of my inclusion of Camera and Scanning was the wizard, not the support itself.
Remote Desktop and Remote Assistance, Shadow Copy Service, WebDAV (Web Client) Support, Concurrent Console Users (Fast User Switching), Camera and scanning wizard, System Restore Points, Driver Rollback, Side by Side DLL support, Windows Firewall, DualView (ability to have the display on both the screen and a projector or TV), Synchronization Manager, Automatic Update (this was later added to Win2k), and a bunch of other stuff I can't think of right now.