| [reply]
[d/l] |
(well, what else can we expect from Micro$oft?)
Oh dear. How ruled by petty prejudices people are.
It's the Win32::API module that has been messed around with, and that has zip, zero, nada, nothing to do with Microsoft. They didn't write it, and they aren't the ones messing with it.
What version of perl is running on the failing system? In both cases (unfortunately still) 5.8.8.
32-bit or 64-bit? On a 32-bit or 64-bit version of which flavour of windows? Etc. You've been around long enough to know better how to answer that question.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
How ruled by petty prejudices people are.
Point taken!
It's the Win32::API module that has been messed around with, and that has zip, zero, nada, nothing to do with Microsoft.
My misunderstanding. I interpreted this sentence as "Since the Windows API changed a lot between Windows versions, the Win32::API module was changed often accordingly". I now see that where my mistake was.
32-bit or 64-bit? On a 32-bit or 64-bit version of which flavour of windows?
Ooops, I wasn't aware of these differences. In Windows 7 it's 32-bit. With XP, I guess it's the same - before you mentioned it, I was not aware that XP was also available in a 64-bit version.
Anyway, your question to the "bitness" makes we wonder whether we could have a problem here in the future: We use the same Perl installation (with all the modules) on all platforms, whether they are Windows 2000, XP or 7. I thought that 32-bit programs can also be run on 64-bit Windows, but if this is not the case, or if we need different versions of modules (or DLLs), depending on which platform we are running, this might cause trouble one day.
If I find time, I'll research a bit into this direction...
--
Ronald Fischer <ynnor@mm.st>
| [reply]
[d/l] |