Thanks for running the test. One issue I can see is that the final space wasn't stripped and it could perhaps be the reason both tests failed. Could you run it again and delete the space before pressing enter?
Of course the regex should take care of this for the user. If I remember correctly, I did try something like this at some point: $inputfile =~ s/^ *[\"\']?(.*?)[\"\']? *$/$1/;
Note the ? for non-greedy matching and the $ anchor, which were intended to exclude any final quotes and spaces from the match while allowing spaces inside the file name or path. I think it didn't work: trailing quotes got caught by the (.*?) and not the \"\'? despite non-greedyness. Right now I'm blanking on what the right regex is for stripping all leading and trailing spaces and quotes. There may be no spaces and no quotes, or both, or only spaces, or only quotes. Makes my head hurt.
In fact, this may be the source of the whole problem: if there are no quotes, the script doesn't strip trailing spaces. As XP always adds quotes, this issue didn't arise on my own machine.

Note: I noticed Your Mother's post with much the same content as I was about to finish this post. One issue is that there is no way of telling if a filename contained a leading or trailing space or the OS tacked it on, although it's pretty safe to assume it's the latter (extensions don't end in a space and file paths don't start with a space... I hope). It's another reason why people shouldn't tempt fate with ludicrous file and folder names.

Admittedly, the method I'm using here is pretty crude: it will probably fail if the file is in the root of the drive or if it has no file extension. Again, these are fringe cases that are really low on my priority list.
I should note that this is a hobby project; I have no obligation to accommodate people with poor file-naming habits.