I suppose something like this:
http://www.commell-sys.com/Product/SBC/LE-330.htm ?
Also i see some 64MB devices on other sites, although those run Linux fine.
On Fri, Sep 27, 2013 at 10:15 AM, Marco van de Voort wrote:
> In our previous episode, Nikolay Nikolov said:
> > > if you aim to use 32-b
On Fri, September 27, 2013 12:21, Bernd Oppolzer wrote:
> Am 26.09.2013 22:33, schrieb Tomas Hajny:
Hi Bernd,
.
.
>> Anyway, as I mentioned - I can imagine that it may be fun (similarly to
>> my attempts to keep and improve the OS/2 support which is also used very
>> rarely by others at best ;
On 09/27/2013 01:32 PM, Thaddy wrote:
Even that is TSR based, not a real multi-tasker.
Under DOS a process can be swapped out and re-activated by a hardware
interupt, either f.e. a timer or the keyboard.
So, at most, co-operative multi-tasking in the sense that multiple
processes can run at the
On 09/27/2013 01:28 PM, DaWorm wrote:
Perhaps you are thinking of Desqview/386?
Yeah !!! Happy memory comes back !!!
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Even that is TSR based, not a real multi-tasker.
Under DOS a process can be swapped out and re-activated by a hardware
interupt, either f.e. a timer or the keyboard.
So, at most, co-operative multi-tasking in the sense that multiple
processes can run at the same time.
Because DOS is non-re entra
On Sep 27, 2013 3:27 AM, "Michael Schnell" wrote:
>
> In fact I remember that there even was a "multitasking" add-on for DOS.
Same allowed for switching between multiple DOS desktops without needing a
graphical UI. I don't remember the features and the requirements.
Perhaps you are thinking of De
What's preventing any threading library from launching it's own
program in a virtual 8086 machine, thereby leaving dos in it's own
space. Any dos calls could simply be routed to that version of
already running dos. Dos supports redirection, so if it's just a
matter of getting some output,
Vmix was an excellent multitasker. Recently, it's been (partially)
released as opensource, though it's nowhere near as complete as the
old shareware product was. Vmix operated by the simple expedient of
creating a virtual 8086 machine for each simultaneous program the user
wished to run.
Am 26.09.2013 22:33, schrieb Tomas Hajny:
How much does the 386 CPU with 2 MB of appropriate RAM cost today? How
much power and cooling does it need? How much reliable would be the HW
compared to more up to date alternatives (let's say ARM or MIPS with 512
MB RAM and an SSD running Linux)?
Anyw
On Fri, September 27, 2013 09:21, Michael Schnell wrote:
> On 09/26/2013 07:31 PM, Leif Ekblad wrote:
.
.
>> DOS never "sleeps". DOS is invoked as you use int 21h.
>
> Yep. So the "DOS multithread RTL" flavor need to handle this whenever
> you do an int 21h.
"DOS multithread RTL" would be somet
On 27 Sep 2013, at 10:25, Marco van de Voort wrote:
> In our previous episode, Nikolay Nikolov said:
Low resource usage perhaps. How well does Linux run on a 386 with 4 MB
of RAM? What about 2 MB? :)
>>> Where can I buy machines with 4MB RAM? It will be hard to find a sub 256MB
>>> mac
In our previous episode, Nikolay Nikolov said:
> >> Low resource usage perhaps. How well does Linux run on a 386 with 4 MB
> >> of RAM? What about 2 MB? :)
> > Where can I buy machines with 4MB RAM? It will be hard to find a sub 256MB
> > machine.
> Here:
>
> http://www.ebay.com/sch/Vintage-Compu
On 09/27/2013 11:15 AM, Marco van de Voort wrote:
In our previous episode, Nikolay Nikolov said:
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? What about 2 MB? :
In our previous episode, Sven Barth said:
>
> Please note that 386 support was completely dropped recently from the
> kernel:
> http://www.zdnet.com/good-bye-386-linux-to-drop-support-for-i386-chips-with-next-major-release-708772/
The 486 production stopped in 2007 afaik. The 386 must have
In our previous episode, Nikolay Nikolov said:
> > 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? What about 2 MB? :)
Where can I buy machines with 4MB RAM
On 09/27/2013 09:39 AM, Michael Schnell wrote:
... user-land reentrand thread scheduling ...
Typo: ... user-land preemptive thread scheduling ...
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman
On 09/26/2013 02:59 PM, Tomas Hajny wrote:
...except when it uses just any RTL function...
ther were lots of "DOS appliances" that could be installed as resident
add-ons. Same e.g. could handle printer queues as well for the local
user as for remote network clients in the background. they coul
On 09/27/2013 03:18 AM, Hans-Peter Diettrich wrote:
I remember running three DOS apps on my similarly equipped desktop, in
separate DOS boxes, copying files in Explorer, and playing Solitaire
while waiting for another program to finish :-)
In fact I remember that there even was a "multitaski
On 09/26/2013 07:31 PM, Leif Ekblad wrote:
It works as long as you don't try to reenter DOS (because the DOS API
switches stacks).
Yep. But there are ways to handle this. Lots of old-time Dos appliances
did so (see my other post)
DOS never "sleeps". DOS is invoked as you use int 21h.
Yep. So
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
[fpc-devel] Multithreading under DOS
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
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: [
elopers' list"
Sent: Thursday, September 26, 2013 11:40 AM
Subject: Re: [fpc-devel] Multithreading under DOS
Am 26.09.2013 11:07, schrieb Tomas Hajny:
Here the old style ("light weight" / "internal" multi-thread enabled)
pthread lib might help. Supposedly
ubject: Re: [fpc-devel] Multithreading under DOS
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
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
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
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 term
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 ab
59 matches
Mail list logo
