I ran across a bug report a while back which claimed that the Shell class on Windows was broken. Thankfully, the reporter was nice enough to enter what client app he was running which made him think the Shell class was broken on Windows. The culprit in this case was Microsoft's ftp app. The issue was that no output could be read from the app, even though it appeared that sending input to it worked just fine. The short answer to this issue is Microsoft's ftp app uses Console Input/Output. The technical details are...
On Windows there are two approaches to console I/O. In Microsoft's terms, there's the high-level approach which enables simple character stream I/O, or the low-level approach which gives the app more flexibility and access to the console's input and screen buffers. Microsoft's ftp app uses low-level console I/O which means it is directly poking the characters to the console instead of streaming it through the standard I/O mechanism. There is no way for our Shell class to pick up the low-level console output that the ftp app is sending so what you get back is nothing, which is what this particular user was encountering. Notice that Microsoft's telnet app also uses low-level console I/O.
So what's the solution? Well for those adventurous enough to explore this further you could spawn the ftp app in a hidden console window and read its input using the low-level console I/O functions as described here: http://msdn.microsoft.com/en-us/library/ms684965(VS.85).aspx
However, for most people I'd suggest finding some good REALbasic ftp classes or adjust the way you're using the ftp client (maybe you don't need it to be interactive. Microsoft's ftp app can be scripted quite easily). You could also try to find a different ftp app that doesn't use low-level console I/O.