Wamp C++ Redistributable

[Dionisio Sechser]

Makesure you run the wamp server installation file as administrator (indeed for any installations). Doing this worked for me when previous installations resulted in not being able to launch wamp server.

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

It is supposed to be a very straightforward process but a chain of unexpected mistakes snowballed into an embarrassing nightmarish experience. WAMP is for Windows (so for Mac users, please install MAMP instead). So this is a sort of confessional tell-it-all which I hope can help some of you out there and thereby reducing my guilt (ha) and stupidity.

After a few hours later when I realised that I had gotten the wrong version and giving my forehead a slap, I uninstalled it and went to look for the correct version. Only after navigating the website a bit did I find the correct link.

I had a very hard time pronouncing this "redistributable" word, kind of the same tongue-twister "deliverable". I could not do it. Tried to slowly say out the word a few times only to mouth off the last syllabus rapidly in order to cover my gibberish pronunciation, only to make it worse. You feel me?

Now, I gotta to install the redistributables because I had missed the warning back then during the installation. I mean, who will bother to read the text in the installation wizard. Oh boy, they did warn us but it was all lost in the wind.

Installation seemed smooth! But the following error message popped up as soon as I start WampServer. Luckily, there was help from the Internet which identified the root cause of this infamous missing MSVCR110.dll error.

WAMP has a few requirements on your system. Chances are that you have at least some of them already because they are also used by many other applications. What I am talking about is the Microsoft Visual C++ redistributable packages, which is a set of standard functionalities.

I go to my.ini and put in a password.Then go to MySQL console.. type in that password and either 1. the console dissapeares or 2. I get Error 2003 "Can't connect to MySQL server on 'localhost' (10061)"

Connection to the MySQL server is not allowed using TCP-IP. Check the 'skip-networking' setting in the MySQL configuration file (my.ini on Windows, my.cnf on Unix/Linux). It shall be commented out like '#skip-networking'. If it is not commented out, then do it and restart the MySQL server for the change to take effect.

Some networking issue prevents connection. It could be a network malconfiguration or a firewall issue. You need to allow the service mysql on windows firewall/ after you install wamp, restart ur pc. and start wamp

BEFORE proceeding with the installation of Wampserver, you must ensure that certain elements are installed on your system, otherwise Wampserver will absolutely not run, and in addition, the installation will be faulty and you will need to remove Wampserver BEFORE installing the elements that were missing.

Third, after interpreting the errror log I navigated to the mysql data directory. The location of that directory on my machine was: C:\wamp64\bin\mysql\mysql5.7.19\data. This can be different on your machine. I noticed that some directories where missing. I didn't had a "mysql" directory, though it must be there in order to work.

Let me explain today how to use the wamp server to run PHP files. You can use this method to run PHP scripts you may have obtained from somewhere and need to run with little to no knowledge of PHP. You can execute your scripts through a web server where the output is a web browser. So let's get started

Server migrations are an inevitable task, but I found myself in a different than normal circumstance recently. A planned server stack retirement, combined with the server "owner's" technical capacity and expertise required a change in platform. Specifically, this shift meant moving from Linux to Windows.

The server stack being retired could be classified as LAMP (Linux, Apache, MySQL, and PHP), though there is technically not an "M" component as the database/MySQL instance is hosted on a different stack unrelated to this change. A suggestion from the new server owner was to give WAMPserver a shot, and something to which I was certainly open.

In installing and giving WAMPserver a test, I wasn't terribly impressed overall. I didn't like the clunky interface and frequent CMD prompt popups when invoking commands/services. Additionally, the whole installation seemed to require installing every VC++ redistributable package on the planet. Ultimately to present a semi-helpful system tray menu and graphical interface to make basic changes in the server and service configurations. This came at the expense of many phantom CMD popups and an overall latency that just felt off to me.

I was able to get a test site up and running in a relatively short period of time (it took way longer to get all the prerequisites installed and wrap my head around how to use the WAMPserver interface). After an initial test, I also pulled a copy of the app project repo and configured it to present the application homepage as a real proof of concept that the project could be ported to Windows with a reasonable effort.

I was still stuck on the overall overhead, though. Ultimately I just need a fairly vanilla Windows instance of Apache and PHP, which are both easily obtainable and configurable. Especially since I have extensive experience with Apache configurations and VirtualHosts, stubbing out those "from scratch" is much less a lift than it could be for others. The absence of the "M" in L/WAMP was really the death knell in using WAMPserver for me, though. It definitely works, and I'm sure it has a place...especially in a full-stack setup that is overseen by someone with less familiarity.

To the question of managing Apache and PHP versions, though, those are both easily identifiable in the split disk system we set up (where almost everything is being installed on the D drive). No need to hunt through other directory trees to figure out what version(s) and installation dates.

A straight up "install" (extraction) of PHP and its basic config is all that's necessary. With Apache, you have to use the Thread Safe version of PHP, which you can pull from the Windows PHP downloads page. In this particular project I pulled the VC15 x64 Thread Safe version of PHP 7.4.xx.

I extracted the PHP build to the D:\php7-4-xx\ path for simplicity and visibility. An important thing to configure, especially in using PHP with Apache, is to make sure that both the php.exe path and the PHP extension paths are added to the system PATH environment variable, as this will prevent trouble and confusion later on:

Most/All of the basic PHP configuration happens in the php.ini file (located in the same directory as php.exe. You can copy one of the pre-stubbed-out versions (php.ini-development or php.ini-production) as a helpful starting point. The primary difference between the two is in the error_reporting variable, which you will want to review and modify according to your needs/tastes.

Apache installation and configuration requires more fiddling than PHP. Obtaining Apache from Apache Lounge downloads for Windows is the simplest. If extra modules are necessary, they have additional module pointers/downloads as well.

I "installed" the Apache build to the D:\Apache24\ path for simplicity and visibility. From there it's right into the httpd.conf file. I decided to make things more obvious for Future Me (or anyone else) that any modified or included conf files would be placed directly in the conf directory (aside httpd.conf).

I jumped over to Windows services to set the Apache2.4 service with a "Manual" startup type, especially useful during setup and testing. This kept the Apache service under my total control until things were ready to go live. At the same time, I "installed" the Apache Service Monitor which is a super helpful system tray application to quickly start/stop/restart Apache.

At this point it's feasible to actually start the Apache service and hit :80 to see if you get the test page (or whatever content might be in the default htdocs directory). I skipped this particular step because I'd already set up a separate test/"Hello World" page in a VirtualHost config. Assuming Apache loads without error and you can view a basic page, you're ready to go with a "real" site!

It's important to note the Directory directive in the above example. This is where you set the most basic security and access controls for the filesystem, including the ability to use and granularity of .htaccess files if necessary.

These commands are useful under other circumstances as well, but running the folllowing commands will produce useful output to verify you configured things "appropriately" (in that they're not broken) for Apache:

It is possible to install the mod_log_rotate module for Apache on Windows, but the Apache installation comes with rotatelogs.exe to which log detail can be piped and managed without much issue. In the spirit of keeping with a "vanilla" mentality, I chose to go with piping to rotatelogs.exe as it reasonably handles the use case.

It's important to know that without any sort of log rotation mechanism Apache on Windows will just grow the log file indefinitely and infinitely. Using rotatelogs.exe does not address infinite disk growth (something separate needs to be employed to cull aged log files), but that is well outside the scope of this already lengthy post.

All of the SSL configuration details for this installation of Apache are outlined in detail in my last post about Certbot on Windows. SSL is one of the last steps to configure once the regular VirtualHosts are ready to go and tested.

Something to know is that it may be necessary in your non-SSL configuration to exclude the .well-known directory from rewrites to SSL as this will break certificate domain validation. This is especially true when using the Certbot --webroot plugin.

3a8082e126