Comment Re:Finally! (Score 1) 233
> But it seemed like there were two implementations of DCC.
> The "right" way, which most Unix-based IRC clients did,
> and the "backwards" way, which Mirc did. I never seemed
> to have any problems with DCC sends when using a
> Unix-based IRC client but it always seemed like I would
> have to stand on my head and chant voodoo chants when
> trying to use Mirc.
Yeah, I've noticed the same problems... IMHO, the mIRC people screwed up big time when they decided to replace their old DCC system with a new one. Whenever I try to receive a file from a *nix or other 'standard' client now, more times than not, the remote end reads a successful send while my end (the mIRC end) reads an incomplete file and quits because they aren't handshaking properly. Switch to my other computer with an older mIRC with the older DCC system in it and they work flawlessly.
I simply don't understand why they felt the need to fix something that wasn't broken to begin with and ended up with something broken. I never had problems with failed DCC's not timing out under the old system. Under the new one? A failed resume will sit there on my screen for hours and hours and maybe timing out. If someone sends me a DCC using the IP of 127.0.0.1, or another reserved local IP that my LAN uses internally? THEY NEVER EVER TIME OUT! On top of that, the old DCC system wasn't succeptible to that DCC exploit that the new DCC system was. Don't get me started on the larger DCC windows either. The old ones I was able to keep so small they never blocked anything on the screen, the new ones are huge and UGLY! /me sighs...
Why is it whenever any author updates their programs to make it better, I end up losing the things about it I liked most... like being able to set priority levels for programs in Win311 right in the PIF file for example.
This ends Smoovious' Rant-of-the-Day...
-- Smoovious
> The "right" way, which most Unix-based IRC clients did,
> and the "backwards" way, which Mirc did. I never seemed
> to have any problems with DCC sends when using a
> Unix-based IRC client but it always seemed like I would
> have to stand on my head and chant voodoo chants when
> trying to use Mirc.
Yeah, I've noticed the same problems... IMHO, the mIRC people screwed up big time when they decided to replace their old DCC system with a new one. Whenever I try to receive a file from a *nix or other 'standard' client now, more times than not, the remote end reads a successful send while my end (the mIRC end) reads an incomplete file and quits because they aren't handshaking properly. Switch to my other computer with an older mIRC with the older DCC system in it and they work flawlessly.
I simply don't understand why they felt the need to fix something that wasn't broken to begin with and ended up with something broken. I never had problems with failed DCC's not timing out under the old system. Under the new one? A failed resume will sit there on my screen for hours and hours and maybe timing out. If someone sends me a DCC using the IP of 127.0.0.1, or another reserved local IP that my LAN uses internally? THEY NEVER EVER TIME OUT! On top of that, the old DCC system wasn't succeptible to that DCC exploit that the new DCC system was. Don't get me started on the larger DCC windows either. The old ones I was able to keep so small they never blocked anything on the screen, the new ones are huge and UGLY!
Why is it whenever any author updates their programs to make it better, I end up losing the things about it I liked most... like being able to set priority levels for programs in Win311 right in the PIF file for example.
This ends Smoovious' Rant-of-the-Day...
-- Smoovious
