Re: [Freedos-devel] Simplifying FreeDOS

[Rugxulo]

Hi again,

Just FYI, if anyone cares, just to be more informed about such things 

On Tue, Nov 10, 2020 at 2:54 PM Rugxulo  wrote:
>
> On Sun, Nov 8, 2020 at 7:31 AM Rugxulo  wrote:
> >
> > Regina was (IIRC) compiled with Watt-32 due to external stack queue or
> > whatever (rxqueue). You can almost certainly rebuild without it (I've
> > done it)

I need to go back and cleanly try to make a proper patch, but it does
build successfully (Regina 3.9.3 from Oct. 2019) with DJGPP 2.05 (GCC
10.2) and works (no obvious slowdowns or regressions, e.g. rexxcps).
That's without needing Watt-32, so it's only supporting the internal
REXX "stack". It's about 220 kb UPX'd, which is far less than the 490
kb one we include already. (Honestly, I'd probably build both with and
without Watt-32, just for completeness. DJGPP does have its own "port"
of Watt-32 in /current/v2tk/ from last year, so it's probably best to
prefer that.)

I did also find my public copy (on iBiblio) of older Regina 3.5 built
for EMX (GCC 2.8.1), which works fine with RSX + DPMI (since EMS has
some obvious environmental bugs and caveats). I don't have GCC/EMX set
up nowadays, so I'd have to check my backups, but it shouldn't be hard
to get working again. Then again, I don't know of any obvious reason
to prefer that over DJGPP.

I also found Compact Rexx (CRX) archived on Mike's website (again),
and while it worked for very simple programs, it didn't quite work for
some of my tests (system resources exhausted). I have no idea if it's
really that paltry on RAM, buggy / incomplete, or somehow getting
confused (too much free??). It's originally from the late '90s, and
the author was testing on a 300 Mhz laptop "for nostalgia". He sounded
very competent, so it's probably still useful somehow. But there's a
lot of auto-generated sources and other complications. It's probably
not impossible to get rebuilt, but you need MASM 6.x (JWasm??) and
Nmake (ugh). It's only 40 kb.

(Remember that my TC++ build of MAWK [GPL] is only 60 kb UPX'd. Both
languages are "standards". It wouldn't be a bad idea for FreeDOS to
include AWK by default.)

> But Regina is also slower to run [external procedures], moreso than just 
> typical
> slowdown from simple path searches. I have no idea if that's DJGPP's
> fault or not (probably not entirely, some is definitely my naive
> code). Splitting out three of my procedures in one script slows Regina down
> (on a 2010 laptop atop RAM disk) nine times: from half a second to four and a 
> half seconds!

Being more idiomatic, removing the need for two trivial external
functions (files) in lieu of better use of built-in functions (BIFs)
saved some time, plus some "don't call unless needed" for the one big
external procedure remaining helped a lot. So it's only 1.3 seconds
now, roughly only 3x slowdown (instead of 9x) when separated out.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Rugxulo]

Hi again,

On Sun, Nov 8, 2020 at 7:31 AM Rugxulo  wrote:
>
> Regina was (IIRC) compiled with Watt-32 due to external stack queue or
> whatever (rxqueue). You can almost certainly rebuild without it (I've
> done it)
>
> > > Regina at least has some justification.  Some later versions of PC DOS
> > > came with REXX.
> >
> Even AWK and REXX have modularity via separate files, which
> is interesting and almost surprising.
>
> > REXX is a very cool language (ANSI standard, too, in 1996).

Just FYI:

In REXX, external functions (in separate .REX files) are permitted,
which is great for modularity (separation of concerns) and reusing
code. But the functions must be immutable, so everything that is
needed is passed as parameter, and you then return a relevant result
from that. You also must remove the "procedure" keyword (Regina hates
it) and forcibly rename the main module as "*.REX" (for BRexx, else it
won't run correctly).

But Regina is also slower to run that way, moreso than just typical
slowdown from simple path searches. I have no idea if that's DJGPP's
fault or not (probably not entirely, some is definitely my naive
code). I'm also not sure what internal REXX caching is done either.
(Regina can tokenize / byte-compile at cmdline, but I'm not sure if
that helps speed at all.) Splitting out three of my procedures in one
script slows Regina down (on a 2010 laptop atop RAM disk) nine times:
from half a second to four and a half seconds! (REXX has a built-in
timer for such tests.) It is definitely noticeable, but I do see an
obvious optimization to add to my code (that will be unnecessarily
redundant and verbose, but only very slightly). BRexx is very fast,
regardless of external functions or not. I also tested two other REXX
interpreters on Windows (ooREXX and r4), and they had similar
slowdowns.

I prefer not having tons of external dependencies and dozens of files
to keep track of. Although lumping everything into one big file is
bad, for very simple scripts (less than 1000 lines), it's probably not
worth modularizing except for theoretical reasons. But I did whip up
another quick REXX script to automate even that for me, so I don't
have to tediously extract it by hand just to test such things.

I know not many people around here prefer REXX, but it can be quite a
useful language. However, if you already have QBASIC or AWK or Forth
or similar, it's much less crucial.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Rugxulo]

Hi,

On Sun, Nov 8, 2020 at 10:40 AM Mark Olesen  wrote:
>
> DOS Chromebook? I do not believe FreeDOS could compete with the latest
> web browser technologies. It is an interesting concept though.I
> believe an attempt was made to Resurrect Amiga with a working machine
> and desktop sometime ago.
>
> FreeDOS is fun stuff for sure. Every once in a while, I enjoy
> tinkering around with it and sometimes programming in that
> environment.

I didn't mean a commercial project aimed at millions of people, just a
niche toy for us nerds. Obviously we wouldn't have HTML 5, but we do
already have ports of Lynx and Links2, Wget, Curl, FTP, IRC, etc.

And of course we have DJGPP (GCC), OpenWatcom, SmallerC, FPC, FBC,
NASM, FASM, AWK, Python, Ruby, Perl, etc. Thus, it should be possible
to have a dedicated machine (or at least one with emulation) that
would let us develop for FreeDOS more easily. Heck, maybe we would
even gain more contributors!

With the online popularity of Git (SCM) these days, it seems to imply
that a Chromebook or similar Linux machine with Git installed, thus
with QEMU for emulating FreeDOS, would be optimal for development (and
maybe DOSBox for graphics / sound / cycle-throttling).

But I'm specifically thinking of a non-generic laptop here. Heck,
maybe something that dual boots into FreeDOS natively. But it's just a
dream, and frankly, Linux has more marketshare (despite heavy
fragmentation). As grateful as I am for FSF's "Respects Your Freedom"
attempts, I'm not sure how reliable those are. Maybe I need to grab
one and find out. But x86 hardware seems like a dead end, yet I don't
know how much success or promise can be found on others (ARM? RISC-V?)
for emulating legacy x86.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Mark Olesen]

DOS Chromebook? I do not believe FreeDOS could compete with the latest
web browser technologies. It is an interesting concept though.I
believe an attempt was made to Resurrect Amiga with a working machine
and desktop sometime ago.

FreeDOS is fun stuff for sure. Every once in a while, I enjoy
tinkering around with it and sometimes programming in that
environment.

OpenBSD is not polished like Ubuntu and such. Lots of troubleshooting
and configuring. X and wireless are the most difficult ones for my
laptop. I went for it because it is not very political. The developers
are typically quiet and just go about their business.

By the way, I have an older laptop that runs Gentoo. I use it mostly
to Skype my 12 year old daughter. Other than that, I used to be a big
fan of Fedora until the big blue bought them out. I suppose today, if
I wanted something my kid could use, I would use OpenSuSE.

On Sun, Nov 8, 2020 at 10:22 AM Rugxulo  wrote:
>
> Hi,
>
> On Sun, Nov 8, 2020 at 8:10 AM Mark Olesen  wrote:
> >
> > That sounds fantastic. It is unfortunate development was abandoned.
> > Having multiple choices seems like a good idea.
>
> TinyCore Linux also has a "Core" (11 MB) "base system which provides
> only a command line interface".
>
> The biggest problem is probably non-free / non-redistributable
> firmware, not the actual wireless drivers. (My ancient Dell laptop has
> BCM4312, which is a minor pain to get working.)
>
> > Q: Does anyone know if DELL still uses FreeDOS for firmware and BIOS
> > updates? Or maybe they used to ship a computer with FreeDOS as the
> > primary OS?
> >
> > At one point, I know they did. I have not kept up with the times,
> > however. I would imagine it would be very lite?
>
> I know almost nothing, but the only link I can think of is this one:
>
> * 
> https://www.dell.com/support/article/en-us/sln171755/update-the-dell-bios-in-a-linux-or-ubuntu-environment?lang=en#updatebios2015
>
> But keep in mind that BIOS/CSM is effectively dead:
>
> * 
> https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#CSM_booting
>
> "In November 2017, Intel announced that it planned to phase out
> support for CSM by 2020."
>
> I don't know the exact rationale. It may be to remove support burdens,
> reduce costs, speed up booting times, or just drop unnecessary legacy.
> Actually, I half got the impression it was for power management /
> battery life reasons. But it could also be for security (secure
> boot?).
>
> (Windows is still 80% marketshare, everything else considered relevant
> is "POSIX" [usually Linux]. Hence nobody majorly needs BIOS/CSM
> anymore, AFAIK.)
>
> > I have an OpenBSD Lenovo A485 laptop rig. Since I do not run Windows,
> > they provided a bootable ISO. I have no idea what they are using?
>
> IIRC, FreeBSD has the best hardware support out of all the *BSD
> family. The big differences with OpenBSD are that they refuse NDAs,
> insist on building atop actual hardware, support various sentimental
> machines, and also have a monolithic kernel with no separate modules.
> (Corrections welcome, I could be wrong.) Apparently 6.8 was just
> released last month for their 25th anniversary. (I've only, very
> barely, tried earlier versions under VM.) Then again, I was surprised
> (a few years ago) that FreeBSD was still supporting ancient ARMv6
> (early RaspPi??), but even there, the only Tier One platforms are
> AMD64 and i386 (with various others under Tier Two). Even most Linux
> distributions (e.g. Ubuntu) have dropped i386 support.
>
> There are many full Linux laptops for sale these days. I'm looking to
> buy one myself soon. This Dell Chromebook isn't too shabby either. (We
> really need a DOS Chromebook. Obviously it won't have Chrome. Or at
> least something that can run QEMU. This one does [Linux "beta",
> cmdline only, optional], but I don't think it allows switching OS
> images, probably for security reasons.)
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Rugxulo]

Hi,

On Sun, Nov 8, 2020 at 8:10 AM Mark Olesen  wrote:
>
> That sounds fantastic. It is unfortunate development was abandoned.
> Having multiple choices seems like a good idea.

TinyCore Linux also has a "Core" (11 MB) "base system which provides
only a command line interface".

The biggest problem is probably non-free / non-redistributable
firmware, not the actual wireless drivers. (My ancient Dell laptop has
BCM4312, which is a minor pain to get working.)

> Q: Does anyone know if DELL still uses FreeDOS for firmware and BIOS
> updates? Or maybe they used to ship a computer with FreeDOS as the
> primary OS?
>
> At one point, I know they did. I have not kept up with the times,
> however. I would imagine it would be very lite?

I know almost nothing, but the only link I can think of is this one:

* 
https://www.dell.com/support/article/en-us/sln171755/update-the-dell-bios-in-a-linux-or-ubuntu-environment?lang=en#updatebios2015

But keep in mind that BIOS/CSM is effectively dead:

* 
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#CSM_booting

"In November 2017, Intel announced that it planned to phase out
support for CSM by 2020."

I don't know the exact rationale. It may be to remove support burdens,
reduce costs, speed up booting times, or just drop unnecessary legacy.
Actually, I half got the impression it was for power management /
battery life reasons. But it could also be for security (secure
boot?).

(Windows is still 80% marketshare, everything else considered relevant
is "POSIX" [usually Linux]. Hence nobody majorly needs BIOS/CSM
anymore, AFAIK.)

> I have an OpenBSD Lenovo A485 laptop rig. Since I do not run Windows,
> they provided a bootable ISO. I have no idea what they are using?

IIRC, FreeBSD has the best hardware support out of all the *BSD
family. The big differences with OpenBSD are that they refuse NDAs,
insist on building atop actual hardware, support various sentimental
machines, and also have a monolithic kernel with no separate modules.
(Corrections welcome, I could be wrong.) Apparently 6.8 was just
released last month for their 25th anniversary. (I've only, very
barely, tried earlier versions under VM.) Then again, I was surprised
(a few years ago) that FreeBSD was still supporting ancient ARMv6
(early RaspPi??), but even there, the only Tier One platforms are
AMD64 and i386 (with various others under Tier Two). Even most Linux
distributions (e.g. Ubuntu) have dropped i386 support.

There are many full Linux laptops for sale these days. I'm looking to
buy one myself soon. This Dell Chromebook isn't too shabby either. (We
really need a DOS Chromebook. Obviously it won't have Chrome. Or at
least something that can run QEMU. This one does [Linux "beta",
cmdline only, optional], but I don't think it allows switching OS
images, probably for security reasons.)


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Mark Olesen]

That sounds fantastic. It is unfortunate development was abandoned.
Having multiple choices seems like a good idea.

Q: Does anyone know if DELL still uses FreeDOS for firmware and BIOS
updates? Or maybe they used to ship a computer with FreeDOS as the
primary OS?

At one point, I know they did. I have not kept up with the times,
however. I would imagine it would be very lite?

I have an OpenBSD Lenovo A485 laptop rig. Since I do not run Windows,
they provided a bootable ISO. I have no idea what they are using?

On Sun, Nov 8, 2020 at 6:54 AM Rugxulo  wrote:
>
> Hi,
>
> On Sat, Nov 7, 2020 at 2:24 PM Mark Olesen  wrote:
> >
> > Great idea. I like minimalism. However, I don't think networking
> > drivers are up to snuff to completely automate the process.
>
> This has already (unofficially) been done.
>
> * 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/metados/
>
> But it still needs cleaning up (and some things haven't been properly
> vetted, e.g. Curl, which is not included by default).
>
> But it does have two packet drivers that work with (old and new) QEMU
> and VirtualBox. These are also used by the FDNET package, but Jim
> seems almost uninterested in that.
>
> N.B. Even Trisquel GNU/Linux has a "net install" (only 42 MB!) .ISO
> download. Perhaps trying or recommending such things from Linux would
> be wiser as a starting point since they have much better hardware
> (e.g. network) support.
>
>
> > On Sat, Nov 7, 2020 at 1:46 PM Chelson a  
> > wrote:
> > >
> > > Why not have a simple floppy that can install the system via internet 
> > > connection?
> > >
> > > Base cd, extras cd and boot disk with internet install?
> > >
> > >
> > >
> > > On Sun, 8 Nov 2020 at 05:37, Mark Olesen  wrote:
> > >>
> > >> Why not have a minimal install iso.  Then have separate additions iso
> > >> for each category? Could the install handle that?
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Rugxulo]

Hi again,

(Sorry in advance for the ramble.)

On Tue, Oct 27, 2020 at 2:06 PM Rugxulo  wrote:
>
> On Sat, Oct 24, 2020 at 4:21 PM Steve Nickolas  wrote:
> >
> > On Sat, 24 Oct 2020, Eric Auer wrote:
> >
> > > Regina REXX was not very small, while some others are small?

Regina was (IIRC) compiled with Watt-32 due to external stack queue or
whatever (rxqueue). You can almost certainly rebuild without it (I've
done it), but I don't think the code supports 16-bit cpus. Even the
smaller BRexx 16-bit build from 2003 isn't 8086-friendly (not sure,
186??), plus it's non-commercial only (not quite GPL). I also have a
newer DJGPP build of BRexx from 2011, it's only like 110 kb. (It's
always "interesting" testing code between various quasi-compatible
interpreters. There's always dozens of caveats and dark corners and
bugs. But it's amazing when portable code works!)

Years ago, I put old Perl 4 [sic!] (16-bit) on my RUFFIDEA floppy just
to have "something" scripting-wise, even though I never learned Perl.
It was really only useful for "ztouch" (touch .gz from internal date,
if found). Although I later wrote a sloppy and unportable (but
functional!) version in REXX (both Regina and BRexx supported)! I
never did finish writing a simpler C version (mktime(), utime()). I
also lamented not just throwing REXX on floppy instead, but perhaps
AWK (which?) would've been a better fit overall. I did recently
rebuild old MAWK with Turbo C++ 1.01. UPX'd it's only 60 kb (compared
to the family / bound DOS + OS/2 build which can't compress and is 160
kb). In some ways, MAWK is better than other ports (e.g. memory
efficiency). With one script of mine, it works where our 16-bit
(G.K.'s OW build, 2010) BWK's AWK doesn't. (32-bit builds of BWK work
fine, as does 32-bit DJGPP Gawk. Again, it's always good to test on
all available interpreters to weed out hidden bugs and non-portable
issues.)

> > Regina at least has some justification.  Some later versions of PC DOS
> > came with REXX.
>
> Yeah, it replaced QBASIC there.

QBASIC only gets about 160 kb free memory (at best), no overlays nor
extended memory, plus there's no modularity, not even include files
(sadly). Even AWK and REXX have modularity via separate files, which
is interesting and almost surprising. I actually dislike extreme
modularity where you have too many separate files all over the place,
but it can indeed be very useful.

> REXX is a very cool language (ANSI standard, too, in 1996).

It's almost too complex with all the (extra) features and extensions.
But the base language is quite simple, almost BASIC-ish. Not as simple
as Sed, but Sed is not a real programming language (no variables, no
arithmetic). But, like I said, Regina is 32-bit (or 64-bit) only,
AFAIK, so I don't think it'll build for 16-bit, which may annoy some
of us purists. But it's still quite good.

(Oh, there was CRX [Brian Marks' Compact Rexx] which was 16-bit, but I
never delved too closely into it. I think it was buggy, but it was
used for verifying standard code, back in the day. I forget the
license, but IIRC it was written in MASM. I should take another look.)

> Our Regina build (ANSI only, no OOP) is mine from 2012 using DJGPP.
> Later sources had bugs that I never dug into that made it refuse to build.

Trisquel had an even older Regina (3.6?)! Sheesh. Sometimes it's weird
how packages are never updated, but I don't blame them (tedious).
Anyways, you used to also be able to rebuild Regina via GCC/EMX, which
I've done a few times (years ago) for fun. Not sure that's really
"better" than DJGPP, though.

Anyways, I've just been messing around with PSR Invaders (yet again),
writing various scripts to convert MASMv4 syntax to various Free/libre
assemblers (e.g. NASM, FASM, TinyASM). So that's my limited
experience. Just FYI.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Rugxulo]

Hi,

On Sat, Nov 7, 2020 at 2:24 PM Mark Olesen  wrote:
>
> Great idea. I like minimalism. However, I don't think networking
> drivers are up to snuff to completely automate the process.

This has already (unofficially) been done.

* 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/metados/

But it still needs cleaning up (and some things haven't been properly
vetted, e.g. Curl, which is not included by default).

But it does have two packet drivers that work with (old and new) QEMU
and VirtualBox. These are also used by the FDNET package, but Jim
seems almost uninterested in that.

N.B. Even Trisquel GNU/Linux has a "net install" (only 42 MB!) .ISO
download. Perhaps trying or recommending such things from Linux would
be wiser as a starting point since they have much better hardware
(e.g. network) support.


> On Sat, Nov 7, 2020 at 1:46 PM Chelson a  wrote:
> >
> > Why not have a simple floppy that can install the system via internet 
> > connection?
> >
> > Base cd, extras cd and boot disk with internet install?
> >
> >
> >
> > On Sun, 8 Nov 2020 at 05:37, Mark Olesen  wrote:
> >>
> >> Why not have a minimal install iso.  Then have separate additions iso
> >> for each category? Could the install handle that?


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Steve Nickolas]

On Sat, 7 Nov 2020, Mark Olesen wrote:


Great idea. I like minimalism. However, I don't think networking
drivers are up to snuff to completely automate the process.


Depends on the NIC, I think.  With the NICs in my DOS boxen, it's 
possible.


-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Mark Olesen]

Great idea. I like minimalism. However, I don't think networking
drivers are up to snuff to completely automate the process.

On Sat, Nov 7, 2020 at 1:46 PM Chelson a  wrote:
>
> Why not have a simple floppy that can install the system via internet 
> connection?
>
> Base cd, extras cd and boot disk with internet install?
>
>
>
> On Sun, 8 Nov 2020 at 05:37, Mark Olesen  wrote:
>>
>> Why not have a minimal install iso.  Then have separate additions iso
>> for each category? Could the install handle that?
>>
>> On Sat, Oct 24, 2020 at 2:39 PM Jim Hall  wrote:
>> >
>> > Some of us had this conversation a while back and I wanted to bring it up 
>> > again on the list.
>> >
>> > MS-DOS was a small operating system. MS_DOS 5 and 6 fit on a few 1.44MB 
>> > floppy disks.
>> >
>> > We always intended FreeDOS to not just replace but enhance DOS. FreeDOS is 
>> > "MS-DOS plus more." To make clear what's part of the "core" of FreeDOS, we 
>> > have the "Base" package group. These packages replicate the behavior and 
>> > functionality of MS-DOS. But we also have a lot of other packages that add 
>> > new functionality to FreeDOS, and we put these programs in other package 
>> > groups like "Editors" (additional editors) and "Devel" (compilers, 
>> > assemblers, and other development tools).
>> >
>> > Over time, FreeDOS has grown to include lots of interesting programs. The 
>> > FreeDOS 1.2 and 1.3RCx distributions are very big.
>> >
>> > As we look to the next FreeDOS 1.3 Release Candidate, I think we should 
>> > consider removing some packages from the FreeDOS distribution.
>> >
>> > To be clear: I am not suggesting deleting packages or programs from the 
>> > FreeDOS archive at ibiblio. There's lots of useful and interesting 
>> > programs there. But I don't think we need to include everything in the 
>> > FreeDOS distribution.
>> >
>> > Here are my thoughts from the FreeDOS 1.3 package list (wiki)
>> >
>> > Base
>> > Keep everything
>> >
>> > Archivers
>> > Do we really need all of those archivers? For example, who needs Zoo these 
>> > days? My suggestions:
>> > 1. Move bz2, gzip, and tar to the "Unix" group - these are replicas of 
>> > Unix tools
>> > 2. Keep zip, unzip, p7zip
>> > 3. Remove the other packages: 7zdec, arj, cabext, lpq1, lzip, lzma, lzop, 
>> > zoo
>> >
>> > *Note that p7zip can unpack a ton of other file formats, so we don't need 
>> > these other archivers anyway.
>> >
>> > Boot Tools
>> > *I don't have any strong feelings here. What are your thoughts?
>> >
>> > Development
>> > Can we pare down the list a bit? We have a lot of packages here, but I 
>> > don't think we need them all. For example, we should include the tools we 
>> > know we'll need to compile the different FreeDOS utilities. I'd also like 
>> > to keep the GCC related packages, and other packages that remain popular. 
>> > My suggestions:
>> > 1. Move perl to the "Unix" group
>> > 2. Keep BWBasic, the DJGPP packages, FASM, the FBC packages (FreeBASIC 
>> > Compiler) fpc (FreePascal compiler), the GCC-IA16 packages, JWASM, NASM, 
>> > OW (OpenWatcom C Compiler), and UPX
>> > 3. Remove bcc (Bruce's C Compiler), euphoria, insight, lua, regina, runtime
>> >
>> > *I think I missed some packages in that list. I don't have a good opinion 
>> > on those. What do you think?
>> >
>> > Editors
>> > Not sure about these. I know there are a few here I'd like to keep:
>> > Blocek, Elvis, FED, Freemacs, MSEDIT, pico, Vim
>> >
>> > *I don't have a good opinion on the other editors in the list. Which ones 
>> > do you think need to stay?
>> >
>> > Emulators
>> > I don't think that these are useful to include in the full distribution. 
>> > These all fall in the general category of "games," anyway. I'd recommend 
>> > we eliminate the entire "Emulators" package group.
>> >
>> > Games
>> > I generally feel that we can add and remove games in the FreeDOS 
>> > distribution on a whim. If a game is interesting and open source, we can 
>> > include it. When a game stops being interesting, or doesn't interest a lot 
>> > of people, we can remove it.
>> >
>> > *I really enjoy Wing and a few others. I don't have strong opinions on the 
>> > other games. What are your thoughts?
>> >
>> > Graphical Desktop
>> > We added GUIs a long time ago when people were still doing active 
>> > development on OpenGEM, oZone, and Seal. If you've been part of the 
>> > discussion for a long time, you also remember we included a few other 
>> > graphical menus and things that have since fallen out of the distribution. 
>> > I think it's time to look at these GUIs too. My recommendations:
>> > 1. PC-GEOS was released as open source software. I haven't followed it, 
>> > but last I checked, they weren't able to compile it (missing libraries, I 
>> > think - requires some rewrites?) If they can get this to compile, I think 
>> > we can include it. If they still can't compile it, then do not include it.
>> > 2. Remove SEAL and oZone. These haven't been worked on for a 

Re: [Freedos-devel] Simplifying FreeDOS

[Chelson a]

Why not have a simple floppy that can install the system via internet
connection?

Base cd, extras cd and boot disk with internet install?



On Sun, 8 Nov 2020 at 05:37, Mark Olesen  wrote:

> Why not have a minimal install iso.  Then have separate additions iso
> for each category? Could the install handle that?
>
> On Sat, Oct 24, 2020 at 2:39 PM Jim Hall  wrote:
> >
> > Some of us had this conversation a while back and I wanted to bring it
> up again on the list.
> >
> > MS-DOS was a small operating system. MS_DOS 5 and 6 fit on a few 1.44MB
> floppy disks.
> >
> > We always intended FreeDOS to not just replace but enhance DOS. FreeDOS
> is "MS-DOS plus more." To make clear what's part of the "core" of FreeDOS,
> we have the "Base" package group. These packages replicate the behavior and
> functionality of MS-DOS. But we also have a lot of other packages that add
> new functionality to FreeDOS, and we put these programs in other package
> groups like "Editors" (additional editors) and "Devel" (compilers,
> assemblers, and other development tools).
> >
> > Over time, FreeDOS has grown to include lots of interesting programs.
> The FreeDOS 1.2 and 1.3RCx distributions are very big.
> >
> > As we look to the next FreeDOS 1.3 Release Candidate, I think we should
> consider removing some packages from the FreeDOS distribution.
> >
> > To be clear: I am not suggesting deleting packages or programs from the
> FreeDOS archive at ibiblio. There's lots of useful and interesting programs
> there. But I don't think we need to include everything in the FreeDOS
> distribution.
> >
> > Here are my thoughts from the FreeDOS 1.3 package list (wiki)
> >
> > Base
> > Keep everything
> >
> > Archivers
> > Do we really need all of those archivers? For example, who needs Zoo
> these days? My suggestions:
> > 1. Move bz2, gzip, and tar to the "Unix" group - these are replicas of
> Unix tools
> > 2. Keep zip, unzip, p7zip
> > 3. Remove the other packages: 7zdec, arj, cabext, lpq1, lzip, lzma,
> lzop, zoo
> >
> > *Note that p7zip can unpack a ton of other file formats, so we don't
> need these other archivers anyway.
> >
> > Boot Tools
> > *I don't have any strong feelings here. What are your thoughts?
> >
> > Development
> > Can we pare down the list a bit? We have a lot of packages here, but I
> don't think we need them all. For example, we should include the tools we
> know we'll need to compile the different FreeDOS utilities. I'd also like
> to keep the GCC related packages, and other packages that remain popular.
> My suggestions:
> > 1. Move perl to the "Unix" group
> > 2. Keep BWBasic, the DJGPP packages, FASM, the FBC packages (FreeBASIC
> Compiler) fpc (FreePascal compiler), the GCC-IA16 packages, JWASM, NASM, OW
> (OpenWatcom C Compiler), and UPX
> > 3. Remove bcc (Bruce's C Compiler), euphoria, insight, lua, regina,
> runtime
> >
> > *I think I missed some packages in that list. I don't have a good
> opinion on those. What do you think?
> >
> > Editors
> > Not sure about these. I know there are a few here I'd like to keep:
> > Blocek, Elvis, FED, Freemacs, MSEDIT, pico, Vim
> >
> > *I don't have a good opinion on the other editors in the list. Which
> ones do you think need to stay?
> >
> > Emulators
> > I don't think that these are useful to include in the full distribution.
> These all fall in the general category of "games," anyway. I'd recommend we
> eliminate the entire "Emulators" package group.
> >
> > Games
> > I generally feel that we can add and remove games in the FreeDOS
> distribution on a whim. If a game is interesting and open source, we can
> include it. When a game stops being interesting, or doesn't interest a lot
> of people, we can remove it.
> >
> > *I really enjoy Wing and a few others. I don't have strong opinions on
> the other games. What are your thoughts?
> >
> > Graphical Desktop
> > We added GUIs a long time ago when people were still doing active
> development on OpenGEM, oZone, and Seal. If you've been part of the
> discussion for a long time, you also remember we included a few other
> graphical menus and things that have since fallen out of the distribution.
> I think it's time to look at these GUIs too. My recommendations:
> > 1. PC-GEOS was released as open source software. I haven't followed it,
> but last I checked, they weren't able to compile it (missing libraries, I
> think - requires some rewrites?) If they can get this to compile, I think
> we can include it. If they still can't compile it, then do not include it.
> > 2. Remove SEAL and oZone. These haven't been worked on for a long time,
> and they are still incomplete
> > 3. Keep OpenGEM. It's not under active development, but it's currently
> pretty solid, if plain looking
> >
> > Networking
> > I don't run FreeDOS with a network, so I don't have any opinions on
> these packages. What do you think?
> >
> > Sound
> > I know OpenCP and MPlayer both work fine, because I demo'd them in a
> YouTube video. I don't have any 

Re: [Freedos-devel] Simplifying FreeDOS

[Mark Olesen]

Why not have a minimal install iso.  Then have separate additions iso
for each category? Could the install handle that?

On Sat, Oct 24, 2020 at 2:39 PM Jim Hall  wrote:
>
> Some of us had this conversation a while back and I wanted to bring it up 
> again on the list.
>
> MS-DOS was a small operating system. MS_DOS 5 and 6 fit on a few 1.44MB 
> floppy disks.
>
> We always intended FreeDOS to not just replace but enhance DOS. FreeDOS is 
> "MS-DOS plus more." To make clear what's part of the "core" of FreeDOS, we 
> have the "Base" package group. These packages replicate the behavior and 
> functionality of MS-DOS. But we also have a lot of other packages that add 
> new functionality to FreeDOS, and we put these programs in other package 
> groups like "Editors" (additional editors) and "Devel" (compilers, 
> assemblers, and other development tools).
>
> Over time, FreeDOS has grown to include lots of interesting programs. The 
> FreeDOS 1.2 and 1.3RCx distributions are very big.
>
> As we look to the next FreeDOS 1.3 Release Candidate, I think we should 
> consider removing some packages from the FreeDOS distribution.
>
> To be clear: I am not suggesting deleting packages or programs from the 
> FreeDOS archive at ibiblio. There's lots of useful and interesting programs 
> there. But I don't think we need to include everything in the FreeDOS 
> distribution.
>
> Here are my thoughts from the FreeDOS 1.3 package list (wiki)
>
> Base
> Keep everything
>
> Archivers
> Do we really need all of those archivers? For example, who needs Zoo these 
> days? My suggestions:
> 1. Move bz2, gzip, and tar to the "Unix" group - these are replicas of Unix 
> tools
> 2. Keep zip, unzip, p7zip
> 3. Remove the other packages: 7zdec, arj, cabext, lpq1, lzip, lzma, lzop, zoo
>
> *Note that p7zip can unpack a ton of other file formats, so we don't need 
> these other archivers anyway.
>
> Boot Tools
> *I don't have any strong feelings here. What are your thoughts?
>
> Development
> Can we pare down the list a bit? We have a lot of packages here, but I don't 
> think we need them all. For example, we should include the tools we know 
> we'll need to compile the different FreeDOS utilities. I'd also like to keep 
> the GCC related packages, and other packages that remain popular. My 
> suggestions:
> 1. Move perl to the "Unix" group
> 2. Keep BWBasic, the DJGPP packages, FASM, the FBC packages (FreeBASIC 
> Compiler) fpc (FreePascal compiler), the GCC-IA16 packages, JWASM, NASM, OW 
> (OpenWatcom C Compiler), and UPX
> 3. Remove bcc (Bruce's C Compiler), euphoria, insight, lua, regina, runtime
>
> *I think I missed some packages in that list. I don't have a good opinion on 
> those. What do you think?
>
> Editors
> Not sure about these. I know there are a few here I'd like to keep:
> Blocek, Elvis, FED, Freemacs, MSEDIT, pico, Vim
>
> *I don't have a good opinion on the other editors in the list. Which ones do 
> you think need to stay?
>
> Emulators
> I don't think that these are useful to include in the full distribution. 
> These all fall in the general category of "games," anyway. I'd recommend we 
> eliminate the entire "Emulators" package group.
>
> Games
> I generally feel that we can add and remove games in the FreeDOS distribution 
> on a whim. If a game is interesting and open source, we can include it. When 
> a game stops being interesting, or doesn't interest a lot of people, we can 
> remove it.
>
> *I really enjoy Wing and a few others. I don't have strong opinions on the 
> other games. What are your thoughts?
>
> Graphical Desktop
> We added GUIs a long time ago when people were still doing active development 
> on OpenGEM, oZone, and Seal. If you've been part of the discussion for a long 
> time, you also remember we included a few other graphical menus and things 
> that have since fallen out of the distribution. I think it's time to look at 
> these GUIs too. My recommendations:
> 1. PC-GEOS was released as open source software. I haven't followed it, but 
> last I checked, they weren't able to compile it (missing libraries, I think - 
> requires some rewrites?) If they can get this to compile, I think we can 
> include it. If they still can't compile it, then do not include it.
> 2. Remove SEAL and oZone. These haven't been worked on for a long time, and 
> they are still incomplete
> 3. Keep OpenGEM. It's not under active development, but it's currently pretty 
> solid, if plain looking
>
> Networking
> I don't run FreeDOS with a network, so I don't have any opinions on these 
> packages. What do you think?
>
> Sound
> I know OpenCP and MPlayer both work fine, because I demo'd them in a YouTube 
> video. I don't have any opinions otherwise.
>
> Unix
> The wiki page lists a few packages to remove based on duplicates or license 
> concerns.
> 1. Move bz2, gzip, and tar from "Archivers" to "Unix"
> 2. Move perl from "Devel" to "Unix"
>
> Utilities
> We have a mix of things in this package group. I think 

Re: [Freedos-devel] Simplifying FreeDOS

[FireBlade X]

I agree with trimming the fat, but Eupora should stay in devel. It was
written for DOS and gives the platform at least one dynamic language the
other OS's take for granted. Obviously Its not suitable for system utils
but applications its a fun and efficient tool to use.

On Wed., Nov. 4, 2020, 5:14 p.m. Rafael Angel Campos Vargas, <
rofoelcom...@gmail.com> wrote:

> Well...
> About the next release of FreeDos...
> I want Dillo for my next Freedos game. It is educative and i am going to
> use a help based on wikipedia.
> I want Setedit. I recommend Rhino (optional) of Djgpp.
> I want Kraptor... It is a new year tradition.
> I want fpc, djgpp, fasm and I recommend Pov Ray 3.5... if you like. I used
> this and others a lot.
> I want freebasic and watcom, but i do not use freebasic nor watcom.
> I want new software about a lor of things...
> Very thanks for my favorite SO.
>
> El 24 oct. 2020 1:39 PM, "Jim Hall"  escribió:
>
>> Some of us had this conversation a while back and I wanted to bring it up
>> again on the list.
>>
>> MS-DOS was a small operating system. MS_DOS 5 and 6 fit on a few 1.44MB
>> floppy disks.
>>
>> We always intended FreeDOS to not just *replace* but *enhance* DOS.
>> FreeDOS is "MS-DOS plus more." To make clear what's part of the "core" of
>> FreeDOS, we have the "Base" package group. These packages replicate the
>> behavior and functionality of MS-DOS. But we also have a lot of other
>> packages that add new functionality to FreeDOS, and we put these programs
>> in other package groups like "Editors" (additional editors) and "Devel"
>> (compilers, assemblers, and other development tools).
>>
>> Over time, FreeDOS has grown to include lots of interesting programs. The
>> FreeDOS 1.2 and 1.3RCx distributions are very big.
>>
>> As we look to the next FreeDOS 1.3 Release Candidate, I think we should
>> consider removing some packages from the FreeDOS distribution.
>>
>> To be clear: I am not suggesting deleting packages or programs from the
>> FreeDOS archive at ibiblio. There's lots of useful and interesting programs
>> there. But I don't think we need to include everything in the FreeDOS
>> *distribution*.
>>
>> Here are my thoughts from the FreeDOS 1.3 package list (wiki)
>> 
>>
>> *Base*
>> Keep everything
>>
>> *Archivers*
>> Do we really need all of those archivers? For example, who needs Zoo
>> these days? My suggestions:
>> 1. Move bz2, gzip, and tar to the "Unix" group - these are replicas of
>> Unix tools
>> 2. Keep zip, unzip, p7zip
>> 3. Remove the other packages: 7zdec, arj, cabext, lpq1, lzip, lzma, lzop,
>> zoo
>>
>> *Note that p7zip can unpack a ton of other file formats, so we don't need
>> these other archivers anyway.
>>
>> *Boot Tools*
>> *I don't have any strong feelings here. What are your thoughts?
>>
>> *Development*
>> Can we pare down the list a bit? We have a lot of packages here, but I
>> don't think we need them all. For example, we should include the tools we
>> know we'll need to compile the different FreeDOS utilities. I'd also like
>> to keep the GCC related packages, and other packages that remain popular.
>> My suggestions:
>> 1. Move perl to the "Unix" group
>> 2. Keep BWBasic, the DJGPP packages, FASM, the FBC packages (FreeBASIC
>> Compiler) fpc (FreePascal compiler), the GCC-IA16 packages, JWASM, NASM, OW
>> (OpenWatcom C Compiler), and UPX
>> 3. Remove bcc (Bruce's C Compiler), euphoria, insight, lua, regina,
>> runtime
>>
>> *I think I missed some packages in that list. I don't have a good opinion
>> on those. What do you think?
>>
>> *Editors*
>> Not sure about these. I know there are a few here I'd like to keep:
>> Blocek, Elvis, FED, Freemacs, MSEDIT, pico, Vim
>>
>> *I don't have a good opinion on the other editors in the list. Which ones
>> do you think need to stay?
>>
>> *Emulators*
>> I don't think that these are useful to include in the full
>> distribution. These all fall in the general category of "games," anyway. I'd
>> recommend we eliminate the entire "Emulators" package group.
>>
>> *Games*
>> I generally feel that we can add and remove games in the FreeDOS
>> distribution on a whim. If a game is interesting and open source, we can
>> include it. When a game stops being interesting, or doesn't interest a lot
>> of people, we can remove it.
>>
>> *I really enjoy Wing and a few others. I don't have strong opinions on
>> the other games. What are your thoughts?
>>
>> *Graphical Desktop*
>> We added GUIs a long time ago when people were still doing active
>> development on OpenGEM, oZone, and Seal. If you've been part of the
>> discussion for a long time, you also remember we included a few other
>> graphical menus and things that have since fallen out of the distribution.
>> I think it's time to look at these GUIs too. My recommendations:
>> 1. PC-GEOS was released as open source software. I haven't followed it,
>> but last I checked, they weren't able to compile it (missing 

Re: [Freedos-devel] Simplifying FreeDOS

[Rugxulo]

Hi,

On Tue, Oct 27, 2020 at 2:15 PM Rugxulo  wrote:
>
> (AFAIK)
> Perl 6 was officially renamed Rakudo.

Apparently the language proper is "Raku" ("camel" in Japanese, like
the old mascot) while the only current major/stable implementation is
Rakudo (Artistic License 2.0, FTW!). The website "perl6.org" just
redirects to "raku.org" (and has the same new mascot, Camelia the
butterfly with the embedded "P6" symbols). It was renamed in October
2019 for ... reasons.

Perl 6 was originally initiated circa 2000, so it's been a long time
coming. Apparently it targets various VMs (including JVM and JS) but
seems to prefer MoarVM. Apparently you can build NQP (Not Quite Perl,
"a lightweight Raku-like environment for virtual machines") with only
Make and Perl 5.8. (No, I doubt it will build with DJGPP, but I
haven't tried.)

Sounds complicated (like almost everything else). Good luck to them.

Just FYI.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Ralf Quint]

On 11/4/2020 5:13 PM, Rafael Angel Campos Vargas wrote:

Well...
About the next release of FreeDos...
I want Dillo for my next Freedos game. It is educative and i am going 
to use a help based on wikipedia.

I want Setedit. I recommend Rhino (optional) of Djgpp.
I want Kraptor... It is a new year tradition.
I want fpc, djgpp, fasm and I recommend Pov Ray 3.5... if you like. I 
used this and others a lot.

I want freebasic and watcom, but i do not use freebasic nor watcom.
I want new software about a lor of things...
Very thanks for my favorite SO.


"You can't always get what you want
But if you try sometime you find
You get what you need..." ;-)

Ralf



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Rafael Angel Campos Vargas]

Well...
About the next release of FreeDos...
I want Dillo for my next Freedos game. It is educative and i am going to
use a help based on wikipedia.
I want Setedit. I recommend Rhino (optional) of Djgpp.
I want Kraptor... It is a new year tradition.
I want fpc, djgpp, fasm and I recommend Pov Ray 3.5... if you like. I used
this and others a lot.
I want freebasic and watcom, but i do not use freebasic nor watcom.
I want new software about a lor of things...
Very thanks for my favorite SO.

El 24 oct. 2020 1:39 PM, "Jim Hall"  escribió:

> Some of us had this conversation a while back and I wanted to bring it up
> again on the list.
>
> MS-DOS was a small operating system. MS_DOS 5 and 6 fit on a few 1.44MB
> floppy disks.
>
> We always intended FreeDOS to not just *replace* but *enhance* DOS.
> FreeDOS is "MS-DOS plus more." To make clear what's part of the "core" of
> FreeDOS, we have the "Base" package group. These packages replicate the
> behavior and functionality of MS-DOS. But we also have a lot of other
> packages that add new functionality to FreeDOS, and we put these programs
> in other package groups like "Editors" (additional editors) and "Devel"
> (compilers, assemblers, and other development tools).
>
> Over time, FreeDOS has grown to include lots of interesting programs. The
> FreeDOS 1.2 and 1.3RCx distributions are very big.
>
> As we look to the next FreeDOS 1.3 Release Candidate, I think we should
> consider removing some packages from the FreeDOS distribution.
>
> To be clear: I am not suggesting deleting packages or programs from the
> FreeDOS archive at ibiblio. There's lots of useful and interesting programs
> there. But I don't think we need to include everything in the FreeDOS
> *distribution*.
>
> Here are my thoughts from the FreeDOS 1.3 package list (wiki)
> 
>
> *Base*
> Keep everything
>
> *Archivers*
> Do we really need all of those archivers? For example, who needs Zoo these
> days? My suggestions:
> 1. Move bz2, gzip, and tar to the "Unix" group - these are replicas of
> Unix tools
> 2. Keep zip, unzip, p7zip
> 3. Remove the other packages: 7zdec, arj, cabext, lpq1, lzip, lzma, lzop,
> zoo
>
> *Note that p7zip can unpack a ton of other file formats, so we don't need
> these other archivers anyway.
>
> *Boot Tools*
> *I don't have any strong feelings here. What are your thoughts?
>
> *Development*
> Can we pare down the list a bit? We have a lot of packages here, but I
> don't think we need them all. For example, we should include the tools we
> know we'll need to compile the different FreeDOS utilities. I'd also like
> to keep the GCC related packages, and other packages that remain popular.
> My suggestions:
> 1. Move perl to the "Unix" group
> 2. Keep BWBasic, the DJGPP packages, FASM, the FBC packages (FreeBASIC
> Compiler) fpc (FreePascal compiler), the GCC-IA16 packages, JWASM, NASM, OW
> (OpenWatcom C Compiler), and UPX
> 3. Remove bcc (Bruce's C Compiler), euphoria, insight, lua, regina, runtime
>
> *I think I missed some packages in that list. I don't have a good opinion
> on those. What do you think?
>
> *Editors*
> Not sure about these. I know there are a few here I'd like to keep:
> Blocek, Elvis, FED, Freemacs, MSEDIT, pico, Vim
>
> *I don't have a good opinion on the other editors in the list. Which ones
> do you think need to stay?
>
> *Emulators*
> I don't think that these are useful to include in the full
> distribution. These all fall in the general category of "games," anyway. I'd
> recommend we eliminate the entire "Emulators" package group.
>
> *Games*
> I generally feel that we can add and remove games in the FreeDOS
> distribution on a whim. If a game is interesting and open source, we can
> include it. When a game stops being interesting, or doesn't interest a lot
> of people, we can remove it.
>
> *I really enjoy Wing and a few others. I don't have strong opinions on the
> other games. What are your thoughts?
>
> *Graphical Desktop*
> We added GUIs a long time ago when people were still doing active
> development on OpenGEM, oZone, and Seal. If you've been part of the
> discussion for a long time, you also remember we included a few other
> graphical menus and things that have since fallen out of the distribution.
> I think it's time to look at these GUIs too. My recommendations:
> 1. PC-GEOS was released as open source software. I haven't followed it,
> but last I checked, they weren't able to compile it (missing libraries, I
> think - requires some rewrites?) *If they can get this to compile*, I
> think we can include it. *If they still can't compile it*, then do not
> include it.
> 2. Remove SEAL and oZone. These haven't been worked on for a long time,
> and they are still incomplete
> 3. Keep OpenGEM. It's not under active development, but it's currently
> pretty solid, if plain looking
>
> *Networking*
> I don't run FreeDOS with a network, so I don't have any opinions on these
> 

Re: [Freedos-devel] Simplifying FreeDOS

[Rugxulo]

Hi again,

Just to clarify 

On Tue, Oct 27, 2020 at 2:15 PM Rugxulo  wrote:
>
> On Sat, Oct 24, 2020 at 6:27 PM Jim Hall  wrote:
> >
> > Another thought: how outdated is this DOS version of perl?
>
> Our build of 5.8.8 (from DJGPP) is from 2008.

Not quite, but close enough. Our build (at least the one I have on
hand) is from 2007 while the copyright itself is from 2006.

> For most basic things, I would greatly prefer AWK or Sed.
>
> I'm not aware of much in FreeDOS that would need Perl. (Devore's NoMySo does, 
> but few here seem to use it.)

The full PERL588B.ZIP (from DJGPP 2.04 /beta/ ... ironically probably
the exact same .ZIP in 2.05 /current/ nowadays, from a quick glance)
that I have here unpacks to 39 MB. If you piecemeal unpack a few
pieces individually, you can minimize that a lot. I was able to get
Devore's NOMYSO working in only about 2 MB of space (hence omitting
most of the 2000+ files). It still has a few bugs and is quite slow,
but it mostly works. (The big advantage is converting implicit data
sizes into explicit overrides and adjusting weird bracket displacement
syntax. It doesn't handle "Assume" seg overrides at all, though.)

I also, years ago, found yet another Befunge-93 interpreter written in
Perl (IIRC, by a guy nicknamed mtve). Not only did I put it inside a
self-contained .BAT (yes, you can do that), but I also slightly
adjusted it (one syntax change) so that it would work even on ancient
5.005 (which was much smaller). (IIRC, 5.005 was just before 5.6.)
Just FYI in case anybody finds that interesting. It's almost a shame
that nobody knows or uses such things anymore. There's a lot of lost
art lying around in computing.

Anyways, I still prefer Sed or AWK. I actually wrote a (very flawed)
AWK script yesterday to auto-adjust implicit data sizes. Previously I
was just doing a functional but very simplistic kludge in Sed (two
passes, temporary files). I was really trying (with AWK) to do it all
in one pass in RAM, but so far I've only half succeeded. But it does
work (mostly). Actually, even that isn't needed with Sed if the
assembler supports EQU or %define (it can be written to a separate
include file), but some assemblers don't (or are buggy).

Yeah, there are no quick fixes for difficult problems, and old code
often needs a lot of work. I'm just trying to get a better
understanding of the basics. No miracles performed here. Still, it's
cool.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[TK Chia]

Hello Steve, hello Random Liegh,


Development; your decisions work for me. I never use perl on dos and I
try to avoid djgpp and GCC-IA16. I end up needing NASM, JWASM, OW, UPX
and FreeBASIC. Would it be possible to replace bwbasic with gw-basic?


Technology-wise, I would think that Open Watcom is the most complete
toolchain (when compared to DJGPP and IA-16 GCC).  If OW's license were
FSF-compatible, I would probably have proposed to make OW an "official"
toolchain.


The open version of GW-BASIC only supports DOS 1.x APIs so far, for what
it's worth.  The general consensus seems to be, it's not worth trying to
reconstitute that code...a shame.  I'd like to see it reconstituted up
to 3.2.


Well, consensus or not, the idea of a GW-BASIC interpreter which is
bug-compatible with, well, GW-BASIC, does sound pretty appealing to me. :-)

I think my current "reconstitution" of GW-BASIC
(https://github.com/tkchia/GW-BASIC/) is quite usable.  It is probably
still not yet near a stage where it can "replace" bwbasic though.
Besides using only DOS 1.x file I/O (which means it does not know about
subdirectories), it is also missing serial port I/O support *a la `OPEN
"COM1:9600,E,7" AS #1' etc.), which seems to be quite a large chunk of
functionality.

(It might turn out to be feasible to modify the code to use DOS 2.x file
I/O syscalls --- they are actually more convenient than the old syscalls
--- but I have yet to try that.)

Thank you!

--
https://github.com/tkchia/


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Rugxulo]

Hi,

On Sat, Oct 24, 2020 at 6:27 PM Jim Hall  wrote:
>
> Another thought: how outdated is this DOS version of perl? I know it's Perl 
> 5.8.8 and the current version is 5.32.x.
> But how "far apart" are those two versions? (It's been years since I 
> intentionally wrote a perl script, so I don't know.)

I've never done any Perl programming. (I have an old book from my
brother, but neither of us ever read it.) But I greatly respect Larry
Wall. It's not perfect (nor is anything), but it can sometimes rarely
be useful (e.g. rebuilding NASM instruction tables to save RAM).

(AFAIK)
Perl 6 was officially renamed Rakudo.
Perl 7 is the "next generation" based upon Perl 5.32 (with "shrinking"
[??] backwards compatibility, saner defaults [use strict ??]).
Perl 5 has been around, in various forms, since 1994.
Our build of 5.8.8 (from DJGPP) is from 2008.

To be honest, there are so many languages that everything overlaps:
Python, Ruby, REXX, AWK, Sed, etc. For most basic things, I would
greatly prefer AWK or Sed.

I'm not aware of much in FreeDOS that would need Perl. (Devore's
NoMySo does, but few here seem to use it.)


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Rugxulo]

Hi,

On Sat, Oct 24, 2020 at 4:21 PM Steve Nickolas  wrote:
>
> On Sat, 24 Oct 2020, Eric Auer wrote:
>
> > Regina REXX was not very small, while some others are small?
>
> Regina at least has some justification.  Some later versions of PC DOS
> came with REXX.

Yeah, it replaced QBASIC there.

REXX is a very cool language (ANSI standard, too, in 1996). TRL2
(1990) was version "4.00" while ANSI was "5.00" and the newer
(non-standard) OOP variant ooREXX is version "6.00" (can be detected
at runtime and your source can branch accordingly). It's garbage
collected, no reserved words, an "easier PL/I", meant even for
non-professional programmers, with few arcane symbolic "line noise"
needed. No dangling pointers nor manual memory management needed just
to use linked lists! (Howard Fosdick gives away his REXX book [PDF]
for free on his website.) It's roughly the same capabilities as
*nix/POSIX AWK (which is also quite useful and has some good DOS
ports).

I don't know if ooREXX will build with DJGPP. Probably not, but I
haven't checked lately. IIRC, it required C++ and Pthreads. But maybe
DJGPP's FSU Pthreads (like in p7zip) would let it "mostly" work??
Honestly, I don't grok any of the Smalltalk-esque OOP stuff (but the
newsgroup users always seemed to love and prefer it).

Our Regina build (ANSI only, no OOP) is mine from 2012 using DJGPP.
Later sources had bugs that I never dug into that made it refuse to
build. You could maybe argue that even rebuilding 3.7 with DJGPP 2.05
(or newer, more powerful GCC) might bring some benefit. Dunno. But he
did (barely) update 3.93 last year (after several years of
inactivity). I haven't checked lately to see if I could rebuild it. I
probably need to do that (since, indeed, I started getting back into
it a little bit).

Just FYI, in case anybody is curious. (No, I never used PC-DOS, but
I'm sure it's good ... but not as good as FreeDOS!)


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Rugxulo]

Hi,

Sorry, I'm late to this thread, but ... I don't feel like reading ten
pages before quickly responding to this misunderstanding.


On Sat, Oct 24, 2020 at 2:39 PM Jim Hall  wrote:
>
> Over time, FreeDOS has grown to include lots of interesting programs. The 
> FreeDOS 1.2 and 1.3RCx distributions are very big.
>
> As we look to the next FreeDOS 1.3 Release Candidate, I think we should 
> consider removing some packages from the FreeDOS distribution.
>
> To be clear: I am not suggesting deleting packages or programs from the 
> FreeDOS archive at ibiblio.
> There's lots of useful and interesting programs there. But I don't think we 
> need to include everything in the FreeDOS distribution.

If you keep networking (FDNET), at least for QEMU and/or VBox, then
you can offload as much as you want to further downloads. That way is
simpler, IMHO. But clearly we're not trying for extreme minimalism
here (like MetaDOS).

> Here are my thoughts from the FreeDOS 1.3 package list (wiki)
>
> Archivers
> Do we really need all of those archivers? For example, who needs Zoo these 
> days? My suggestions:
> 1. Move bz2, gzip, and tar to the "Unix" group - these are replicas of Unix 
> tools
> 2. Keep zip, unzip, p7zip
> 3. Remove the other packages: 7zdec, arj, cabext, lpq1, lzip, lzma, lzop, zoo
>
> *Note that p7zip can unpack a ton of other file formats, so we don't need 
> these other archivers anyway.

I've explained several times that p7zip is very buggy. It has many
versions (for DOS/DJGPP) and many flaws. I do not consider it as
"standalone" nor totally stable. (Even worse, our package is an
archaic version, 4.65.) In particular, very few people seem inclined
to rebuild to even attempt fixes. I've done so before (despite limited
skills) and did some fixes with 9.20, but it's never going to be
perfect. Even M.K.'s latest build of 16.02 I didn't mirror
(particularly because it included non-Free RAR support, which you
dislike). I also didn't find the time to diff his changes since he
just included one lump source archive instead of a separate patch. His
build still has many bugs and idiosyncrasies due to the POSIX nature
of the port (and the Win32-centric nature of the original sources). It
doesn't mean it's useless, far from it, but it is indeed tedious to
use.

7zdec is very simplified, so it lacks some things ("-x!" can be very
useful in rare circumstances), but it's much cleaner and smaller, if
you're only interested in simply unpacking entire .7z archives. I
would definitely not exclude it. (In fact, I emailed you recently
saying I personally wanted to update it to a newer version.)

> Development
> Can we pare down the list a bit? We have a lot of packages here, but I don't 
> think we need them all.
> For example, we should include the tools we know we'll need to compile the 
> different FreeDOS utilities.
> I'd also like to keep the GCC related packages, and other packages that 
> remain popular.

By far, DJGPP and FPC take up the most space, IIRC, but few people
here use them (from FD packages, I mean, most just grab newer versions
upstream). That doesn't mean they aren't incredibly useful, just that
we never seemed motivated enough to update the DJGPP packages (which
get even huger in newer versions). I halfway suggested before that we
make "DJGPPLITE" (GCC 2.95.3 or 3.46?) or "FPCLITE", but nobody seemed
to even acknowledge the usefulness of that idea. (Yes, I saw Andris'
recent email about DJGPP 2.05 / GCC 10.2. Honestly, I'm not sure how
to 100% bundle all the appropriate sources [MPC? MPFR?], which are
huge and impossible to build in raw DOS anyways.) AFAIK, there's
little reason to have a separate BinUtils anyways since no other
package relies on it besides GCC (which, in newer versions, also
requires newer BinUtils). FPC doesn't really need it anymore, and FBC
has its own older version.

> Editors
> Not sure about these. I know there are a few here I'd like to keep:
> Blocek, Elvis, FED, Freemacs, MSEDIT, pico, Vim

Probably not, honestly, but it's not the end of the world. There's too
much stuff. I'm not direly opposed to anything that works, but some
things are very flawed.

> Networking
> I don't run FreeDOS with a network, so I don't have any opinions on these 
> packages. What do you think?

FDNET just borrows from Crynwr, but without it we can't have a working
packet driver under QEMU. I would consider removing it "a downgrade /
loss of useful functionality" (but maybe you're still worried about
the confusing licensing text??).

> Utilities
> We have a mix of things in this package group. I think some of these were 
> interesting long ago, but probably aren't used anymore and can be deleted. My 
> recommendations:
> 1. Keep aefdisk, ansimat, bootfix, callver, cdrcache, cdrom2ui clamav + 
> clamdb, cpied, cwsdpmi, dialog, dn2, dog, dos32a, dosutil, doszip + dzemm,
> fdimples + fdisrc, fdnpkg, fdshield, fdtui, foxcalc, foxtype, gcdrom, gnuchcp 
> + gnufonts, hexcomp, localize, lptdrv, memteste, 

Re: [Freedos-devel] Simplifying FreeDOS

[Jerome Shidel]

Eric,

> On Oct 26, 2020, at 9:06 AM, Eric Auer  wrote:
> 
> 
> Hi Jerome,
> 
>> The more I think about it. The more I like a having a separate EXTRAS disc.
>> 
>> Possibly even dropping the FULL/BASE choice and having just a BASE. 
> 
> We did have a separate BASE ISO at some point in the past, but given
> your earlier hint that FPC and DJGPP are 70 MB each, I think we should
> still "show off" having a lot of cool stuff in our main ISO, excluding
> only a handfull of the most bloated packages, such as FPC and DJGPP.

That was 1.0. However, it really only had BASE. The other disc was BASE + 
SOURCES.

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/ 


> 
> You could for example make a separate download for "full choice of
> compilers and emulators" while keeping the 10 smallest compilers
> and everything else on the normal ISO for every FreeDOS fan :-)
> 
> The actual "replicates MS DOS" subset is so small that it
> fits on 2 to 3 diskettes with suitable compression, so it
> would be sort of anticlimactic to have only that on a CD.
> 
> Cheers, Eric

The minimal BASE is rough 5-6MB compressed without sources. 

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc3/
 

 

The 1.3-RC3 Light USB, is 20mb (Base + Source Only)

The 1.3-RC3 Full USB, is 608mb (Base + Source or Full, plus Extras + All 
Sources)

The 1.3-RC3 Floppy Only zip file 5.4mb,

But, yes, it kinda feels wasteful to burn 6, 10 or 20mb and use an entire CD. 


> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Eric Auer]

Hi Jerome,

> The more I think about it. The more I like a having a separate EXTRAS disc.
>  
> Possibly even dropping the FULL/BASE choice and having just a BASE. 

We did have a separate BASE ISO at some point in the past, but given
your earlier hint that FPC and DJGPP are 70 MB each, I think we should
still "show off" having a lot of cool stuff in our main ISO, excluding
only a handfull of the most bloated packages, such as FPC and DJGPP.

You could for example make a separate download for "full choice of
compilers and emulators" while keeping the 10 smallest compilers
and everything else on the normal ISO for every FreeDOS fan :-)

The actual "replicates MS DOS" subset is so small that it
fits on 2 to 3 diskettes with suitable compression, so it
would be sort of anticlimactic to have only that on a CD.

Cheers, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Jerome Shidel]

> On Oct 24, 2020, at 7:26 PM, Jim Hall  wrote:


The more I think about it. The more I like a having a separate EXTRAS disc.
 
Possibly even dropping the FULL/BASE choice and having just a BASE. 

BASE to replicate MS-DOS functionality, plus networking support (FDNET), FDNPKG 
and FDIMPLES. 

Put all games, development tools, other utilities and etc on a separate media. 

If the users want more stuff, they can use the additional CD and FDIMPLES or 
FDNPKG to install it. 

This would bring the release down to the approximate size of the Floppy Only 
edition.

The exception being the LiveCD should contain some extra tools and games and 
such. 

> 
> 
> EDICT. 
> 
> At present, it creates images of diskettes. Similar to raread (image files 
> are compatible). However, unlike raread it is far more persistent and always 
> creates appropriate sized images. EDICT came into existence because I had a 
> bunch of really old and neglected floppies sitting around. I couldn’t get 
> Linux/Mac’s dd to image them. Nor was raread able to do it. Some of the 
> diskettes were very borderline, throwing read errors at different places on 
> each attempt. So, EDICT was born and was able to pull good images from those 
> diskettes. 
> 
> There are future plans to stop, resume, switch drives or computers and 
> generally improve data extraction. (Only so much time). Eventually, it will 
> also get support to create disks from images. Operate on hard drives and 
> partitions, etc. Once diskette creation is added, it could replace raread + 
> rawrite at a fraction of their size. 
> 
> Did I mention it also has multi-language support and is pure assembler?
> 
> 
> If it makes sense to include EDICT, then it can stay. Just putting out ideas 
> for people to respond to. :-)

At present, it’s only turns diskettes into images. Although it is smaller and 
better at conversion than raread (especially with hard to read diskettes), 
raread has been around a long long time, has had a lot of testing and is known 
by the DOS community. If I had to make an un-biased decision, raread may be a 
better choice for now. However when I eventually add the other features I 
mentioned, EDICT would be a better choice than raread+rawrite.

There is no reason that the choice for today need be the choice for tomorrow. 

> 
> PGME.
> 
> Fully customizable, text mode multi-language program launching multi-menu 
> system on steroids and some associated utilities. Add the couple (or 
> hundreds) of games and/or programs to one or more menus, then add it to your 
> autoexec or fdauto. Never see or type anything at the command prompt again. 
> You can even use some of the KIOSK features to lock the menus and keep a user 
> from exiting to a command prompt. 
> 
> 
> I haven't used PGME. Is it similar to the text-mode DOS shell from MS-DOS 4?

PGME similar to DOSSHELL? Not even remotely similar. 

A little PGME history…

PGME’s roots go back a long, long way to circa 1983 on a Coleco Vision Adam. 
The need arose to do cassette tape boot sector hacking in machine language to 
provide improvements to a menu that would pick and then load one of  several 
game cartridge ROMs stored on cassette. Not to long later, the PC/clone became 
a thing and moving to DOS, the concept of having a menu to quickly and easily 
run programs and games came along. From simple batch menus, to a Quick Basic 
version and on to TurboPascal the need remained. It grew more advanced, easier 
to use and changed names a couple times over the years. Eventually as PGM 7.2, 
it sat for decades as “good enough”. There was a version 8.x started. It was in 
graphics mode and was dropped for several reasons. Mostly, because of users 
switching to Windows 3.1. Version 9.x was considered for Windows 3.1. However 
do to like of time and motivation, never happened. Then a couple years ago, I 
was bored and decided to do version 10 with another slight name change to PGME. 
The E stands for Eternity. It is complete overkill of the concept. There are a 
couple features I have yet to add to PGME. But version 10 is the last version. 
This one is built to last forever. 

What program is PGME like? 
(With PGME’s roots being ancient, it would be more fair to say “what program is 
like PGME?“) 

Well, I’ve seen a couple other’s that have sprung up over the decades. But 
preferred none over the at-the-time version of PGM. But, I forget most of their 
names and wouldn’t expect anyone else to remember them either. If I had to pick 
one thing that is most like PGME that any layman would be familiar with, it 
would be the “Windows Start Menu”. But that is only in concept, not design. The 
Start Menu allows a user to only need click on a menu item and end up with the 
program they want running. PGME also allows users to double-click on a menu 
item to run a program (single-click only selects the item).

What are some features of PGME?

Text mode only.
Custom Fonts (ranging from 8x8 to 8x26). 
Themed UI. 

Re: [Freedos-devel] Simplifying FreeDOS

[Steve Nickolas]

On Sun, 25 Oct 2020, Harald Arnesen wrote:


I made a new port of tail in March, taken from 4.3BSD, and sent it to
the list. Here it is again, rename attachment to "tail.zip".


4.3BSD would certainly be an improvement over what I did.  I should've 
thought of that - knew the 4.4BSD version wouldn't port because it uses 
mmap(), but never thought to check if an earlier version used a different 
method.


-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Steve Nickolas]

On Sun, 25 Oct 2020, Eric Auer wrote:


Do you say in the Unix group, only TAIL and UPTIME have
license issues? Any other packages in other categories?


If tail and uptime are the only issues I can solve the former: I've got a 
PD (it's unambiguous that this was the author's intent; it says 
"Copyright: None. Released to the public domain.") version of tail I took 
from Minix a while ago for another project before replacing it with the 
BSD version.  I got it to roll under Watcom and it seems to work there, 
just kitbashed (I didn't do any advanced testing).


Uptime, that's trickier, I'm not sure how exactly that could be 
determined, but I could perhaps kitbash something up.


http://6.buric.co/tail-dos.zip

-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Eric Auer]

Hi Jim, a few short additional thoughts:

> But CAB files? No DOS system distributed files in CAB format

I remember DOS drivers for stuff like soundcards shipping
as part of some Windows installers. So it helps to be able
to dig into files meant for Windows, without needing any
Windows or Wine, but I do not remember a specific thread
on our lists which explains this in more detail.

About DJGPP: It is almost like Linux, so many tools ;-)
And I think there once really was an entire distro for
DJGPP itself and all the ported GNU apps around it?

Do you say in the Unix group, only TAIL and UPTIME have
license issues? Any other packages in other categories?

Regards, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Steve Nickolas]

On Sat, 24 Oct 2020, Random Liegh via Freedos-devel wrote:



What DOS was, in my mind, was simple. You didn't really have an entire tree 
with documents in one place, helpfiles in another and LSM files in a third. 
You had -for MS DOS, c:\dos. Everything was there.


It's been a long time, but I think PC-DOS may have had some folders with help 
files -so it was like DOS -> DOS\help or something? It's been ages and I 
could be misremembering but that would still be simple enough for me.


PC DOS 7 had a couple folders with back-end stuff for the stuff IBM 
licensed from Central Point, but that's about it, judging by how I have a 
disk image set up in QEMU.




Development; your decisions work for me. I never use perl on dos and I try to 
avoid djgpp and GCC-IA16. I end up needing NASM, JWASM, OW, UPX and 
FreeBASIC. Would it be possible to replace bwbasic with gw-basic?




The open version of GW-BASIC only supports DOS 1.x APIs so far, for what 
it's worth.  The general consensus seems to be, it's not worth trying to 
reconstitute that code...a shame.  I'd like to see it reconstituted up to 
3.2.


Then again, the question would be: Did M$ release 1.x because that's what 
they wanted to release, or because that's all they could dig up?  If the 
latter, then disassembling or reconstituting the 3.23 source would be 
legitimate.  (And I have reason to suspect both are plausible.)


-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Random Liegh via Freedos-devel]

On 10/24/2020 3:26 PM, Jim Hall wrote:



On Sat, Oct 24, 2020 at 6:06 PM Jerome Shidel > wrote:


Hi,

If I don’t mention removing or keeping something, I don’t have
much of an opinion on it.


Over time, FreeDOS has grown to include lots of interesting
programs. The FreeDOS 1.2 and 1.3RCx distributions are very big.

As we look to the next FreeDOS 1.3 Release Candidate, I think we
should consider removing some packages from the FreeDOS distribution.


We will definitely need to do that eventually. As thing are now,
it will continue to grow and grow and at some point we will be
forced to ship it as a DVD or 2 CD set.


Yeah, I'm trying to avoid turning FreeDOS into a multi-CD software 
set. It's DOS. It should be small. :-)


I would tend to disagree -not that DOS is small (yes, it ought to be); 
but that a multi-cd software set would be a bad thing. We don't really 
have BBS' and such any more and god only knows about the things you find 
on archive.org and such sites. I think having a dev cd and game cd 
wouldn't be a horrible thing -though it may be from a maintenance point 
of view.


But from my point of view, that's the better way to go.

My largest problem with what is provided in FreeDOS is the 
organizational scheme. It's too crowded and unix-centric.


What DOS was, in my mind, was simple. You didn't really have an entire 
tree with documents in one place, helpfiles in another and LSM files in 
a third. You had -for MS DOS, c:\dos. Everything was there.


It's been a long time, but I think PC-DOS may have had some folders with 
help files -so it was like DOS -> DOS\help or something? It's been ages 
and I could be misremembering but that would still be simple enough for me.


Obviously everything in one folder that would be a horrible idea for 
FreeDOS, I'm not sure what to suggest apart from that. One thing I would 
suggest -probably not for the upcoming release, would be to consider a 
less overwhelming layout. LSM files ought to be with the source since 
they're used by the developers, and instead of trying to recreate a 
unix-style of tree i'd suggest having the base programs in fdos, 
helpfiles in fdos\help\$program, READMES and program documents in 
fdos\docs\$program and the rest put off into a seperate developer tree. 
perhaps c:\src.fd\$program and (in the case of LSM files) 
c:\src.fd\$program\lsm and so on.


I like the way that the dev tools are put off into the develop folder 
now, and I'd expand on that -maybe have an opt folder for miscellaneous 
programs (instead of putting them in c:\)?


To touch briefly on your original email, I think that the net packages 
should remain as they are -especially if you're going to include less on 
cd and people will need to be able to connect and use fdnpkg to install 
things from ibiblio.


I'd like to see tar and gzip stay in base simple because using pcem and 
86box I have had problems creating zipfiles (usually out of memory 
errors). Tar and gzip have usually been more reliable for me. I could 
simply fetch them from the unix collection, but it's convient having 
them in base.


Editors; I use msedit and the FreeDOS editor; I don't really use vim, 
pico or the others.


Development; your decisions work for me. I never use perl on dos and I 
try to avoid djgpp and GCC-IA16. I end up needing NASM, JWASM, OW, UPX 
and FreeBASIC. Would it be possible to replace bwbasic with gw-basic?


I'd like to see both lfndos and doslfn kept, but as long as one's 
available I am ok.


Myself, I never use the desktops and I'd almost suggest moving them to 
c:\windows ...or a similar idea ;)


Anyway, that's my thoughts -ty for keeping the torch lit and aloft!


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Jim Hall]

On Sat, Oct 24, 2020 at 3:22 PM Eric Auer  wrote:

>
> Hi Jim, good to think about the package list :-)
>
> If you ask me, the distro has grown large because a SMALL
> number of packages are rather LARGE. Even then, when you
> do not install all sources, it uses a lot less space: It
> would be fine to keep the sources zipped until one wants
> to work on a specific package.
>

Yes, that is why we have the option to install without source code.


> > 3. Remove ... 7zdec, arj, cabext, lpq1, lzip, lzma, lzop, zoo
>
> I guess it would be okay to have those somehow separate,
> although I wonder how large they are anyway. People might
> enjoy ARJ and CAB support out of the box.
>
>
I want to be careful about how many packages we include that do not really
need to be there. I can see an argument to keep the ARJ tool, because some
websites have archives of classic shareware games, and some of them come in
ARJ format.

But CAB files? No DOS system distributed files in CAB format - that's
Windows. But p7zip is supposed to be able to extract CAB files (I haven't
tried).

> *Development*
> > Can we pare down the list a bit?
>
> I guess the complete DJGPP ecosystem could be moved to
> a separate group, it can get really big.
>
>
I think creating a "sub-group" like one just for DJGPP is a bad idea. Think
about this from the viewpoint of users who want to do programming under
FreeDOS: They go into the "Development" group and look for a list of
compilers and assemblers. "Oh, no DJGPP?" But wait - it's really there, if
you go look somewhere else for it?

DJGPP is a compiler, it should stay in "Development."



> > 1. Move perl to the "Unix" group
>
> That would confuse me. Perl is multi-platform and it
> clearly is a programming language.
>

I guess I don't know what to do with perl if we keep it. See also my other
reply to Jerome where I mention perl - how outdated is our version?



>
> > 2. Keep BWBasic, the DJGPP packages, FASM, the FBC packages
> > (FreeBASIC Compiler) fpc (FreePascal compiler), the GCC-IA16
> > packages, JWASM, NASM, OW (OpenWatcom C Compiler), and UPX
>
> I would move UPX to archivers, although it is not multi-file.
> People will have to be aware that FBC, FPC, OW, DJGPP are big.
>

Is UPX really an "archiver" though? It's an *executable packer*. It's not a
general file compression program. UPX should stay in "Development."


> > 3. Remove bcc (Bruce's C Compiler), euphoria, insight, lua, regina,
> runtime
>
> I would move RUNTIME to some generic tool category. I believe
> Regina REXX was not very small, while some others are small?
>

I agree; if we keep it, Runtime belongs in a different group. (FWIW: I
wrote this version of Runtime.)


>
> > *Editors*
> > Not sure about these. I know there are a few here I'd like to keep:
> > Blocek, Elvis, FED, Freemacs, MSEDIT, pico, Vim
>
> I would add SETEDIT because it can edit large files, maybe TDE?
>

Agree on both. We should keep SETEDIT and TDE on the list.



> > *Graphical Desktop*
> > We added GUIs a long time ago...
>
> Of course most GUI do not have lots of apps, so it
> might be good to treat them similar to emulators by
> offering them separately, outside the ISO. How about
> the set of productivity apps ported by Georg Potthast?
> I agree that OpenGEM is a good choice as general GUI.
>
>
I tried to get rid of the GUI package group, years ago, but people wanted
to keep it. :-)

My general issue with GUIs is this: I think it's confusing to include a GUI
on FreeDOS if it makes people think that GUI is basically a replacement for
Windows. I think OpenGEM is different enough from Windows that people
aren't likely to think it's "Windows." But oZone and SEAL are a bit
Windows-like.

>
> > *Unix*
> > The wiki page lists a few packages to remove based on
> > duplicates or license concerns.
>
> Which ones would you remove?
>
>
In my original email, I gave this link:
http://wiki.freedos.org/wiki/index.php/Releases/1.3/Packages

On that wiki page, if you scroll down to the "Unix" group, you'll see we're
removing Tail and Uptime from that license group.


> > *Utilities*
> > We have a mix of things in this package group...
>
> > 2. Remove b64, blwcbc, bmp2png, bsum, daa2iso, edict, fdshell,
>
> It is good to have Base64 support and PNG support.
> Blowfish, BSD sum and DAA/GBI are indeed exotic.
> FDSHELL and EDICT (disk imaging) sound useful.
>
> > finddisk, flashrom, gifsicle, hip, hiram, pgme,
> > pngcrush, sqlite, terminal, topspin, wptail, zdir,> zerofill
>
> Of course I suggest to keep FINDDISK and TERMINAL :-)
>
> FLASHROM sounds useful, depending on how many mainboard
> chipsets it is able to BIOS update?
>
> HIP and GIFsicle sound a bit exotic. I do not see PGME
> on the list, so no opinion about that.
>
> How does HIRAM compare to UMBPCI?
>
> PNGCRUSH is a bit exotic, as is SQLITE. If anything,
> the latter could be kept as a programming language?
>
> TOPSPIN, WHIPTAIL and similar might be too special.
> I have no opinion about ZDIR.
>
> ZEROFILL 

Re: [Freedos-devel] Simplifying FreeDOS

[Jim Hall]

On Sat, Oct 24, 2020 at 6:06 PM Jerome Shidel  wrote:

> Hi,
>
> If I don’t mention removing or keeping something, I don’t have much of an
> opinion on it.
>
> Over time, FreeDOS has grown to include lots of interesting programs. The
> FreeDOS 1.2 and 1.3RCx distributions are very big.
>
> As we look to the next FreeDOS 1.3 Release Candidate, I think we should
> consider removing some packages from the FreeDOS distribution.
>
>
> We will definitely need to do that eventually. As thing are now, it will
> continue to grow and grow and at some point we will be forced to ship it as
> a DVD or 2 CD set.
>

Yeah, I'm trying to avoid turning FreeDOS into a multi-CD software set.
It's DOS. It should be small. :-)



>
> Although, a FreeDOS cd that only contains BASE and FULL along with an
> EXTRA packages CD may actually be better than including uninstalled
> packages as EXTRAS on the install media.
>
>
As we shoot for FreeDOS 1.3, I want to get away from the "Extras" thing.
When people do a "Full" install of FreeDOS 1.3, they really should get
*everything* that's available in the distribution. There shouldn't be
"extras" that they can also install afterwards.

>From the user perspective, "doing a 'Full' install" means "install
everything." So it's confusing to have "extras" that they could install via
FDIMPLES afterwards.

If a package isn't really necessary (i.e. not used by many people, etc)
then I think it shouldn't be in the FreeDOS 1.3 distribution. They can get
it from the Files Archive at ibiblio and install it separately if they like
to.

*Base*
> Keep everything
>
>
> Drop or update SAMCFG. It is extremely outdated.
>

Missed that one. Thanks.



>
> *Archivers*
> Do we really need all of those archivers? For example, who needs Zoo these
> days? My suggestions:
>
>
> Just a point to note.
>
> Although you did not mention Slicer, it provides the install functionality
> for the Floppy Only version.
> Those needs caused are/were not met by any other archiver. When compared
> to others (like tar), it’s
> design and operation are very different.
>
> However practically speaking, (other than the Floppy Only version), no one
> else really needs it. Nor
> will any one else probably ever use it.
>

Good point. I should clarify: there may be tools listed on my "remove"
lists that are used during the install process. In that case, "remove"
doesn't mean "don't use it" but rather "this doesn't need to be installed
as part of the Full install." It doesn't need a separate package.

That said, those tools that are used during the install process need to
have source code available for them somewhere, preferably on the install
CD. (Doesn't need to be included on the install boot floppy, since that's
limited space. But "from the same place" in the GNU GPL could refer to the
install CD - in my opinion.)



>
> *Boot Tools*
> *I don't have any strong feelings here. What are your thoughts?
>
>
> I don’t think we need them.
>
> Tools Booting FreeDOS from ROM? I don’t think 99.9% of the people who
> download FreeDOS would miss them.
> Syslinux? We use it on some of the install media. But, do most end-users
> need it on the release?
>


Agree. (See also my point above [in this reply] about tools in the install
process.)



>
> *Development*
>
>
> This is the section with some of the biggest offenders. We are talking
> HUGE packages.
>
> FPC roughly 70mb,
> DJGPP, almost as big.
> IA-GCC, no slouch either.
> OWC, nothing to sneeze at.
>
> Drop those and reduce the ISO by roughly 160mb.
>
> Drop all of the development tools and probably cut the ISO in half.
>


I'd assumed the compilers and assemblers were quite big, but I didn't do
the math. Wow.



> *Games*
> I generally feel that we can add and remove games in the FreeDOS
> distribution on a whim. If a game is interesting and open source, we can
> include it. When a game stops being interesting, or doesn't interest a lot
> of people, we can remove it.
>
> *I really enjoy Wing and a few others. I don't have strong opinions on the
> other games. What are your thoughts?
>
>
> I think we need more “good” games.
>
>
Agree! I also like DrMind - and of course, Simple Senet. :-)

I think we should also watch the DOS Games Jam and see what interesting DOS
games come out of that. (I don't think it literally has to be a "DOS" game
to be part of the DOS Games Jam - it just has to feel part of the DOS era.
But I'd be interested in actual DOS games. The Spring Jam winner was
Post-Apocalyptic Petra, which was a DOS game.)


>
> *Graphical Desktop*
> We added GUIs a long time ago when people were still doing active
> development on OpenGEM, oZone, and Seal. If you've been part of the
> discussion for a long time, you also remember we included a few other
> graphical menus and things that have since fallen out of the distribution.
> I think it's time to look at these GUIs too. My recommendations:
> 1. PC-GEOS was released as open source software. I haven't followed it,
> but last I checked, 

Re: [Freedos-devel] Simplifying FreeDOS

[Jerome Shidel]

Hi,

If I don’t mention removing or keeping something, I don’t have much of an 
opinion on it.

> Over time, FreeDOS has grown to include lots of interesting programs. The 
> FreeDOS 1.2 and 1.3RCx distributions are very big.
> 
> As we look to the next FreeDOS 1.3 Release Candidate, I think we should 
> consider removing some packages from the FreeDOS distribution.

We will definitely need to do that eventually. As thing are now, it will 
continue to grow and grow and at some point we will be forced to ship it as a 
DVD or 2 CD set. 

Although, a FreeDOS cd that only contains BASE and FULL along with an EXTRA 
packages CD may actually be better than including uninstalled packages as 
EXTRAS on the install media.  

> Base
> Keep everything

Drop or update SAMCFG. It is extremely outdated. 

> Archivers
> Do we really need all of those archivers? For example, who needs Zoo these 
> days? My suggestions:

Just a point to note.

Although you did not mention Slicer, it provides the install functionality for 
the Floppy Only version. 
Those needs caused are/were not met by any other archiver. When compared to 
others (like tar), it’s 
design and operation are very different. 

However practically speaking, (other than the Floppy Only version), no one else 
really needs it. Nor 
will any one else probably ever use it. 

> Boot Tools
> *I don't have any strong feelings here. What are your thoughts?

I don’t think we need them. 

Tools Booting FreeDOS from ROM? I don’t think 99.9% of the people who download 
FreeDOS would miss them.
Syslinux? We use it on some of the install media. But, do most end-users need 
it on the release?

> Development

This is the section with some of the biggest offenders. We are talking HUGE 
packages. 

FPC roughly 70mb,
DJGPP, almost as big.
IA-GCC, no slouch either.
OWC, nothing to sneeze at.

Drop those and reduce the ISO by roughly 160mb.

Drop all of the development tools and probably cut the ISO in half. 

> Emulators
> I don't think that these are useful to include in the full distribution. 
> These all fall in the general category of "games," anyway. I'd recommend we 
> eliminate the entire "Emulators" package group.

Since most are running probably running FreeDOS in a virtual machine to support 
their old DOS games, I’d agree. Running emulators within emulators can get 
rather slow. 
 
( Personally, I think I’ve only gone 3 emulators deep. VM running VMware 
server, running Linux, running qemu. Talk about slow... ). 

> Games
> I generally feel that we can add and remove games in the FreeDOS distribution 
> on a whim. If a game is interesting and open source, we can include it. When 
> a game stops being interesting, or doesn't interest a lot of people, we can 
> remove it.
> 
> *I really enjoy Wing and a few others. I don't have strong opinions on the 
> other games. What are your thoughts?

I think we need more “good” games. 

> 
> Graphical Desktop
> We added GUIs a long time ago when people were still doing active development 
> on OpenGEM, oZone, and Seal. If you've been part of the discussion for a long 
> time, you also remember we included a few other graphical menus and things 
> that have since fallen out of the distribution. I think it's time to look at 
> these GUIs too. My recommendations: 
> 1. PC-GEOS was released as open source software. I haven't followed it, but 
> last I checked, they weren't able to compile it (missing libraries, I think - 
> requires some rewrites?) If they can get this to compile, I think we can 
> include it. If they still can't compile it, then do not include it.
> 2. Remove SEAL and oZone. These haven't been worked on for a long time, and 
> they are still incomplete
> 3. Keep OpenGEM. It's not under active development, but it's currently pretty 
> solid, if plain looking

PC-GEOS is pretty big. 

> 
> Networking
> I don't run FreeDOS with a network, so I don't have any opinions on these 
> packages. What do you think?

Use networking a lot. 

ETHERDFS is very useful for transferring files and doing development. 

( Side note… Eventually, I really need to add networking support to FDIMPLES. 
It would take a lot of worry out of the “should we keep or drop” discussion. 
Since most users are running in a VM, they could just browse the repo and fetch 
what they want. Only so many hours in the day. :-(  )

> Unix
> The wiki page lists a few packages to remove based on duplicates or license 
> concerns.
> 1. Move bz2, gzip, and tar from "Archivers" to "Unix"
> 2. Move perl from "Devel" to “Unix"

I don’t think we need to “ship” perl. 

Just a thought… We are DOS not Unix...

> 
> Utilities
> We have a mix of things in this package group. I think some of these were 
> interesting long ago, but probably aren't used anymore and can be deleted. My 
> recommendations:
> 1. Keep aefdisk, ansimat, bootfix, callver, cdrcache, cdrom2ui clamav + 
> clamdb, cpied, cwsdpmi, dialog, dn2, dog, dos32a, dosutil, doszip + dzemm, 
> fdimples + fdisrc, 

Re: [Freedos-devel] Simplifying FreeDOS

[Steve Nickolas]

On Sat, 24 Oct 2020, Eric Auer wrote:




I guess the complete DJGPP ecosystem could be moved to
a separate group, it can get really big.


DJGPP is practically an OS unto itself.




I would move RUNTIME to some generic tool category. I believe
Regina REXX was not very small, while some others are small?


Regina at least has some justification.  Some later versions of PC DOS 
came with REXX.





While packages are slowly getting outdated, they can
be fun to use at times. Does VNC viewer still work?
Links, Lynx, Dillo and Arachne are the four larger,
more powerful browsers in this category. It would be
good to hear how people like their size power balance?


Links is pretty useful to me (and for one, the version I use on my Pentium 
DOS machine has graphical support with a couple switches, making it even 
more useful).


Is there even a decent VNC viewer? o.o I have two DOS boxen and could 
easily spin up VNC sessions on my Linux boxen.




-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Simplifying FreeDOS

[Eric Auer]

Hi Jim, good to think about the package list :-)

If you ask me, the distro has grown large because a SMALL
number of packages are rather LARGE. Even then, when you
do not install all sources, it uses a lot less space: It
would be fine to keep the sources zipped until one wants
to work on a specific package.

> 1. Move bz2, gzip, and tar to the "Unix" group

Nice idea to collect Unix like tools in a group, yes.

> 3. Remove ... 7zdec, arj, cabext, lpq1, lzip, lzma, lzop, zoo

I guess it would be okay to have those somehow separate,
although I wonder how large they are anyway. People might
enjoy ARJ and CAB support out of the box.

> *Boot Tools*
> *I don't have any strong feelings here. What are your thoughts?

I expect them to be small and would keep them.

> *Development*
> Can we pare down the list a bit?

I guess the complete DJGPP ecosystem could be moved to
a separate group, it can get really big.

> 1. Move perl to the "Unix" group

That would confuse me. Perl is multi-platform and it
clearly is a programming language.

> 2. Keep BWBasic, the DJGPP packages, FASM, the FBC packages
> (FreeBASIC Compiler) fpc (FreePascal compiler), the GCC-IA16
> packages, JWASM, NASM, OW (OpenWatcom C Compiler), and UPX

I would move UPX to archivers, although it is not multi-file.
People will have to be aware that FBC, FPC, OW, DJGPP are big.

> 3. Remove bcc (Bruce's C Compiler), euphoria, insight, lua, regina, runtime

I would move RUNTIME to some generic tool category. I believe
Regina REXX was not very small, while some others are small?

> *Editors*
> Not sure about these. I know there are a few here I'd like to keep:
> Blocek, Elvis, FED, Freemacs, MSEDIT, pico, Vim

I would add SETEDIT because it can edit large files, maybe TDE?

> *Emulators*
> I don't think that these are useful to include...

Most of them will need rather specific files to use, yes.

> These all fall in the general category of "games," anyway.

They should be kept separate if you ask me, but I agree
to not have them in the ISO. Rather offer them online.

> *Games*
> I generally feel that we can add and remove games in the FreeDOS
> distribution on a whim. If a game is interesting and open source

Having a few dozen small games can certainly be fun, but
I guess BOOM (Doom) or KRAPTOR might be quite large? Would
be great to have a game screenshot gallery online :-)

Frotz should probably be moved to emulators.

> *Graphical Desktop*
> We added GUIs a long time ago...

Of course most GUI do not have lots of apps, so it
might be good to treat them similar to emulators by
offering them separately, outside the ISO. How about
the set of productivity apps ported by Georg Potthast?
I agree that OpenGEM is a good choice as general GUI.

> *Networking*
> I don't run FreeDOS with a network...

While packages are slowly getting outdated, they can
be fun to use at times. Does VNC viewer still work?
Links, Lynx, Dillo and Arachne are the four larger,
more powerful browsers in this category. It would be
good to hear how people like their size power balance?

> *Sound*
> I know OpenCP and MPlayer both work fine, because I demo'd them
> in a YouTube video. I don't have any opinions otherwise.

The others are: BladeEnc (MP3), AdPlay (OPL), cdp (CDDA),
DOSMid (MIDI) and LAME (MP3). I think they are all useful
OPL FM song files are probably rare, but the player small.

> *Unix*
> The wiki page lists a few packages to remove based on
> duplicates or license concerns.

Which ones would you remove?

> 1. Move bz2, gzip, and tar from "Archivers" to "Unix"

One could argue either way about those three.

> 2. Move perl from "Devel" to "Unix"

As said, Perl should count as programming language, not Unix.

> *Utilities*
> We have a mix of things in this package group...

> 2. Remove b64, blwcbc, bmp2png, bsum, daa2iso, edict, fdshell,

It is good to have Base64 support and PNG support.
Blowfish, BSD sum and DAA/GBI are indeed exotic.
FDSHELL and EDICT (disk imaging) sound useful.

> finddisk, flashrom, gifsicle, hip, hiram, pgme,
> pngcrush, sqlite, terminal, topspin, wptail, zdir,> zerofill

Of course I suggest to keep FINDDISK and TERMINAL :-)

FLASHROM sounds useful, depending on how many mainboard
chipsets it is able to BIOS update?

HIP and GIFsicle sound a bit exotic. I do not see PGME
on the list, so no opinion about that.

How does HIRAM compare to UMBPCI?

PNGCRUSH is a bit exotic, as is SQLITE. If anything,
the latter could be kept as a programming language?

TOPSPIN, WHIPTAIL and similar might be too special.
I have no opinion about ZDIR.

ZEROFILL can be really useful before diskimage creation.

> *We have both doslfn and lfndos, but do we need both?
> Is one better (more complete) than the other?

Probably yes, but I do not remember.

I agree that all utilities by Jack are useful :-)

> I skipped some packages in that list. I don't have a
> good opinion on those. What do you think?

If you could make a list of those?

Regards, Eric

[Freedos-devel] Simplifying FreeDOS

[Jim Hall]

Some of us had this conversation a while back and I wanted to bring it up
again on the list.

MS-DOS was a small operating system. MS_DOS 5 and 6 fit on a few 1.44MB
floppy disks.

We always intended FreeDOS to not just *replace* but *enhance* DOS. FreeDOS
is "MS-DOS plus more." To make clear what's part of the "core" of FreeDOS,
we have the "Base" package group. These packages replicate the behavior and
functionality of MS-DOS. But we also have a lot of other packages that add
new functionality to FreeDOS, and we put these programs in other package
groups like "Editors" (additional editors) and "Devel" (compilers,
assemblers, and other development tools).

Over time, FreeDOS has grown to include lots of interesting programs. The
FreeDOS 1.2 and 1.3RCx distributions are very big.

As we look to the next FreeDOS 1.3 Release Candidate, I think we should
consider removing some packages from the FreeDOS distribution.

To be clear: I am not suggesting deleting packages or programs from the
FreeDOS archive at ibiblio. There's lots of useful and interesting programs
there. But I don't think we need to include everything in the FreeDOS
*distribution*.

Here are my thoughts from the FreeDOS 1.3 package list (wiki)


*Base*
Keep everything

*Archivers*
Do we really need all of those archivers? For example, who needs Zoo these
days? My suggestions:
1. Move bz2, gzip, and tar to the "Unix" group - these are replicas of Unix
tools
2. Keep zip, unzip, p7zip
3. Remove the other packages: 7zdec, arj, cabext, lpq1, lzip, lzma, lzop,
zoo

*Note that p7zip can unpack a ton of other file formats, so we don't need
these other archivers anyway.

*Boot Tools*
*I don't have any strong feelings here. What are your thoughts?

*Development*
Can we pare down the list a bit? We have a lot of packages here, but I
don't think we need them all. For example, we should include the tools we
know we'll need to compile the different FreeDOS utilities. I'd also like
to keep the GCC related packages, and other packages that remain popular.
My suggestions:
1. Move perl to the "Unix" group
2. Keep BWBasic, the DJGPP packages, FASM, the FBC packages (FreeBASIC
Compiler) fpc (FreePascal compiler), the GCC-IA16 packages, JWASM, NASM, OW
(OpenWatcom C Compiler), and UPX
3. Remove bcc (Bruce's C Compiler), euphoria, insight, lua, regina, runtime

*I think I missed some packages in that list. I don't have a good opinion
on those. What do you think?

*Editors*
Not sure about these. I know there are a few here I'd like to keep:
Blocek, Elvis, FED, Freemacs, MSEDIT, pico, Vim

*I don't have a good opinion on the other editors in the list. Which ones
do you think need to stay?

*Emulators*
I don't think that these are useful to include in the full
distribution. These all fall in the general category of "games," anyway. I'd
recommend we eliminate the entire "Emulators" package group.

*Games*
I generally feel that we can add and remove games in the FreeDOS
distribution on a whim. If a game is interesting and open source, we can
include it. When a game stops being interesting, or doesn't interest a lot
of people, we can remove it.

*I really enjoy Wing and a few others. I don't have strong opinions on the
other games. What are your thoughts?

*Graphical Desktop*
We added GUIs a long time ago when people were still doing active
development on OpenGEM, oZone, and Seal. If you've been part of the
discussion for a long time, you also remember we included a few other
graphical menus and things that have since fallen out of the distribution.
I think it's time to look at these GUIs too. My recommendations:
1. PC-GEOS was released as open source software. I haven't followed it, but
last I checked, they weren't able to compile it (missing libraries, I think
- requires some rewrites?) *If they can get this to compile*, I think we
can include it. *If they still can't compile it*, then do not include it.
2. Remove SEAL and oZone. These haven't been worked on for a long time, and
they are still incomplete
3. Keep OpenGEM. It's not under active development, but it's currently
pretty solid, if plain looking

*Networking*
I don't run FreeDOS with a network, so I don't have any opinions on these
packages. What do you think?

*Sound*
I know OpenCP and MPlayer both work fine, because I demo'd them in a
YouTube video. I don't have any opinions otherwise.

*Unix*
The wiki page lists a few packages to remove based on duplicates or license
concerns.
1. Move bz2, gzip, and tar from "Archivers" to "Unix"
2. Move perl from "Devel" to "Unix"

*Utilities*
We have a mix of things in this package group. I think some of these were
interesting long ago, but probably aren't used anymore and can be deleted.
My recommendations:
1. Keep aefdisk, ansimat, bootfix, callver, cdrcache, cdrom2ui clamav +
clamdb, cpied, cwsdpmi, dialog, dn2, dog, dos32a, dosutil, doszip + dzemm,
fdimples + fdisrc, fdnpkg, fdshield, fdtui, foxcalc,