A long standing lack of synchronization on the elevated process handle
made the non-elevated process always exit, so the updater would assume
it was started elevated and launch OBS from the elevated context.
Also applies the altered working directory to the non-elevated code
path so it can find the OBS executable properly.
The program can get stuck waiting for the browser within a event queue,
so instead mark that the program is closing, do it in a separate thread,
signal the window when it's finished, and then check whether it's in the
process of closing before actually showing the dialog.
The current updater code won't prompt the user if an output is active or
if game capture is in use. These are both fairly common situations to be
in as soon as OBS starts up - for example, the NDI and VirtualCam
plugins both start outputs automatically, and a game capture source will
hook if the game is open.
It should be fairly obvious to a user that OBS will be closed when an
update is installed. Given the low frequency of game capture updates,
the risk of an update encountering in-use files is also very low, and
the standalone updater UI already shows a prompt should this happen.
Code submissions have continually suffered from formatting
inconsistencies that constantly have to be addressed. Using
clang-format simplifies this by making code formatting more consistent,
and allows automation of the code formatting so that maintainers can
focus more on the code itself instead of code formatting.
This can take a while on a hard drive since it hashes the entire OBS
installation, show a undetermined progress marquee to avoid users
thinking that the updater has frozen.
(This commit also modifies UI)
Adds a universal function for determining whether video output is
currently active, rather than having to use video_output_active() on the
value returned by obs_get_video().
Makes Visual C runtime libraries consistent across
Debug/MinSizeRel/Release/RelWithDebInfo, rather than just changing those
flags for RelWithDebInfo. Also adds /Zl for statically linked
libraries.
Closesobsproject/obs-studio#1421
It would only check whether it should download a package if the 32bit
version existed. This would cause it to not download all files
correctly to update 64bit installs (post 22.0.1).
Saves a bit of bandwidth when the update module just updates binaries
for the specific architecture being updated. Especially true when
libcef needs to be updated.
This is just for the update module -- allows us the ability to
seamlessly update the program to VC2017 and seamlessly install Visual
C++ 2017 redistributables without potential issues that could be caused
by GPL usage for the update module.
On Windows 7, WinHTTP defaults to using only SSL3 and TLS 1.0. The
obsproject.com server was updated to remove TLS 1.0 support and
this has caused updates to stop working on Windows 7.
Currently if a file is partially written to (eg, the file is opened for
writing but the write fails), the updater won't correctly roll back to the
previous version, leaving the OBS install in an inconsistent state.
We now track failed installs or hash failures on patched files with a new
STATE_INSTALL_FAILED state and properly roll back on errors.
When updating large files such as libcef, the patching process can take a
decent amount of time. Previously the progress bar would remain at 100%
after completing the downloads, so the user may think the updater has
frozen. Now it shows the process of the install / patching process.
When building with VS2017 the compiler shows some warnings which is
undesirable.
The compiler rightly complains about declarations which hide older ones
which are trivially fixed.
Finally only POD types should be passed to variadic functions which is
why the String should be converted to c_str().
Relying on the current undefined behavior is a bad idea as it can change
with compilers and compiler versions.
Closesjp9000/obs-studio#902
This would cause people to download the 64bit files when they were on
the 32bit version of windows, even though those files aren't meant to be
installed.
The GetTempPath and GetTempFileName functions weren't being used
correctly, GetTempFileName always create a temporary file, and was
creating a temporary file in the root directory of the hard drive
unintentionally.
jp9000
Richard Stanway
Matthieu Cunzi
craftwar
Michael Fabian 'Xaymar' Dirks
Richard Stanway
Dmitry-Me
e00E