- People who are interested in DOS software might take note of "Pits", a DOS assembler demo from 2024 which features, quote:
- Multithreading (using all hyper-threads / CPU cores)
- Video mode up to Full HD (1920x1080 / 16 bpp)
- 64-iterative ray-casting
- Pure DOS with Protected Mode (no drivers, no DPMI)
https://www.pouet.net/prod.php?which=96532It is a seriously technically impressive demo, if not being the most visually impressive.
by vintagedave
3 subcomments
- So this seems to be a mystery binary someone found on a company DVD, that runs DOS on one core and runs another core with code but no interrupts etc. Fascinating.
The thread later mentions a second way to do it.
In this setup, how would cross-core communication work, including cross-thread? On DOS is there even the concept of threads, or would an app using this have to invent user-mode thread objects and scheduling?
by stevefan1999
0 subcomment
- Well, even so, multicore nowadays is supposedly just running the kernel over different CPUs by treating each CPU as its independent computer, and use a message box to deliver event messages, that's how x86 works with APIC and SIPI
by userbinator
0 subcomment
- I wouldn't necessarily call this "support" because DOS itself does nothing for or against; and "all" you need to do conceptually is tickle the APIC to get the other cores running, something that can be done easily even in flat real mode (but this sample appears to use DPMI, so protected mode --- and DPMI itself begins to contain the elements of an OS.)
Not surprised to see the German comments; a lot of low-level PC stuff came from there in the 80s and 90s.
- Pastebin links here in case someone's getting Vogons issues.
https://pastebin.com/9sgW9dVu
https://pastebin.com/3rG2eiWD
I seriously wonder how many APICs are exposed in the DOSBOX code even... Would be a fun exercise to do this and wake up real mode on all cores. I know it's easy to get to long mode after that:
https://github.com/guilt/KOS/blob/master/os/src/x86/realprot...
- Certainly if you do not call out to DOS or the BIOS! All the time with DOS we would write text to the screen by writing it into memory because it was so fast and if you wrote a terminal emulator you would catch the interrupts and write to the UART registers in assembly or C or Turbo Pascal. You only needed DOS for the filesystem otherwise the application could do anything that DOS could do.
Old versions of Linux had a giant lock on the whole kernel which would let only one CPU enter the kernel at once. You could probability protect DOS the same way at the cost of scalability.
- Well, according to the legend the main reason for MS-DOS 4.x failure was the attempt to rewrite it to be multitasking proper.
https://en.wikipedia.org/wiki/MS-DOS_4.0_(multitasking)
- > ERR_HTTP2_PROTOCOL_ERROR
Hm?
- KA9Q?
Hacker News