Firefox breaks the space time continuum!
-
Yep, another nutty download manager.
Looks like this one accidentally filled up its progress bar, panicked, and then attempted time travel to go back and fix the problem.
Speaking of progress bars (yep, OT already), has anyone else found it strange how Windows Explorer's FTP stuff spends more time needlessly calculating how long it will take to upload a tiny file than it takes to actually upload the file?
-
Windows Explorer is crap in many ways, though not all.
It's not just FTP stuff, it's most networking stuff that's horribly sluggish in the GUI. Partially because of Explorer's insanely long timeouts (20 seconds! Dude!), and the large volumes of file metadata transferred.
-
You type \machinename in Explorer and then forget about it. Nothing justifies waiting minutes for Explorer to say that the machine name I entered could not be found or is offline.
-
@mercurysquad said:
You type \machinename in Explorer and then forget about it. Nothing justifies waiting minutes for Explorer to say that the machine name I entered could not be found or is offline.
Well, this is what actually happens (Java-like pseudocode):try {
address = resolve(name);
}
catch (NotFoundException n) {
try {
address = resolve_with_some_compatibility_hacks(name, 30) ; // 30=timeout
}
catch (NotFoundException n) {
address = resolve_with_more_hacks(name, 60) ; // 60=timeout
}
}
</sarcasm>
-
Or when you try to copy a bunch of files (I have a collection of Dilbert comics, 4000 files that are 10K each) it spends 20 minutes "preparing to copy" in which it scans all of the files to decide how to fill the progress bar, then it ignores that data and asks you if you want to "move thumbs.db because its a system file" anyway! you can't let it copy unsupervised, even after waiting for it to enumerate the files! Grarrrr!!!!
On a related note, this textbox is really slow too (it takes 3-5 seconds for my keystrokes to respond) (IE6, XP Tablet 2005) The code seems to be:
<FONT face="Courier New">Do
Sleep 5000
If KbdBuffer.Length > 0 Then
Textbox.Text += KbdBuffer.GetText
End If
Loop</FONT>
-
@ammoQ said:
@mercurysquad said:
You type \machinename in Explorer and then forget about it. Nothing justifies waiting minutes for Explorer to say that the machine name I entered could not be found or is offline.
Well, this is what actually happens (Java-like pseudocode):try {
address = resolve(name);
}
catch (NotFoundException n) {
try {
address = resolve_with_some_compatibility_hacks(name, 30) ; // 30=timeout
}
catch (NotFoundException n) {
address = resolve_with_more_hacks(name, 60) ; // 60=timeout
}
}
</sarcasm>
Yeah, that seems about right.
And I have SOME application (Lord only knows what) on my work laptop that is registered to a network machine IN my office.
So if I'm ever AWAY from my office, (just about) everything takes an extra 60 seconds to do.
Click 'Start', (wait 60)
Click 'Programs' (wait 60), etc.
Press 'Window-E' for an explorer. (wait 60).
Move between most local folders, Thats ok.
Right Click on a file (wait 60)
'Open With...', (wait 60).
Defenistrate from second floor. (32 ft/sec sq. = wait 0.85 for satisfying crunch.)
-
@marvin_rabbit said:
Defenistrate from second floor. (32 ft/sec sq. = wait 0.85 for satisfying crunch.)
Now that's using windows!
-
@marvin_rabbit said:
Defenistrate from second floor. (32 ft/sec sq. = wait 0.85 for satisfying crunch.)
Best conversational use of defenistrate ... ever.
-
@ender said:
Anyway, my biggest gripe with progress bars is the Windows Installer (MSI) - that stupid thing seems to use the progress bar just to tell you "hey, look, I'm doing [i]something[/i]!" - and just keeps refilling it (the absolute record in this regard is one of the service packs for Office 2000 when you install it on Windows 98 - I counted 15 times for the progress bar to fill, then the computer reboots, then it fills another 6 times [when you have a summer job that requires you to do this on 25 computers, you kinda notice it]).
Quite honestly, Windows Installer is a WTF in itself. If you need to do anything more complex than basic operations, you've got a lot of work ahead of you. I once worked on a Windows Installer project that took several months to get working correctly, and even then had numerous problems in the field. It took about 3 days to convert entirely into InstallShield (non-MSI) code, and worked flawlessly.
The reason that Windows Installer does the progress bar multiple times is that there are multiple stages during the install. There's the preparing stage, the main action stage, and the cleanup stage. Each one has its own turn to fill up the status bar.
I agree it's stupid, but that's just how it works.
-
@ammoQ said:
@mercurysquad said:
You type \machinename in Explorer and then forget about it. Nothing justifies waiting minutes for Explorer to say that the machine name I entered could not be found or is offline.
Well, this is what actually happens (Java-like pseudocode):try {
address = resolve(name);
}
catch (NotFoundException n) {
try {
address = resolve_with_some_compatibility_hacks(name, 30) ; // 30=timeout
}
catch (NotFoundException n) {
address = resolve_with_more_hacks(name, 60) ; // 60=timeout
}
}
</sarcasm>
From reading <http://blogs.msdn.com/oldnewthing/archive/2006/03/30/564809.aspx>this</a>, and subsequent articles on the same topic... probably.
To be fair, I should add that Microsoft has promised to fix a lot of this behaviour in Vista, namely the fallback lookup on name resolution failure and single-threaded and brain-dead file-copy.
-
Couldn't some bright mind at Microsoft have added some sort of an option in a control panel applet to change this behaviour of 10 "fallback" hacks, each with 30 second timeouts? I wonder if employees at Microsoft use explorer themselves, or is it something else that they use. Cuz I can't see how something so obviously annoying has passed right up to Win XP SP2.
Same with deleting files, for example. Try to delete a bunch of files (say, temporary files), and if there's one file in use, the whole operation crashes down in the middle. The most logical thing would be to continue with the next file, isnt it. Or try copying a group of files, and if there's a read error with one file, the copy operation decides to abort. I'm sure more elegant/logical ways are possible to deal with read/write errors.
-
@eimaj2nz said:
@ender said:
Anyway, my biggest gripe with progress bars is the Windows Installer (MSI) - that stupid thing seems to use the progress bar just to tell you "hey, look, I'm doing [i]something[/i]!" - and just keeps refilling it (the absolute record in this regard is one of the service packs for Office 2000 when you install it on Windows 98 - I counted 15 times for the progress bar to fill, then the computer reboots, then it fills another 6 times [when you have a summer job that requires you to do this on 25 computers, you kinda notice it]).
Quite honestly, Windows Installer is a WTF in itself. If you need to do anything more complex than basic operations, you've got a lot of work ahead of you. I once worked on a Windows Installer project that took several months to get working correctly, and even then had numerous problems in the field. It took about 3 days to convert entirely into InstallShield (non-MSI) code, and worked flawlessly.
The reason that Windows Installer does the progress bar multiple times is that there are multiple stages during the install. There's the preparing stage, the main action stage, and the cleanup stage. Each one has its own turn to fill up the status bar.
I agree it's stupid, but that's just how it works.Could be worse - the Wine folks have to accurately reproduce Windows Installer, WTFs and all...
-
@makomk said:
@eimaj2nz said:
Quite honestly, Windows Installer is a WTF in itself. If you need to do anything more complex than basic operations, you've got a lot of work ahead of you. I once worked on a Windows Installer project that took several months to get working correctly, and even then had numerous problems in the field. It took about 3 days to convert entirely into InstallShield (non-MSI) code, and worked flawlessly.
The reason that Windows Installer does the progress bar multiple times is that there are multiple stages during the install. There's the preparing stage, the main action stage, and the cleanup stage. Each one has its own turn to fill up the status bar.
I agree it's stupid, but that's just how it works.Could be worse - the Wine folks have to accurately reproduce Windows Installer, WTFs and all...
[b]Beware: desktop-application-creation-oblivious reply ahead[/b]
But isn't that just because Setup-makers rely on an MSI-api-thing to modify the system (as in, "[i]give me a progress bar here[/i]" or "[i]Display License Agreement Text; disable Next Until checkbox 'accepted' checked[/i]" etc)?
Can't WINE simply mimic that API and make it go [i]vroom[/i] under the hood?
