Hello PHP devs,
A few words of introduction. I'm the author of the PHP Desktop project (
https://code.google.com/p/phpdesktop/) that lets you develop native desktop
applications using PHP, HTML5, JavaScript & SQLite. Turning a website into
a desktop application is basically a matter of copying it to the www/
directory. PHP Desktop embeds a Chrome browser, a multithreaded web server
and a php interpreter. You don't need to install Google Chrome on a user's
computer or anything else, there are no dependencies and it works out of
the box. I know that PHP was never intended for running long hours/days as
usually desktop applications do, and there are memory leaks when you try to
use PHP for such a task. But this is not a concern in case of phpdesktop,
as it serves web pages through CGI, so it behaves exactly the same as your
web apps in regards to memory handling.
It works very well. Though there is one major issue with PHP when deploying
on a Desktop. It does not support unicode paths on Windows. When the php
directory with binaries or the www directory with php scripts, are in a
path that contains unicode characters (one of the parent directories on a
path), then launching the php-cgi results with "No input file specified".
This is a major issue when deploying your application on Windows. Due to
UAC security features in Vista/7/8 your application does not have
permissions to write to the "Program Files" directory to which application
is installed. You are supposed to keep your application data in the User's
profile directory to which you have write permision. This path is something
like "C:\Users%USER%\AppData\Local\myapp". The problem is that user's name
may contain unicode characters. Thus you can't use this directory to keep
your sqlite database or write other files using PHP.
I've done some research and hacking of my own. I've modified the php-cgi
sources to allow for relative paths and it launched the main script fine.
But when trying to include another php script, also using a relative path,
then you get a php warning that include failed. This seems like a more
complex problem. I've investigated it further, googled a lot, and seems
like the required changes to support unicode paths on Windows would be
required in the TSRM/tsrm_virtual_cwd.c file (on a side note, this file
disappeared in php 5.6). I've found many php bugs where users were
reporting problems with unicode paths. Some even provided patches to the
mentioned tsrm file. But they were rejected and some promises were made to
support it soon. I saw some replies by Joy, saying that it is planned to
support unicode paths in php-next. These posts were from 1-2 years ago.
I've just checked php 5.6.0-alpha1, and sadly it still does not work. I've
tested both php.exe and php-cgi.exe.
So are there any plans to support unicode paths on Windows? It doesn't have
to be a full-blown solution, if we could just allow for the php binaries
and the php scripts to reside in a path that contains unicode chars.
Theoretically, this could be easily fixed, by just replacing the calls to
fopen()
with _wfopen(), preceded with conversion of the utf-8 path to
unicode using MultiByteToWideChar(). But I am aware that this is no enough,
as there are other functions like zend_resolve_path() that parse the ansi
path and they are not aware that this path could contain utf-8 characters,
thus these functions fail.
Thanks for any help in this matter.
Best regards,
Czarek
Hello Czarek,
AFAIK, two solutions exist:
- an extension: https://code.google.com/p/php-wfio/
- a PHP class:
https://github.com/nicolas-grekas/Patchwork-UTF8/blob/lab-windows-fs/class/Patchwork/Utf8/WinFsStreamWrapper.php
The PHP class is based on COM+shortPath and suffers from Windows sometimes
returning non-ASCII chars in shortPath on non latin computers. No
workaround found currently.
Hi Nicolas,
On Mon, Jan 27, 2014 at 6:58 PM, Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:
AFAIK, two solutions exist:
- an extension: https://code.google.com/p/php-wfio/
- a PHP class:
https://github.com/nicolas-grekas/Patchwork-UTF8/blob/lab-windows-fs/class/Patchwork/Utf8/WinFsStreamWrapper.phpThe PHP class is based on COM+shortPath and suffers from Windows sometimes
returning non-ASCII chars in shortPath on non latin computers. No
workaround found currently.
Thank you for the links. Looks like that the php-wfio extension is a better
solution as it would be more reliable.
I've just tested the pdo sqlite extension and it worked fine when provided
with a utf-8 path to the file database. This extension seem to be handling
unicode paths independently of php. That's a good news.
Best regards,
Czarek