Looking at the ActiveState sources, it seems 5.8.3 had the first Win32 implementation of alarm(). Here's the changelog comment -

[ 21901] By: nicholas              on 2003/12/13  21:22:15
        Log: Integrate:
             ...
             
             [ 21895]
             alarm() is now implemented on Win32.
             
             ...
[download]

And from looking inside win32.c it seems that win32_alarm() uses SetTimer.

And yes, the behaviour of SetTimer has changed from Win 2000 to Win 2003

On 2000 if the timeout "is greater than USER_TIMER_MAXIMUM, the timeout is set to 1."

On 2003 SP1 if the timeout "is greater than USER_TIMER_MAXIMUM, the timeout is set to USER_TIMER_MAXIMUM."

That might be your problem, maybe.

15.7.1. Problem You want to sound an alarm on the user's terminal.

15.7.2. Solution
Print the "\a" character to sound a bell: 

print "\aWake up!\n";
Or use the "vb" terminal capability to show a visual bell:

use Term::Cap;

$OSPEED = 9600;
eval {
    require POSIX;
    my $termios = POSIX::Termios->new( );
    $termios->getattr;
    $OSPEED = $termios->getospeed;
};

$terminal = Term::Cap->Tgetent({OSPEED=>$OSPEED});
$vb = "";
eval {
    $terminal->Trequire("vb");
    $vb = $terminal->Tputs('vb', 1);
};

print $vb;                                  # ring visual bell
15.7.3. Discussion
The "\a" escape is the same as "\cG", "\007", and "\x07". They all cor
+respond to the ASCII BEL character and cause an irritating ding. In a
+ crowded terminal room at the end of the semester, this beeping cause
+d by dozens of vi novices all trying to get out of insert mode at onc
+e can be maddening. The visual bell is a workaround to avoid irritati
+on. Based upon the polite principle that terminals should be seen and
+ not heard (at least, not in crowded rooms), some terminals let you b
+riefly reverse the foreground and background colors to give a flash o
+f light instead of an audible ring.

Not every terminal supports the visual bell, which is why we eval the 
+code that finds it. If the terminal doesn't support it, Trequire will
+ die without having changed the value of $vb from "". If the terminal
+ does support it, the value of $vb will be set to the character seque
+nce to flash the bell.

There's a better approach to the bell issue in graphical terminal syst
+ems like xterm. Many of these let you enable the visual bell from the
+ enclosing application itself, allowing all programs that blindly out
+put a chr(7) to become less noisy.
[download]

Thanks, I've started rewriting my programs with Win32::Process::Create(), and Wait(), and that's solved my problem. I have never examined the return values from alarm(), so it may not have been fully functional, but was quite useful nonetheless. The problem with Windows 2003 is that the timeout never occurs. I used it when calling processes that risk hanging. For example some proprietary so-called 'batch' routines that stupidly report errors with alert boxes. I started a countdown with alarm() based on expected time-to-complete, and if it timed out before the process returned, I'd kill the process to get rid of the alert box. If not, I'd cancel it with alarm(0); I also used it with Openwebload (from Sourceforge) which calls a GIS web site every few minutes and examines the result to see if a map was actually generated as a result of the call (if not, it restarts various processes). Unfortunately, if IIS is not running, Openwebload gets into an endless loop consuming 100% of CPU resources, and here alarm() was a useful safety valve allowing me to break out and kill it. So Win32::Process::Create(), and Wait() now do this, and it works fine. It will take me a while to rewrite all my scripts, though, so it is a pity that Windows 2003 has broken some useful (partially implemented) perl functions. thanks, David