Req #72768 [Ana]: Add ENABLE_VIRTUAL_TERMINAL_PROCESSING flag for php.exe

Edit report at https://bugs.php.net/bug.php?id=72768&edit=1 ID: 72768 Updated by: ab@php.net Reported by: mlocati at gmail dot com Summary: Add ENABLE_VIRTUAL_TERMINAL_PROCESSING flag for php.exe Status: Analyzed Type: Feature/Change Request Package: Output Control Operating System: Windows 10 PHP Version: Irrelevant Block user comment: N Private report: N New Comment: @mlocati, thanks for all the work so far. I made a quick look over your latest patch so far, a couple of comments already. Please check the coding style doc for function naming conventions, etc. http://git.php.net/?p=php-src.git;a=blob;f=CODING_STANDARDS;h=5cf70c92b5f5ab06977629ba6fff87255cc80116;hb=HEAD . Particularly, in most casse the internal APIs should be prefixed with php_*, and Windows specific with php_win32_*. Also the underscore is used for separation, etc. Please see other sources there. Also the following regarding the code: - the Unicode APIs have to be used, where it matters in 7.1+. Fe GetFinalPathNameByHandleW. Please check the corresponding helper routines in win32/ioutil.h. - usually we don't use the driver routines, Rtl*, etc. Regarding getting the version, there's quite some functionality already in the core, please check EG(windows_version_info). It should suffice as till now the only case is the usage after MINIT is bypassed. - please don't use static vars in functions, until it's thread safe - for the streams, particularly main/streams/plain_wrapper.c were relevant for STDIO. Taking some stream and stepping through it in the debugger might help for better understanding. Basically, a stream resource needs to be passed, as the fd might be duped but still point to a vt100 term. - tests are required :) Indeed, it might be handier to discuss the patch in a github PR, which you already can attach to this ticket. Thanks. Previous Comments: ------------------------------------------------------------------------ [2016-08-28 18:12:04] mlocati at gmail dot com What about continuing this discussion on a new pull request at https://github.com/php/php-src ? ------------------------------------------------------------------------ [2016-08-26 16:38:48] mlocati at gmail dot com I changed the stream_vt100_support function to accept strings ('php://stdout', 'php://stderr') instead of stream objects. This is a bit a workaround, but I really don't know how to determine the standard stream (stdin/stdout/stderr) from stream objects. See patch 0001-Start-adding-VT100-support-for-Windows-v3 ------------------------------------------------------------------------ [2016-08-26 14:14:45] mlocati at gmail dot com I finally managed to compile php (basically an include of php.h was missing) - see attached patch 0001-Start-adding-VT100-support-for-Windows-v2. Just one thing remains to be done: how to get the standard Windows handle (eg STD_INPUT_HANDLE/STD_OUTPUT_HANDLE/STD_ERROR_HANDLE) starting from a php_stream? I thought it was possible by inspecting stream->orig_path, but it's not the case. Any hint? ------------------------------------------------------------------------ [2016-08-25 13:09:10] mlocati at gmail dot com I tried to add this new function, and since this is my first attempt to contribute to PHP I'm surely doing something wrong: the compilation fails with strange messages (redefinitions of #define, structs, functions). ------------------------------------------------------------------------ [2016-08-22 09:34:47] ab@php.net @mlocati, I only mentioned the control sequences stripping as a result of further deliberation. Bash does it, as you mentioned. ASCII (compatible) would be probably easy to do, but not sure with double byte and other mb encodings. So mentioned it, just to keep in mind, this option is possible. Otherwise - yeah, what we discuss till now as an initial plan is to not to strip control sequences automatically. Thanks. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=72768 -- Edit this bug report at https://bugs.php.net/bug.php?id=72768&edit=1