Discussion:
Epson printing problems?
(too old to reply)
Gareth Evans
2020-04-06 11:45:55 UTC
Permalink
Epson WF-2510 printer, driven by WiFi

Asuspro laptop

Windows 10 64 bit

McAfee virus protection

This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.

The ink-level screen does report back OK after a short delay

Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.

Has anyone here any clues, please?
Gareth Evans
2020-04-06 13:54:10 UTC
Permalink
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Furthermore, have got the latest Epson drivers for W10 64 bit.

Strangely, I can scan a document back to the computer so everything else
seems to be in order, but send a document to
print and it just hangs indefinitely.

I might tend to think that a motor driver component has gone
down the pan but the fact that I can do an offline copy which involves
both scanning and printing suggests that the motor drive
from the controlling micro is all in order.

Mystifying.
Dan Espen
2020-04-06 14:12:46 UTC
Permalink
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Well, I don't use printers connected to WIFI, and I don't use Windows
but I have a little experience with it, so:

1. Reboot (printer, PC, WIFI).
2. On PC re-install drivers

There is an online video of someone with a similar problem to yours,
the PC was using a printer driver for a different model.
--
Dan Espen
Gareth Evans
2020-04-06 15:57:07 UTC
Permalink
Post by Dan Espen
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Well, I don't use printers connected to WIFI, and I don't use Windows
1. Reboot (printer, PC, WIFI).
2. On PC re-install drivers
There is an online video of someone with a similar problem to yours,
the PC was using a printer driver for a different model.
Thanks, Dan, done all that, now need to find space on the
workbench to look for dead spiders that might have crawled in.
Dan Espen
2020-04-06 22:26:44 UTC
Permalink
Post by Gareth Evans
Post by Dan Espen
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Well, I don't use printers connected to WIFI, and I don't use Windows
1. Reboot (printer, PC, WIFI).
2. On PC re-install drivers
There is an online video of someone with a similar problem to yours,
the PC was using a printer driver for a different model.
Thanks, Dan, done all that, now need to find space on the
workbench to look for dead spiders that might have crawled in.
I see you're getting the "use Linux" treatment.
It warms my heart.

:)

Let's see, on my Linux system I'd look to see if the document was making
it to the printer. Does the PC side see the printer go from "Printing"
to "Idle"? Are your PC drivers reporting any error message in the logs?

Does the printer let you look at it's queue?

Has anything changed? Like your router?

Did you reinstall the drivers and try a test page?

Why does my spell checker think reinstall is not a word?
--
Dan Espen
Scott Lurndal
2020-04-06 22:41:23 UTC
Permalink
Post by Dan Espen
Why does my spell checker think reinstall is not a word?
Should it not be hyphenated?
Dan Espen
2020-04-06 23:26:07 UTC
Permalink
Post by Scott Lurndal
Post by Dan Espen
Why does my spell checker think reinstall is not a word?
Should it not be hyphenated?
I guess that makes the spell checker happy...re-install.
Now Google says:

Did you mean: reinstall


Then the dictionary goes off the deep end:

Dictionary
re·in·stall
/ˌrēinˈstôl/
Learn to pronounce
verb
verb: re-install

place or fix (equipment or machinery) in position again.
install (computer software) again.
"I reinstalled the program"

noun
noun: re-install

an act of reinstalling something, especially software.
"try performing a “clean” reinstall of your system software"
--
Dan Espen
Peter Flass
2020-04-07 01:13:19 UTC
Permalink
Post by Dan Espen
Post by Scott Lurndal
Post by Dan Espen
Why does my spell checker think reinstall is not a word?
Should it not be hyphenated?
I guess that makes the spell checker happy...re-install.
Did you mean: reinstall
Dictionary
re·in·stall
/ˌrēinˈstôl/
Learn to pronounce
verb
verb: re-install
place or fix (equipment or machinery) in position again.
install (computer software) again.
"I reinstalled the program"
noun
noun: re-install
an act of reinstalling something, especially software.
"try performing a “clean” reinstall of your system software"
I’m constantly adding words to my dictionary.
--
Pete
Gareth Evans
2020-04-07 13:26:22 UTC
Permalink
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Well, I don't use printers connected to WIFI, and I don't use Windows
1. Reboot (printer, PC, WIFI).
2. On PC re-install drivers
There is an online video of someone with a similar problem to yours,
the PC was using a printer driver for a different model.
Thanks, Dan, done all that, now need to find space on the
workbench to look for dead spiders that might have crawled in.
I see you're getting the "use Linux" treatment.
It warms my heart.
:)
Let's see, on my Linux system I'd look to see if the document was making
it to the printer. Does the PC side see the printer go from "Printing"
to "Idle"? Are your PC drivers reporting any error message in the logs?
Does the printer let you look at it's queue?
Has anything changed? Like your router?
Did you reinstall the drivers and try a test page?
Why does my spell checker think reinstall is not a word?
The behaviour of the printer is the same, both from a W10 laptop and
also from a W7 laptop. In both cases it has been
printing OK for over a year but now when a file is sent to it,
the LCD screen on the printer shows, "printing ..." but apart
from a couple of clunks and whizzes nothing further happens.

I've had the printer on the workbench with a supply of air to
give it a good blow through and can see nothing lodged inside
although very little is visible of the innards.

Again, if I use the printer in local mode to do a photocopy,
it works fine, suggesting that control from the microprocessor
is all in order.

Via the network, both on W10 and W7 machines I can interrogate
the ink levels and scan documents to load into the laptops.

I've ensured that there is a sufficiently large tranche of paper in the to.

I've done an extensive google search for faults on this model but have
found nothing of use.

This makes me hark back to the days of 50 years ago when
blinkenlights were all the rage. Back then, if something were
amiss you could drill down to ever-decreasing lower levels
until you found the fault but nowadays? You're faced with
layer upon layer of others' inscrutable software with no
help at all apart from an error message saying that the
printer could not print the page. GRRRR!!!!!!

Come back the PDP8e and PDP11/20, all is forgiven!
r***@gmail.com
2020-04-08 02:51:02 UTC
Permalink
Post by Gareth Evans
The behaviour of the printer is the same, both from a W10 laptop and
also from a W7 laptop. In both cases it has been
printing OK for over a year but now when a file is sent to it,
the LCD screen on the printer shows, "printing ..." but apart
from a couple of clunks and whizzes nothing further happens.
I've had the printer on the workbench with a supply of air to
give it a good blow through and can see nothing lodged inside
although very little is visible of the innards.
Again, if I use the printer in local mode to do a photocopy,
it works fine, suggesting that control from the microprocessor
is all in order.
Via the network, both on W10 and W7 machines I can interrogate
the ink levels and scan documents to load into the laptops.
I've ensured that there is a sufficiently large tranche of paper in the to.
I've done an extensive google search for faults on this model but have
found nothing of use.
Have you substituted a USB cable for the WiFi ?
Gareth Evans
2020-04-08 08:56:16 UTC
Permalink
Post by r***@gmail.com
Post by Gareth Evans
The behaviour of the printer is the same, both from a W10 laptop and
also from a W7 laptop. In both cases it has been
printing OK for over a year but now when a file is sent to it,
the LCD screen on the printer shows, "printing ..." but apart
from a couple of clunks and whizzes nothing further happens.
I've had the printer on the workbench with a supply of air to
give it a good blow through and can see nothing lodged inside
although very little is visible of the innards.
Again, if I use the printer in local mode to do a photocopy,
it works fine, suggesting that control from the microprocessor
is all in order.
Via the network, both on W10 and W7 machines I can interrogate
the ink levels and scan documents to load into the laptops.
I've ensured that there is a sufficiently large tranche of paper in the to.
I've done an extensive google search for faults on this model but have
found nothing of use.
Have you substituted a USB cable for the WiFi ?
No, I am not set up to do that.
r***@gmail.com
2020-04-09 00:45:26 UTC
Permalink
Post by Gareth Evans
Post by r***@gmail.com
Post by Gareth Evans
The behaviour of the printer is the same, both from a W10 laptop and
also from a W7 laptop. In both cases it has been
printing OK for over a year but now when a file is sent to it,
the LCD screen on the printer shows, "printing ..." but apart
from a couple of clunks and whizzes nothing further happens.
I've had the printer on the workbench with a supply of air to
give it a good blow through and can see nothing lodged inside
although very little is visible of the innards.
Again, if I use the printer in local mode to do a photocopy,
it works fine, suggesting that control from the microprocessor
is all in order.
Via the network, both on W10 and W7 machines I can interrogate
the ink levels and scan documents to load into the laptops.
I've ensured that there is a sufficiently large tranche of paper in the to.
I've done an extensive google search for faults on this model but have
found nothing of use.
Have you substituted a USB cable for the WiFi ?
No, I am not set up to do that.
Buy a cable.
Melzzzzz
2020-04-06 17:22:52 UTC
Permalink
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Install Linux?
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Charlie Gibbs
2020-04-06 17:54:31 UTC
Permalink
Post by Melzzzzz
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Install Linux?
If that solution works for you, please let me know what you did
to make it work. Printer access from my Linux box ranges from
flaky to nonexistent, so I usually just rsync the file in question
over to my wife's Mac and let her print it from there. I suspect
an addressing problem - CUPS and DHCP don't seem to be talking to
each other.

I don't do that much printing myself, so I've never cared enough
to go to the effort required to sort it out.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <***@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Peter Flass
2020-04-06 18:09:08 UTC
Permalink
Post by Charlie Gibbs
Post by Melzzzzz
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Install Linux?
If that solution works for you, please let me know what you did
to make it work. Printer access from my Linux box ranges from
flaky to nonexistent, so I usually just rsync the file in question
over to my wife's Mac and let her print it from there. I suspect
an addressing problem - CUPS and DHCP don't seem to be talking to
each other.
I don't do that much printing myself, so I've never cared enough
to go to the effort required to sort it out.
Never had a problem myself, I’ve got an HP hard-wired and a Brother laser
connected with wifi, and they both work mostly flawlessly. Occasionally I
have to reset the wifi adapter on the Brother.
--
Pete
Peter Flass
2020-04-06 18:09:06 UTC
Permalink
Post by Melzzzzz
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Install Linux?
I’d agree, but I’ve just been fighting my own problems with deja-dup, so I
can’t.
--
Pete
Andreas Kohlbach
2020-04-06 20:28:08 UTC
Permalink
Post by Melzzzzz
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Install Linux?
Get a USB-stick Linux, like Ubuntu. Install it on the USB-stick, boot
from it and see,of the problem persist. If not, install Linux.
--
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0
Dave Garland
2020-04-07 02:54:39 UTC
Permalink
Post by Andreas Kohlbach
Post by Melzzzzz
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Install Linux?
Get a USB-stick Linux, like Ubuntu. Install it on the USB-stick, boot
from it and see,of the problem persist. If not, install Linux.
My experience with all-in-one printers under Linux suggests that
getting them working can be challenging (and the printer mfgr will say
"we don't support that"). But it was working for him before.

Sometimes a problem wedges the print queue in Win, and you have to
clear it manually (because it may survive a reboot) and start again.
Also, make sure the printer is selected as the default in Win and the
printing isn't going to one of those Win pseudo-devices. Try the
routine for "print a test page". DL fresh drivers from Epson website.
Try printing via USB instead of WiFi.

I hate all-in-ones.
Scott Lurndal
2020-04-07 15:05:27 UTC
Permalink
Post by Dave Garland
Post by Andreas Kohlbach
Post by Melzzzzz
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Install Linux?
Get a USB-stick Linux, like Ubuntu. Install it on the USB-stick, boot
from it and see,of the problem persist. If not, install Linux.
My experience with all-in-one printers under Linux suggests that
getting them working can be challenging (and the printer mfgr will say
"we don't support that"). But it was working for him before.
HP Printers work well with linux, even the all-in-ones.
Dave Garland
2020-04-07 23:28:47 UTC
Permalink
Post by Scott Lurndal
Post by Dave Garland
My experience with all-in-one printers under Linux suggests that
getting them working can be challenging (and the printer mfgr will say
"we don't support that"). But it was working for him before.
HP Printers work well with linux, even the all-in-ones.
They work better. Though I had to hunt online to find an unofficial
driver for my 2605dn and 4000 printers over the LAN. But those are
serious (if elderly) printers. Gareth has a consumer-grade Epson
connected with Wifi, and I'm not gonna tell him he needs to buy a new
printer. It was working before, and the "copy" function works ok so
the paper handling and printing mechanics must not be borked.
Gareth Evans
2020-04-08 08:55:08 UTC
Permalink
Post by Dave Garland
Post by Scott Lurndal
Post by Dave Garland
My experience with all-in-one printers under Linux suggests that
getting them working can be challenging (and the printer mfgr will say
"we don't support that"). But it was working for him before.
HP Printers work well with linux, even the all-in-ones.
They work better. Though I had to hunt online to find an unofficial
driver for my 2605dn and 4000 printers over the LAN. But those are
serious (if elderly) printers. Gareth has a consumer-grade Epson
connected with Wifi, and I'm not gonna tell him he needs to buy a new
printer. It was working before, and the "copy" function works ok so the
paper handling and printing mechanics must not be borked.
As it happens, I have ordered a newer printer as the WF2510 is
no longer listed, and when my several work benches have been
cleared to make enough room, then I'll attempt disassembly to
look for dry joints, dead spiders, etc, purely out of
interest as its purpose in life will have been surpassed
by the newer printer.

But thankyou to all who have responded

I have used Linux in a number of contract software jobs but having cut
my teeth on naked blinkenlights machines where you had to write your own
OS, and subsequently been exposed to
loads of other OSs, ISIS on Intel gear, OS/32 on Perkin Elmer,
MSDOS on PCs, CP/M on 8 bit machines,
RSX11-M and RSX11-S on PDP11s, to me Linux is just another OS
with nothing in particular to recommend it; it is just so
much of a muchness.
Peter Flass
2020-04-08 19:07:18 UTC
Permalink
Post by Gareth Evans
Post by Dave Garland
Post by Scott Lurndal
Post by Dave Garland
My experience with all-in-one printers under Linux suggests that
getting them working can be challenging (and the printer mfgr will say
"we don't support that"). But it was working for him before.
HP Printers work well with linux, even the all-in-ones.
They work better. Though I had to hunt online to find an unofficial
driver for my 2605dn and 4000 printers over the LAN. But those are
serious (if elderly) printers. Gareth has a consumer-grade Epson
connected with Wifi, and I'm not gonna tell him he needs to buy a new
printer. It was working before, and the "copy" function works ok so the
paper handling and printing mechanics must not be borked.
As it happens, I have ordered a newer printer as the WF2510 is
no longer listed, and when my several work benches have been
cleared to make enough room, then I'll attempt disassembly to
look for dry joints, dead spiders, etc, purely out of
interest as its purpose in life will have been surpassed
by the newer printer.
But thankyou to all who have responded
I have used Linux in a number of contract software jobs but having cut
my teeth on naked blinkenlights machines where you had to write your own
OS, and subsequently been exposed to
loads of other OSs, ISIS on Intel gear, OS/32 on Perkin Elmer,
MSDOS on PCs, CP/M on 8 bit machines,
RSX11-M and RSX11-S on PDP11s, to me Linux is just another OS
with nothing in particular to recommend it; it is just so
much of a muchness.
I suppose windows is the next-best thing to no OS at all ;-)
--
Pete
r***@gmail.com
2020-04-09 00:46:39 UTC
Permalink
Post by Peter Flass
Post by Gareth Evans
Post by Dave Garland
Post by Scott Lurndal
Post by Dave Garland
My experience with all-in-one printers under Linux suggests that
getting them working can be challenging (and the printer mfgr will say
"we don't support that"). But it was working for him before.
HP Printers work well with linux, even the all-in-ones.
They work better. Though I had to hunt online to find an unofficial
driver for my 2605dn and 4000 printers over the LAN. But those are
serious (if elderly) printers. Gareth has a consumer-grade Epson
connected with Wifi, and I'm not gonna tell him he needs to buy a new
printer. It was working before, and the "copy" function works ok so the
paper handling and printing mechanics must not be borked.
As it happens, I have ordered a newer printer as the WF2510 is
no longer listed, and when my several work benches have been
cleared to make enough room, then I'll attempt disassembly to
look for dry joints, dead spiders, etc, purely out of
interest as its purpose in life will have been surpassed
by the newer printer.
But thankyou to all who have responded
I have used Linux in a number of contract software jobs but having cut
my teeth on naked blinkenlights machines where you had to write your own
OS, and subsequently been exposed to
loads of other OSs, ISIS on Intel gear, OS/32 on Perkin Elmer,
MSDOS on PCs, CP/M on 8 bit machines,
RSX11-M and RSX11-S on PDP11s, to me Linux is just another OS
with nothing in particular to recommend it; it is just so
much of a muchness.
I suppose windows is the next-best thing to no OS at all ;-)
DOS is even better.
Dan Espen
2020-04-08 22:21:41 UTC
Permalink
Post by Gareth Evans
Post by Dave Garland
Post by Scott Lurndal
Post by Dave Garland
My experience with all-in-one printers under Linux suggests that
getting them working can be challenging (and the printer mfgr will say
"we don't support that"). But it was working for him before.
HP Printers work well with linux, even the all-in-ones.
They work better. Though I had to hunt online to find an unofficial
driver for my 2605dn and 4000 printers over the LAN. But those are
serious (if elderly) printers. Gareth has a consumer-grade Epson
connected with Wifi, and I'm not gonna tell him he needs to buy a
new printer. It was working before, and the "copy" function works ok
so the paper handling and printing mechanics must not be borked.
As it happens, I have ordered a newer printer as the WF2510 is
no longer listed, and when my several work benches have been
cleared to make enough room, then I'll attempt disassembly to
look for dry joints, dead spiders, etc, purely out of
interest as its purpose in life will have been surpassed
by the newer printer.
But thankyou to all who have responded
I have used Linux in a number of contract software jobs but having cut
my teeth on naked blinkenlights machines where you had to write your
own OS, and subsequently been exposed to
loads of other OSs, ISIS on Intel gear, OS/32 on Perkin Elmer,
MSDOS on PCs, CP/M on 8 bit machines,
RSX11-M and RSX11-S on PDP11s, to me Linux is just another OS
with nothing in particular to recommend it; it is just so
much of a muchness.
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.

I was once faced with a Windows Laptop that would boot, and half way
through the boot process, it would just boot again. I had no idea what
the problem was. So, I booted from a Linux CD, Linux then looked at the
hard disk and told me it was bad.

I've got my printer shared by way of Samba.
WIFI devices should be able to print to it.
Not sure how to print to it with my tablet and phone.
--
Dan Espen
Gareth Evans
2020-04-09 10:43:19 UTC
Permalink
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.

How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Dan Espen
2020-04-09 11:02:08 UTC
Permalink
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
--
Dan Espen
Gareth Evans
2020-04-09 12:09:10 UTC
Permalink
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DOS had two different ways of accessing disk files,
both the CP/M way and also the UNIX way.

I have no quasi-religious attitude to any language
or OS. I've used several of each in my time and
when I get around to them, I have my own ideas for
both (QV).
Dan Espen
2020-04-09 14:35:04 UTC
Permalink
Post by Gareth Evans
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DOS had two different ways of accessing disk files,
both the CP/M way and also the UNIX way.
Sure, and .BAT is exactly equivalent to .sh.
Post by Gareth Evans
I have no quasi-religious attitude to any language
or OS. I've used several of each in my time and
when I get around to them, I have my own ideas for
both (QV).
Religious, why are you going there?
I just didn't want to use junk.

So, DOS had 2 characters to end each line.
Completely ridiculous. Then I seem to remember
^Z would sit at the end of your file even though the
system knew the file byte count.

I once decided to become expert at using the display on DOS.
I bought a rather thick book on VGA.
I'd previously decided IBM 3270s were crap due to unwarranted
complexity.

The hundreds of VGA modes showed me exactly how bad a display design
could be.

If I remember DOS and it's TSRs, there was no way to wait for keyboard
input, you just kept polling the keyboard for input.
What a POS.
--
Dan Espen
Gareth Evans
2020-04-09 14:46:02 UTC
Permalink
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
Scott Lurndal
2020-04-09 17:29:59 UTC
Permalink
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
Indeed, but only one of the two characters are necessary
to terminate a line; both just waste space.
Gareth Evans
2020-04-09 17:42:20 UTC
Permalink
Post by Scott Lurndal
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
Indeed, but only one of the two characters are necessary
to terminate a line; both just waste space.
With the Teletypes, ASR / KSR 33/35 CR, carriage return
brought the printing head back to the start, the left hand side
of the line but did not move the paper up to the next line, which was
the function of LF, line feed.

With just CR, you could overtype the line.

There's difference between a text file to be shipped out
to your local Teletype, and the organisation of files
in the OS.
Scott Lurndal
2020-04-09 18:21:27 UTC
Permalink
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
Indeed, but only one of the two characters are necessary
to terminate a line; both just waste space.
With the Teletypes, ASR / KSR 33/35 CR, carriage return
brought the printing head back to the start, the left hand side
of the line but did not move the paper up to the next line, which was
the function of LF, line feed.
I used one. Every day for three years.
Post by Gareth Evans
With just CR, you could overtype the line.
There's difference between a text file to be shipped out
to your local Teletype, and the organisation of files
in the OS.
Dos, of course, had a TYPE command which was designed specifically
to format data for display. It could easily have added the CR
(if LF was the line terminator) or vice versa.

Unix predated DOS, so there was precedent for using LF as a record
terminator.

There is no need to store both characters on every line in a text file.
r***@gmail.com
2020-04-10 02:17:11 UTC
Permalink
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
Indeed, but only one of the two characters are necessary
to terminate a line; both just waste space.
With the Teletypes, ASR / KSR 33/35 CR, carriage return
brought the printing head back to the start, the left hand side
of the line but did not move the paper up to the next line, which was
the function of LF, line feed.
I used one. Every day for three years.
Post by Gareth Evans
With just CR, you could overtype the line.
There's difference between a text file to be shipped out
to your local Teletype, and the organisation of files
in the OS.
Dos, of course, had a TYPE command which was designed specifically
to format data for display. It could easily have added the CR
(if LF was the line terminator) or vice versa.
Unix predated DOS, so there was precedent for using LF as a record
terminator.
And Teleprinters and Teletypes predated Unix by some 50 years
so there was a precedent for using CR LF.
Post by Scott Lurndal
There is no need to store both characters on every line in a text file.
There was, because of the need to copy a file to a teleprinter
or other serial devices.
Scott Lurndal
2020-04-10 16:13:42 UTC
Permalink
Post by r***@gmail.com
And Teleprinters and Teletypes predated Unix by some 50 years
so there was a precedent for using CR LF.
Not in file storage, Rod.

And the machines using those teleprinters and teletypes had
device drivers that handled the device requirements.
Post by r***@gmail.com
Post by Scott Lurndal
There is no need to store both characters on every line in a text file.
There was, because of the need to copy a file to a teleprinter
or other serial devices.
Nonsense, Rod.
r***@gmail.com
2020-04-11 00:54:39 UTC
Permalink
Post by Scott Lurndal
Post by r***@gmail.com
And Teleprinters and Teletypes predated Unix by some 50 years
so there was a precedent for using CR LF.
Not in file storage, Rod.
Rubbish.
Post by Scott Lurndal
And the machines using those teleprinters and teletypes had
device drivers that handled the device requirements.
Again, Rubbish. How is the "device driver" going to know
when to issue a CR and LF? (see also below)
Post by Scott Lurndal
Post by r***@gmail.com
Post by Scott Lurndal
There is no need to store both characters on every line in a text file.
There was, because of the need to copy a file to a teleprinter
or other serial devices.
Nonsense, Rod.
How so? If there's a file on disc that is to be printed to
a serial printer (e.g., a Teletype), how do you suppose that
the relevant CR and LF can be given at the appropriate moment?

For that matter, how do you suppose that a page throw or tab,
or print on same line, or even a BELL can be issued?
r***@gmail.com
2020-04-10 02:12:00 UTC
Permalink
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
Indeed, but only one of the two characters are necessary
to terminate a line; both just waste space.
With the Teletypes, ASR / KSR 33/35 CR,
Don't forget the ARS 38 [upper and lower case]
Post by Gareth Evans
carriage return
brought the printing head back to the start, the left hand side
of the line but did not move the paper up to the next line, which was
the function of LF, line feed.
With just CR, you could overtype the line.
Indeed, for underlining or for double printing a character
for simulated bold face.
Post by Gareth Evans
There's difference between a text file to be shipped out
to your local Teletype, and the organisation of files
in the OS.
r***@gmail.com
2020-04-10 02:09:28 UTC
Permalink
Post by Scott Lurndal
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
Indeed, but only one of the two characters are necessary
to terminate a line;
True, for keyboard input.
Post by Scott Lurndal
both just waste space.
And how do you suppose a file sent to a printer such
as as a Teletype or one of the many different kinds of
serial printers will print unless it has CR and LF in it?
Charlie Gibbs
2020-04-10 19:35:34 UTC
Permalink
Post by r***@gmail.com
Post by Scott Lurndal
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
Indeed, but only one of the two characters are necessary
to terminate a line;
True, for keyboard input.
Post by Scott Lurndal
both just waste space.
And how do you suppose a file sent to a printer such
as as a Teletype or one of the many different kinds of
serial printers will print unless it has CR and LF in it?
A properly-written driver can take care of that, as well as
inserting enough NULs to give the print head time to get back
to the left. (Ever seen a Teletype scatter characters backwards
across a line because it had no NUL padding?)
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <***@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Dan Espen
2020-04-09 20:55:20 UTC
Permalink
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
And as I said, that's a completely ridiculous reason to use
CR/LF as a line ending in files.

Some of those Teletypes you had to send nulls after the CR/LF
to give the printer time to restore the carriage before you could send
more data.
--
Dan Espen
John Floren
2020-04-09 22:55:24 UTC
Permalink
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
And as I said, that's a completely ridiculous reason to use
CR/LF as a line ending in files.
Some of those Teletypes you had to send nulls after the CR/LF
to give the printer time to restore the carriage before you could send
more data.
How many DOS machines were ever connected to Teletypes, anyway? It's
before my time, but I'd assume that graphical terminals were pretty
common by the time they wrote MS-DOS. I can see an argument for
maintaining compatibility with text files from other, earlier
microcomputer operating systems, but given the tiny memories of these
early systems I'd also be pretty eager to claw back one byte per line of
text.

john
J. Clarke
2020-04-09 23:58:45 UTC
Permalink
On Thu, 09 Apr 2020 16:55:24 -0600, John Floren
Post by John Floren
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
And as I said, that's a completely ridiculous reason to use
CR/LF as a line ending in files.
Some of those Teletypes you had to send nulls after the CR/LF
to give the printer time to restore the carriage before you could send
more data.
How many DOS machines were ever connected to Teletypes, anyway? It's
before my time, but I'd assume that graphical terminals were pretty
common by the time they wrote MS-DOS. I can see an argument for
maintaining compatibility with text files from other, earlier
microcomputer operating systems, but given the tiny memories of these
early systems I'd also be pretty eager to claw back one byte per line of
text.
QDOS was originally written to be a stopgap until CPM/86 came out. It
was aimed at S-100 machines, not the IBM PC. And a lot of S-100
machines were connected to teletypes. It wasn't a Microsoft
development--Microsoft bought and renamed it and made minimal
modifications.
Dave Garland
2020-04-10 01:53:14 UTC
Permalink
Post by John Floren
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
And as I said, that's a completely ridiculous reason to use
CR/LF as a line ending in files.
Some of those Teletypes you had to send nulls after the CR/LF
to give the printer time to restore the carriage before you could send
more data.
How many DOS machines were ever connected to Teletypes, anyway? It's
before my time, but I'd assume that graphical terminals were pretty
common by the time they wrote MS-DOS. I can see an argument for
maintaining compatibility with text files from other, earlier
microcomputer operating systems, but given the tiny memories of these
early systems I'd also be pretty eager to claw back one byte per line of
text.
Not teletypes. But MSDOS was kind of a successor to DR's CP/M-80,
which did see teletypes (and used CRLF), especially in the earlier
days. As to graphic terminals, I saw very few of those in the early
days of MSDOS (printers were mostly Epson dot printers). Mostly people
were using text terminals (IBM's color terms were graphic, but the
resolution was poor enough to preclude business use). A lot of
Hercules graphics cards with clones.

IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
was an arbitrary standard. Yes, CRLF used one character per line more.
Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
for CP/M-80 with 64K memory, and it's unlikely it ever unduly
constrained DOS. And today, who cares? A .docx file with a single line
of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
Jorgen Grahn
2020-04-10 05:35:42 UTC
Permalink
On Fri, 2020-04-10, Dave Garland wrote:
...
Post by Dave Garland
IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
was an arbitrary standard. Yes, CRLF used one character per line more.
Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
for CP/M-80 with 64K memory, and it's unlikely it ever unduly
constrained DOS. And today, who cares? A .docx file with a single line
of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
Bogus in terms of file size, yes, but it still, in 2020, steals
time for me and the rest of the team.

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Peter Flass
2020-04-10 21:56:32 UTC
Permalink
Post by Jorgen Grahn
...
Post by Dave Garland
IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
was an arbitrary standard. Yes, CRLF used one character per line more.
Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
for CP/M-80 with 64K memory, and it's unlikely it ever unduly
constrained DOS. And today, who cares? A .docx file with a single line
of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
Bogus in terms of file size, yes, but it still, in 2020, steals
time for me and the rest of the team.
When you’re storing files on 360K floppies, a few hundred bytes per file
adds up quickly.
--
Pete
J. Clarke
2020-04-11 00:24:24 UTC
Permalink
On Fri, 10 Apr 2020 14:56:32 -0700, Peter Flass
Post by Peter Flass
Post by Jorgen Grahn
...
Post by Dave Garland
IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
was an arbitrary standard. Yes, CRLF used one character per line more.
Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
for CP/M-80 with 64K memory, and it's unlikely it ever unduly
constrained DOS. And today, who cares? A .docx file with a single line
of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
Bogus in terms of file size, yes, but it still, in 2020, steals
time for me and the rest of the team.
When you’re storing files on 360K floppies, a few hundred bytes per file
adds up quickly.
A hundred nine year old diskettes go for 85 bucks on Amazon. A 2
terabyte USB hard drive goes for 65 bucks at Best Buy. Why does
anybody today store large amounts of data on 360 floppies?
Peter Flass
2020-04-11 00:36:10 UTC
Permalink
Post by J. Clarke
On Fri, 10 Apr 2020 14:56:32 -0700, Peter Flass
Post by Peter Flass
Post by Jorgen Grahn
...
Post by Dave Garland
IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
was an arbitrary standard. Yes, CRLF used one character per line more.
Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
for CP/M-80 with 64K memory, and it's unlikely it ever unduly
constrained DOS. And today, who cares? A .docx file with a single line
of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
Bogus in terms of file size, yes, but it still, in 2020, steals
time for me and the rest of the team.
When you’re storing files on 360K floppies, a few hundred bytes per file
adds up quickly.
A hundred nine year old diskettes go for 85 bucks on Amazon. A 2
terabyte USB hard drive goes for 65 bucks at Best Buy. Why does
anybody today store large amounts of data on 360 floppies?
We were talking about DOS. Many early systems only had floppies.
--
Pete
r***@gmail.com
2020-04-10 02:29:50 UTC
Permalink
Post by John Floren
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
And as I said, that's a completely ridiculous reason to use
CR/LF as a line ending in files.
Some of those Teletypes you had to send nulls after the CR/LF
to give the printer time to restore the carriage before you could send
more data.
How many DOS machines were ever connected to Teletypes, anyway?
Probably most.

Are you aware that the serial keyboard/printer attached to a DOS machine
could be used as a terminal? The keyboard of the DOS machine
could be reassigned to the keyboard/printer, thereby obtaining
not only what was typed at the keyboard, but the interleaved
responses from DOS.
Post by John Floren
It's
before my time, but I'd assume that graphical terminals were pretty
common by the time they wrote MS-DOS.
Sure, but graphical terminals were fairly expensive, whereas
teleprinters could be obtained for a few dollars.
Post by John Floren
I can see an argument for
maintaining compatibility with text files from other, earlier
microcomputer operating systems, but given the tiny memories of these
early systems I'd also be pretty eager to claw back one byte per line of
text.
Inconsequential.
Peter Flass
2020-04-10 21:56:29 UTC
Permalink
Post by r***@gmail.com
Post by John Floren
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
And as I said, that's a completely ridiculous reason to use
CR/LF as a line ending in files.
Some of those Teletypes you had to send nulls after the CR/LF
to give the printer time to restore the carriage before you could send
more data.
How many DOS machines were ever connected to Teletypes, anyway?
Probably most.
Are you aware that the serial keyboard/printer attached to a DOS machine
could be used as a terminal? The keyboard of the DOS machine
could be reassigned to the keyboard/printer, thereby obtaining
not only what was typed at the keyboard, but the interleaved
responses from DOS.
Post by John Floren
It's
before my time, but I'd assume that graphical terminals were pretty
common by the time they wrote MS-DOS.
Sure, but graphical terminals were fairly expensive, whereas
teleprinters could be obtained for a few dollars.
Only a while after graphical terminals go cheap. A real Teletype was a
pretty expensive piece of gear.
--
Pete
J. Clarke
2020-04-11 00:26:22 UTC
Permalink
On Fri, 10 Apr 2020 14:56:29 -0700, Peter Flass
Post by Peter Flass
Post by r***@gmail.com
Post by John Floren
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
And as I said, that's a completely ridiculous reason to use
CR/LF as a line ending in files.
Some of those Teletypes you had to send nulls after the CR/LF
to give the printer time to restore the carriage before you could send
more data.
How many DOS machines were ever connected to Teletypes, anyway?
Probably most.
Are you aware that the serial keyboard/printer attached to a DOS machine
could be used as a terminal? The keyboard of the DOS machine
could be reassigned to the keyboard/printer, thereby obtaining
not only what was typed at the keyboard, but the interleaved
responses from DOS.
Post by John Floren
It's
before my time, but I'd assume that graphical terminals were pretty
common by the time they wrote MS-DOS.
Sure, but graphical terminals were fairly expensive, whereas
teleprinters could be obtained for a few dollars.
Only a while after graphical terminals go cheap. A real Teletype was a
pretty expensive piece of gear.
A real _new_ Teletype was. An old one could be had fairly cheap in
1974 or thereabouts. I remember my girlfriend at the time had just
dumped her husband because he spent the rent money on a teletype.
Gareth Evans
2020-04-10 10:49:59 UTC
Permalink
Post by John Floren
How many DOS machines were ever connected to Teletypes, anyway? It's
before my time, but I'd assume that graphical terminals were pretty
common by the time they wrote MS-DOS.
At the tome of fomenting a 16 bit machine, the mid 1970s, Teletypes were
still common. (And were only just getting
succeeded by the Decwriter).

What a noisy beast is the DecWriter today, yet at the time
we marvelled about how quiet it was compared to the Teletypes!
r***@gmail.com
2020-04-10 02:22:51 UTC
Permalink
Post by Dan Espen
And as I said, that's a completely ridiculous reason to use
CR/LF as a line ending in files.
No it isn't. You've missed the point.
Post by Dan Espen
Some of those Teletypes you had to send nulls after the CR/LF
to give the printer time to restore the carriage before you could send
more data.
It was necessary to give the CR first, as the
carriage could not return in the time of a single character.

The LF coming after the CR meant that the carriage could return
in time for the following character.
Peter Flass
2020-04-10 21:56:27 UTC
Permalink
Post by r***@gmail.com
Post by Dan Espen
And as I said, that's a completely ridiculous reason to use
CR/LF as a line ending in files.
No it isn't. You've missed the point.
Post by Dan Espen
Some of those Teletypes you had to send nulls after the CR/LF
to give the printer time to restore the carriage before you could send
more data.
It was necessary to give the CR first, as the
carriage could not return in the time of a single character.
The LF coming after the CR meant that the carriage could return
in time for the following character.
No, I wrote a TTY handler for CICS, and I experimented to see how many NULs
I needed, IIRC I think 3 at 10cps
--
Pete
Gareth Evans
2020-04-10 10:46:10 UTC
Permalink
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
And as I said, that's a completely ridiculous reason to use
CR/LF as a line ending in files.
Some of those Teletypes you had to send nulls after the CR/LF
to give the printer time to restore the carriage before you could send
more data.
No more ridiculous than using an 8 bit byte to store 7 bit
ASCII, wasting, a bit at a time, enough space to store another
character every 7? If your argument is that computer programs
can intervene to fettle the text between reading the file and
sending to the teletype, then successively extracting 7 bits
at a time from a binary stream is a trivial matter.

And then, what of Unicode? Encoding some of the rarer ASCII
characters in more than 8 bits? How wasteful is that?

But really in today's system, with mega-oodles of RAM
and tera-oodles of disk space, is it really a realistic
argument to complain about CRLF sequences?

You do have a point, though, and that is, if encoding text,
then a single character should suffice as an end-of-line
marker. But you couldn't have a single character for
stream-encoded binary because your end-of-line character
might be part of that binary and you'd have to resort to
multi-character escape sequences, such as the use of
HDLC's 01111110.

As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
Dan Espen
2020-04-10 13:54:07 UTC
Permalink
Post by Gareth Evans
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
And as I said, that's a completely ridiculous reason to use
CR/LF as a line ending in files.
Some of those Teletypes you had to send nulls after the CR/LF
to give the printer time to restore the carriage before you could send
more data.
No more ridiculous than using an 8 bit byte to store 7 bit
ASCII, wasting, a bit at a time, enough space to store another
character every 7? If your argument is that computer programs
can intervene to fettle the text between reading the file and
sending to the teletype, then successively extracting 7 bits
at a time from a binary stream is a trivial matter.
And then, what of Unicode? Encoding some of the rarer ASCII
characters in more than 8 bits? How wasteful is that?
But really in today's system, with mega-oodles of RAM
and tera-oodles of disk space, is it really a realistic
argument to complain about CRLF sequences?
You do have a point, though, and that is, if encoding text,
then a single character should suffice as an end-of-line
marker. But you couldn't have a single character for
stream-encoded binary because your end-of-line character
might be part of that binary and you'd have to resort to
multi-character escape sequences, such as the use of
HDLC's 01111110.
I think I'm not following. Finding CR/LF in binary data is
possible too. If you're going to encode binary data, you have
to rely on something more complicated than special characters.
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
Nope, don't care that backslash is used by C to denote special
characters.

My point is that the file system has no business emulating the
requirements of a particular printer type. There were flavors of that
printer type that had even more bizarre print requirements. Why isn't
that in the file system.

You did touch on the checking for 2 bytes issue. We all know how that
can complicate code.
--
Dan Espen
Scott Lurndal
2020-04-10 16:11:40 UTC
Permalink
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?

The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Gareth Evans
2020-04-10 16:52:48 UTC
Permalink
Post by Scott Lurndal
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?
The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Dan was discussing space taken up by text files, of which
source files are an example.
Scott Lurndal
2020-04-10 18:42:37 UTC
Permalink
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?
The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Dan was discussing space taken up by text files, of which
source files are an example.
A C source file of 4000 lines might have one or two escaped characters
in it (or fewer, or more, but it's irrelevent to using CRLF as a
line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
Gareth Evans
2020-04-10 18:53:57 UTC
Permalink
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?
The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Dan was discussing space taken up by text files, of which
source files are an example.
A C source file of 4000 lines might have one or two escaped characters
in it (or fewer, or more, but it's irrelevent to using CRLF as a
line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
4000 lines ???? That's 50 pages and a file of that size could
only have been produced by a computing incompetentismo.
Scott Lurndal
2020-04-10 19:07:19 UTC
Permalink
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?
The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Dan was discussing space taken up by text files, of which
source files are an example.
A C source file of 4000 lines might have one or two escaped characters
in it (or fewer, or more, but it's irrelevent to using CRLF as a
line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
4000 lines ???? That's 50 pages and a file of that size could
only have been produced by a computing incompetentismo.
Evasion noted.

We have well over two millions lines of C/C++ code, and several files are
in the 2 to 4 thousand line range, even without counting header files that
are generated. And there is no "computing incompetentismo" involved.
Charlie Gibbs
2020-04-10 19:41:53 UTC
Permalink
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?
The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Dan was discussing space taken up by text files, of which
source files are an example.
A C source file of 4000 lines might have one or two escaped characters
in it (or fewer, or more, but it's irrelevent to using CRLF as a
line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
4000 lines ???? That's 50 pages and a file of that size could
only have been produced by a computing incompetentismo.
Evasion noted.
We have well over two millions lines of C/C++ code, and several files are
in the 2 to 4 thousand line range, even without counting header files that
are generated. And there is no "computing incompetentismo" involved.
A couple of my source files have grown to over 10,000 lines.
Not by design, but changing requirements, plus a compiler that
can handle it. A single source file makes the makefile smaller.

Small modules are a sign of a short attention span. :-)
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <***@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Dan Espen
2020-04-10 21:13:25 UTC
Permalink
Post by Charlie Gibbs
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?
The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Dan was discussing space taken up by text files, of which
source files are an example.
A C source file of 4000 lines might have one or two escaped characters
in it (or fewer, or more, but it's irrelevent to using CRLF as a
line delimiter). One or two extra backslash instead of 4000 useless
carriage returns.
4000 lines ???? That's 50 pages and a file of that size could
only have been produced by a computing incompetentismo.
Evasion noted.
We have well over two millions lines of C/C++ code, and several files are
in the 2 to 4 thousand line range, even without counting header files that
are generated. And there is no "computing incompetentismo" involved.
A couple of my source files have grown to over 10,000 lines.
Not by design, but changing requirements, plus a compiler that
can handle it. A single source file makes the makefile smaller.
Small modules are a sign of a short attention span. :-)
10K is way out there, I've seen that size with COBOL but it wasn't pleasant.
If there is any pattern to that 10K of source code perhaps a code
generator can condense some of it.

I've taken good line counts out of Assembler and C buy writing macros.
--
Dan Espen
J. Clarke
2020-04-11 00:27:32 UTC
Permalink
Post by Dan Espen
Post by Charlie Gibbs
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?
The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Dan was discussing space taken up by text files, of which
source files are an example.
A C source file of 4000 lines might have one or two escaped characters
in it (or fewer, or more, but it's irrelevent to using CRLF as a
line delimiter). One or two extra backslash instead of 4000 useless
carriage returns.
4000 lines ???? That's 50 pages and a file of that size could
only have been produced by a computing incompetentismo.
Evasion noted.
We have well over two millions lines of C/C++ code, and several files are
in the 2 to 4 thousand line range, even without counting header files that
are generated. And there is no "computing incompetentismo" involved.
A couple of my source files have grown to over 10,000 lines.
Not by design, but changing requirements, plus a compiler that
can handle it. A single source file makes the makefile smaller.
Small modules are a sign of a short attention span. :-)
10K is way out there, I've seen that size with COBOL but it wasn't pleasant.
If there is any pattern to that 10K of source code perhaps a code
generator can condense some of it.
I've taken good line counts out of Assembler and C buy writing macros.
The trouble is that you have to find the time to analyze it and make
the changes and test them.
Peter Flass
2020-04-10 21:56:34 UTC
Permalink
Post by Charlie Gibbs
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?
The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Dan was discussing space taken up by text files, of which
source files are an example.
A C source file of 4000 lines might have one or two escaped characters
in it (or fewer, or more, but it's irrelevent to using CRLF as a
line delimiter). One or two extra backslash instead of 4000 useless
carriage returns.
4000 lines ???? That's 50 pages and a file of that size could
only have been produced by a computing incompetentismo.
Evasion noted.
We have well over two millions lines of C/C++ code, and several files are
in the 2 to 4 thousand line range, even without counting header files that
are generated. And there is no "computing incompetentismo" involved.
A couple of my source files have grown to over 10,000 lines.
Not by design, but changing requirements, plus a compiler that
can handle it. A single source file makes the makefile smaller.
Small modules are a sign of a short attention span. :-)
I have a lot of multi-thousand line modules. I try to keep all related code
together. If the program is organized it’s not difficult to work with.

I recall the days when a program that was a tray of cards (2000 lines) was
pretty big, and anything over a tray was HUGE.
--
Pete
Gareth Evans
2020-04-10 20:32:53 UTC
Permalink
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?
The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Dan was discussing space taken up by text files, of which
source files are an example.
A C source file of 4000 lines might have one or two escaped characters
in it (or fewer, or more, but it's irrelevent to using CRLF as a
line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
4000 lines ???? That's 50 pages and a file of that size could
only have been produced by a computing incompetentismo.
Evasion noted.
We have well over two millions lines of C/C++ code, and several files are
in the 2 to 4 thousand line range, even without counting header files that
are generated. And there is no "computing incompetentismo" involved.
You're very aggressive, so little point in continuing this. I
have expressed correct views and you other views and clearly
we are not going to agree.
Dan Espen
2020-04-10 21:04:59 UTC
Permalink
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?
The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Dan was discussing space taken up by text files, of which
source files are an example.
A C source file of 4000 lines might have one or two escaped characters
in it (or fewer, or more, but it's irrelevent to using CRLF as a
line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
4000 lines ???? That's 50 pages and a file of that size could
only have been produced by a computing incompetentismo.
Well, I guess we are talking about C, but 4000 lines for COBOL
is very common.

With C, I've seen a few that size. Big complicated applications require
that. I've seen attempts to break big applications into dozens of
called modules. You end up with a nest where you can't find anything.
(Even with the help of TAGS.)

A few decades back I got temporary ownership of a huge C module.
Even though the code was all in one module, it was still hard to find
your way through the code.

So, I looked for ways to use separate called modules and there was
plenty of called modules, but so much shared stuff that the module
resisted my efforts.

So, I took a few hours and renamed all the called subroutines using
COBOL rules. It looked pretty weird, C code like this:

int b100_findstuff(int num, char* dta) {
x100_getzip();
}

I then went through the prefixes (like b100,x100) and made them reflect
the calling hierarchy.
Then I moved all the code into alphanumeric order.

Then I fixed the reason I was in the code in the first place.

The other developers with years of C said they loved it.
--
Dan Espen
J. Clarke
2020-04-11 00:30:15 UTC
Permalink
Post by Dan Espen
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
Post by Scott Lurndal
Post by Gareth Evans
As to multicharacter markers in text files, do you
object to the \n end of line convention in the C language
because that takes two characters! :-)
You do, of course, realize that '\n' translates into a single
byte, right?
The fact that you need two characters to represent LF in source
is irrelevent. Note that you need four for CRLF (\r\n).
Dan was discussing space taken up by text files, of which
source files are an example.
A C source file of 4000 lines might have one or two escaped characters
in it (or fewer, or more, but it's irrelevent to using CRLF as a
line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
4000 lines ???? That's 50 pages and a file of that size could
only have been produced by a computing incompetentismo.
Well, I guess we are talking about C, but 4000 lines for COBOL
is very common.
With C, I've seen a few that size. Big complicated applications require
that. I've seen attempts to break big applications into dozens of
called modules. You end up with a nest where you can't find anything.
(Even with the help of TAGS.)
A few decades back I got temporary ownership of a huge C module.
Even though the code was all in one module, it was still hard to find
your way through the code.
So, I looked for ways to use separate called modules and there was
plenty of called modules, but so much shared stuff that the module
resisted my efforts.
So, I took a few hours and renamed all the called subroutines using
int b100_findstuff(int num, char* dta) {
x100_getzip();
}
I then went through the prefixes (like b100,x100) and made them reflect
the calling hierarchy.
Then I moved all the code into alphanumeric order.
Then I fixed the reason I was in the code in the first place.
The other developers with years of C said they loved it.
That's a good idea. I have a ton of APL that is difficult to wade
through with which I might try that.
r***@gmail.com
2020-04-10 02:05:01 UTC
Permalink
Post by Gareth Evans
Post by Dan Espen
So, DOS had 2 characters to end each line.
Completely ridiculous.
If it was CR & LF, then they were control
characters for the Teletypes that were extant
for many years.
Of course it was CR LF.

And it was not only for Teletypes and teleprinters.

A number of vendors had band printers going at 300 cps,
and there were even faster daisywheel printers, etc.
Peter Flass
2020-04-09 18:53:49 UTC
Permalink
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DOS had two different ways of accessing disk files,
both the CP/M way and also the UNIX way.
Sure, and .BAT is exactly equivalent to .sh.
Post by Gareth Evans
I have no quasi-religious attitude to any language
or OS. I've used several of each in my time and
when I get around to them, I have my own ideas for
both (QV).
Religious, why are you going there?
I just didn't want to use junk.
So, DOS had 2 characters to end each line.
Completely ridiculous. Then I seem to remember
^Z would sit at the end of your file even though the
system knew the file byte count.
I once decided to become expert at using the display on DOS.
I bought a rather thick book on VGA.
I'd previously decided IBM 3270s were crap due to unwarranted
complexity.
I loved 3270s and all,the stuff they can do. Of course I started from TTYs.
Post by Dan Espen
The hundreds of VGA modes showed me exactly how bad a display design
could be.
If I remember DOS and it's TSRs, there was no way to wait for keyboard
input, you just kept polling the keyboard for input.
What a POS.
No, I think you get a key-press interrupt.
--
Pete
Scott Lurndal
2020-04-09 14:41:11 UTC
Permalink
Post by Gareth Evans
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DOS had two different ways of accessing disk files,
both the CP/M way and also the UNIX way.
Compared to unix, DOS was a toy. There is no
comparison between the two.
Jorgen Grahn
2020-04-09 15:54:08 UTC
Permalink
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
MS-DOS looked impressive to me; I was on some kind of CP/M system, and
only read about DOS in library books. Then I never got to use it;
someone introduced me to the Commodore-Amiga, and then there was Unix.

But I read those library books and planned what I'd do with that
exciting and strange MS-DOS environment. I can still feel the
excitement.

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Charlie Gibbs
2020-04-09 15:58:59 UTC
Permalink
Post by Jorgen Grahn
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
MS-DOS looked impressive to me; I was on some kind of CP/M system, and
only read about DOS in library books. Then I never got to use it;
someone introduced me to the Commodore-Amiga, and then there was Unix.
But I read those library books and planned what I'd do with that
exciting and strange MS-DOS environment. I can still feel the
excitement.
You were fortunate; this is definitely one of those cases
where the reality doesn't live up to the fantasy.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <***@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Charlie Gibbs
2020-04-09 15:56:47 UTC
Permalink
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
And Windows inherited those shortcomings, so they're
with us to this day.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <***@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Peter Flass
2020-04-09 18:53:48 UTC
Permalink
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
Yes, I never understood why they didn’t do something closer to unix.
--
Pete
J. Clarke
2020-04-09 20:42:05 UTC
Permalink
Post by Peter Flass
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
Yes, I never understood why they didn’t do something closer to unix.
Well, the developer hating Unix might have something to do with it.
Gareth Evans
2020-04-10 10:35:45 UTC
Permalink
Post by J. Clarke
Post by Peter Flass
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
Yes, I never understood why they didn’t do something closer to unix.
Well, the developer hating Unix might have something to do with it.
Was it not a bought in product for Microsoft? Originally QDOS
The Quick and Dirty Operating System just kludged together
in a hurry to give what were essentially CP/M facilities but
on a 16 bit X86 processor?
Andreas Kohlbach
2020-04-10 15:29:18 UTC
Permalink
Post by Gareth Evans
Post by J. Clarke
Post by Peter Flass
Yes, I never understood why they didn’t do something closer to unix.
Well, the developer hating Unix might have something to do with it.
Was it not a bought in product for Microsoft? Originally QDOS
The Quick and Dirty Operating System just kludged together
in a hurry to give what were essentially CP/M facilities but
on a 16 bit X86 processor?
That's what I think too. QDOS was not intended to be "UNIX-Like". When
sold to Micro Soft (were two words back then) they didn't bothered
either.
--
Andreas
Dan Espen
2020-04-09 20:59:36 UTC
Permalink
Post by Peter Flass
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
Yes, I never understood why they didn’t do something closer to unix.
Because they correctly saw, they couldn't monopolize the market with
an OS so clean that it can be reproduced by competitors.
--
Dan Espen
r***@gmail.com
2020-04-10 02:00:28 UTC
Permalink
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DR DOS was better.

Unix was crummy. It had documented bugs,
that were never going to be fixed.
Dave Garland
2020-04-10 04:31:27 UTC
Permalink
Post by r***@gmail.com
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DR DOS was better.
A bit. Or MSDOS with 4DOS enhancement. (Norton sold a "NDOS" that was
an OEM version of 4DOS.)
Post by r***@gmail.com
Unix was crummy. It had documented bugs,
that were never going to be fixed.
To be fair, all the micro OS had bugs (as do all OS even today). Not
all of them documented. I don't think the real UNIX ever ran on
microcomputers. The problem with its clones (and the reason I didn't
get an *IX) was cost. IIRC the options were all hundreds or thousands
of dollars, where MSDOS was reasonable (or free, if you took
liberties). BSD did exist, but they had legal problems with ATT and it
wasn't clear they'd survive that. As a one man shop, I couldn't afford
to gamble.
r***@gmail.com
2020-04-10 04:51:56 UTC
Permalink
Post by Dave Garland
Post by r***@gmail.com
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DR DOS was better.
A bit.
A lot better.
For one, it was possible to edit a previous command,
something that MS-DOS never did, and you could not do until
in DOS under a much later Windows.
Post by Dave Garland
Or MSDOS with 4DOS enhancement. (Norton sold a "NDOS" that was
an OEM version of 4DOS.)
Post by r***@gmail.com
Unix was crummy. It had documented bugs,
that were never going to be fixed.
To be fair, all the micro OS had bugs
No they didn't.
Post by Dave Garland
(as do all OS even today). Not
all of them documented. I don't think the real UNIX ever ran on
microcomputers. The problem with its clones (and the reason I didn't
get an *IX) was cost. IIRC the options were all hundreds or thousands
of dollars, where MSDOS was reasonable (or free, if you took
liberties). BSD did exist, but they had legal problems with ATT and it
wasn't clear they'd survive that. As a one man shop, I couldn't afford
to gamble.
Gareth Evans
2020-04-10 10:56:07 UTC
Permalink
Post by r***@gmail.com
For one, it was possible to edit a previous command,
something that MS-DOS never did, and you could not do until
in DOS under a much later Windows.
I beg to differ. ISTR the use of F2 and F3 to repeat the
previous command character by character.
Dave Garland
2020-04-10 14:25:47 UTC
Permalink
Post by r***@gmail.com
Post by Dave Garland
To be fair, all the micro OS had bugs
No they didn't.
Which OS was completely bug-free?
Dan Espen
2020-04-10 14:40:57 UTC
Permalink
Post by Dave Garland
Post by r***@gmail.com
Post by Dave Garland
To be fair, all the micro OS had bugs
No they didn't.
Which OS was completely bug-free?
I believe the OP was referring to the BUGS section in man pages which is
sort of unique to Unix.

Calling the BUGS section a bad thing is absurd.

I'm most familiar with the voluminous IBM documentation.
I don't recall any bugs section in their documents, instead
you're presented with complexity and obstacles. I think
I prefer the simplicity.

Here is the BUGS section for "find":

There are security problems inherent in the behaviour that the POSIX
standard specifies for find, which therefore cannot be fixed. For
example, the -exec action is inherently insecure, and -execdir should
be used instead. Please see Finding Files for more information.

Yep, won't be fixed.
--
Dan Espen
Peter Flass
2020-04-10 21:56:33 UTC
Permalink
Post by Dan Espen
Post by Dave Garland
Post by r***@gmail.com
Post by Dave Garland
To be fair, all the micro OS had bugs
No they didn't.
Which OS was completely bug-free?
I believe the OP was referring to the BUGS section in man pages which is
sort of unique to Unix.
Calling the BUGS section a bad thing is absurd.
I'm most familiar with the voluminous IBM documentation.
You need to look at the maintenance. When you install a product you get a
separate “tape” with all the known bugs, hopefully with fixes or
workarounds.
--
Pete
Dan Espen
2020-04-10 22:24:06 UTC
Permalink
Post by Peter Flass
Post by Dan Espen
Post by Dave Garland
Post by r***@gmail.com
Post by Dave Garland
To be fair, all the micro OS had bugs
No they didn't.
Which OS was completely bug-free?
I believe the OP was referring to the BUGS section in man pages which is
sort of unique to Unix.
Calling the BUGS section a bad thing is absurd.
I'm most familiar with the voluminous IBM documentation.
You need to look at the maintenance. When you install a product you get a
separate “tape” with all the known bugs, hopefully with fixes or
workarounds.
I've never had authority to look at APARs but I've seen plenty and
helped create more than one.

The man pages do something odd, they just list any bugs as if the tool
is still in beta. Most of the pages I just scanned just had a
"REPORTING BUGS" section.
--
Dan Espen
Peter Flass
2020-04-10 21:56:31 UTC
Permalink
Post by r***@gmail.com
Post by Dave Garland
Post by r***@gmail.com
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DR DOS was better.
A bit.
A lot better.
For one, it was possible to edit a previous command,
something that MS-DOS never did, and you could not do until
in DOS under a much later Windows.
Post by Dave Garland
Or MSDOS with 4DOS enhancement. (Norton sold a "NDOS" that was
an OEM version of 4DOS.)
Post by r***@gmail.com
Unix was crummy. It had documented bugs,
that were never going to be fixed.
To be fair, all the micro OS had bugs
No they didn't.
“All known bugs are fixed.”
--
Pete
Peter Flass
2020-04-10 21:56:30 UTC
Permalink
Post by Dave Garland
Post by r***@gmail.com
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DR DOS was better.
A bit. Or MSDOS with 4DOS enhancement. (Norton sold a "NDOS" that was
an OEM version of 4DOS.)
Post by r***@gmail.com
Unix was crummy. It had documented bugs,
that were never going to be fixed.
To be fair, all the micro OS had bugs (as do all OS even today). Not
all of them documented. I don't think the real UNIX ever ran on
microcomputers.
PDP-11,so the LSI-11.
Post by Dave Garland
The problem with its clones (and the reason I didn't
get an *IX) was cost. IIRC the options were all hundreds or thousands
of dollars,
AT&T licensing was ridiculous, unless you were a college.
Post by Dave Garland
where MSDOS was reasonable (or free, if you took
liberties). BSD did exist, but they had legal problems with ATT and it
wasn't clear they'd survive that. As a one man shop, I couldn't afford
to gamble.
--
Pete
J. Clarke
2020-04-11 00:55:13 UTC
Permalink
On Thu, 9 Apr 2020 23:31:27 -0500, Dave Garland
Post by Dave Garland
Post by r***@gmail.com
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DR DOS was better.
A bit. Or MSDOS with 4DOS enhancement. (Norton sold a "NDOS" that was
an OEM version of 4DOS.)
Post by r***@gmail.com
Unix was crummy. It had documented bugs,
that were never going to be fixed.
To be fair, all the micro OS had bugs (as do all OS even today). Not
all of them documented. I don't think the real UNIX ever ran on
microcomputers.
Of course it did.

The porting base for System V Release 3 was the 3B2, which used a
Western Electric WE-3200 microprocessor.

The porting bases for SVR4 were the x86 and Sparc.

And SVR2 was available for the 80286--AT&T shipped an Olivetti-made
286 machine with SVR2 bundled.

And AT&T Unix was ported to many other architectures, a lot of them
micros.
Post by Dave Garland
The problem with its clones (and the reason I didn't
get an *IX) was cost. IIRC the options were all hundreds or thousands
of dollars, where MSDOS was reasonable (or free, if you took
liberties). BSD did exist, but they had legal problems with ATT and it
wasn't clear they'd survive that. As a one man shop, I couldn't afford
to gamble.
Scott Lurndal
2020-04-10 16:12:20 UTC
Permalink
Post by r***@gmail.com
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DR DOS was better.
Unix was crummy. It had documented bugs,
that were never going to be fixed.
Nonsense, Rod Speed.
Dan Espen
2020-04-10 17:35:31 UTC
Permalink
Post by Scott Lurndal
Post by r***@gmail.com
Post by Dan Espen
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DR DOS was better.
Unix was crummy. It had documented bugs,
that were never going to be fixed.
Nonsense, Rod Speed.
Nonsense, but all of a sudden, these posts by Robin Vowel make sense.
Thanks.
--
Dan Espen
Jim Jackson
2020-04-10 17:51:57 UTC
Permalink
Post by r***@gmail.com
Post by Dan Espen
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DR DOS was better.
Unix was crummy. It had documented bugs,
that were never going to be fixed.
Good job I wasn't drinking I'd have sprayed the keyboard. What a bozo!
J. Clarke
2020-04-10 18:15:53 UTC
Permalink
On Fri, 10 Apr 2020 17:51:57 -0000 (UTC), Jim Jackson
Post by Jim Jackson
Post by r***@gmail.com
Post by Dan Espen
Hmm, MSDOS annoyed me from day 1.
What I wanted was a Unix flavor.
DOS fell short in so many ways.
DR DOS was better.
Unix was crummy. It had documented bugs,
that were never going to be fixed.
Good job I wasn't drinking I'd have sprayed the keyboard. What a bozo!
Amen. I tried DR DOS. It didn't do anything that MS-DOS didn't do,
and there was stuff that wouldn't run on it that I used (that was a
long time ago, so don't ask me what), so any claim that it was
"better" needs some factual support.
Scott Lurndal
2020-04-09 14:40:18 UTC
Permalink
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
That's incorrect. Intel and AMD x86_64 processors still
reset to real mode. The boot loader generally transitions
to protected mode, turns on paging, then switches to long mode (64-bit).
Peter Flass
2020-04-09 18:53:47 UTC
Permalink
Post by Gareth Evans
Post by Dan Espen
Actually Linux is one of the few OSes that let you get near those
naked blinkenlights.
AIUI the 64 bit processors no longer boot as 16 bitters,
which counts out MSDOS as an option.
How proud I was in 1986 to have the book,
"Advanced MSDOS" by Ray Duncan, and how
passe it is today!
Sort of an oxymoron now.
--
Pete
r***@gmail.com
2020-04-09 00:44:31 UTC
Permalink
Post by Gareth Evans
As it happens, I have ordered a newer printer as the WF2510 is
no longer listed,
You haven't checked out the wifi.
Post by Gareth Evans
and when my several work benches have been
cleared to make enough room, then I'll attempt disassembly to
look for dry joints, dead spiders, etc, purely out of
interest as its purpose in life will have been surpassed
by the newer printer.
Have you substituted a USB cable for the WIFI?
r***@gmail.com
2020-04-09 01:02:25 UTC
Permalink
Post by Gareth Evans
As it happens, I have ordered a newer printer as the WF2510 is
no longer listed,
Rubbish. It's a current model; you can find it at EPSON.
It's one of a family of WORKFORCE printers that uses
4 ink cartridges with great ink.
Post by Gareth Evans
and when my several work benches have been
cleared to make enough room, then I'll attempt disassembly to
look for dry joints, dead spiders, etc, purely out of
interest as its purpose in life will have been surpassed
by the newer printer.
Reminds me of the time that my brother discarded an HP printer
of the 5xx series.
I looked at it, and all it required was wiping the bar
on which the cartridge carrier moved.
At that time, it was about 2 years old.

My HP500C (1994) still runs (touch wood).
William Pechter
2020-04-07 17:28:00 UTC
Permalink
Post by Dave Garland
Post by Andreas Kohlbach
Post by Melzzzzz
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Install Linux?
Get a USB-stick Linux, like Ubuntu. Install it on the USB-stick, boot
from it and see,of the problem persist. If not, install Linux.
My experience with all-in-one printers under Linux suggests that
getting them working can be challenging (and the printer mfgr will say
"we don't support that"). But it was working for him before.
Sometimes a problem wedges the print queue in Win, and you have to
clear it manually (because it may survive a reboot) and start again.
Also, make sure the printer is selected as the default in Win and the
printing isn't going to one of those Win pseudo-devices. Try the
routine for "print a test page". DL fresh drivers from Epson website.
Try printing via USB instead of WiFi.
I hate all-in-ones.
One good thing is the Brother multifunctions all work on x86 linux.
They even have a shell script to download the .deb files for debian/ubuntu
and install them for you. They also support the .rpm installers as well.

The support includes scanning under linux as well as printing. I wish I had the same support on FreeBSD and on Raspberry Pi's with their Arm processors.

Bill
maus
2020-04-07 18:09:06 UTC
Permalink
Post by Dave Garland
My experience with all-in-one printers under Linux suggests that
getting them working can be challenging (and the printer mfgr will say
"we don't support that"). But it was working for him before.
Sometimes a problem wedges the print queue in Win, and you have to
clear it manually (because it may survive a reboot) and start again.
Also, make sure the printer is selected as the default in Win and the
printing isn't going to one of those Win pseudo-devices. Try the
routine for "print a test page". DL fresh drivers from Epson website.
Try printing via USB instead of WiFi.
I hate all-in-ones.
++1, not only with computers
--
greymaus
Kerr-Mudd,John
2020-04-07 19:38:19 UTC
Permalink
[]
Post by maus
Post by Dave Garland
Try printing via USB instead of WiFi.
I hate all-in-ones.
++1, not only with computers
I think they called "onesies" now
--
Bah, and indeed, Humbug.
r***@gmail.com
2020-04-07 05:44:12 UTC
Permalink
Post by Gareth Evans
Epson WF-2510 printer, driven by WiFi
Asuspro laptop
Windows 10 64 bit
McAfee virus protection
This setup had been working fine for over a year but when I came today
to print, nothing happens. The LCD on the printer indicates
that it is printing, as does the printer queue on Windows,
but nothing happens.
The ink-level screen does report back OK after a short delay
Using the printer off-line and it copies documents OK, paper
feeds and printing, so mechanically everything seems in order.
Has anyone here any clues, please?
Kill the print job.

Try pulling out the USB connection from the computer,
and re-insert it. (computer switched on, of course).

Same for printer (if possible).

That worked for me last week with a different printer
that had been working for yonks.

If you had a cable connection, I could suggest replacing the cable
(that worked for me). I replaced the cable with a slightly shorter one.
Loading...