I'm not quite sure what behavior you're trying to get out of this. ASCII (text) files are, by their very nature, different than binary files not only in that they tend to contain only readable data, but this data is broken up into multiple lines. Each OS handles newlines differently, as I'm sure you know. Tools written for one OS should (for major compatibility reasons) adapt to that OS's mechanism for interpreting newlines (as Perl does with \n). If you are using tools under Windows that work with text files yet do not honor Windows' newline convention, I would consider that a bug with the tools.

Along the same line, if you FTP files from one OS to another, you do so using the ASCII protocol, which correctly adapts your text file's newlines to match the conventions of the other OS, so that tools on the new OS can correctly read the lines of your file. Again, if the new OS incorrectly uses conventions from your source OS instead of the newline conventions of the OS they're running on, that is anomalous behavior that should be corrected.

If you truly need Perl to treat a file as anything but a simple text file (allowing you to set your own newline conventions), you should use binmode and treat the file as a binary file:

binmode(FH);
local $/ = "\cM\cJ";  # CRLF
print FH "A line of pseudo-ASCII text$/";
while (<FH>) { 
   # This might actually work, given that it honors $/
}
[download]

If you do something like this, avoid \n, which literally means "newline", which will behave differently under different operating systems, counter to what you seem to want.