On 10/27/2020 3:38 PM, zz zz wrote:
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..
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...
-- 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.
Not sure if there are really that many x86 SBCs that do support UEFI,
most certainly do not support a BIOS anymore.
-- 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.
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...
-- 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! ;)
not a gamer on DOS at all, so I skip that
-- 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
Well, that's in fact so crazy IMHO that I refrain at this point from
further comments without my legal counsel present... 😉
-- 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?
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.
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
--
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
