[Freedos-user] What it was all about for some of us

2021-04-30 Thread Alvah Whealton
Wherever I have DOS (generically speaking) installed, I always include a
copy  of  "bywater basic."  It's a tribute to what home computing was, once
upon a time. I suspect there are many here who remember first coming upon
Ted Campbell's note at the end of his documentation for the interpreter.
For anyone who doesn't remember, please allow me to offer the story that
stopped some of us in our tracks, back in the day . . . .


* THE STORY OF BYWATER BASIC

   This program was originally begun in 1982 by my grandmother, Mrs.
   Verda Spell of Beaumont, TX.  She was writing the program using
   an ANSI C compiler on an Osborne I CP/M computer and although my
   grandfather (Lockwood Spell) had bought an IBM PC with 256k of
   RAM my grandmother would not use it, paraphrasing George Herbert
   to the effect that "He who cannot in 64k program, cannot in 512k."
   She had used Microsoft BASIC and although she had nothing against
   it she said repeatedly that she didn't understand why Digital
   Research didn't "sue the socks off of Microsoft" for version 1.0
   of MSDOS and so I reckon that she hoped to undercut Microsoft's
   entire market and eventually build a new software empire on
   the North End of Beaumont. Her programming efforts were cut
   tragically short when she was thrown from a Beaumont to Port
   Arthur commuter train in the summer of 1986. I found the source
   code to bwBASIC on a single-density Osborne diskette in her knitting
   bag and eventually managed to have it all copied over to a PC
   diskette. I have revised it slightly prior to this release. You
   should know, though, that I myself am an historian, not a programmer.
*


I used DOS and BASIC  to write a gradebook program for  my  wife,  a
7th grade science teacher. As computer programs go, mine  sucked big
time.  It did not have any graphic interface, just  the code and a
place to key in the grades. But because  it worked and was  such  a
big  help to my wife, she wanted  to show  it to everybody that came
to the house.  I could only cringe in embarrassment and beg her not to
do so.

Nevertheless, after programming in COBOL on a mainframe for fifteen
years, a home computer and DOS offered an incredible level of
excitement. I was living where history was taking place.   But there
is more than just nostalgia involved here. I wish I could articulate
the valid things that are surrendered with the demise of computing at
that level. Fortunately, people who invest time and energy into the
use of FREEDOS understand what  it is that I am unable to convey.

Al Whealton
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

2021-04-30 Thread Carsten Strotmann

Hi,

On 30 Apr 2021, at 18:36, Eric Auer wrote:


I would like to hear opinions about FDISK, XFDISK, SPFDISK,
AEFDISK and RANISH partition managers from *everybody* :-)
They were all part of the 1.2 distro after all.


I'm a long time user of XFdisk and I prefer it over the plain FDISK. For 
the install process, providing XFDisk over FDISK would be a plus.


The FDISK should still be part of the base installation.

I have not used SPFDISK, AEFDISK and RANISH, so I cannot say anything 
about them.


Greetings

Carsten


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


Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

2021-04-30 Thread ZB
On Thu, Apr 29, 2021 at 05:18:11PM +0200, Eric Auer wrote:

> Which better SYSINFO utilities could we bundle? HWINFO, NSSI
> and VC probably are all closed source, what else is out there?

Disk Navigator?

But, actually, why are you so upset about this review? You won't please
the Windows' user; he expects "user-friendly OS" -- and "user friendliness"
he sees as the way Windows offer. So to sum up that review one can answer:
"...and what did you expect? It's DOS -- you have to learn at least some
basic skills to make any use out of it"
-- 
regards,
Zbigniew


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


Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

2021-04-30 Thread TK Chia

Hello Eric,


For comparison, at the moment, DOG (shell, 1 file per command),
Arachne (browser), Emacs, FreeBASIC, GhostScript, OpenXP, Lynx
browser, Pacific C, Pegasus Mail, SETEDIT and various games are
better off in their own directories, while several 100 single
executable files can nicely stay together in the BIN directory
because you would not want PATH to become too long in DOS.


The (newer) FreeDOS package format already has a links/ mechanism
(http://wiki.freedos.org/wiki/index.php/Package), which allows one to
create executable "shortcuts" in a links/ directory to programs elsewhere.

I am already using this mechanism in my gcc-ia16 packages.  E.g.
i16gcc.zip has a file links/i16gcc.bat, which (newer versions of) the
fdnpkg installer will transform into a small .com file that hands over
to devel/i16gnu/bin/i16gcc.exe.

I think this is a simple and straightforward way to keep %PATH% short,
and still allow each package's files to (largely) go into its own
directory.  Perhaps we just need to get more packages and package
maintainers to use it. :-)

Thank you!

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


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


Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

2021-04-30 Thread Eric Auer

Hi Jerome, Laaca, others,

Given that I have verbose thoughts about Laaca's review and your
replies to it, I hope you have some time. Thank you for reading.

> Many people run FreeDOS on bare metal...
> 
> However, the overwhelming vast majority of users do not do that.

I guess "many" are still many enough to add a nice UHDD cache to
make the install significantly faster. Also, try something like
DIR /S > NUL to pre-cache directory data at some early moment.

As I never use DOSLFN or LFNDOS, I do not know whether they have
the need to become "better"? I think UDVD2 already is quite nice,
not sure what "ASPI driver" is about, maybe USB storage drivers?

A task switcher does not sound like a core feature given that the
"overwhelming vast majority" rund DOS inside one or more windows
inside some other operating systems anyway. We have TriDOS. Hmm.

It is good that the CD contains separate app package zips, but it
is still a good suggestion to pre-install MORE in the Live CD area,
so FEWER of them have to be unzipped while entering Live CD mode.

All packages which are pre-installed to a directory on the CD
1. make the CD larger but 2. do not have to be unzipped (slow)
into a ramdisk (where space is limited) :-)

Please DISABLE swapfiles in your installer cwsdpmi configuration!

You could only swap to ramdisk until the target drive is formatted
and ramdisk is too valuable to be used for swap if you ask me.

As far as I remember, we have package managers with built-in
unzip library. Not sure whether they show progress bars BUT
I think a progress info like "N out of N APPS unpacked" will
be sufficient to at least get an idea of the unpack progress.

Note that 7zip WILL give a progress indication and is part of
the distro anyway :-) Have not compared RAM use to unzip though.

As you explicitly want to support people with low (HOW low? Do
not overdo it!) amounts of RAM, I think it is again better to
have more pre-installed and fewer live-ramdisk-unzipped packages
for the Live CD. Even when this means you can squeeze fewer app
packages into 700 MB. You now only have 20 MB and 600 MB zip
download categories and separate Lite, Live, Legacy and Full
versions. Lite ONLY exists for USB and I think it is TOO small.

Basically nobody will be limited to a 32 MB USB stick. Better
make the "lite" version a BIT larger with more non-BASE apps.
Like 55 MB or 110 MB or something like that :-)

The Live version only exists for CD, why not for USB? And why
do Live and Full (USB) or Legacy (CD) have to be separate
downloads? Also, why not call it "Full CD", like "Full USB"?

The purpose of a Live CD is that you can ENJOY APPS without
having to install the operating system in question. If you
only include BASE apps, you should call it "boot disk" ;-)

> Perhaps more software will be pre-extracted on the CD and
> not made “active” on a RAM disk in 1.3-FINAL. However, this
> has some trade-offs. You really can’t remove the CD...

It is still better to have (more) pre-extracted apps :-)

> Some programs cannot be run on a read-only filesystem.

Which? Probably only a few apps would complain about that.

You could provide a SIMPLE batch script which, when there is
enough RAM, can be run by the user to copy all pre-extracted
apps into the ramdisk and update PATH. Then they can remove
the CD and still use all apps. But I think it is quite okay
that a Live CD wants to remain inserted into the CD drive.

I would like to hear opinions about FDISK, XFDISK, SPFDISK,
AEFDISK and RANISH partition managers from *everybody* :-)
They were all part of the 1.2 distro after all.

> Regardless, RC4 does a much better job than RC3 to auto partition
> blank hard disks. On a clean system or VM, most users will no
> longer even see FDISK.

To ME that sounds like "it will auto destroy ALL your data
when it accidentally mis-detects the disk as being empty,
without even asking you first!" :-o Please clarify.

> The easiest way to run in advanced mode is to exit the
> installer and run “setup adv”. But, ... CTRL+C ...

Are tricks like those announced and well-visible during install?
Also the thing that CTRL+C can either open menu or kick you out?

>> FDCONFIG.SYS. It is important because on the tested notebook (Dell
>> Latitude 610) the first two options did not work for me...

Which options are the first two? Probably those with EMM386? Is
it possible to use more "humble" default options to fix them?

> There really is no way to store a log of “the whole process”. 
> Anything prior to having a formatted hard disk will be lost.

Unless you make a temp file in a small RAMDISK which you should
have anyway because pipelines in DOS actually are temp files ;-)

I support the request that HELP offers a README or INSTALL file,
for example outlining the step by step phases of install, with
info which are optional, which are required and at which moments
the user can make which rough type of choices, so people know
what expects them and get an idea where they got 

Re: [Freedos-user] hardware recommendations

2021-04-30 Thread Bryan Kilgallin

Dear Christoph:


which hardware would you recommend for running FreeDOS?


I had an absolute requirement of a serial port. That was for 
communicating with a heart-rate monitor's interface-box. So I used an 
old 32 bit tower-PC that had a serial port.

--
members.iinet.net.au/~kilgallin/


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


Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

2021-04-30 Thread tom ehlert
> First, the amount of RAM available varies greatly making it an all or nothing 
> prospect.

> Second, unzip requires DMPI and wants HD swap. Unless the binary is
> somehow modified at boot, it will complain about no C drive swap.
> Also with no swap and limited RAM constraints, it is potential point of 
> failure.

just unzip base.zip, put the executables into a directory (\FDOS?) on the
CD/DVD, point PATH to it, and call it a day. it's hardly more then a
few MB.

absolutely not necessary to unpack on every boot.

Tom




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


Re: [Freedos-user] Why I use DOS a.k.a. FreeDOS for Dummies?

2021-04-30 Thread Bryan Kilgallin

Yes, Andrew:


The "snapback" I see for example (?) to earlier-era ethos by way of typewriters 
is echoed in the newer generation who realise the delight of using ancient (for example, 
IBM) *mechanical* keyboards over the standard bubblewrap that is marketed with modern, 
built-to-self-destruct consumer-level laptops.


I buy metal garden tools, not cheap-and-break-easily plastic commodities!


In a similar way I guess, the FreeDOS environment offers a window back to that golden age 
of the de-cluttered work ethic where the user actually *produced* things - rather than 
serve primarily as a consumer being continually prescribed "products".


Yes, I have been editing HTML code, noticing aesthetic elegance!


These products - or distractions - could be in the form of ribbon-based 
interfaces, all the data-mining that goes on with social media interfaces - all 
the bells and whistles that come with a modern poker/gaming machine.


That's more trouble than it's worth.
--
members.iinet.net.au/~kilgallin/


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


Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

2021-04-30 Thread Jerome Shidel
Hi Eric,

I don’t know why I’m even responding to this forwarded “review”. But, I’ll 
assume the author will eventually see it. So, I’ll share some of my personal 
thoughts on some of it.

Most of it comes down to user preference. As is always the case, any decision 
will nearly always have some who disagrees and would have preferred another 
choice.  

Many people run FreeDOS on bare metal and their experience of installing the OS 
is extremely important. 

However, the overwhelming vast majority of users do not do that. They install 
into one of the virtual machine platforms. Therefore, their experience should 
be prioritized. 

> On Apr 29, 2021, at 9:15 PM, Eric Auer  wrote:
> 
> 
> Hi, forwarding a verbose update of the review from Laaca on BTTR :-)
> 
> My summary: Better LFN, faster disk I/O, problem of opening many small
> files on CD being slow (how about using more CACHE, Jerome? Maybe even
> with read-ahead or similar speed tricks?), problem of the Live CD not
> having apps pre-installed (it has to unzip them first), problem of the
> Live CD having too few apps available, lack of progress/status info,
> lack of analysis of existing system structure before install, lack
> (?) of ability to select install size (base, full etc.), lack of a
> mechanism to dual-boot on FAT (you know my opinion about that),
> lack of "what has been done where" summary log on the target drive,
> wish that running "help" should initially display an introduction
> or readme about what can be found where on the installed system,
> lack of utilities for manual installs and repairs in the live cd,
> wish for image viewer and mpxplay on live cd and default install,
> wish to add image editors, wish for descript.ion or similar method
> to let people know what zip contains what in the on-CD repository,
> wish to have separate directories for apps which are multiple files?

Do you want a better FreeDOS or a perfect one?

Active development resources dedicated to improving the OS are very limited. 

A better version (RC4) is coming any day now. (possibly even today or tomorrow)

If you want to wait for a perfect one that solves everyones problems, it will 
be a while. Like maybe the in the spring of 2150. In other words, never.


> The original update from Laaca on BTTR is below. Regards, Eric
> Source: https://www.bttr-software.de/forum/forum_entry.php?id=17804
> 
> Well, I wrote quite crititical review about FreeDOS 1.3rc. It was
> reposted into FreeDOS user forum and was few times commented and it is
> of course commented also here.
> Just to be clear - I don't complain about DOS as such but specificaly
> about FreeDOS 1.3rc and mainly about installer.
> I will try to summarize my criticism into several categories:
> 1) Missing DOS/FreeDOS features
> 2) FreeDOS live system from CD
> 3) FreeDOS installation
> 4) Help system
> 5) Packages
> 
> ad 1) Here is not much to say. I miss some feature in modern DOS system
> but it is not fault of the FreeDOS community. I would like to see a
> better LFN driver, better disk read/write/seek performance (much worse
> than f.e. under Win98). We do not have a good ASPI driver we do not have
> a good task switcher and so on and so on. But again, this is not the
> point of my criticism.

That is understandable and I completely agree. There are many such projects 
that the original authors brought to a certain point but for whatever reason 
stopped. Perhaps they lost interest and moved on to other things. Since they 
are open source, it doesn’t really matter. Someone who is interested in 
improving the software could pick up where the original author left off. As a 
developer of DOS related software, even the author of the original “review” 
post can do this. We can always use more help improving things.

> 
> ad 2) Why the booting starts with unzipping of many basic utilities like
> ATTRIB.ZIP, FORMAT.ZIP, COMP.ZIP and so on. Why it just does not unzip
> something like BASE.ZIP which would contain all this basic utilities?
> You forgot how slow is the file seeking on the CD on the real hardware?
> Sure, the contiuous read is fast on most of CD drives but seeking and
> opening the large amount of small files is a pain.

There actually many reasons the LiveCD Environment does things the way it does. 
But, I’ll stick to only some of the key reasons.

I’ve run it several times on real hardware. Yes it is slower. But with the 
current list of packages it makes “active", it isn’t actually that bad. 

The Live Environment actually was designed to do some of that already. If you 
pay close attention to the status of the packages as they are brought online, 
you will see a couple “skipped.” That status is displayed for packages that 
have already been made active by other means.

Earlier versions of the LiveCD had many more “skipped” packages. During the 
startup process, an entire group was done by extracting a single zip. This has 
several issues. 

First, the amount of RAM available varies greatly 

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

2021-04-30 Thread Mateusz Viste

On 30/04/2021 02:19, Jon Brase wrote:
I'm not particularly attached to any particular GUI, or to having a GUI 
in FreeDOS per-se, but I'm a bit concerned, in terms of preserving 
historical software, that the Win16 API is not well served by existing 
options (Wine, NTVDM, MS-DOS/Win3 under virtualization, Win3 under 
DOSBox, etc), compared to the resources that are available for DOS, so 
I'd really like to see something I'll call "Free-point-one", a FOSS 
implementation of Win16 built on FreeDOS.


Isn't this possible already using the HX extender? It focuses mostly on 
running Win32 application from within DOS, but IIRC it also comes with 
some Win16 support.


Mateusz


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


Re: [Freedos-user] Using a USB stick and an optical drive

2021-04-30 Thread Thomas Desi
HI Eric, 
just to let you know (isn’t a question, just an observation for a nice feature)

on my HP Think Client AND on my Mini ITX, both can do (without any tweaking or 
stuff):

1. Plug in 2 USB Sticks (one has  the bootable FreeDOS on it)
both are FAT formated (FAT)

2. boot into FreeDOS from USB-Stick 

3. BOTH USB Sticks are avaible for Read/Write. (as drives C:  and   D:)


Regards, 
Thomas

> On Wed,20210414- week15, at 19:22, Eric Auer  wrote:
> 
> 
> Hi Thomas,
> 
>> I just found a recipe regarding USB-Sticks & MS-DOS.
> 
>> SOURCE: https://slomkowski.eu/retrocomputing/usb-mass-storage-on-ms-dos/
> 
> Well, the old USBASPI drivers might work for you, yes.
> Or those by Bret Johnson. Or those by Georg Potthast:
> 
> http://www.georgpotthast.de/usb/
> 
> The general problem is that each driver only supports
> a limited set of different controller chips, so it will
> depend on your luck on whether one works for you.
> 
> The drivers by Georg are shareware and will only work
> for a limited time after each boot, but that is probably
> enough for what you want to do :-)
> 
> Regards, Eric
> 
> 
> 
> 
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
> 



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


Re: [Freedos-user] Printing over the network

2021-04-30 Thread Frantisek Rysanek
FYI, and apologies for getting off topic on this FreeDOS mailing 
list: about CUPS, I can tell the following:

1) CUPS apparently does some auto-detection of input file type. It 
can auto-detect several bitmap image file types, such as PDF, 
Postscript, HTML, ASCII text... apparently it can detect MS Word DOC 
for christ sake :-)   Detect, not sure if print too.

2) out of the box, it does technically detect HP PCL, but it 
considers it a "raw" format, and passes that through to the printer 
without further conversion.

3) with a bit of custom configuration, this automatic filetype 
detection and auto-conversion (to an internal PostScript format) can 
be bent to use GhostPCL, to actually prefilter the print job at hand 
= convert the job from PCL to internal / intermediate / common 
denominator PostScript. Which then gets rendered onto any back-end 
driver, such as your proprietary GDI.

Someone has documented this back in 2007 (made a mistake at first and 
asked for help, the problem got solved - see the whole thread):
https://lists.cups.org/pipermail/cups/2007-June/041365.html

Current default contents of the upstream CUPS /etc/cups/mime.types:
https://github.com/apple/cups/blob/master/conf/mime.types#L155
(line 155 is key)

Means to me that you still need to get GhostPCL and configure this on 
your own, but it shouldn't be very difficult.

And, this sorcery is not really necessary, if you can do *without* 
PCL when printing from DOS. Such as, you can use direct PostScript 
output, if your DOS apps support that. Or plain ASCII should work 
too.

So after you get your basic TCP/IP connectivity to work in DOS, via 
the MS Network Client, the very next step would be to install and 
configure Samba. Ask me for an example minimal config file if you're 
interested.

Frank

P.S., further reading on CUPS:
https://www.samba.org/samba/docs/old/Samba3-HOWTO/CUPS-printing.html#i
d2635892
Nominally deprecated / no longer maintained, but in fact pretty 
informative. I haven't found a newer version of this overview.

On 29 Apr 2021 at 22:10, Bryan Kilgallin , 
freedos-user@lists.sourcRe: [Freedos-user] Printing over the network 
wrote:

> In your use case Bryan, my "package of canned DOS drivers" is just a
> first half of the needed configuration. Next up, we need to configure
> Samba and CUPS to transport and transform your print jobs :-) 



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