And on that very page they say:

Drop handlers are registered under the file class's HKEY_CLASSES_ROOT\ProgID\Shellex\DropHandler subkey. Create a subkey of DropHandler named for the handler, and set the subkey's default value to the string form of the handler's CLSID GUID.

(emphasis mine) which confirms what I said ! (But I was too lazy to check MSDN - thanks for ref ++but I ran out of votes!) So though the Perl script itself doesn't have a CLSID, file extension .pl is registered to type perl which can have a shell extension drop handler registered by placing it in Shellex\DropHandler.

My remaining question is whether the .exe drop handler I blithely copied across is safe to use with Perl scripts or whether we need to wait for ActiveState as you suggested.

Cheerio!
Osfameron

And on that very page they say: Drop handlers are registered under the file class's HKEY_CLASSES_ROOT\ProgID\Shellex\DropHandler subkey. Create a subkey of DropHandler named for the handler, and set the subkey's default value to the string form of the handler's CLSID GUID.

(emphasis mine)

What handles .pl files? Is it perl.dll or is it shell.dll(shell.dll being the handler for executables)? Does your system have a registered CLSID for perl56.dll?
More importantly, what happens when shell.dll gets an DDE request it may not understand or be able to handle?

You don't get anything because the script doesn't run. In Windows Explorer, the .pl icon doesn't "light up" like a .bat file or a .exe will when you drag something on top of it. There must be some place in the system (registry?) that enables drag and drop on certain file extensions.

OK I think I understand you... I found a solution for my Win2K box but please bear in mind that

1. I still think it's a bad idea ;->
2. It involves editing the Registry: search www.microsoft.com, or speak to your neighbourhood NT hacker if you aren't aware of the potential consequences of this. I've not tested to see if there are side-effects.
3. (Also there may be a better solution: particularly Activestate or others might offer a solution that doesn't involve manually hacking the registry)

I fired up regedit to have a look in the registry:
It looks like the property of a filetype being able to accept dropped files, e.g. like batfile is stored in the registry under HKEY_CLASSES_ROOT\batfile\shellex\DropHandler

So if you created the keys under (in this case) HKEY_CLASSES_ROOT\perl\ for shellex and DropHandler and then copied the name of the handler CLSID into the default value (which on my system is {86C86720-42A0-1069-A2E8-08002B30309D} - don't you love the way Windows is so easy to use), it might work on the basis that... err... they're both console applications. Perhaps a monk who knows NT really well can give more insight?

Anyway, I tested and was able to drop a text file onto a perl script which ran it - I think this was what you were looking for.
You may want to be more scientific that I was... no warranty express or implied...

Update: More poking around in the registry. That class ID (the nasty looking hex string above) represents the .exe drop handler which fits nicely. It is enabled in the same way (e.g. under ShellEx\DropHander for .bat, .cmd, .com, .exe, .pif, and also for .scr (screen savers!) and shcmdfile Explorer commands. OK off topic for Perl but I'd like to understand more about this. I think O'Reilly have a book on Windows NT Shell Extensions

Update2: After following Boo's link to MSDN I came across Microsoft's admonition:

It is not recommended that you copy existing file associations from the registry. This often leads to the propagation of poorly formed file associations. Instead, you should follow the steps outlined in...

So there's some stern advice against following the instructions above... you have been warned!

Update3 (a bit OT):The O'Reilly book I found is Visual Basic Shell Programming Integrating Applications with the Windows Shell which is out of print, but there is more information on http://www.oreilly.com/catalog/vbshell/ including a link to read more about it online. I'm sure they had a non VB specific book too, but this looks interesting. Apologies if off-topic.

Cheerio!
Osfameron

Well, I don't know, but this definitely rings bells with me coming from a Windows NT drag-and-drop background to Perl and Unix culture.

I think that the drag and drop metaphor works really well for some things: and ad hoc copying files is still one of them. But nowadays apart from some copying, directory browsing, and deleting directories (because I can never remember the *^$%! command to delete a directory tree but Explorer lets me do it with a couple of clicks!) I tend to use command line instead.

My point? Oh yes, that I think that running executable content might be something that's best left out of the drag-and-drop metaphor. What if you click on the wrong files? What if you drag them onto the wrong icon? (That Click, hold, drag, release sequence is intuitive but I get it wrong surprisingly often... - well, maybe that's just me) Do you need control over which order the scripts run? or what happens to the output or error messages?

If you are running a group of scripts that you run regularly you might be better off writing a .bat file to call them and pipe the output to a log file.

I think if you really wanted drag-and-drop execution, it might be worth looking into Windows Scripting Host (which supports Perl) as I think this does allow more control over order, logging etc.

Cheerio!
Osfameron