Hi Folks:

I know that PHP is not for windows users, and it's much better when used whith *nix. But this is temporary, just until our server is ready.

I need to use encrypt/decrypt functions. And for now all I have found is mcrypt* functions, wich need php_mcrypt.dll.

The point is that I can't find this dam dll anywhere. And nobody knows where to find it compiled for php4.0.6 :o/

What's the point? Is it possible to have php_mcrypt.dll compiled for php4.0.6 for win32? Or the pressure to use *nix OS are much more greater than the interest in more and more servers running PHP?

Please, can anybody help me?

    If u want to be on certain level, u have to start putting Windows into the garbage, and start getting into the real world of OS.....

    sorry, can`t help u...

      That's exactly what I wanted to do. But that's also exactly what my boss don't want me to do.

      At home I use primary Linux and FreeBSD. But at work I need to follow the IT directions.

      They want to use linux, but we need another machine that will arrive in a month or two.

      That's ok. Thanks for you help

        I would argue that PHP is for all users of all platforms. If Rasmus et. al. had wanted PHP to be Nix only, they would have written it to be Nix only.

        The problem with php_mycrypt.dll is not a PHP problem. The problem is in Win32 the port of mCrypt.... or lack thereof. Win32 is missing certain routines and elements which makes porting to Win32 very difficult. The port does exist, but it's buggy and a real pain to use. Thus, no one really bothers creating the PHP extension.

        If crypt/decrypt is so important.... can't you just "borrow" an old throw away PC to install Linux on while waiting for the new box to arrive? Surely if it's that essential you can convince the people in the IT Dept. to scrounge you up some parts🙂

        -geoff

          I'm really sorry to hear such a thing. If it is implemented inside most *nix and not inside any windows, then it should be implemented through another way for windows distros.

          If it's implemented and it's buggy, then we need to debug it. I always though PHP is a wonderful program, and although we had some problems last year with PHP4, these days it's very stable. Why can't we have a stable patch for this bug?

          Probably most people will agree with me, but encryption/decryption is a must for most of serious sites. How can we (PHP comunity) desire to be taken seriously if for windows PHP only offers one-way encryption?

          I'll try to implement a PHP-encryption function to solve this problem. But now I must tell my boss (and his boss) that the choice of PHP was a Bad Idea(c) because it's not as portable as it claims to be.

          I'm really sorry about this. For me PHP will still be a good program. But for my boss (and his boss, and their friends) PHP will be "vaporware", promisses but nothing more.

            Ok, let's be specific here and get a couple things straight. When I said that PHP is not intended to be a *Nix only language, I meant it. However, I did not mean that to say that PHP does or should be able to give support to all the features which Win32 itself doesn't support.

            The old adage about not shooting the message applies in full force here. I realize I'm preaching to the converted since you obviously support and choose to use PHP, but the only aspects of PHP (that I'm aware of) which aren't supported by Win32-PHP are the mcrypt functions, curl, and some of the network lookup functions. In any form of cross-platform language effort there are always going to be certain restrictions imposed on the language's capabilites by the platforms upon which the language is going to run. This is precisely the case with those features.

            1) PHP is just as portable as it claims to be. There is NO other scripting language (again, that I'm aware of) that is even close when it comes to cross-platform support, the number of platforms it runs on, or the ablity to seamlessly drop code from one platform to another and still have it work properly.

            2) The absense of php_mcrypt.dll is not a PHP problem, bug, or deficiency. The problem is actually due to the fact that because MS doesn't use true strong encryption in their OS's, there are no native Win32 strong encryption libraries. Since mcrypt uses the OS's native encryption libraries for part of it's functionality, you cannot easily port mcyrpt itself to Win32. Without an effective port of the mcrypt library for Win32, there can be no Win32 mcrypt extensions for any language (ie. PHP, Perl, ColdFusion, ASP, C, Ruby, Python, etc.). Remember that the php_*.dll's merely contain hooks to third party libraries or extensions which don't need to be bunded into the PHP core.

            3) It seems to me that your problem is more a supply chain problem than anything else. You've claimed that the goal is run on a Linux-based server, and that's what the higher ups want, but you now can't get that server for 2+ months. How is it PHP's fault as a language that you're now running into problems when you try to use features on a different platform (Win32) that the that platform itself doesn't support.

            This is why I suggested that you try to convince the IT Dept. to find an old machine from somewhere that can serve as a temporary server until the back-ordered box arrives. Time and time again, Linux has proved it's ability to run, and run well, on hardware that it probably questionable for even Win98.

            If your boss and those above him in the chain want to stick their heads in the sand and consider PHP "vaporware" and a non-solution because it can't fix the short-comings of Windows itself, it's their own loss and it just shows their own ignorance of the real computing world. Any least you've seen the light and can hopefully convince them of the error in their thinking🙂

            -geoff

              Write a Reply...