Слайд-шоу | Уроки, извлеченные из кроссплатформенной разработки

class: middle

# Windows, macOS and the Web
## *Lessons from cross-platform development at think-cell*

Sebastian Theophil, think-cell Software, Berlin  
[stheophil@think-cell.com](stheophil@think-cell.com)

---
# The Problem

- 12 years of development for Windows only 
- About 1.000.000 lines of C++ 
- Pervasive use of Windows platform-specifics through-out code base
- Product is an add-in, dynamically loaded

--
    
- Not in control of the main application (nor the computer itself!)

???
- Needed toolkit giving us lots of flexibility
- Light weight abstractions for OS objects

--
  - Render into application-supplied objects: 
      - NSView, CALayer, HWND, DirectX texture
  - Renderer needs to support DirectX and OpenGL/Metal
  - Share the main message loop
  - Support platform-specific features like host application 
  
--
  
  
- Need cross-platform toolkit that hides platform specifics and **behaves identically** on different platforms

???

- Sandboxing or triple clicks on macOS
- Also need to interact cross-platform with files, interprocess shared memory, named semaphores.

---
class: agenda
# Agenda

1. **Levels of Abstraction: Handling Files**
2. Kernel Object Lifetimes: Interprocess Shared Memory
3. Diverging OS Behavior: Handling Mouse Events
4. Common Tooling I: Text Internationalization
5. Common Tooling II: Error Reporting
6. Moving to WebAssembly

---
# Levels of Abstraction
--

- How many ways to rename a file?
  
--

```cpp
BOOL MoveFileExW(LPCWSTR lpExistingFileName, LPCWSTR lpNewFileName, DWORD dwFlags)

int rename(char const* old, char const* new)

int renamex_np(char const* from, char const* to, unsigned int flags)
int copyfile(char const* from, char const* to, copyfile_state_t state,  
    The copyfile_flags_t flags)

bool QFile::rename(QString const& newName)
void boost::filesystem::rename(const path& old_p, const path& new_p)

- [NSFileManager replaceItemAtURL:withItemAtURL:backupItemName:  
    options:resultingItemURL:error:]
```

???

As a motivating example, consider the many different file rename/move functions on Windows, Posix and macOS, e.g.,
 
Which of these overwrite the target if it exists?

Which can move files and directories? Atomically?

Which fall back to copying if source and target are on different volumes?

To make matters more complicated: Which move the file’s ACL, or reapply the target location's ACL?

---
# Levels of Abstraction

- Hard to get identical semantics on different platforms

--
  
  
- We don't need a file rename function!
- **This is the wrong level of abstraction!**
- Need functions to 
  
--
  - create a user application settings file
  - create a temporary file that is automatically deleted but which can be opened by another application
  - download a file to a cache in thread-safe way
  - create a document in a user-specified folder,  
    open system-specific “Save File" dialog,  
    and create sandbox exception
  
  
- Functions with **strong** and **identical** semantics

???

Each of these functions might create files in different locations and with different access rights, depending on the best-practices of each operating system. And each of these functions has clear and strong semantics!

QStringList QStandardPaths::standardLocations(StandardLocation type) is close
QFile is not (sets same security descriptor and same sharing bits for each file)

---
# Levels of Abstraction

- Create a user application settings file
      - Windows: `%APPDATA%\think-cell [+ integrity level]\`
      - macOS: `~/Library/Application Support/think-cell/` or <br/> `~/Library/Group Containers/[Application Group Identifier]/`
      - Exclusive access while writing
      - Inherit ACL from parent folder

---
# Levels of Abstraction

- Create a temporary file that is automatically deleted but which can be opened by another application
  
```
CreateFile( 
*	"%TEMP%\\...", 
    FILE_GENERIC_READ|FILE_GENERIC_WRITE, 
    FILE_SHARE_READ, 
*	// make SECURITY_ATTRIBUTES FILE_ALL_ACCESS&~FILE_EXECUTE
*	// accessible by current user only, 
    CREATE_NEW, // the file should not already exist 
    FILE_ATTRIBUTE_TEMPORARY | FILE_ATTRIBUTE_HIDDEN 
*	| FILE_FLAG_DELETE_ON_CLOSE, 
    nullptr
);
// synchronize file access
```
???
- we make very different choices for temporary files

- integrity level: https://docs.microsoft.com/en-us/windows/win32/secauthz/mandatory-integrity-control
- security descriptor dacl: https://docs.microsoft.com/en-us/windows/win32/api/aclapi/nf-aclapi-setentriesinacla

---
# Levels of Abstraction

- Create a temporary file that is automatically deleted but which can be opened by another application

---
# Levels of Abstraction

- Cross-platform interfaces need to have well-defined, strong semantics

- Weak semantics lead to subtle errors
    - Warning sign: Having to look at the implementation

- Too high-level: You miss a chance to unify code 
- Too low-level: 
    - You'll force identical interfaces on very different things  
    - Semantics don't match operating system (`QFile::setPermissions`)  
    - or you lose a lot of expressiveness (`rename`)

???
- At least if you are writing good old Desktop applications!
- Especially for business customers that have IT administrators!

---
class: agenda
# Agenda

1. Levels of Abstraction: Handling Files
2. **Kernel Object Lifetimes: Interprocess Shared Memory**
3. Diverging OS Behavior: Handling Mouse Events
4. Common Tooling I: Text Internationalization
5. Common Tooling II: Error Reporting
6. Moving to WebAssembly

---
# Kernel Object Lifetimes

- We use shared memory to implement inter-process communication
- Boost.Interprocess (like Qt) offers a common API for shared memory on Windows and Posix

.center[<img src="/assets/en/career/talks/cross-platform/processes.png" style="width:60%;"/>]

---
# Kernel Object Lifetimes

- We use shared memory to implement inter-process communication
- Boost.Interprocess (like Qt) offers a common API for shared memory on Windows and Posix

- named memory objects mappable into different processes
    - `boost::interprocess::managed_shared_memory`

- pointers stored in shared memory
    - `boost::interprocess::offset_ptr`  
    - store offset to their own this pointer
    - shared memory can be mapped at different addresses

- named synchronization objects
    - `boost::interprocess::named_mutex`

---
# Kernel Object Lifetimes

Server process:
```
#include <boost/interprocess/managed_shared_memory.hpp>
...
using namespace boost::interprocess;
using T = std::pair<double, int>;

// Name specific to build version, host,  security identifier
char const szName[] = { ... };
managed_shared_memory seg(create_only, szName, /* size */ 65536);
T* p = seg.construct<T>("A") // name of the object
    (10.0, 0); // ctor first argument
```

Child process:
```
// Open managed shared memory
managed_shared_memory seg(open_only, szName);

// Find object
T* p = seg.find<T>("A").first;
assert(p->first == 10.0);
``` 
---
# Kernel Object Lifetimes

Server process:
```
#include <boost/interprocess/managed_shared_memory.hpp>
...
using namespace boost::interprocess;
using T = std::pair<double, int>;

// Name specific to build version, host,  security identifier
char const szName[] = { ... };
*managed_shared_memory seg(create_only, szName, /* size */ 65536);
T* p = seg.construct<T>("A") // name of the object
    (10.0, 0); // ctor first argument
```

Child process:
```
// Open managed shared memory
managed_shared_memory seg(open_only, szName);

// Find object
T* p = seg.find<T>("A").first;
assert(p->first == 10.0);
```
---
# Kernel Object Lifetimes
- **But**  `managed_shared_memory` does not use native Windows shared memory

```
HANDLE hMapFile = CreateFileMapping(
*   /* use page file */ INVALID_HANDLE_VALUE,
    /* security attributes */ NULL,
    PAGE_READWRITE, 
    0,
    /* size */ 256,
    /* object name */ szName);
```

- On Windows, if last process accessing the named memory segment dies, memory is freed
- **This is a feature you want**

... and not supported on Posix

---
# Kernel Object Lifetimes

- This seems to cause problems occasionally:
.center[<img src="/assets/en/career/talks/cross-platform/interprocess1.png" style="width:90%;"/>]
---
# Kernel Object Lifetimes

- This seems to cause problems occasionally:
.center[<img src="/assets/en/career/talks/cross-platform/interprocess2.png" style="width:90%;"/>]
---
# Kernel Object Lifetimes

- This seems to cause problems occasionally:
.center[<img src="/assets/en/career/talks/cross-platform/interprocess3.png" style="width:90%;"/>]
---
# Kernel Object Lifetimes

- This seems to cause problems occasionally:
.center[<img src="/assets/en/career/talks/cross-platform/interprocess4.png" style="width:90%;"/>]
---
# Kernel Object Lifetimes

- This seems to cause problems occasionally:
.center[<img src="/assets/en/career/talks/cross-platform/interprocess5.png" style="width:90%;"/>]
---
# Kernel Object Lifetimes

- On Windows, shared memory and mutexes are reference counted,   
i.e., when the last user dies or crashes, resource is freed

- On Posix, shared memory is either 
  1. File-backed:  
    backing file still exists if processes crash, even after reboot
  2. Posix shared memory (`shm_open`/`shm_unlink`):  
    backing memory persists until reboot

- Posix model assumes server-client model  
& Server owns shared memory object

- If not, there are two solutions to this problem.  
Boost.Interprocess and Qt implement **neither**

---
# Kernel Object Lifetimes

**1. Robust mutexes**

```
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
// Allow mutex to be placed in shared memory
pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);
// Mark mutex as robust
pthread_mutexattr_setrobust(&attr, PTHREAD_MUTEX_ROBUST);

pthread_mutex_t mtx;
pthread_mutex_init(&mtx, &attr);

[...]

if(EOWNERDEAD == pthread_mutex_lock(&mtx)) {
    // Owner of lock has died, reinitialize shared memory
}

```

[See Linux man pages](https://man7.org/linux/man-pages/man3/pthread_mutexattr_setrobust.3.html) and ❤️ this Boost.Interprocess pull request [https://github.com/boostorg/interprocess/pull/67](https://github.com/boostorg/interprocess/pull/67)

---
# Kernel Object Lifetimes

**2. File Locking**

- macOS does not support robust pthread locks unfortunately
- the only other resource that has process-lifetime are file locks

- **Attention!** File locks are weird on Posix as well:  
["Everything you never wanted to know about file locking" https://apenwarr.ca/log/20101213](https://apenwarr.ca/log/20101213)

- Please 👍 our Boost.Interprocess pull request [https://github.com/boostorg/interprocess/pull/132](https://github.com/boostorg/interprocess/pull/132)

---
# Kernel Object Lifetimes