hi
> DOS is based on 8086 architecture, with 1MB of RAM
Wasn't protected mode supposed to extend that? Anyways, I'm running on a 48MB machine and even DSL and tinycore had problems with such a low amount, which is somewhat disturbing for the preservation of technology.
> and at times rather finicky ways to extended this amount for application running on top of DOS.
what would be the maximum? 32 bits can address 4GB, 16 bits would be 64KB (which is definetely NOT enough for everyone :D) so it's already kind of a hack to have anything in between..
_______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 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...
Why, I just told you, Ralf.. maybe you skimmed too quickly but there is a J in DOjS (doJs, clever huh?), and I discovered it only thanks to you guys, since it's in the FD pages ("what's included"). That's why I said you already got a canvas (HTML5 programmable video audio.. in js) WITH filesystem support.
What is NOT in the pages but IS in the repositories for FD is an actual LISP implementation for DOS! It isn't there because, I'd assume, it's probably abandoned as the author's website is gone for years. It's usable though..
>Sorry, I am programming for far too long, in a lot of different programming languages, as to be buying into this nonsense.
Time can be a good OR a bad thing but, it does not address the argument.
> Well, I might actually have found a reasonably priced one and with a little bit of luck, I might have have one by Christmas.
Cool! x86 is rather surprising (to me) for a SBC as ARMv8 and beyond will be all the rage going forward (got a little one here as well :)).. so the emulation route would probably be needed most of the time.
> 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...
I agree with you here, which is why I've been (jokingly) writing "even" before the "more" ever since I suggested that. But skimming the mailing list I saw some people expressed that want, so my suggestion was a quick way to get them that without any additional work, like I said, C is probably a better target, it also has a bunch of those compilers and lower resistance of course.
Cheers,
F.
Sent: Monday, November 16, 2020 at 11:47 PM
From: "Ralf Quint" <[email protected]>
To: [email protected]
Subject: Re: [Freedos-devel] New Old Timer reporting :-)
From: "Ralf Quint" <[email protected]>
To: [email protected]
Subject: Re: [Freedos-devel] New Old Timer reporting :-)
On 11/16/2020 11:26 AM, zz zz wrote:
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.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.
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...> 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)
Sorry, I am programming for far too long, in a lot of different programming languages, as to be buying into this nonsense.>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.
Well, I might actually have found a reasonably priced one and with a little bit of luck, I might have have one by Christmas.> 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 :)
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...> 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.
Ralf
| Virus-free. www.avast.com |
_______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
