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.

gsos wrote on Yesterday, 23:44:

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.

Some quick test results with the latest commit.

On my B75 the OOM is no longer there. However, it seems for some reasons, both Windows and OS/2 versions of DN/2 hang on launch and has to be killed via F12 menu.
The klog doesn't show much info apart from quite a few sound underrun spams.

After killing DN/2 the keyboard feels sluggish. However, I'm able to subsequently run both Windows and OS/2 versions of NDN fine, and after exiting from those versions, keyboard responsiveness restored to normal.

And as for the H97 system. This time it booted.
From the klog I'm able to see it correctly initialized the dISAppointment and performed ISA PnP.
However, it's not picking up my card (ESS1869) despite it's listed in the ISA PnP output, probably because it's not an official Creative Sound Blaster card.
I'm using hkzlab's ES1868_ISA8 card that I assembled. I'm using an ES1869F chip which also works, though with other OSes I still need to use ES1868 drivers. UNISOUND (using the /XEA option as suggested by the board author) can configure the card without any issue.

Though I'd like to know if there's a way to somehow store the active klog back to the USB stick even in Protected Disk mode.
As on some systems that I'm initially testing booting RetroOS with, there may not be any partition immediately available that I could let RetroOS use as backing partition for storing persistent klog files.

LSS10999 wrote on Today, 00:49:

On my B75 the OOM is no longer there. However, it seems for some reasons, both Windows and OS/2 versions of DN/2 hang on launch and has to be killed via F12 menu.

After killing DN/2 the keyboard feels sluggish. However, I'm able to subsequently run both Windows and OS/2 versions of NDN fine, and after exiting from those versions, keyboard responsiveness restored to normal.

This used to work before right? So this is a regression? Keyboard responsiveness is very weird, I have no idea at moment, how apps could influence that.

LSS10999 wrote on Today, 00:49:

And as for the H97 system. This time it booted. From the klog I'm able to see it correctly initialized the dISAppointment and pe […]
Show full quote

And as for the H97 system. This time it booted.
From the klog I'm able to see it correctly initialized the dISAppointment and performed ISA PnP.
However, it's not picking up my card (ESS1869) despite it's listed in the ISA PnP output, probably because it's not an official Creative Sound Blaster card.
I'm using hkzlab's ES1868_ISA8 card that I assembled. I'm using an ES1869F chip which also works, though with other OSes I still need to use ES1868 drivers. UNISOUND (using the /XEA option as suggested by the board author) can configure the card without any issue.

Huh?!? It now works, wow. Maybe it's the memory. I added ESS detection/initialization. Note: kernel mixing requites 16bit so only sb16, but sound blaster pro 2.0 should still allow for native use by dos apps. So if it now logs detection games should work with it.

LSS10999 wrote on Today, 00:49:

Though I'd like to know if there's a way to somehow store the active klog back to the USB stick even in Protected Disk mode.
As on some systems that I'm initially testing booting RetroOS with, there may not be any partition immediately available that I could let RetroOS use as backing partition for storing persistent klog files.

Yes, I realize next important thing is to have usb storage driver added. The usb stick workflow is the most convenient for starting so I'll add this. Thank you for testing.

gsos wrote on Today, 01:22:

This used to work before right? So this is a regression? Keyboard responsiveness is very weird, I have no idea at moment, how apps could influence that.

Yes this does appear as a regression, and I'm not sure what might have influenced the keyboard responsiveness.
- When launching OS/2 version I got a completely black screen but F12 can be called out to kill it.
- When launching Windows version I get a window and working mouse cursor but it seems to be stuck on loading for some reasons (a small white rectangle in the upper left) so I had to kill it.

When I went to launch Windows and OS/2 versions of NDN, however, they both started fine, and keyboard responsiveness returned to normal while inside NDN and after exit.

Maybe install fresh/delete dn.cfg or so. Maybe something wrong, i cant repro locally.

Questions:
- On your setup with SB16 (dISApointment) and HDA together, does live toggling while running a game playing on sound blaster between "kernel emulated" and native work?
- Does the new release work on your H97 with correct sb detection?
- Does the H97 boot now deterministically? Or was it a lucky boot, where some irq didn't happen in a critical section.