Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71643
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.176 as permitted sender)
MIME-Version: 1.0
Date: Mon, 27 Jan 2014 13:36:43 +0100
Message-ID: <CAMYZVL5xa-j3rs1aosj+SqOQg91fWFsT6gOejN=DBZ+vQ2wL6w@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7bb03ed6d11bd504f0f2f5b0
Subject: ETA for unicode paths support on Windows?
From: czarek.tomczak@gmail.com (Czarek Tomczak)

--047d7bb03ed6d11bd504f0f2f5b0
Content-Type: text/plain; charset=ISO-8859-1

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

--047d7bb03ed6d11bd504f0f2f5b0--