This 'data loss' was introduced in 809a8ee693, because
I hoped we could eventually outlaw overlong paths entirely. This sparked some discussion:
https://github.com/SerenityOS/serenity/discussions/4357
Among other things, we agree that yeah, the Kernel can and should be able to return
paths of arbitrary length. This means that the 'arbitrary' maximum of PATH_MAX in
UserspaceEmulator should be considered to be unnecessary data loss, and as such, needs to
be fixed.
The realpath syscall can attempt to return arbitrarily long paths, in particular
paths that are longer than PATH_MAX. The only way to detect this case is
checking whether 'rc', the true length of the returned path including NUL byte,
exceeds our buffer length. In such a case, the buffer contains invalid data.
All Serenity code calls LibC's realpath() with a nullptr buffer, meaning that
realpath is supposed to allocate memory on its own. All Serenity code can handle
arbitrarily long paths returned by LibC's realpath, so it is safe to "do the
dance" and repeat the syscall with a new buffer.
Ports are likely to be graceful in this regard, too. If a Port calls realpath()
with a pre-allocated buffer, however, there is nothing better we can do than
return a truncated buffer.
Now that WindowServer broadcasts the system theme using an anonymous
file, we need clients to pledge "recvfd" so they can receive it.
Some programs keep the "shared_buffer" pledge since it's still used for
a handful of things.
The priority boosting mechanism has been broken for a very long time.
Let's remove it from the codebase and we can bring it back the day
someone feels like implementing it in a working way. :^)
The consolidation of the initialization code between HTTP and HTTPS
downloads was capturing the "job" local by reference, which was not safe
after we left the init() scope.
Fix this by getting the HTTP::Job from the Download object instead.
64 was cutting it pretty close, especially now as we start using file
descriptor passing more and more.
This (1024) matches many other systems, and if we need more there's
always sys$poll().
IPC::File should only be used when there's an actual file to pass.
Invalid ShareableBitmaps don't have a backing file, so fix this by
first encoding a "valid" flag.
Whilst SystemMenu maintains a constant WindowServer connection, there
isn't always a Window active on that connection to listen for theme
changes - this causes the current theme in this process to fall out of
sync with the rest of the system. This fixes this problem by
re-requesting an UpdateSystemTheme message when the dialog is
instantiated.
Adds a mechanism through which windowing clients can re-request an
UpdateSystemTheme message. This is currently used in SystemMenu's
ShutdownDialog to refresh it's theme when the dialog is instantiated.
This is in preparation of adding (much) more process information to
coredumps. As we can only have one null-terminated char[] of arbitrary
length in each struct it's now a single JSON blob, which is a great fit:
easily extensible in the future and allows for key/value pairs and even
nested objects, which will be used e.g. for the process environment, for
example.
Window icons in Taskbar were previously received in WM events with
shbuf ID's. Now that Gfx::ShareableBitmap is backed by anonymous files,
we can easily switch to using those.
Now, `chres 640 480 2` can set the UI to HighDPI 640x480 at runtime. A
real GUI for changing the display factor will come later.
(`chres 640 480 2` followed by `chres 1280 960` is very fast since
we don't have to re-allocate the framebuffer since both modes use
the exact same number of physical pixels.)
It's in efficient, and it also meant we wouldn't reallocate a bigger
backing bitmap in a lowdpi->highdpi transition, leading to minor drawing
glitches after such a transition.
(Whoops!)
