On Thu, Nov 25, 2021 at 1:33 PM Rugxulo <rugx...@gmail.com> wrote:
> On Wed, Nov 24, 2021 at 8:06 PM dmccunney <dennis.mccun...@gmail.com> wrote:
> > On Wed, Nov 24, 2021 at 7:20 PM Rugxulo <rugx...@gmail.com> wrote:
> > > On Wed, Nov 24, 2021 at 4:36 PM dmccunney <dennis.mccun...@gmail.com>
> > > wrote:
> > > > On Wed, Nov 24, 2021 at 4:19 PM Eric Auer <e.a...@jpberlin.de> wrote:
> > > >
> > > > > Bocke adds this: (I think FTP is just broken in the major browsers
> > > > > now,
> > > > > alas!)
> > > >
> > > > It is broken and will *not* be fixed.
> > >
> > > I assume this is moreso due to unneeded extra maintenance rather than
> > > just dislike for it.
> >
> > No, it's because it is no longer *necessary*. You can do the same
> > thing in other ways. If you can, why bother with FTP?
>
> In case you haven't noticed, FTP is much simpler to implement than
> Curl or Wget. Those are incredibly complex, especially for DOS.
> However, it's unavoidable these days, things are too complicated
> elsewhere to rely on "simple" FTP exclusively (or if at all).
I *have* noticed. That is irrelevant to the decision to deprecate it
in *browsers*. Browsers already had support, but it is going away.
> > And please note, I said it was deprecated and would not be fixed *in
> > the browsers*. This does not mean it won't live on in other places.
>
> I still assume this is more of "we don't need it, we don't have time"
> rather than "we don't like it" reasoning.
All three. They have reasons for disliking it, it is not *needed* in
a browser, and it will be one less thing to maintain and perform
security audits on..
> > FreeDOS (and any other form of DOS) is increasingly locked out of
> > access to the wider world, because it does not and *cannot* support
> > the methods now used.
>
> I get it, FreeDOS will never rule the world and will never support
> 100% of everything. Even if it IS possible (as most things are),
> there's not enough skilled workers to do it. Those with the skills
> lack motivation and/or time. So it won't get done. However, it's not
> true that FreeDOS can do "nothing". The fact that we don't have
> Javascript in a web browser is less of an impossibility and more of a
> simple lack of effort.
Nothing simple about the lack.JavaScript is an evolving standard. The
current standard is ECMAscript 6, but development is continuing.
To give you an example, when you compile code in current compilers
like GCC, it's a two step process. A front end parser examines your
code and attempts to convert it to an architecture independent
Intermediate Representation Language. The back end code generator
converts that to object code for the architecture you are developing
for. (That is why you can set up GCC to cross compile, and develop
code under X86 that will run on ARM.)
It is now possible to use JavaScript *as* the IRL. In many cases, you
may not bother compiling to object code. Your target has a JavaScript
engine already present, like Google's V8, that does JIT compilation to
object code on the device. Just compile your source language to JS
and send that to the target.
I won't say it's *impossible* to get that level of JS into a DOS
browser, but I do think it's highly unlikely. And even if you can,
you need to understand what current websites will send to the browser
and expect it to make sense of, to know whatJ > S support you need.
> DOS can at least crunch numbers, edit text,
> compile stuff, and run some games, even multimedia (within reason).
> It's just not "do everything like Linux or Windows". And that's okay.
I never said FreeDOS could do *nothing*. It does all sorts of things
and people do those things with it.
The pain points for using FreeDOS are in two areas.
1. 64 bit Windows (and I 8think* 64 bit Linux) dropped support for 16 bit code.
If you are a Windows user used to 32bit XP, which provided NTVDM and
let you run 16 bit code under it, it means you either use an emulator
like DOSBox, or run a full blown virtual machine with WinXP as a
guest, and DOS apps running in it under NTVDM. (The latter is a "You
are going through far more trouble than you need to..." thing.)
Or, you're Old Skool, and want to boot and run DOS on the bare metal
on old hardware. That's a different set of challenges.
2. The Internet ate the world, but *connecting* to the Internet has
become increasingly difficult for *any* flavor of DOS.
HTTP is deprecated, and all communication must use https and be
encrypted both ways. (And encryption standards are changing, as folks
find vulnerabilities in older forms.The current standard is TLS 1.1,
but TLS 1.2 is in beta and will become the standard soon.)
Using a browser? Web standards are moving targets, but you are
currently expected to have support for HTML5, CSS3, SVG, and a current
implementation of JavaScript in the browser. If you don't have that,
you will not have a good experience, and many sites will simply not be
usable. Turn off JavaScript support in your browser (and I think
Chrome on Chromebooks will let you do that,) and surf for a while.
Tell me what you get.
And note that HTML5 is an evolving standard. The current reason
developers are moving to it as fast as they can is support for the
<video> keyword.. This allows you to embed video in your site that
does *no* have to be encapsulated as a Shockwave Flash object. Flash
is going away as fast as people can get rid of it.
But how do you display the video? You need a CODEC. The default
standard for video was H_244. It was proprietary, and the outfit that
developed it charged a license fee. IE and Chrome could display those
videos because MS and Google paid for licenses. Firefox could not.
The issue wasn't the license fee. It was that FF was open source, and
all parts of it needed to be available in source form. FF could *not*
distribute H_264 CODEC source, and therefore could not include it in FF.
The issue heated up when Google decided to open source Chrome, and
were looking at third-party CODECs with equivalent performance for
which they *could* offer source. Cisco Systems broke the logjam by
negotiating a license that allowed them to offer a reference
interpretation in source form, and that's what everyone uses. I have
no idea if it's *possible* to build that for DOS, but I suspect not.
Since I run DOS programs under emulation using DOSBox or vDOS Plus,
I don't care. I use the host machine to reach the outside world, and
can get stuff into the DOS programs or out of them from the host. If I
was trying to do it *from* DOS, I would be in a world of hurt.
> > I suppose it's significant that you *could* get DOSBox X to run on top
> > of FreeDOS using HX, but why would you *do* that? What do you get
> > from doing it?.
> >
> > I am honestly curious about what use case you might have beyond "Let's
> > see whether I *can*... '
>
> For me, I've only tested it a few times for fun. I had no pressing need for
> it.
So it was "Can I *do* this?" I've done a fair bit of that myself and
I understand.
> Having said that, I imagine that the adjustable speed or various cpu
> configs can help identify bottlenecks, cpu incompatibilities, and
> certainly being able to take screenshots is always a plus. (If, for
> some bizarre reason, HX supported your sound card, you could then say
> it's able to emulate other sound cards successfully, which would also
> be very nice.)
Agreed
> But there are other ways of doing similar tasks (usually TSRs): SNARF,
> SLOWDOWN, etc.
Also agreed. If I needed to do that, I'd want to do it outside of
DOSBox X. I consider that a function to be handled at the OS level,
not the qapplication. In DOS, TSRs are OS level..
> > > BIOS and CSM are basically dead, so it's probably under emulator (e.g.
> > > QEMU). So what? Better than nothing (especially since most new
> > > computers "supposedly" have VT-X! Great!)
> >
> > If you *can* run DOS under emulsion, splendid. DOSBox exists to let
> > folks who want to play DOS games do so on things that *aren't* PCs.
> > (I got a few DOS apps up under DOSBox on an ARM based Android tablet,
> > using an ARM port of DOSBox.)
>
> DOSBox is meant to be portable, so there's no emphasis on VT-X or any
> other x86-specific cpu extensions. It's also "only for games" (at
> least upstream, forks are free to expand upon that).
And we have vDOS Plus for folks like me whose usage is *not* games,
save for some ancient character mode stuff which do not use video or
sound.
> > Folks trying to run DOS on bare metal on old hardware that still has a
> > BIOS will have challenges.
>
> I still use my old Dell laptop (with a BIOS) for FreeDOS (and bootable
> jump drives). It actually came with a Diagnostics partition and tools
> that were running atop DRMK ("Dell Real Mode Kernel", aka modified
> DR-DOS)!
You still have older hardware that will do that. Most don't.
> The whole point of my minimal MetaDOS distro was to facilitate using
> FreeDOS under VMs like QEMU or VirtualBox. But I half-relied on FTP
> quite heavily (mTCP), only using Wget (or Curl) when forced. In part,
> this was because of iBiblio.org mirroring FreeDOS files. The other
> reason was because mTCP supported 8086 while Wget or Curl would need
> 386 DPMI. But I guess FTP is almost a lost cause. So MetaDOS was never
> anything less than 386+, even if I tried to keep as many pieces as
> possible to the lowest common denominator. Long story short: if I ever
> make an update (unlikely), I'll probably include CURLLITE.EXE (386
> DPMI) by default.
Internally, on a legacy network, use FTP to sling files all you want.
Anything outside your network will require wget or curl.
> > > I wish I knew how to run FreeDOS on a generic Chromebook like this
> > > one. (I've tried Linux cmdline support [beta] before, it wasn't bad,
> > > but it needs 10 GB of space, yikes!)
> >
> > I fail to understand why it needs 10GB of space, unless you are trying
> > to run Linux *instead* of ChromeOS. But 10GB is not a significant
> > amount of space these days.
>
> It's trying to run Linux (Debian? cmdline only) under KVM (QEMU via
> VT-X). And 10 GB is a lot, especially when these Chromebooks don't
> barely have 16 GB total! (My bad for having such a low-end device. I
> tried "Linux (beta)" (under ChromeOS) before, a year ago, successfully
> ... but not lately. But it's truly tedious trying to pare down bloated
> distros, so I don't blame them much. PuppyLinux is usually lean,
> though.)
I ran Puppy. I gave up. It was simply too non-standard (where Ubuntu
is the closest thing to a standard desktop Linux possess
Other alternatives were DSL (Damn Small Linux), whose claim to fame
was fitting everything into a 50MB ISO file. They hit a wall where
they could no longer fit everything required into a 50MB ISO because
component sizes went up. A third option was TinyCore Linux..(Sttll
around the last time I looked.)
>> > What you *want* is a port of DOSBox that will run on ChromeOS and not
> > need Linux.. Good luck.
>
> I'm not sure, but I infer that Chromebooks are more for business /
> school rather than gaming.
I *am* sure, and that is exactly what they are for. They provide a
machine that boots fasts, uses what is essentially a Linux kernel, and
runs standard business apps. They assume you are connected to the
cloud, and the data you use is on the cloud. Local storage is
normally limited.
If you are a serious gamer, you either visit the DIY section of your
preferred retailer, and build your own gaming machine from parts, or
you buy a laptop intended for gamers like Dell's Alienware line.
In fact, I think the whole kernel and setup
> is optimized not for games at all. The timing of a lot of things is
> off. Not that I care, just saying ... I think emphasis is more on
> video / video conferencing / audio rather than actual gaming. But I
> could be wrong. I'm out of the loop, honestly.
You are not wrong, and have described their intended use cases in a
nutshell. They are not intended for gaming at all.
> > > > (Most interest I see in DOS these days is in running old DOS *games*,
> > > > where communication with the outside world is not a factor. Those
> > > > folks won't care about FTP, and may have never used it.).
>
> The whole "Linux (beta)" add-on download (which, IIRC, originally was
> only 300 MB) was to enable some simple cmdline tool usage, e.g. simple
> things like Sed or AWK or REXX would be nice. It had VIM, which is
> very nice (and syntax highlighting).
>
> > > I hope Jim (and Eric and Tom and Jerome and Bart and Jeremy and Robert
> > > and ...) all realize how much I adore FreeDOS and have appreciated it
> > > over the years. My only complaint is that I couldn't contribute more.
> > > FreeDOS is great! (Now if only the rest of the world knew that.)
> >
> > I'm sure all here understand and appreciate your efforts.
>
> Moreso I just meant overall there were a lot of good people and good
> programs that I've tried to appreciate by actually using those
> programs! I just wish I could organize a little better in order to
> accomplish even more (admittedly trivial stuff). So DOS isn't dead,
> it's alive ... if only under QEMU (another brilliant suite of tools).
> We can still use DJGPP, FPC, FBC, NASM, FASM, Sed, AWK, REXX, Lua,
> etc. etc. There's plenty that can be improved, and it's always fun.
I never said DOS was dead.
The blocker is contributors. The sorts of stuff I see people wishing
upon a star for are high level efforts that require serious
development skills. The people who *can* do it get *paid* significant
salaries for their skills. They will not contribute free time
consuming significant work to a hobby project that isn't even their
hobby. Got a spare few tens of thousands of dollars to fund desired
development? If you do, something might be worked out. If not...
______
Dennis
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
