UnigramDev/Unigram/develop • 8fdb141 • 7 files, +139/-23
Check whether a file still exists off the TDLib thread

1,152 of these ran during app start and cost 74 us each - seven times what
parsing a whole update costs - which made them a third of everything the TDLib
thread spent parsing. They are I/O and an app container access check, so no
build makes them cheaper; the only thing wrong with them is where they happen.

Nothing waits on the answer. The single outcome is a DeleteFile that TDLib acts
on whenever it arrives, so first sight of a downloaded file now queues the path
and a drain does the syscalls. One drain at a time: these arrive in bursts of a
thousand and a work item each would be a thousand thread pool hops for calls
that queue behind one another on the disk anyway. The same queue takes the
other first-sight check, in ProcessFile.

TdExtensions.Update stays synchronous - its caller acts on the answer instead
of sending a request about it.

NativeFile.Exists replaces NativeUtils.FileExists at all three call sites: one
P/Invoke to GetFileAttributesExFromAppW, which is what the C++/WinRT method
called anyway. Verified against the real export - the struct marshals to the
36 bytes the C layout wants, and a directory still reads as existing, as it did
before. The native method is now unused and can go on the next Telegram.Native
rebuild.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • 53efd5c • 1 files, +8/-5
Note the file check deferral in the resume section

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • c72b366 • 3 files, +18/-8
Give the modern build libvlc's plugins

UnigramUsesVcpkg is matched on project name, and Telegram.Modern was not in the
list, so neither the vcpkg runtime DLLs nor UnigramAddVlcPlugins applied to it.
libvlc.dll was there and its plugins were not, which is a native death with no
managed error report to show for it - the crash Fela hit on video.

Adding the project to that list is the whole fix; the plugin tree then arrives
through the same target Telegram.csproj uses, keeping the plugins\<category>\
shape that plugins.dat records.

It also means vcpkg supplies the shared runtime, which collided with the sixteen
ffmpeg and libvlc DLLs copied out of x64\Release\Telegram.Native (NETSDK1152).
Only Telegram.Native.dll, Telegram.Native.Calls.dll and their .pri files come from
there now - the arrangement Telegram.csproj already had. Telegram.Td.dll goes with
them: the shipping package does not carry it either.

Published, registered and launched: the app starts and stays up. Whether video
plays is Fela's to say.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram