Differences in php scripts functionality between 32-bit and 64-bit Win7

[FinnViking]

I have Win 7 home premium, Apache 2.2 (installed using the .msi) and PHP 5.2.14 (downloaded as "php-5.2.14-Win32-VC6-x86.zip", installed manually, it works) on both machines. The other is 32-bit and the other is 64-bit, both Windows 7 Home Premium.

 

When I run the exactly same script on one machine, it does what it is supposed to (32-bit), but on the 64-bit it does not.

 

Basically this appears in two situations (so far): I have a script that reads a (xml) file into a simplexml object, and if this is not successful, it prints an error message. On the 32-bit machine I can import (read) another xml file at once once the first one is processed (into a sqlite database), but on the 64-bit machine it gives me an error originating from the fact that the script did not manage to create the simplexml object.

 

The other situation is when I want to open a specific PDF - file in a browser window (Firefox, the newest one, on the 32-bit machine, IE something newish on the 64-bit). The file exists, the path to the folder is in the Path environment variable, I can open it normally etc on the 64-bit machine, but when I click on a link that is supposed to open the file in a browser window I only get an error message saying that the file does not start with "%PDF....

 

Needless to say, the precisely same script works just fine on the 32 bit machine.

 

$path_to_image="D:\\path_to_folder\\";

$file_name=$_GET['file_name'];

header("Content-disposition: inline; filename=".$path_to_image.$file_name);
header("Content-type: application/pdf");
readfile($path_to_image.$file_name);

 

The above code is from the part that receives the file name from a form (other file).

 

Anyone noticed anything like this? Any suggestions? Have been trying to figure this out for days, now...

 

Oh, forgot: In both cases the thing is accessed as/from "localhost".

[Mchl]

1. compare both php.ini files.

2. post actual error messages

 

[FinnViking]

The php.ini files are identical, and the only thing I did change (in both of them) was to un-comment the lines

 

extension=php_pdo.dll

extension=php_pdo_sqlite.dll

 

the rest of the php.ini - files are copies of the "php.ini-recommended" as it was when I unzipped the package.

 

As for the error messages. in the "PDF not showing on 64-bit" it is an Adobe Reader error saying "File does not begin with '%PDF-'.

 

And yes, the file to be shown is outside of the web root, but as I said, this has no effect on the 32-bit machine.

 

In the other case, not being able to process "uploaded" (from within the web root), the error message is of my own production, but is the result from

 

$dbh=new PDO('sqlite:/path/to/sqlite/database.db');

//Get the file to be processed from POST
$file_to_process=$_POST['csv'];

//Add the static path in front of file name, as POST only gives us the file name, but not
//the path, therefore if the file is outside the dir where this script is, it cannot be
//processed
$path_to_file_to_process="././xml_test_files/";

//Add the path to the filename
$file_to_process=$path_to_file_to_process.$file_to_process;

//Put the xml file contents into a variable $xml, show a message if not successful and die
if(simplexml_load_file($file_to_process)){$xml=simplexml_load_file($file_to_process);} else
{
include ("html_headers.txt");
include ("bhr_page_header.txt")
echo "<table align=\"center\"><tr><td align=\"center\">";
echo "<div class=\"head\">Unable to process file $file_to_process</div>";
;......

 

That is, the error is from the "if(simplexml_load_file(..." that goes wrong somehow, on the 64-bit machine.

[Mchl]

Regarding "File does not begin with '%PDF-'. issue: try opening the pdf in notepad and seeing what it starts with. It's likely a PHP's error message.

[FinnViking]

The PDF files are OK, they do open correctly in Adobe Reader.

 

I read from somewhere that IE is somewhat picky about things, therefore I downloaded and installed Firefox, and voilá, the xml stuff started to work as it was supposed to. And changed the script from having been

 

header("Content-Type: application/octet-stream");
header("Content-Disposition: inline; filename=\"".$file_name."\"");
header("Content-Length:".filesize($full_path));
sleep(1);
readfile($full_path);

 

to:

 

$path_to_image="c:\\temp";
$file_name=$_GET['file_name'];
$full_path=$path_to_image."\\".$file_name;
$fop=fopen($full_path, 'r');
header("Cache-Control: no-cache, must-revalidate");
header("Content-Disposition: attachment; filename=".basename($file_name));
header("Content-Type: application/pdf");
header("Content-Length:".(filesize($full_path)));
sleep(1);
//readfile($full_path);
fpassthru($fop);

 

 

Although I also added, as You can see, some "header("Cache-Control: no-cache, must-revalidate");", which might have had some effect on the outcome. But anyway, now I can "import" a xml - file, and then another, and then another, etc.

 

About the PDF files not opening...I found that if I place the files (and make the script look for them) in a folder where the path to this folder does NOT include any spaces the images were directly viewable. I also tried to get the thing working by saving the PDF files on a remote (network) drive (NAS), which was mapped as drive Y: to the workstation. This had the same effect as a path with spaces: Only now the error message was not the one in  the beginning, but rather one which mentioned the file having been encoded somewhat incorreclty.

 

But anyway, it works now, from a local folder, with the path not containing spaces.

 

The work continues, though, since I would like it to work using the NAS also. But so far, I consider this case closed.

 

Thank You for Your efforts.