Custom Query (80 matches)

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.

The standard file open/save dialog is seriously broken in the current Odin builds: it doesn't allow to navigate through the file system properly and can't be even dismissed with OK or Cancel buttons.

This is in particular seen in Java AWT applications that use this dialog.

There is one incompatibility with GCC 4.7.3 in Odin: the PE and PEC tools.

They use custom startup code (to reserve as low virtual address in private memory space as possible — this is vital for some WIn32 .EXE files which have the very low virtual entry point which we must be able to provide as there is 1-to-1 address mapping).

However, GCC 4.7.3 puts a reference to __ehInit (C++ exception handling) in each object file it generates. And since we don't link to the normal CRT startup code in case of PE/PEC, this symbol remains undefined. This seems like a bug of GCC, more details are here: ​https://github.com/psmedley/gcc/issues/8.