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?
> In this setup, how would cross-core communication work, including cross-thread?
Communication via shared memory. DOS and friends run on core 0 more or less normally; core 1 runs your alternate programming. Allocate a shared ring buffer for messages in each direction, core 0 writes messages and updates the written index on one, reads messages and updates the read index on the other; vice version for core 1. Core 1 probably spins on checking the indexes if it doesn't have anything else to do.
Either allocate a big chunk of memory for core 1 work at startup, or let it message core 0 to allocate. Don't let core 1 call into DOS/BIOS syscalls directly or you'll have a big mess.
Next step in efficiency would be letting core 1 sleep when it's bored and use an inter-processor interrupt (IPI) to wake it up as needed.
That's not true - DOS lacks multitasking but it absolutely has a concept of processes. They're called PSPs (program segment prefixes, a struct containing data about that process) and the OS has a range of syscalls to manage them. Any program can spawn a child program and wait for its completion.
The memory allocation syscalls track which program owns each dynamically allocated block of memory (the block has a header which points to the PSP), and frees the blocks allocated by a program when it exits. The filesystem syscalls deal with file handles opened by processes in just the same way.
The famous "terminate and stay resident" syscall causes a program to exit and return to its parent process while keeping its PSP and dynamically allocated memory blocks intact.
16 bit Windows introduced multitasking but reused DOS's PSP based process model and would allocate a PSP for each Windows task, switching the current DOS PSP when switching between Windows tasks.
DOS has no concept of multiple cores, much less threads. Multiprocessing in such an environment "works" mainly for the same reason why pthreads and friends "worked" in the decades before C++11 standardized a memory model for native code. The hardware and your code must conspire to work around the part that isn't thread-aware.
Nothing is really stopping you from using the underlying hardware for concurrent execution, but at the same time DOS (and possibly BIOS/UEFI???) will blow chunks if you don't carefully synchronize access to it. Cross-core communication works exactly the same as it does in kernel-mode systems programming; and you need to bring your own synchronization primitives on top of the ones x86 processors ship with. You're basically writing an OS kernel at that point; one that just so happens to support kexec-ing back into COMMAND.COM and using bits of it as a filesystem driver.
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?
> In this setup, how would cross-core communication work, including cross-thread?
Communication via shared memory. DOS and friends run on core 0 more or less normally; core 1 runs your alternate programming. Allocate a shared ring buffer for messages in each direction, core 0 writes messages and updates the written index on one, reads messages and updates the read index on the other; vice version for core 1. Core 1 probably spins on checking the indexes if it doesn't have anything else to do.
Either allocate a big chunk of memory for core 1 work at startup, or let it message core 0 to allocate. Don't let core 1 call into DOS/BIOS syscalls directly or you'll have a big mess.
Next step in efficiency would be letting core 1 sleep when it's bored and use an inter-processor interrupt (IPI) to wake it up as needed.
DOS barely has any concept of processes, let alone threads.
So it’ll all be very do it yourself. Of course with everything running in ring 0, there’s not much that’s going to get in the way of you.
> DOS barely has any concept of processes
That's not true - DOS lacks multitasking but it absolutely has a concept of processes. They're called PSPs (program segment prefixes, a struct containing data about that process) and the OS has a range of syscalls to manage them. Any program can spawn a child program and wait for its completion.
The memory allocation syscalls track which program owns each dynamically allocated block of memory (the block has a header which points to the PSP), and frees the blocks allocated by a program when it exits. The filesystem syscalls deal with file handles opened by processes in just the same way.
The famous "terminate and stay resident" syscall causes a program to exit and return to its parent process while keeping its PSP and dynamically allocated memory blocks intact.
16 bit Windows introduced multitasking but reused DOS's PSP based process model and would allocate a PSP for each Windows task, switching the current DOS PSP when switching between Windows tasks.
DOS has no concept of multiple cores, much less threads. Multiprocessing in such an environment "works" mainly for the same reason why pthreads and friends "worked" in the decades before C++11 standardized a memory model for native code. The hardware and your code must conspire to work around the part that isn't thread-aware.
Nothing is really stopping you from using the underlying hardware for concurrent execution, but at the same time DOS (and possibly BIOS/UEFI???) will blow chunks if you don't carefully synchronize access to it. Cross-core communication works exactly the same as it does in kernel-mode systems programming; and you need to bring your own synchronization primitives on top of the ones x86 processors ship with. You're basically writing an OS kernel at that point; one that just so happens to support kexec-ing back into COMMAND.COM and using bits of it as a filesystem driver.
> ERR_HTTP2_PROTOCOL_ERROR
Hm?