innoextract VS outcome

IIRC they can be extracted using innoextract: https://github.com/dscharrer/innoextract

Now you're being silly. They repackage the whole game (and, by the way, remove/circumvent any drm that may have been present in the original) into an installer. If you happen to want to run the game with an alternative engine you can even extract the files without running said installer.

Bypassing this is simple, use innoextract on the installer. File should be in the APP folder.

For instances where you have a self extracting exe installer (like if you buy games from GoG) you can use innoextract to extract the contents on a Linux OS withing needing to use WINE to actually perform an installation, like if you only need the art assets like if you are using OpenMW to play Morrowind or Arx Libertatis to play Ark Fatalis.

To fix this, you'll need innoextract, 7zip, and the driver installer from creative's website. Extract the downloaded installer using InnoExtract, and open Bin.cab in the HOAL directory with 7zip; there'll be two directories in there. Copy the Sens_oal.dll in WINSYS64 to C:\Windows\System32 , and the Sens_oal.dll in WINSYSDIR to C:\Windows\SysWOW64 , replacing the file if it already exists.

I've had trouble with the version of innoextract in the repo sometimes (running Fedora), and had to build it from the git repo to get a newer version.

https://github.com/ned14/outcome/tree/develop/abi-compliance uses both in a CI pass to ensure Outcome never changes anything which breaks either API or ABI with earlier versions.

outcome and/or expected

A "Sample Usage" appears on the front page of the docs: https://ned14.github.io/outcome/

I recently came across boost outcome as I was searching for a better error handling method. It took me a minute to get a hang of it but now I love it. After creating my own policy and a few aliases for easier use.

std::optional and std::variant can be a bit awkward to use in this scenario, though. Consider a dedicated type like boost::outcome (standalone versions) or one of the implementations of the proposed std::expected.

Minimum possible compile time impact is a key goal of https://github.com/ned14/outcome. We ship a single header edition which only includes the low impact standard headers as listed at https://github.com/ned14/stl-header-heft. We also don't use union storage for non-TC non-MB types in order to avoid complex metaprogramming execution by the compiler per instantiation.

It's really weird that I wrote the above, and then this bug was reported to Outcome: https://github.com/ned14/outcome/issues/244. Here is my exact complaint about lack of lifetime tracking in C++.