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.
> 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)
>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.
> 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 :)
> 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.
> not a gamer on DOS at all, so I skip that
To your horror, some people are doing both! Emulation + _javascript_ .. DOS emulation, just to be ironic, in the browser. Check it out:
https://archive.org/details/softwarelibrary_msdos_games
> Well, that's in fact so crazy IMHO that I refrain at this point from further comments without my legal counsel present... 😉
Another reply pointed out there is ALREADY something to that effect ;) the documentation says "if simple enough", though it even supports openGL AND DirectX! Indeed amazing.. should be enough for my humble needs.
> Not quite sure what you mean by "same hd installation". All you need to boot (Free)DOS is to get a basic kernel and command shell being loaded from a SYS'ed HD.
I mean "same hd" BUT "different partition", which was unclear if it would work, since it was expressely 'forbidden" to do "same drive" installation, which is ambiguous but I managed to do that. Not sure why the installation can't sys the drive without formating it and preserving the copied contents from the CD to use as installation media, SPECIALLY since it's basically just a copy. But at least a "no format" option would have to be added to the Basic installer.
> Which is something relatively easy to do on a second system, if that is what you are referring to. Otherwise, there isn't much on "installation" beside copying folders/unzipping archives.
assuming you can RUN sys at all? I don't have a windows machine, mostly linux here. So the 1st DOS installation would be nice to not need a 2nd system for anything besides precisely copying stuff. I did the diskette boot though.
Cheers!
F
Sent: Thursday, October 29, 2020 at 2:26 AM
From: "Ralf Quint" <freedos...@gmail.com>
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] New Old Timer reporting :-)
From: "Ralf Quint" <freedos...@gmail.com>
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] New Old Timer reporting :-)
On 10/27/2020 3:38 PM, zz zz wrote:
I would consider this rather a fallacy! Seriously, _javascript_ has rather large memory requirements, so I am not sure that this is overall such a good fit for DOS. Also the lack of support of _javascript_ in the existing DOS web browsers (Arachne, Dillo,..) might be another indicator for this. Beside in general that _javascript_ has morphed into a rather awful behemoth these days...So, here's some ideas: Checking the Dev apps, I see you got a DOS _javascript_ canvas! (you could also add to the description that it can handle files as well, since it's a very interesting feature, see below) This can help solve some of the 'problems'/requests/suggestions I've noticed here, while skimming the mailing list. For example:-- More programming language support: There have been a lot of effort over the last few years to compile next to every single language to JS. Check out asm.js / WebAssembly (though here is the perfect place to find actual asm programmers that will cringe to the nomenclature :-) those people never had to deal with the intricacies of x86 assembly! )Want FreeDos to support Common Lisp? Throw in some Parenscript, possibly with the Emacs modes to compile with the click of a button and you're good to go. Similar projects exists for most other languages.-- "Threads" : The more I thought about it, the more JS seemed like the perfect fit for DOS. It can handle all those heavy loaded web servers and yet it is single threaded, rather similar to DOS :-) I wonder if node.js could be ported over, perhaps having a dynamic web DOS server would improve our relevancy further; Maybe security would be a big plus, being single user, single threaded, etc..
Not sure if there are really that many x86 SBCs that do support UEFI, most certainly do not support a BIOS anymore.-- UEFI support : Suppose the above is true, now there is much more impetus to leverage FreeDOS appeal for embedded systems/application, considering all the new SBC's coming out and much more to come due to IoT. There would be interest in booting from the newer standard.
Sorry, I just don't see this. 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...-- High Level language for OS development: Check out Douglas Crockford's ideas on high level vs low level languages for OS dev, the apps above the OS should be programmed with the higher level language you could support, that way we can make more and higher quality applications. He's the author of "_javascript_ the good parts", which is also relevant to this argument. As I mentioned, since DOjS support files and other OS calls, it is perfect for this, even as a compilation target.It may sound like all my ideas are based on JS but this could work with anything that already has translation support to something you already have. It just happens to have been a lot of effort in that front for JS ('cause the webs).. and if we could piggyback on that, all the better.
not a gamer on DOS at all, so I skip that-- Another idea I'd like to suggest is including an Amiga emulator, to "complete" the emulation support of all 8-bit classics. Perhaps some MAME too? FD can be installed on newer machines (with legacy BIOS support anyway) so power should not be a concern even for newer games. Speaking of "completing emulation", 16-bit consoles are lacking a Genesis emulator it seems, I don't think MEKA does it. (though SMS is the best of all, in any number of bits, so if you're not going for completion, at least scratch everything EXCEPT meka! ;)
Well, that's in fact so crazy IMHO that I refrain at this point from further comments without my legal counsel present... 😉-- An even crazier idea: Porting WINE to DOS o.O` imagine running any software from windows one might need that is not yet on DOS! ON DOS! Not to mention some people seem to install FreeDos then turn around and slap a windows on it, I just find this somewhat distasteful :-D
Not quite sure what you mean by "same hd installation". All you need to boot (Free)DOS is to get a basic kernel and command shell being loaded from a SYS'ed HD. Which is something relatively easy to do on a second system, if that is what you are referring to. Otherwise, there isn't much on "installation" beside copying folders/unzipping archives.-- The installation process: I believe could be improved by having an "Advanced" tab where one could check and ideally select the target and source drives. One of the reasons I postponed trying FD out was that my old box doesn't have a CD drive (and I prefer not to have to burn them and have them lying around) and there was some uncertainty/trial and error into doing the "same hd" installation, the instructions were kinda hidden, I believe in the readme and not widely available (site? wiki? don't remember) and the FD installer is quite particular about installing itself on the C: drive, active partition, AND first IDE port even (in case you have more than one with hds plugged in).. perhaps a closer integration with fdisk could ease this process?
I realize some of these are long term or maybe not desirable/feasible? But hey, one can dream.. here's a simpler one: Emacs client mode, so you can bypass the DJGPP limitations (from what I've read) by connecting to a server instead or fixing it ( one can easily run emacs as server on one's own LAN, for instance) This is perhaps already working on the djgpp port? Or even Freemacs could already support or have a dev willing to hack it?
I personally would prefer not to have any form of EMACS (or Lisp) anywhere my FreeDOS boxes, I prefer "Stallman free" environments... 😉
Ralf
| Virus-free. www.avast.com |
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
