[fpc-devel] Multithreading under DOS (was: [Lazarus] Why development remains constant for msdos?)

[Tomas Hajny]

On Wed, September 25, 2013 17:40, Nikolay Nikolov wrote:
> On 09/25/2013 01:45 PM, Mark Morgan Lloyd wrote:
>> Nikolay Nikolov wrote:
>>> 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.
 .
 .
>>> 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.
>>
>> It's more complex than that: there's undocumented provision in DOS for
>> context switching under certain well-defined conditions, and each
>> context can invoke int 21h irrespective of other contexts' states.
>> That sort of thing was used fairly extensively by- for example- IBM
>> real-time control executives (RIC card etc.) but it wasn't until the
>> 1990s that it leaked to general knowledge see Ralph Brown's list).
> Interesting. I didn't know that. That makes it even more feasible to try
> to implement multithreading under real mode DOS.

In addition to the InDOS flag, DOS int 21h, AX=5D06h suggests some options
for addressing this topic too.

 .
 .
>> Whether it's really worth tackling, and whether any implementation can
>> be really reliable, are questions to be considered.
>>
> It's worth for the fun factor for me at least :) As for reliability, I
> bet you can make it as reliable as Windows 98 was at the time, which is
> not that great, as we all know, but still quite usable.
>
> Oh, and before I forget, later versions of DR-DOS have a version of
> emm386.exe which supports multitasking and has an API that supports
> creating processes and threads (from both real and dpmi protected mode) :
>
> http://www.drdos.net/documentation/multtask/
>
> This should be easy to implement under both i386-go32v2 and i8086-msdos.
> Since the FPC rtl has support for pluggable thread managers, it can be
> put in a unit like cthreads.

Anyway, interesting thread. ;-) Still, the overall goal (or set of goals)
is not clear for me from the limited context included:

If the goal is writing multi-threaded applications for existing pure DOS
machines, then using features of a special DR-DOS version may not be
relevant at all, because it imposes a considerable additional restriction
(it is not like that potential applications developed this way may be
simply run under the existing installations, but users would need to
install this particular version first).

If the goal is running light-weight multi-threaded FPC-compiled
applications on old/weak hardware using free operating systems (which may
need to be installed to support this application - as it would be the case
with DR-DOS too), then there are probably better options (e.g. some
fine-tuned Linux distribution).

If the goal is converting previously existing TP/BP applications written
for DOS to become multi-threaded, porting to a different target is
probably still easier, because the multi-threaded design will require
changes to the application anyway.

If the goal is just having some fun with low-level programming - OK,
understood; I would know some some other fairly low-level challenges, but
the fun factor of different topics is obviously purely individual.

Tomas