Custom Query (80 matches)

The current implementation of SEH (__try/__except) requires Odin to force the Win32 TIB switch mode in which the FS register points to the Win32 thread information block instead of the OS/2 one.

This mode is the default in Odin if it runs a Win32 binary as this is what the binary expects and needs. But in cases when we build Win32 apps from sources there is actually no sense in maintaining this FS context switch from OS/2 to Win32 and back. Even if the Win32 application not only uses __try/__except but also accesses FS directly, it can always be tailored with #ifdef (we can access the Win32 TIB with GetThreadTEB() regardless of the real FS value).

Switching FS may even be dangerous in some cases and this especially relates to situations when Win32 code calls OS/2 code and vice versa: the called party may not expect a wrong context (if e.g. it does its own exception handling since this is what FS is used mostly for). In either case, maintaining the context switch is error-prone per se due its complexity (you may look at e.g. sehutil.s to see it).

I have a guess that if we build a Win32 application from sources, we don't need to switch the FS register from the OS/2 TIB to the Win32 TIB and back. This is a continuation of the idea from #82 (which already eliminates the need to do this FS switch in order for SEH to work).

If we can get rid of this switch completely, we will get save ourselves from having a milky-way of function wrappers used to call OS/2 functions from the Win32 context (and the other way around). Getting rid of something is always good as it reduces chaos.

When using Odin in SDK mode, the console I/O is not done properly. This means that STDIN/STDOUT handles are implemented using a very restricted set of functions (HMDeviceStandardClass) which only implements reading and writing (regardless of if the handles are the real console or redirected to files etc).

As a result things like GetNumberOfConsoleInputEvents?() and PeekConsoleInput?() don't work in real console mode (although the code implementing them is present in classes HMDeviceConsoleInClass and HMDeviceConsoleOutClass). And things like SetFilePointer?() don't work in redirected mode (although the HMDeviceFile class implements them properly).

Due to these defects, the console I/O got partially broken after r22024 (which fixed a lot of inconsistencies in return codes). In particular, this affects Java which will throw an exception if you e.g. attempt to read something from STDIN.