AuroraSupport/AuroraRuntime
2
1
Fork 0
Code Issues 27 Pull Requests Releases Wiki Activity

[*] Formatting: this was bothering me

Browse Source
This commit is contained in:
Reece Wilson 2022-04-11 14:11:47 +01:00
parent a36a1b8211
commit c7fb247f99
1 changed files with 29 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
Source/Processes/Open.Win32.cpp
View File

@ -33,27 +33,7 @@ namespace Aurora::Processes
{
for (const auto &open : gOpenItems)
{
if (open.empty())
{
// We probably ran out of memory.
// AuProcess/Open can safely drop as we expect shells to be kinda fucky and async
//
// Case in point: Minecraft on Linux (would?) blocks when you click a link in chat
//
// Fuck tons of applications support clicking of links, in the case of TS and others, allowing for RCE.
// In the case of MC and others, they don't even know if the operation blocks until the process closes.
// Assuming non-blocking, the API returns false on failure; but if it's blocking, who knows what that
// means... Nonzero exit code? Not enough resources? No error?
//
// Websites, programs, and scripts wouldn't know how to process "missing protocol handler,"
// "not enough resources," "process crashed before pump," "shell busy." For the most part, we don't
// expect expect the developer to be aware of what happens after a request to open a resource is
// requested. It's a lot of engineering effort for what should be fork, exec("start", ...)
//
// Dropping invalid paths, out of memory during UTF8 conversion, and other IO issues is probably fine.
// Use an actual IProcess object, if you care about spawning and monitoring executables.
continue;
}
if (open.empty()) continue; // [*1]
ShellExecuteW(nullptr,
AuIOFS::DirExists(open) ? L"explore" : L"open",
@ -118,9 +98,32 @@ namespace Aurora::Processes
{
OpenUri(AuIOFS::NormalizePathRet(file));
}
}
// TODO: Consider creating blocking apis whose return value is an IProcess (construct from ShellExecuteExW -> in.hProcess, or ("xdg-start", ...))
// For the most part, blocking for a specific application in the context of a protocol or file open request is a dated computing construct.
// Nowdays, opening an editor, mail client, or such like means poking a single executable that'll spawn a fuck ton of background workers, io threads,
// and other resources, to manage multiple instances of whatever the application deals with (think: editor tabs; browser windows; sendto: isnt a modal)
}
// [*1] :
// We probably ran out of memory.
// AuProcess/Open can safely drop as we expect shells to be kinda fucky and async
//
// Case in point: Minecraft on Linux (would?) blocks when you click a link in chat
//
// Fuck tons of applications support clicking of links, in the case of TS and others, allowing for RCE.
// In the case of MC and others, they don't even know if the operation blocks until the process closes.
// Assuming non-blocking, the API returns false on failure; but if it's blocking, who knows what that
// means... Nonzero exit code? Not enough resources? No error?
//
// Websites, programs, and scripts wouldn't know how to process "missing protocol handler,"
// "not enough resources," "process crashed before pump," "shell busy." For the most part, we don't
// expect expect the developer to be aware of what happens after a request to open a resource is
// requested. It's a lot of engineering effort for what should be fork, exec("start", ...)
//
// Dropping invalid paths, out of memory during UTF8 conversion, and other IO issues is probably fine.
// Use an actual IProcess object, if you care about spawning and monitoring executables.
// TODO: Move the above comments into something less gross