On 09/25/2013 07:13 PM, Tomas Hajny wrote:
Anyway, interesting thread. ;-) Still, the overall goal (or set of
goals) is not clear for me
My intention with this was the (original) POSIX thread definition, that
(IIRC) does not require or rely on an external OS that (besides
multitasking
On Thu, September 26, 2013 09:39, Michael Schnell wrote:
On 09/25/2013 07:13 PM, Tomas Hajny wrote:
Anyway, interesting thread. ;-) Still, the overall goal (or set of
goals) is not clear for me
My intention with this was the (original) POSIX thread definition, that
(IIRC) does not require or
Am 26.09.2013 11:07, schrieb Tomas Hajny:
Here the old style (light weight / internal multi-thread enabled)
pthread lib might help. Supposedly same does not need to be installed
but could be statically linked to.
You can run another operating system on top of DOS (that's basically what
DOS
On 09/26/2013 11:07 AM, Tomas Hajny wrote:
Well, there are certain assumptions for the POSIX thread definition
regarding the underlying operating system - e.g. compliancy of the
underlying operating system to other parts of POSIX (which is
certainly not fulfilled in case of DOS).
Only _if_
Another appropriate link:
http://www.e-reading.mobi/chapter.php/143358/128/Tanenbaum_-_Distributed_operating_systems.html
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
In fact here seems to be a library that might be usable:
http://www.arl.wustl.edu/~fredk/Courses/OS/wuthreads.html
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
(Sorry for multiple posts)
Yet another link:
http://maxim.int.ru/bookshelf/PthreadsProgram/htm/r_47.html
states that there is (or might be) a pthread implementation Based on
pure user space .
-Michael
___
fpc-devel maillist -
On Thu, September 26, 2013 11:55, Michael Schnell wrote:
In fact here seems to be a library that might be usable:
http://www.arl.wustl.edu/~fredk/Courses/OS/wuthreads.html
All of your links refer to Unix (or even explicitly Linux). Even just the
definition of kernel space and user space gives
On 09/26/2013 01:28 PM, Tomas Hajny wrote:
suggests that pre-emptive multithreading is hardly possible (if at
all) with pure user space implementation; FPC TThread design is based
on an assumption of a pre-emptive multithreading.
In fat, already many years ago, I did write a preemptive
On 26.09.2013 13:51, Michael Schnell wrote:
On 09/26/2013 01:28 PM, Tomas Hajny wrote:
suggests that pre-emptive multithreading is hardly possible (if at
all) with pure user space implementation; FPC TThread design is based
on an assumption of a pre-emptive multithreading.
In fat, already
On 26.09.2013 13:28, Tomas Hajny wrote:
On Thu, September 26, 2013 11:55, Michael Schnell wrote:
In fact here seems to be a library that might be usable:
http://www.arl.wustl.edu/~fredk/Courses/OS/wuthreads.html
All of your links refer to Unix (or even explicitly Linux). Even just the
Michael Schnell schrieb:
On 09/26/2013 01:28 PM, Tomas Hajny wrote:
suggests that pre-emptive multithreading is hardly possible (if at
all) with pure user space implementation; FPC TThread design is based
on an assumption of a pre-emptive multithreading.
In fat, already many years ago, I did
On Thu, September 26, 2013 14:11, Sven Barth wrote:
On 26.09.2013 13:28, Tomas Hajny wrote:
On Thu, September 26, 2013 11:55, Michael Schnell wrote:
In fact here seems to be a library that might be usable:
http://www.arl.wustl.edu/~fredk/Courses/OS/wuthreads.html
All of your links refer to
On 09/26/2013 02:04 PM, Hans-Peter Diettrich wrote:
But I doubt that your kernel can run on top of DOS :-(
It did.
I did my first step this way, before I got hardware and development
tools for 68 K.
-Michael
___
fpc-devel maillist -
On 09/26/2013 02:09 PM, Sven Barth wrote:
But on bare metal you don't have the OS in your way and thus can of
course implement preemptive multithreading as other operating systems
are also able to implement preemptive multithreading...
How do you think DOS would get in the way ?
As this is
On Thu, September 26, 2013 14:45, Michael Schnell wrote:
On 09/26/2013 02:09 PM, Sven Barth wrote:
But on bare metal you don't have the OS in your way and thus can of
course implement preemptive multithreading as other operating systems
are also able to implement preemptive multithreading...
On 09/26/2013 02:59 PM, Tomas Hajny wrote:
...except when it uses just any RTL function..
Supposedly nearly all RTL function in DOS are not problematic as they
either do simple stuff (get the current time - even this supposedly is
done without a DOS call), do unrelated stuff (disk I/O) or
On 26.09.2013 14:23, Tomas Hajny wrote:
On Thu, September 26, 2013 14:11, Sven Barth wrote:
On 26.09.2013 13:28, Tomas Hajny wrote:
On Thu, September 26, 2013 11:55, Michael Schnell wrote:
In fact here seems to be a library that might be usable:
On Thu, September 26, 2013 15:20, Michael Schnell wrote:
On 09/26/2013 02:59 PM, Tomas Hajny wrote:
...except when it uses just any RTL function..
Supposedly nearly all RTL function in DOS are not problematic as they
either do simple stuff (get the current time - even this supposedly is
done
On 09/26/2013 03:31 PM, Tomas Hajny wrote:
Actually, disk I/O is _highly_ related
I don't see how it would interfere with program - internal multithreading.
(as are all standard console I/O operations).
IIRC, the TurboPascal RTL did this without using DOS or BIOS. Maybe the
FPC RTL works
Here is output from the 2.4.5 Compiler and the 2.62 compiler. of the following
program
compiled the same way.
It has always been possible to eliminate runtime checking when incrementing a
byte/word in
this way (if one wants the byte to roll over).
This is not possible with the 2.6.2 compiler.
On 26.09.2013 16:21, Carsten Bager wrote:
Here is output from the 2.4.5 Compiler and the 2.62 compiler. of the following
program
compiled the same way.
It has always been possible to eliminate runtime checking when incrementing a
byte/word in
this way (if one wants the byte to roll over).
On 26.09.2013 17:13, Jonas Maebe wrote:
On 26 Sep 2013, at 16:21, Carsten Bager wrote:
Here is output from the 2.4.5 Compiler and the 2.62 compiler. of the
following program
compiled the same way.
It has always been possible to eliminate runtime checking when
incrementing a byte/word in
this
On 26 Sep 2013, at 16:21, Carsten Bager wrote:
Here is output from the 2.4.5 Compiler and the 2.62 compiler. of the
following program
compiled the same way.
It has always been possible to eliminate runtime checking when
incrementing a byte/word in
this way (if one wants the byte to roll
2013/9/25 Tomas Hajny xhaj...@hajny.biz
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
DOS extenders are even worse candidates for multitasking than DOS. And if
you aim to use 32-bit anyway, I see no reason to use an DOS extender over a
real multitasking OS.
Leif
- Original Message -
From: Michael Schnell mschn...@lumino.de
To: fpc-devel@lists.freepascal.org
Sent:
The problem with multitasking under DOS is that the DOS int 21h call will
switch stacks before doing anything useful. That means you cannot multitask
DOS calls in the same virtual machine (unless you provide a fully emulated
DOS environment as my RDOS OS did some 10 years ago). BIOS is less
It works as long as you don't try to reenter DOS (because the DOS API
switches stacks).
DOS never sleeps. DOS is invoked as you use int 21h.
Leif
- Original Message -
From: Michael Schnell mschn...@lumino.de
To: fpc-devel@lists.freepascal.org
Sent: Thursday, September 26, 2013 2:45
On 09/25/2013 08:13 PM, Tomas Hajny wrote:
Anyway, interesting thread. ;-) Still, the overall goal (or set of goals)
is not clear for me from the limited context included:
Ok, here's my point:
Since the FPC RTL offers pluggable thread manager support, we can offer
multiple implementations.
On 09/26/2013 08:24 PM, Leif Ekblad wrote:
DOS extenders are even worse candidates for multitasking than DOS. And
if you aim to use 32-bit anyway, I see no reason to use an DOS
extender over a real multitasking OS.
Low resource usage perhaps. How well does Linux run on a 386 with 4 MB
of RAM?
RDOS (my OS) runs well on an 386 with 4MB, but it no longer supports
emulating DOS, and the FPC adaption I did many years ago probably is broken.
OTOH, it would be possible to adapt the FPC RTL to RDOS, provided it is
thread-safe, and that way provide a light-weight environment. I have an RTL
Sven Barth schrieb:
Well, we do have a TThread.Yield procedure since the last time I worked
on TThread :)
What does it do on a DOS target?
DoDo
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 26.09.2013 19:48, Nikolay Nikolov wrote:
On 09/26/2013 08:24 PM, Leif Ekblad wrote:
DOS extenders are even worse candidates for multitasking than DOS. And
if you aim to use 32-bit anyway, I see no reason to use an DOS
extender over a real multitasking OS.
Low resource usage perhaps. How
On 26.09.2013 14:14, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
Well, we do have a TThread.Yield procedure since the last time I
worked on TThread :)
What does it do on a DOS target?
Currently it will print this:
=== output begin ===
This binary has no thread support compiled in.
On 09/26/2013 09:25 PM, Sven Barth wrote:
On 26.09.2013 19:48, Nikolay Nikolov wrote:
On 09/26/2013 08:24 PM, Leif Ekblad wrote:
DOS extenders are even worse candidates for multitasking than DOS. And
if you aim to use 32-bit anyway, I see no reason to use an DOS
extender over a real
Nikolay Nikolov schrieb:
On 09/26/2013 08:24 PM, Leif Ekblad wrote:
DOS extenders are even worse candidates for multitasking than DOS. And
if you aim to use 32-bit anyway, I see no reason to use an DOS
extender over a real multitasking OS.
Low resource usage perhaps. How well does Linux run on
On 09/26/2013 09:41 PM, Hans-Peter Diettrich wrote:
Nikolay Nikolov schrieb:
On 09/26/2013 08:24 PM, Leif Ekblad wrote:
DOS extenders are even worse candidates for multitasking than DOS.
And if you aim to use 32-bit anyway, I see no reason to use an DOS
extender over a real multitasking OS.
On Thu, September 26, 2013 21:03, Nikolay Nikolov wrote:
On 09/26/2013 09:41 PM, Hans-Peter Diettrich wrote:
Nikolay Nikolov schrieb:
On 09/26/2013 08:24 PM, Leif Ekblad wrote:
DOS extenders are even worse candidates for multitasking than DOS.
And if you aim to use 32-bit anyway, I see no
On 09/26/2013 11:33 PM, Tomas Hajny wrote:
On Thu, September 26, 2013 21:03, Nikolay Nikolov wrote:
On 09/26/2013 09:41 PM, Hans-Peter Diettrich wrote:
Nikolay Nikolov schrieb:
On 09/26/2013 08:24 PM, Leif Ekblad wrote:
DOS extenders are even worse candidates for multitasking than DOS.
And
On Thursday, September 26, 2013 1:24 PM, Leif Ekblad l...@rdos.net wrote:
DOS extenders are even worse candidates for multitasking than DOS. And if
you aim to use 32-bit anyway, I see no reason to use an DOS extender over a
real multitasking OS.
does that include old systems like PC-MOS?
Nikolay Nikolov schrieb:
On 09/26/2013 09:41 PM, Hans-Peter Diettrich wrote:
Nikolay Nikolov schrieb:
On 09/26/2013 08:24 PM, Leif Ekblad wrote:
DOS extenders are even worse candidates for multitasking than DOS.
And if you aim to use 32-bit anyway, I see no reason to use an DOS
extender over
Tomas Hajny schrieb:
My first notebook had 4 MB RAM, and Win3.1 and Word 1.0 worked very
well on it :-)
Yes, but windows 3.1 is a DOS extender :)
Yes. Moreover, an extender not featuring multi-threading and even the
multitasking wasn't preemptive if I remember correctly.
I remember running
42 matches
Mail list logo
