I'm completely new at this and am downloading PHP and am confused from the git-go ... What's the difference between "thread safe" and "non thread safe" and VC6 and VC9 files? I have installed IIS, MySQL, and have downloaded and installed the VC9 msi file.
I created a very simple PHP page from the Dreamweaver tutorial that is supposed to display the current time. With my browser I can locate the file but for some reason it doesn't want to serve my page with the correct time displayed.
From the tutorial I read the line:
"In the PHP installation folder, locate the file called libmysql.dll and copy it to the C:\Windows\system32 folder. This file is required so that IIS can work with PHP 5 and MySQL."
I attempted to locate the libmysql.dll file, but it was non-existent, so could not be copied as required. Is that where my problem is? Where do I get this required file?
I'm running,
WinXP
IIS
IIS CGI with extensions installed on the HD
MySQL
Should I run Apache instead of IIS?
Sooo many questions .... ?
What's the difference between VC6 and VC9?
Moderators: macek, egami, gesf
Re: What's the difference between VC6 and VC9?
It looks like I need VC9 for WinXP, but I also read that "the VC9 versions require you to have the Microsoft 2008 C++ Runtime (x86)". Do I have that? Who knows?? And "thread safe" vs. "non thread safe" -- still a mystery.
Re: What's the difference between VC6 and VC9?
So, I've downloaded the zip file of VC9, unzipped it and don't see any installation executable file? There is also no libmysql.dll file in the list. The install.txt file suggests using the msi file for installation instead of the zip file -- but I still have no libmysql.dll file. Where can I find it?
Re: What's the difference between VC6 and VC9?
Found it! Yeay for me!! The libmysql.dll file is not in the PHP folder at all, but in the MySQL folder. Copied it into the Windows\System32 folder and ... presto, it works. Guess I can junk all the other stuff I downloaded.
Re: What's the difference between VC6 and VC9?
A year ago, my company started the migration path of moving from Visual C++ 6.0 to Visual Studio 2005 (VC8). This was mainly done because after Vista was released, it was disclosed that VC6 had limited support on Vista. If and when our development computers needed to be upgraded, XP may have limited availability. So we decided then that moving to the newer compiler was pretty much required.
The problem is that, truthfully, migrating compilers is not something customers care about nor will pay for. So when you have all your developers dedicated to new features and bug fixes, compiler migration always seems to take a back seat.
So throughout 2007, I put in cycles where I can to ensure our code base compiles using VC8. However, in 2008, Visual Studio 2008 (VC9) was released. Since we had not moved to 2005 yet, I decided to take the extra jump to 2008.
In February of 2008, I had all the developers start doing their development using VC9. However, I continued to build our Alpha, Beta and Release builds using VC6. This required some redundant work with projects and some fixes which worked with VC9 that would not work with VC6.
In April, I made the switch for our Alpha builds and later for the new Beta and Release builds to VC9. This went as well as could be expected.
Below are some of the more common issues that we faced.
1. For loop variable scope differences
In VC6, the following is valid:
for (int i = 0; i < 10; i++)
{
}
_tprintf(_T("%i\n"), i);
However, in VC9, by default, the above code is not valid. Instead, the variable i is local for the for loop and cannot be referenced outside the loop. To maintain similar functionality, we modified our code to be like the following:
int i = 0;
for (i = 0; i < 10; i++)
{
}
_tprintf(_T("%i\n"), i);
There is a project setting which we could have set to allow the old behaviour. But I decided to keep the default and modify our code. I think it's better and, IMO, makes more sense.
2. STL iterators behave differently
In VC6, the following used to be valid:
std::list<int> mylist;
mylist.push_back(5);
std::list<int>::iterator it = mylist.begin();
// (*it) == 5
it++;
// it == mylist.end()
it++;
// it still == mylist.end()
Now, when debugging, the second ++ will produce an assertion failure and release will crash. Some of our algorithms needed to be updated because they were taking advantage of the fact that you could iterate past end() and still have end().
Another change is the fact that you cannot -- again begin(). Example:
std::list<int>::iterator it = mylist.begin();
it--; // would go one before begin()
In hindsight, this is kind of silly, but if the libraries support it, why not use it? We used this because std::list::erase() only takes an iterator, not a reverse_iterator, so to get around this, we could use an interator and work backwards through the list deleting as we went along until we got to the element "before" begin().
After migrating, this also needed to change.
As it turns out, I think the STL changes showed us exactly where many of the problems and crashes were in our code base. For a long time, I felt that many crash reports we were getting were related to this code, but it would never crash here. Instead, it invalidated some data somewhere and would crash later on making debugging, especially remotely, nearly impossible. These changes ensured that improper use of STL would crash the software then and there. At first, we faced many crashes in our alpha builds. But after time, the code base became rock solid.
3. Some 3rd-party libraries need to be recompiled
We were using some 3rd-party libraries such as libpng, zlib, libxml. These DLLs needed to be recompiled since they were initially compiled using MSVCRT, but now must use MSVCR90. Not a big deal. Just recompile and re-link.
4. Data type size changes
Some data types changed sizes. For example, time_t moved from 4 bytes to 8 bytes. We cared about this because we were writing some time_t values to file as a 4 byte integer. We had to change our code to use __time32_t and time32() instead. It's possible to set some defines to force time_t to continue to be 4 bytes, but we decided to embrace the change.
5. "Safe" C-library functions
Microsoft added some "safe" versions of many functions such as strcpy(), makepath(), etc. They called them _strcpy_s() and _makepath_s() respectfully. When compiling the old code, many warnings were displayed about using the "unsafe" version and that the "safe" version should be used instead. Again, there is a define that could be set to suppress this warning, but instead I decided to embrace the change. This one I actually liked. In order to accomplish this, I created my own set of these same functions. When compiling against VC6, we linked to my custom versions. When compiling against VC9, we linked to Microsoft's. After it was done, it was painless to maintain.
The problem is that, truthfully, migrating compilers is not something customers care about nor will pay for. So when you have all your developers dedicated to new features and bug fixes, compiler migration always seems to take a back seat.
So throughout 2007, I put in cycles where I can to ensure our code base compiles using VC8. However, in 2008, Visual Studio 2008 (VC9) was released. Since we had not moved to 2005 yet, I decided to take the extra jump to 2008.
In February of 2008, I had all the developers start doing their development using VC9. However, I continued to build our Alpha, Beta and Release builds using VC6. This required some redundant work with projects and some fixes which worked with VC9 that would not work with VC6.
In April, I made the switch for our Alpha builds and later for the new Beta and Release builds to VC9. This went as well as could be expected.
Below are some of the more common issues that we faced.
1. For loop variable scope differences
In VC6, the following is valid:
for (int i = 0; i < 10; i++)
{
}
_tprintf(_T("%i\n"), i);
However, in VC9, by default, the above code is not valid. Instead, the variable i is local for the for loop and cannot be referenced outside the loop. To maintain similar functionality, we modified our code to be like the following:
int i = 0;
for (i = 0; i < 10; i++)
{
}
_tprintf(_T("%i\n"), i);
There is a project setting which we could have set to allow the old behaviour. But I decided to keep the default and modify our code. I think it's better and, IMO, makes more sense.
2. STL iterators behave differently
In VC6, the following used to be valid:
std::list<int> mylist;
mylist.push_back(5);
std::list<int>::iterator it = mylist.begin();
// (*it) == 5
it++;
// it == mylist.end()
it++;
// it still == mylist.end()
Now, when debugging, the second ++ will produce an assertion failure and release will crash. Some of our algorithms needed to be updated because they were taking advantage of the fact that you could iterate past end() and still have end().
Another change is the fact that you cannot -- again begin(). Example:
std::list<int>::iterator it = mylist.begin();
it--; // would go one before begin()
In hindsight, this is kind of silly, but if the libraries support it, why not use it? We used this because std::list::erase() only takes an iterator, not a reverse_iterator, so to get around this, we could use an interator and work backwards through the list deleting as we went along until we got to the element "before" begin().
After migrating, this also needed to change.
As it turns out, I think the STL changes showed us exactly where many of the problems and crashes were in our code base. For a long time, I felt that many crash reports we were getting were related to this code, but it would never crash here. Instead, it invalidated some data somewhere and would crash later on making debugging, especially remotely, nearly impossible. These changes ensured that improper use of STL would crash the software then and there. At first, we faced many crashes in our alpha builds. But after time, the code base became rock solid.
3. Some 3rd-party libraries need to be recompiled
We were using some 3rd-party libraries such as libpng, zlib, libxml. These DLLs needed to be recompiled since they were initially compiled using MSVCRT, but now must use MSVCR90. Not a big deal. Just recompile and re-link.
4. Data type size changes
Some data types changed sizes. For example, time_t moved from 4 bytes to 8 bytes. We cared about this because we were writing some time_t values to file as a 4 byte integer. We had to change our code to use __time32_t and time32() instead. It's possible to set some defines to force time_t to continue to be 4 bytes, but we decided to embrace the change.
5. "Safe" C-library functions
Microsoft added some "safe" versions of many functions such as strcpy(), makepath(), etc. They called them _strcpy_s() and _makepath_s() respectfully. When compiling the old code, many warnings were displayed about using the "unsafe" version and that the "safe" version should be used instead. Again, there is a define that could be set to suppress this warning, but instead I decided to embrace the change. This one I actually liked. In order to accomplish this, I created my own set of these same functions. When compiling against VC6, we linked to my custom versions. When compiling against VC9, we linked to Microsoft's. After it was done, it was painless to maintain.
Re: What's the difference between VC6 and VC9?
If you are using PHP with Apache 1 or Apache2 from apache.org you need to use the VC6 versions of PHP
If you are using PHP with IIS you should use the VC9 versions of PHP
VC6 Versions are compiled with the legacy Visual Studio 6 compiler
VC9 Versions are compiled with the Visual Studio 2008 compiler and have improvements in performance and stability. The VC9 versions require you to have the Microsoft 2008 C++ Runtime (x86) or the Microsoft 2008 C++ Runtime (x64) installed
Do NOT use VC9 version with apache.org binaries
If PHP is used with IIS then choose PHP 5.3 VC9 Non Thread Safe or PHP 5.2 VC6 Non Thread Safe;
If PHP is used with Apache 1 or Apache 2 then choose PHP 5.3 VC6 or PHP 5.2 VC6
If you are using PHP with IIS you should use the VC9 versions of PHP
VC6 Versions are compiled with the legacy Visual Studio 6 compiler
VC9 Versions are compiled with the Visual Studio 2008 compiler and have improvements in performance and stability. The VC9 versions require you to have the Microsoft 2008 C++ Runtime (x86) or the Microsoft 2008 C++ Runtime (x64) installed
Do NOT use VC9 version with apache.org binaries
If PHP is used with IIS then choose PHP 5.3 VC9 Non Thread Safe or PHP 5.2 VC6 Non Thread Safe;
If PHP is used with Apache 1 or Apache 2 then choose PHP 5.3 VC6 or PHP 5.2 VC6
Who is online
Users browsing this forum: No registered users and 2 guests