I was hoped the project includes a forum but only found a google groupo.
I don't have an account and don't wish to.
Daniel wrote to alt.folklore.computers <=-
From Newsgroup: alt.folklore.computers
Seeking stories from others who have used the RC2014 board with CP/M. I
am researching this device as a potential platform for an evolving
project in the works.
Anything to be aware of? Warnings? Lessons learned? I was hoped the project includes a forum but only found a google groupo. I don't have
an account and don't wish to.
I may settle for getting a thin client PC and running MS-DOS on it.
Similar command-line goodness with less tinkering.
Lawrence wrote to alt.folklore.computers <=-
I may settle for getting a thin client PC and running MS-DOS on it.
Similar command-line goodness with less tinkering.
Command-line goodness and MS-DOS don't really go together
Back when I was in college, I did most of my peojects in C on MS-DOS.
There were a couple of decent BASH shells for DOS, vi and EMACS, a
handful of command line apps (tee, grep and so on) and a couple of C compilers that could compile from the command line. It made a compelling solution, years before you could chuck it and run Linux on your deskop.
This was so long ago that our only experience with UNIX was running
a userland environment called PRIMIX on a PRIME midrange that did the
same thing I was doing.
Back when I was in college, I did most of my peojects in C on MS-DOS. There were a couple of decent BASH shells for DOS, vi and EMACS, a
handful of command line apps (tee, grep and so on) and a couple of C compilers that could compile from the command line. It made a compelling solution, years before you could chuck it and run Linux on your deskop.
There was, once upon a time, a fairly robust community discussing schemes-tips-tools-tricks for getting more out of MS-DOS batch files. Certainly not as powerful as a real unix shell, but then even using one
of the unix toolkits on DOS, you didn't actually get pipes. You got intermediate disk files.
This was so long ago that our only experience with UNIX was running
a userland environment called PRIMIX on a PRIME midrange that did the
same thing I was doing.
On the gripping hand, if you were comparing against PRIMIX, you were
probably quite happy.
But I do wish I could find a copy of PRIMIX.
De
On Sun, 8 Mar 2026 20:30:00 -0000 (UTC), Lawrence D?Oliveiro wrote:
?Command-line goodness? and ?MS-DOS? don?t really go together ...
Back when I was in college, I did most of my peojects in C on
MS-DOS. There were a couple of decent BASH shells for DOS, vi and
EMACS, a handful of command line apps (tee, grep and so on) and a
couple of C compilers that could compile from the command line. It
made a compelling solution, years before you could chuck it and run
Linux on your deskop.
Example:
BTDT - alt.msdos.batch; best days 2000-10 - there were some really expert wanglers on there - embedded asm, executable text, rerun the same batch
with different parameters, date tricks, all sorts.
On Mon, 9 Mar 2026 19:55:19 -0000 (UTC)
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
Example:
That's not an issue with the Windows CLI, that's a case of the Rust
devs not doing their homework. As pointed out in the article itself,
"cmd.exe doesn't give you split arguments for free" is a known
factor that has been a solved problem in C implementations for ages.
There was, once upon a time, a fairly robust community discussing schemes-tips-tools-tricks for getting more out of MS-DOS batch
files.
The MIX C compiler cost $20 and ran very well on DOS. It was a
really great value vs buying whatever MS was selling as a DOS C
compiler. Fast too.
The bug could only happen on Windows, not on any Linux or Unix system.
On Mon, 9 Mar 2026 22:43:23 -0000 (UTC)
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
The bug could only happen on Windows, not on any Linux or Unix
system.
Sure - but the fact that it *did* happen is the fault of the Rust
devs who came up with an inadequate solution.
On 9 Mar 2026 16:25:54 GMT, Ted Nolan <tednolan> wrote:
The MIX C compiler cost $20 and ran very well on DOS. It was a really
great value vs buying whatever MS was selling as a DOS C compiler. Fast
too.
MS either bought or licensed Lattice C, I forget which, for 1.0 but then continued to develop it. By 6.0 it was pretty good but certainly not
cheap. Some of my clients bought it but I used DJGPP.
I will say back when you got hardcopy documentation with the product MS's was excellent for C.
I got a copy of Lattice C before MS took it over. It was a decent
compiler - and it had good hardcopy documentation even then.
On Tue, 10 Mar 2026 03:03:44 GMT, Charlie Gibbs wrote:
I got a copy of Lattice C before MS took it over. It was a decent
compiler - and it had good hardcopy documentation even then.
Back when everything you needed to know could fit in one volume ...
There can be no completely adequate solution: this kind of bug isith-ransomware-via-critical-php-vulnerability/>
likely to recur again, on Windows.
<https://arstechnica.com/security/2024/06/thousands-of-servers-infected-w
I mean, that's not good, but it also has nothing to do with the
point at issue ...
On 2026-03-10, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
On Tue, 10 Mar 2026 03:03:44 GMT, Charlie Gibbs wrote:
I got a copy of Lattice C before MS took it over. It was a decent
compiler - and it had good hardcopy documentation even then.
Back when everything you needed to know could fit in one volume ...
Four or five volumes, actually. The documentation was comprehensive.
On Tue, 10 Mar 2026 08:06:06 -0700, John Ames wrote:
I mean, that's not good, but it also has nothing to do with the
point at issue ...
The point at issue is that care around these pitfalls are only needed
on Windows, not on any other platform.
On Mon, 9 Mar 2026 08:29:23 -0700, Kurt Weiske wrote:
On Sun, 8 Mar 2026 20:30:00 -0000 (UTC), Lawrence D?Oliveiro wrote:
?Command-line goodness? and ?MS-DOS? don?t really go together ...
Back when I was in college, I did most of my peojects in C on
MS-DOS. There were a couple of decent BASH shells for DOS, vi and
EMACS, a handful of command line apps (tee, grep and so on) and a
couple of C compilers that could compile from the command line. It
made a compelling solution, years before you could chuck it and run
Linux on your deskop.
I suppose it was a cheaper compromise, back when proper Unix
workstations were quite expensive.
Besides the lack of multitasking, the whole MS-DOS command-line
concept is fundamentally broken, and that carries over to Windows
today.
Example: <https://www.theregister.com/2024/04/10/rust_critical_vulnerability_windows/>
Schmitty wrote to alt.folklore.computers <=-
If you want to run CP/M software (OK, on Windows), you can use the CP/M Player from TAKEDA, available here:
https://takeda-toshiya.my.coocan.jp/. --thomas.
Lawrence D?Oliveiro schrieb am 09.03.2026 um 20:55:
Besides the lack of multitasking, the whole MS-DOS command-line
concept is fundamentally broken, and that carries over to Windows
today.
Example:
<https://www.theregister.com/2024/04/10/rust_critical_vulnerability_windows/>
If you want to run CP/M software (OK, on Windows), you can use the
CP/M Player from TAKEDA ...
On Fri, 13 Mar 2026 11:41:51 +0100, Schmitty wrote:
Lawrence D?Oliveiro schrieb am 09.03.2026 um 20:55:
Besides the lack of multitasking, the whole MS-DOS command-line
concept is fundamentally broken, and that carries over to Windows
today.
Example:
<https://www.theregister.com/2024/04/10/rust_critical_vulnerability_windows/>
If you want to run CP/M software (OK, on Windows), you can use the
CP/M Player from TAKEDA ...
Talking of CP/M, that?s where MS-DOS got its broken command line from.
And Gary Kildall copied the concept in turn from the DEC systems he
used for cross-development.
On 2026-03-14, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
Talking of CP/M, that?s where MS-DOS got its broken command line
from. And Gary Kildall copied the concept in turn from the DEC
systems he used for cross-development.
Oh, MS-DOS came up with some breakages of its own. For instance, its
COPY command would refuse to copy empty files (i.e. length zero) -
although it would still delete an existing destination file of the
same name.
To: Schmitty
Schmitty wrote to alt.folklore.computers <=-
If you want to run CP/M software (OK, on Windows), you can use the CP/M Player from TAKEDA, available here:
https://takeda-toshiya.my.coocan.jp/. --thomas.
I've been more tempted to try a 30-day GUI cleanse - go back to a command-line for a month and see how it goes. DOS or CP/M would be an interesting experiment.
On Sun, 15 Mar 2026 01:48:58 GMT, Charlie Gibbs wrote:
On 2026-03-14, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
Talking of CP/M, that?s where MS-DOS got its broken command line
from. And Gary Kildall copied the concept in turn from the DEC
systems he used for cross-development.
Oh, MS-DOS came up with some breakages of its own. For instance, its
COPY command would refuse to copy empty files (i.e. length zero) -
although it would still delete an existing destination file of the
same name.
That?s a fixable bug in a specific utility. I?m talking about the fundamentally broken architecture of the MS-DOS command line itself,
which carries over to Windows today.
On 15/03/2026 02:43, Lawrence D?Oliveiro wrote:
On Sun, 15 Mar 2026 01:48:58 GMT, Charlie Gibbs wrote:
On 2026-03-14, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
Talking of CP/M, that?s where MS-DOS got its broken command line
from. And Gary Kildall copied the concept in turn from the DEC
systems he used for cross-development.
Oh, MS-DOS came up with some breakages of its own. For instance,
its COPY command would refuse to copy empty files (i.e. length
zero) - although it would still delete an existing destination
file of the same name.
That?s a fixable bug in a specific utility. I?m talking about the
fundamentally broken architecture of the MS-DOS command line
itself, which carries over to Windows today.
It is what it is. If you don't like it you can always user
PowerShell which seems even more broken
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 117:51:22 |
| Calls: | 125 |
| Calls today: | 125 |
| Files: | 489 |
| D/L today: |
859 files (365M bytes) |
| Messages: | 76,472 |
| Posted today: | 26 |