it would appear , that when mirc gets the size of a file, for dcc send, it is only using the low order dword of the return.
When attempting to dcc send a dvd image 4.19 GB (4,499,464,192 bytes), mirc only "see" 195MB of size (which is roughly what would be the remainder in the low order return), and so attempts to send a 195mb file.
Indeed, if i had been able to find that post I wouldnt have bothered, but I highly disagree with their diagnosis.. Its not a limitation; windows provides the correct file size via EAX (low order) and a return buffer (high order) .. mirc simply ignores the high order data provided by the windows API - hence flawed coding, hence a bug which results in erroneous file sizes displayed/sent. He didnt even bother to send a silly message "this file is too big". yes its a bug.
It really wouldnt take THAT much work to fix it... and it wouldnt require 64bit processing to send the file in its entirety
Have you considered if the dcc protocol allows for that much data to be sent in a stream? From memory the size of file recived so far is returned as a bigended dword, so gfetting a file larger than it might (well) pose problems.
(ps I been up a while, but im pretty sure i remebnr this correctly)
Have you considered if the dcc protocol allows for that much data to be sent in a stream? From memory the size of file recived so far is returned as a bigended dword, so gfetting a file larger than it might (well) pose problems.
(ps I been up a while, but im pretty sure i remebnr this correctly)
Even if it wouldn't, an error message or at least a warning would be appropriate.