On 11/16/2020 11:26 AM, zz zz wrote:
hello,
> Seriously, JavaScript has rather large memory requirements, so I am
not sure that this is overall such a good fit for DOS.
I plan to eventually get freeDos into 2GB RAM machines, at the least
(probably 4GB eventually). Should be enough.
DOS is based on 8086 architecture, with 1MB of RAM and at times rather
finicky ways to extended this amount for application running on top of DOS.
> Also the lack of support of Javascript in the existing DOS web
browsers (Arachne, Dillo,..) might be another indicator for this.
I wasn't talking about browsers -- nor the web for that matter -- at
all. As I've pointed out, you already got a canvas going AND it has
file/filesyestem support, with the package of DOjS. All the benefits
I've listed, which has been at least discussed here before, stemmed
from that simple realization: Higher level development, even more
languages support with active maintenance (since it's not DOS
specific), even threads (efficient simulated threads in a single
process enviroment, which is what Ecmascript was designed for and
excels at)
Well, if not in a browser, how do you actually run Javascript? You need
the "engine" for that, and that is part of a browser. And I am not aware
of a standalone Javascript interpreter, and even if there is, you can't
really use it for DOS, as you have kind of a "chicken and egg" problem
here...
>Beside in general that JavaScript has morphed into a rather awful
behemoth these days...
I'll again recommend reading "javascript the good parts", the fact
that it has been put together in a week and managed to morph into the
most used behemoth these days -- running at nearly native assembly
speed -- is testament to the underlying power at its core, even though
you dislike lisp. In fact, one doesn't need to use anything that makes
it a behemoth.
Sorry, I am programming for far too long, in a lot of different
programming languages, as to be buying into this nonsense.
> Not sure if there are really that many x86 SBCs that do support
UEFI, most certainly do not support a BIOS anymore.
That's fair. On another thread there is discussion of running a DSL
or TinyCore (I recommend) and autoboot into a QEMU running FreeDOS. I
approve :)
Well, I might actually have found a reasonably priced one and with a
little bit of luck, I might have have one by Christmas.
> To me that just all looks and sounds as just another attempt to make
some behemoth out of DOS, like a second coming of Linux...
Amen. :) J/K.. All this would be optional, of course. The context of
my suggestion was to satisfy the expressed need of (even) more
languages programmable within FD and, to boot, get current maintenance
(the term I used was "piggyback", since it's not done with FD in mind
but the web). But this could be done for other targets, probably C
would be best.
Sorry, but there are enough programming languages around for use with
DOS, there is no need to "even more", specially not any of those that
have become self-serving solutions that only solve issues that nobody has...
Ralf
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
