Thanks LSS, you are running another newer version that relied on new symbols, I added those it might work now. I addresses some keyboard mapping issues between OS personalities and other fixes. Also fixed executing across personalities in the different versions.

@superfure Excellent I will test more tonight.

As a hat tip to the excellent work on rust-dos by dividebysandwitch I added rat commander as the linux personality tui.

Some tests with the recent release.

Windows versions of NDN and DN/2 now works.
DN/2 OS/2 version still doesn't work.

1synth_fork_exec entry: ds=0625 dx=87DC es=0625 bx=86C6
2synth_fork_exec: filename="DN.EXE" tail.len=0 tail_first8=[]
3handle_fork_exec: "C:\\DN2O214\\DN.EXE" size=1053524 format=lx free_pages=26528
4  fork done, loading protected-mode image...
5OS/2: unresolved NLS ordinal 7
6OS/2: cannot fix up module DN.EXE
7Bad command or file name: 'DN.EXE'

Not sure if this matters for NDN OS/2 version but I noticed these OS/2 log messages in the klog when launching it.
NDN OS/2 itself works, however.

1synth_fork_exec entry: ds=0625 dx=87DA es=0625 bx=86C4
2synth_fork_exec: filename="NDN.EXE" tail.len=0 tail_first8=[]
3handle_fork_exec: "C:\\NDN-O32\\NDN.EXE" size=1459451 format=lx free_pages=26414
4  fork done, loading protected-mode image...
5  child tid=2, parent tid=1 continues without blocking
6WARNING: sound underrun #4 written_frames=4844813 consumed_frames=4845740
7OS/2: unresolved PMWIN ordinal 701
8OS/2: unresolved PMSHAPI ordinal 115
9OS/2: unresolved PMSHAPI ordinal 114
10
11Necromancer's Dos Navigator v3.00.0012v/OS/2. 
12Based on Dos Navigator by Ritlabs...
13[DEFINES/CPU86/CPU87/OS2/VIRTUALPASCAL]
14* OS/2 (v20.45 rev. 0) detected...
15* Process ID = 3 ...
16* PCRE Version 8.45 2021-06-15
17
18OS/2: unsupported Base(272) args=0x3,0x4,0x4,0x3

On the other hand, sound underrun messages still spams the log a bit (as seen in the NDN log), even though sound is working without apparent issues.
I wonder if there are options to mitigate it somehow.

Besides, it seems I cannot launch any other OS ports of NDN from the DPMI32 version of NDN, complaining about "This program must be run under xxx" (xxx being Win32 or OS/2 depending on the port type). Perhaps this is a limitation.

And by the way... I wonder if it's somehow possible to make Windows or OS/2 processes run fullscreen, as "Make window/Make fullscreen" doesn't seem to have any effect on Windows or OS/2 processes (such as NDN ports) at the moment.

EDIT: I noticed something odd with DN/2 Windows version. In the bottom line where it shows the info of the selected file (file name, size, timestamp), only the file name is being shown correctly, while the size and timestamp appear garbled.

I downloaded DN/2 and fixed the issues. garbled text was a windows locale syscall missing. It seems to work for me.

Right now os2, windows and linux are all composited. I should make a fullscreen/resize solution.

I added vga-uni unicode rendering and unicode support for linux,win,os2 and a locale in config.sys. DN/2 should display correctly in Cyrillic (this was the garbled text). Keyboards should also work for different countries.

LOCALE=nl-NL in config.sys, not all combinations are added.

Did a boot test on my H97 system.
Still hangs with cursor blinking on the very first line.
But looks like there are additional messages now, apart from memory range listing.

1Boot: framebuffer init
2Boot: framebuffer ready
3Boot: ACPI timer search
4HPET: ACPI base 0xfed00000 (Multiboot2 ACPI tag)
5Boot: IRQ init

I wonder if this means an issue with IRQ with Intel 9 series.

Testing this on my B75 system and got a kernel panic when running DN/2 OS/2 version.
Apparently, this kernel panic happens on pretty much everything that switches from native VGA to Framebuffer.
Including both Windows and OS/2 versions of DN/2 and NDN.
In fact, just by pressing F12 to open the host monitor menu is enough to trigger it (system hangs with a black screen, probably a panic whose output is not visible).
Probably a regression as I did not encounter this kind of panic before.
I'm not exactly on 0.8.0 but on your latest commit (d39a418), using build artifact from the CI workflow (retroos-<full commit hash>).
This is a panic when running Windows versions of DN/2 or NDN.

1!!! KERNEL PANIC !!!
2RetroOS kernel v0.8.0-2-gd39a4182
3at arch-metal/src/traps.rs:1017
4Arch: OOM during kernel heap demand paging
5
6RetroOS kernel v0.8.0-2-gd39a4182
7Stack trace:
8   0: 0xc0b0b267 <core::fmt::Formatter>::pad_integral+0x0
9   1: 0xc0b0d46c core::panicking::panic_nounwind_fmt+0x0
10   2: 0xc0b0d44d core::panicking::panic_display::<&str>+0x0
11   3: 0xc0b08ada arch_metal::traps::try_handle_page_fault+0x2af
12   4: 0xc0b08ea1 arch_metal::traps::isr_handler_ring1+0x4b
13   5: 0xc0b080d5 isr_handler+0x6dd
14   6: 0xc0bffdd7
15   7: 0xc0bdaade __rustc::__rust_alloc_zeroed+0x1f
16   8: 0xc0b00146 <alloc::alloc::Global>::alloc_impl+0x1b
17   9: 0xc0b0061d <alloc::raw_vec::RawVecInner>::try_allocate_in+0x42
18  10: 0xc0b0f3c7 alloc::vec::from_elem::<u8>+0x5b

I do not encounter this panic on my X570 system which is booting with UEFI (GOP Framebuffer).
Both Windows and OS/2 versions of DN/2 and NDN launched fine (from DNOSP 6.4.0 Real-mode).
Windows version of DN/2 still has the garbled info line despite the UI language is already set to English. Not sure why.
The OS/2 version of DN/2 seems to use Russian by default (probably because I'm using en-US locale so it can't render Cyrillic), switching to English and everything (including the info line) looks fine.

@LSS it looks like physical memory exhaustion allocating the buffer for compositing. The full klog would be helpful, then I can see what mode (how much mem for the framebuffer) and how much memory is available.

I'll try to shore up some mem inefficiencies. I need to refactor the allocator and page sharing some more.

I improved the memory / page allocation, it should now have access to all memory available. I added more diagnostics on booting that might shine some light on the h97 problem.