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
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
On Thursday, September 26, 2013 1: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.
does that include old systems like PC-MOS?
ok, maybe
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 if
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,
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.
Lo
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: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 multitaskin
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.
Rec
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 well
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
http://lists.freepascal.org/mailman/listinfo/f
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
i
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? W
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. J
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"
To:
Sent: Thursday, September 26, 2013 2:45 PM
Subject: Re: [fpc-devel] Multithreading u
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
pro
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"
To:
Sent: Thursday, September 26, 2013 9:39 AM
Subject: Re:
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 o
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.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).
This
2013/9/25 Tomas Hajny
> 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 develop
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 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 di
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
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:
http://www.arl.wustl.edu/~fredk/Courses/OS/wuth
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 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 multithr
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
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 - fpc-devel@l
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
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 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
definit
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 many
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 multith
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"
(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 - fpc-devel@lists.
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
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
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_ th
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 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 req
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 multipl
42 matches
Mail list logo
