Use the On-Screen Display feature to report the fact. The user should be told to install additions that are provided with the current VBox build: VBOX_VERSION_MAJOR.VBOX_VERSION_MINOR.VBOX_VERSION_BUILD
Just keep quiet about failures now - we'll fail here because we're not allowed to raise our own priority. This is a problem when starting the threads with higher priority from EMT (i.e. most threads it starts). This is apparently inherited from the parent in some cases and not in other cases. I guess this would come down to which kind of pthread implementation is actually in use, and how many sensible patches which are installed. I need to find a system where this problem shows up in order to come up with a proper fix. There's an pthread_create attribute for not inherting scheduler stuff I think...
We don't support wrapping calls taking a va_list yet. It's not worth it yet, since there are only a couple of cases where this fprintf implementation is used. (The macro below will deal with the majority of the fprintf calls.)
r=bird: In the long run we should just do the interrupt handling in EM/CPUM/TRPM/somewhere and if we cannot execute the interrupt handler in raw-mode just reschedule to REM. Once that is done we remove this kludge.
This is a workaround for synchronization problems between EMT and the SDL main thread. It can happen that the SDL thread already starts a new resize operation while the EMT is still busy with the old one leading to a deadlock. Therefore we call SetVideoModeHint only once when the mouse button was released.
The current implementation is very brute force... Rewrite it so that it doesn't flush the cache completely but simply checks whether anything has changed in the HID config. With any luck, there might even be a callback or something we can poll for HID config changes... setRemovalCallback() is a start...
r=bird: You should've requested a better RTFileOpen API! This code could certainly have benefitted from it. I've done the long overdue adjustment of RTFileOpen so it better reflect what a decent OS should be able to do. I've also added some OS specific flags (non-blocking, delete sharing), and I'm not picky about adding more if that required. (I'm only picky about how they are treated on platforms which doesn't support them.) Because of the restrictions in the old version of RTFileOpen this code contains dangerous race conditions. File creation is one example where you may easily kill a file just created by another user.
implement uAlignment properly... We'll probably need to make some dummy mappings to fill up alignment gaps. This is of course complicated by fragmentation (which we might have cause ourselves) and further by there begin two mmap strategies (top / bottom).
we should add a priority priority to the queues so we don't have to rely on the initialization order to deal with problems like #1605 (pgm/pcnet deadlock caused by the critsect queue to be last in the chain). Update, the critical sections are no longer using queues.
All the string MMIO stuff can do terrible things since physical contiguous mappings are assumed all over the place! This must be addressed in a general way, like for example let EM do all the interpretation and checking of selectors and addresses.
Check if the A20 enable/disable method implemented here in any way should cooperate with the one implemented in the PS/2 keyboard device. This probably belongs together in the PS/2 keyboard device (since that is where the "port B" mentioned by Ralph Brown is implemented).
this isn't safe. a scheduling interrupt on the other cpu while we're in here could cause the thread to be timed out before we manage to wake it up and the event ends up in the wrong state. ditto for posix signals.