Perl for Win32 Frequently Asked Questions (FAQ)

8.1. How do I change the Win32 registry?

There are several Win32 registry functions provided with Perl for Win32. Check the win32mod document provided with Perl for Win32.

If you don't understand how the registry works, remember that a *key* is like a directory, and a *value* is like a file. There are several *top*level*keys*, and these are kind of like drives.

Named pipes are a inter-process communcations mechanism, mainly used with Microsoft operating systems (like Win32 platforms). A named pipe can be addressed just like a file.

The name of a named pipe is a UNC (Universal Naming Convention) name, and looks like "\\servername\pipe\pipename". "servername" is the name of the server you're connecting to, or "." for the current computer. "pipe" is a constant, and "pipename" is the name of the pipe, such as "sql" for Microsoft SQL Server.

You can use open(), close(), read(), and print() on a named pipe just like a file. However, you can't use sysread() or syswrite() on one, because they aren't really files.

There's a program called Win32Pipe on the CPAN archive that can be used to create a named pipe.

There are several examples of socket scripts that are distributed with Perl for Win32. They're in the eg subdirectory of your perl directory.

There's an example of a socket server, TCP-SERVER, in the eg directory of your perl directory. In general, information on socket programming for UNIX is applicable to Perl for Win32. See especially the perlipc page of the documentation.

Note that using Perl for Win32 is *not* a good way to implement a server, since you will only be able to service one client at once. This is because a) Perl, the language, doesn't support threads, and b) Perl for Win32 doesn't support the fork() function.

There's an ftp.pl file in the lib directory of the perl subdirectory, but it doesn't work, since it depends on alarm() and select() calls that aren't available in Perl for Win32. Net::FTP, from the CPAN archive, also appears not to work. [Anyone have better information? -ESP]

Thus, you have several possibilities for doing FTP. You can fix the ftp.pl script so that it works for Perl for Win32 [If you do, please share it! -ESP]. You can get a copy of the FTP specification and hand- code the module from scratch.

The quick-and-dirty solution is to compile a script for the FTP program that comes with Windows NT [and Windows 95? -ESP]. You can then execute the FTP program, passing this script as a parameter. See the FTP program's help file for more details. Yes, I know, it's a real ugly solution, but it works.

Again, the CPAN solution would be to use libwww. However, to work under Perl for Win32, libwww must be altered. See the information at this URL:

Serial ports can be opened just like files in Perl for Win32. To open COM1, just do this:

    open( PORT, "+>COM1" ) or die "Can't open COM1: $!";

You should be able to read from and write to the file handle using the standard I/O functions (read() and print()), but not the system functions (sysread() and syswrite()). [Anyone done this? Does it really work? Caveats? -ESP]

It does, in fact, work. However, people tend to use it incorrectly and get bad results. To check for all the sub-directories in a directory, try code like this:

    $path = shift;
    $path = "." unless $path;

    opendir( DIR, $path )
      or die "Can't open $path: $!";

    while ( $entry = readdir( DIR ) )
    {
      $type = ( -d "$path\\$entry" ) ? "dir" : "file"; # $path is crucial!
  
      print "$type\t$entry\n";
    }

    closedir( DIR );

On Win32 platforms, there's a big difference between text files and binary files. For text files, the "\r\n" characters are translated into "\n" when read from disk, and the ^Z character is read as an end-of-file marker. For binary files, no such translation is used.

Although this works great for text files, it really messes things up when you're trying to read and write binary files. If the read or write does not abort prematurely because a ^Z was found in the file, you will almost definitely get incorrect bytes in the file due to \n -> \r\n translation.

The problem is that Perl for Win32, and the C runtime library it uses, open file in text mode by default. For each file handle you use in Perl for binary data, you need to specify that the file handle is in binary mode. Fortunately, there's a function, binmode, that does just that. See the perlfunc documentation file for details.

This script copies one binary file to another. Note its use of binmode to set the mode of the file handle.

    open( INFILE, "<$infile" );
    open( OUTFILE, ">$outfile" );

    binmode( INFILE ); binmode( OUTFILE ); # crucial for binary files!

    while ( read( INFILE, $buffer, 1024 ) )
    {
      print OUTFILE $buffer;
    }

    close( INFILE ); close( OUTFILE );

8.12. When I try to open a file, I get a "bad argument" error. What gives?

Win32 platforms use the '\' character as a delimiter for paths in a file name (C:\like\this). However, Perl uses the '\' character as an escape code, to symbolize a special character like the line feed character ("\n") or the tab character ("\t").

So, if you try and open a file like this:

    open( MYFILE, "C:\temp\newfile.txt" );

you'll get an error. One solution is to replace each '\' with a double-'\', to show that you really mean to use that character, not an escape:

    open( MYFILE, "C:\\temp\\newfile.txt" );

Another solution is to use non-interpolating single quote strings, which lets Perl know not to use any special characters:

    open( MYFILE, 'C:\temp\newfile.txt' );

This is a weird error that occurs when your string terminator is on the last line of your script. With a script like:

    print <<"END";
    The snake is old, and his skin is cold.
    END

perl is looking for the word "END" on a line by itself, followed by a line-feed character ("\n"). If the "END" is the last line of your script, you have to remember to hit <Enter> after the word "END", so that Perl can recognize it as the string terminator.

Most UNIX text editors will do this automatically. Most Windows text editors won't. Thus the problem.

Note that this can also cause a problem with Perl formats, since these are terminated with a single "." on a line by itself. However, it's much more rare, since programmers often specify the format for output at the top rather than at the bottom of a file.