This is interesting as an example of something that can be done on NTVDM but generally not other DOS emulation solutions such as DOSBox. A DOS program running in NTVDM can have a Windows console application as a subprocess; other DOS emulation solutions such as DOSBox generally don't support that. So a QBASIC program running under NTVDM can use the SHELL statement to run a Windows console program.

Part of how this works is that NTVDM uses the Windows console to host DOS applications. By contrast, DOSBox shows them in a Windows GUI window, not a console window. In principle, DOSBox could display them in a console window too; that works fine for text mode applications, but it can't support graphics. But, actually, NTVDM can run graphical applications in a Windows console window – how? Well, the legacy Windows console subsystem actually supports two different kinds of console buffers – text and graphics – but only the former is documented. NTVDM creates a graphics buffer for graphical DOS applications using an undocumented CONSOLE_GRAPHICS_BUFFER flag to the CreateConsoleScreenBuffer API – http://blog.airesoft.co.uk/2012/10/things-ms-can-do-that-the... – regrettably, creating a console graphics buffer is broken on 64-bit Windows. Another method that would still work on 64-bit Windows is GetConsoleWindow to get HWND of the console Window and draw on it manually. But Microsoft is discouraging console APIs such as CreateConsoleScreenBuffer and GetConsoleWindow since they don't work with pseudoconsoles (Windows 10 equivalent to Unix ptys) – and it actually looks like in more recent Windows code the CONSOLE_GRAPHICS_BUFFER API flag is gone – see https://github.com/microsoft/terminal/blob/fb597ed304ec6eef2... and https://github.com/microsoft/terminal/issues/246