Welcome to the world of Windows, where nothing works right. The problem here is that Windows has two modes for reading files: one is text mode, the other binary mode.

Windows needs this because the standard I/O library, as it is supposed to, translates your machine's line endings into a \n for the C programs that manipulate data. Perl is written in C and uses the standard I/O library, so it happens. And we want it to--otherwise any program that wanted to print or read a line would have to know about all the different systems' line endings.

Text mode is where line ending conversion happens. Binary mode is where it doesn't. If you're not reading a text file, but instead a binary file that happens to have a pair of characters in it that are the Windows line ending set, you don't want the stdio library rewriting your binary data! Binary mode good.

However, that text/binary distinction also affects end of file. Windows has this stupid half-assed file system that keeps the length of the file in the directory entry, but also will return end of file when you're reading the file in text mode and have read a Ctrl-Z byte. So even though it knows full well by the directory entry that you haven't read all the data in the file, it's happy to pretend you have when you encounter the Ctrl-Z. The only reason I can think of for this is that on the console you have to be able to indicate EOF, and they use Ctrl-Z for this, so perhaps a naive implementation of it carried the Ctrl-Z bug over to non-terminal files as well? Who knows.

So that's what you're running into. Your binary image data happens to have a Ctrl-Z byte in it, and that's prematurely ending your read. The solution is to say

  binmode(IMG);
[download]

after you open the IMG filehandle. It doesn't change the behaviour on Unix, but makes it work right on Windows. sigh.