On 13.09.2024 at 16:07, Sara Golemon wrote: > On Thu, Oct 12, 2023 at 6:50 PM Patrik Pasterčík <pl...@seznam.cz> wrote: > >> An analysis of other solutions, a detailed description of the problems >> and a proof of concept is in the proposal in the issue here: >> https://github.com/php/php-src/issues/12227 > > Resurrecting this message from last October... I think this is a > completely reasonable ask, the only bikeshedding I would have is about how > we set ourselves up for future success. Specifically, I think there's a > space (a small one) for OS-specific functionality. This sort of thing on > Windows, exposing CoreFoundation framework utilities on macOS, and probably > a whole host of Linux specific toys (oh hey look, we have a posix extension > with exactly those things -- yes, I know macOS and windows are posix-ish, > don't at me). > > My point is, I think we should consider `ext/win` (potentially starting in > PECL and only later promoting to build-by-default) and use a deliberately > chosen prefix namespace like `win_*()`.
Note that there are already a couple of related extensions on PECL[1]; of these only win32service is still maintained, though. Still, having a look at these extensions might make sense. Also note that there are a couple of Windows specific functions in core, prefixed as sapi_win32_ (not sure why the sapi_ prefix had been chosen), and these already allow dealing with some console specifics (codepages, some events and vt100). Maybe these should be moved in an own extension, but unbundling these is likely an issue (even renaming would be) for BC reasons. [1] <https://pecl.php.net/package-search.php?pkg_name=win32> Christoph
