[Lazarus] Why development remains constant for msdos?

[Nikolay Nikolov]

On 09/25/2013 11:26 AM, Michael Schnell wrote:
> On 09/24/2013 10:58 AM, Nikolay Nikolov wrote:
>>
>> When you try to create a thread, your program terminates and writes a 
>> message that threading is not supported.
>
> While this absolutely does make sense, one could think about 
> alternatives.
>
> AFAIK, (at least for some archs) there is a variant of the pthread 
> (="POSIX thread") library, that internally does "user-land 
> multithreading". IIRC, the original POSIX definition was done with 
> exactly this in mind and, regarding Linux, the original Linux 
> implementations (aka "Linux Threads")  was not fully compatible with 
> POSIX. Only some years ago, the Linux changed it's way of Kernel-based 
> thread handling to the POSIX compatible "NPTL" implementation.
>
> Thus it should be possible to link fpc projects to a user-land thread 
> enabled version of pthreadlib and allow for working with TThread in DOS.

I've actually thought about implementing some sort of multithreading for 
DOS for a long time. The problems are the following:

1) DOS functions are not reetrant and are thus not safe to call from 
different threads. There's an undocumented InDOS flag that indicates 
whether a DOS function is safe to call:

http://stanislavs.org/helppc/int_21-34.html

But the RTL currently doesn't check it before every call and normally 
it's only used when writing TSRs.

2) In DPMI protected mode applications (such as go32v2), you cannot 
modify the return address from within an interrupt handler, which means 
you cannot implement your task scheduler as a timer interrupt handler, 
because you won't be able to switch to a different context from there. 
Doing this would require modifications to the DPMI host (cwsdpmi.exe) 
and will not work if another DPMI host is active (such as when running 
in a windows dos prompt, etc.)

3) Even if you solve 2), DPMI requires that all code and data touched 
from an interrupt handler to be locked, so that it cannot be swapped 
out. This is a tedious and error prone task to do from a high level 
language such as pascal. You should ensure that your entire scheduler's 
code and data are locked. An alternative option is to switch to a DPMI 
host, that doesn't support swapping (i.e. cwsdpr0.exe), but then you 
lose the virtual memory support (and thus the ability to run on machines 
that don't have enough memory).

2) and 3) do not apply to 16-bit MS-DOS.

Another option is to implement cooperative multitasking, which would 
require each thread to call periodically an yield function. This solves 
1), 2) and 3), but threaded code written for other OSes will require 
modifications to run under DOS. However, that's still better than not 
running at all.

Nikolay