Implement some FS opcodes used in windows dlls

[mittorn]

Used by exception handlers and TLS in win32

[ptitSeb]

Sounds good, but are you sure it works by just adding the segment content?
My understanding is the FS: on windows is similar to GS: on linux: so accessing TLS (Thread Local Storage) data? Maybe it would be needed to check the content of FS value, and if similar to GS, use the same mecanism?

[mittorn]

It only needed if you need to interact with native libraries, but native linux libraries does not use FS. So it should be enough until box86 ported to arm windows (but arm windows has own x86 translator). And different threads using different x86emu_t structs, i am right?

[ptitSeb]

Ok for FS: I'll add some code later, but I understand it will probably be not used on linux.

Different thread should be using different x86emu_t struct yes.
Note that now, you can create small x86emu_t from the stack. look at RunFunction(...) for example, that can be usefull in your case (you don't even need to create an x86emu_t sruct in that case, you just need a global box86context_t for it).

[mittorn]

I think, RunFunction is slow and eats many stack memory. and it still needs box86context. Single global should be enough for hl.dll as it single-threaded, but if some other games need dll in multi-threaded mode, it is possible to keep current context storage in TLS, which should make FS usage correct.

[ptitSeb]

RunFunction(...) eats some stack memory yes, but it's not slow. "Allocation" of memory on the stack is super fast (just a substraction from a register), much much faster than malloc (that is a functon call, doing many things).