Age | Commit message (Collapse) | Author |
|
Use LLStringUtil::getenv() or getoptenv() whenever we fetch a string that will
be used as a pathname.
Use LLFile::tmpdir() instead of getenv("TEMP").
As an added extra-special bonus, finally clean up $TMP/llcontrol-test-zzzzzz
directories that have been accumulating every time we run a local build!
|
|
Move Windows-flavored llstring_getoptenv() to Windows-specific section of
llstring.cpp.
boost::optional type must be stated explicitly to initialize with a value.
On platforms where llwchar is the same as wchar_t, LLWString is the same as
std::wstring, so ll_convert specializations for std::wstring would duplicate
those for LLWString. Defend against that.
The compilers we use don't like 'return condition? { expr } : {}', in which we
hope to construct and return an instance of the declared return type without
having to restate the type. It works to use an explicit 'if' statement.
|
|
Add ll_convert<TO, FROM> template, used as (e.g.):
ll_convert<std::string>(value_of_some_other_string_type);
There is no generic template implementation -- the template exists solely to
provide generic aliases for a bewildering family of llstring.h string-
conversion functions with highly-specific names. There's a generic
implementation, though, for the degenerate case where FROM and TO are
identical.
Add ll_convert<> specialization aliases for most of the string-conversion
functions declared in llstring.h, including the Windows-specific ones
involving llutf16string and std::wstring.
Add a mini-lecture in llstring.h about appropriate use of string types on
Windows.
Add LL_WCHAR_T_NATIVE llpreprocessor.h macro so we can detect whether to
provide separate conversions for llutf16string and std::wstring, or whether
those would collide because the types are identical.
Add inline ll_convert_wide_to_string(const std::wstring&) overloads so caller
isn't required to call arg.c_str(), which naturally permits an ll_convert
alias.
Add ll_convert_wide_to_wstring(), ll_convert_wstring_to_wide() as placeholders
for converting between Windows std::wstring and Linden LLWString, with
corresponding ll_convert aliases. We don't yet have library code to perform
such conversions officially; for now, just copy characters.
Add LLStringUtil::getenv(key) and getoptenv(key) functions. The latter returns
boost::optional<string_type> in case the caller needs to detect absence of a
given environment variable rather than simply accepting a default value.
Naturally getenv(), which accepts a default, is implemented using getoptenv().
getoptenv(), in turn, is implemented using an underlying llstring_getoptenv().
On Windows, llstring_getoptenv() returns boost::optional<std::wstring> (based
on GetEnvironmentVariableW()), whereas elsewhere, llstring_getoptenv() returns
boost::optional<std::string> (based on classic Posix getenv()).
The beauty of generic ll_convert is that the portable LLStringUtilBase<T>::
getoptenv() template can call the platform-specific llstring_getoptenv() and
transparently perform whatever conversion is necessary to return the desired
string_type.
Add windows_message<T>(error) template, with an overload that implicitly calls
GetLastError(). We provide a single concrete windows_message<std::wstring>()
implementation because that's what we get from Windows FormatMessageW() --
everything else is a generic conversion to the desired target string type.
This obviates llprocess.cpp's previous WindowsErrorString() implementation --
reimplement using windows_message<std::string>().
|
|
|
|
|
|
Instead of returning a wchar_t* and requiring the caller to delete it later,
return a std::basic_string<wchar_t> that's self-cleaning. If the caller wants
a wchar_t*, s/he can call c_str() on the returned string.
Default the code_page parameter to CP_UTF8, since we try to be really
consistent about using UTF-8 encoding for all our internal std::strings.
|
|
|
|
The previous build declared a static std::ofstream; but the code that
determines the pathname for the log file is called so early that static
objects have not yet been constructed. Declare a pointer instead, and
instantiate it on demand.
|
|
|
|
|
|
|
|
|
|
This logic is essentially copy-and-edited from the same suspenders-and-belt
concerning APPDATA and CSIDL_APPDATA for SL-10153.
|
|
In that case, also update $APPDATA for child processes.
|
|
The whole remaining difference between llifstream and std::ifstream is that
the former handles UTF-8 coded pathnames. Microsoft's implementation of the
latter does not.
|
|
|
|
Viewer (repository: axon)
|
|
|
|
|
|
|
|
Curiously, the value of $INSTDIR is correct before MULTIUSER_UNINIT, but is
made incorrect by MULTIUSER_UNINIT. Save and restore the correct value.
Saving $MultiUser.InstallMode in the registry (by setting relevant macros
examined by MultiUser.nsh) is susceptible to overwriting if the user installs
multiple viewers with the same channel name. Instead, write an InstallMode.txt
in the install directory, and read it back on uninstall. Of course, add it to
the files to be deleted on uninstall.
|
|
|
|
|
|
Back out misguided attempt to overwrite $PROGRAMFILES with $PROGRAMFILES64.
|
|
for 64-bit viewers.
It seems there's a longstanding bug in NSIS: it fails to use $PROGRAMFILES64
rather than $PROGRAMFILES when performing an all-users install of a 64-bit
program. Try to remedy that.
Also pick up a few NSIS suggestions from Ansariel Hiller.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
thereby avoiding strange Windows requirement for elevated privilege.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
from NSIS installer, instead of via explorer.exe.
A recent test run performed the install, then opened an Explorer window on My
Documents. <eyeroll/>
|
|
This should eliminate any confusion due to a Standard user needing to elevate
to Admin privileges, since from that point on Windows tells the running
program the current user is that Admin. Bypass all that.
|
|
|
|
|
|
run the viewer from the installer.
Turns out that the peculiar indirection through explorer.exe was a known trick
for an elevated-privileges program to launch a program as the logged-in
Windows user. (They could have commented that...)
But explorer.exe doesn't pass command-line parameters, so if you want to pass
any such to the actual target program, you have to launch a shortcut with
those parameters.
But this target program (the updater) and its parameters (precheck mumble) are
specific to the very first viewer run after installation, so delete it after.
Having an additional permanent icon that always runs the updater before the
viewer would only confuse matters.
|
|
|
|
In fact, mark UpdaterServiceURL as obsolete. (Consumers should consult
build_data.json.)
|
|
viewer_manifest.py was signing updater.exe within the package, and then
signing the installer executable itself, but not the actual viewer executable.
Add that.
|
|
|