Trying a one solution fits all approach was always Microsoft's approach.
Back over a decade ago when I was big into MFC development, it was amazing
how much of the Windows bloat was present in WINCE (or Windows Moble as they
later styled it). It's almost impossible to differentiate a desktop and
mobile on the Windows side. They tout it as an advantage.
Oddly, Android gives an indication of how to do it right. Sure, you can
take the essentials out of the common system, but you don't have to move
inappropriate bloat over.
> On the programming side, there wasn't either the memory capacity or
> processing power to implement a modern disk file system. One of the
> first computers I worked with was a System/360 model 25 running
> DOS/360. The machine had 48K of core memory, 12K of which was for the
> OS, leaving 36K for programs. No virtual memory.
Unix was a counterexample. Recall that v1 worked on a 24K
machine, 16K of which was OS and 8K user. And it had a modern
file system. Programming was so much easier that it lured
people (e.g. me) away from big mainframe computers.
Doug
> From: Dave Horsfall <dave(a)horsfall.org>
> Just think, if it wasn't for him and Ken, we'd all be running Windoze,
> and thinking it's wonderful.
It's actually worse than that.
We'd be running a Windows even worse than current Windows (which has managed
to pick up a few decent ideas from places like Unix).
Noel
Evening,
Okay - now that I've completed moving and settling in, I am slowly
bringing some stuff back up. UCBVAX should come back in the next few
weeks (now much closer to Berkeley...).
One advantage of the new location: cheaper power so my PBX runs all the
time now. ;)
Once I acquire a second modem I will accept UUCP at 115200 and 2400 baud
via telephone :)
--
Cory Smelosky
b4(a)gewt.net
> does anyone know anything about the 1961 DoD 8-bit
> character set standard it refers to?
>
> This does not appear to say anything about LF vs "Newline" (as either a
> name or a function), though the 1986 version of ASCII deprecates it, so
> was most likely acknowledged in versions between these in response to
> practices on OSes such as Multics. ECMA-6:1973 acknowledges it
I wouldn't say the "practices" of Multics influenced the recognition
of NL in the ASCII standard, for Multics didn't go into use until
1970, while NL was specified by 1965 (see below) with direct
reference to the properties of equipment, not operating systems.
Just what equipment, I don't know. IBM Selectric perhaps?
I recall Multics discussions that specifically cited the standard,
in particular Joe Ossanna's liaison between Multics and the TTY 37
design team at Western Electric, circa 1967. Thus it is my
understanding that Multics was an early adopter of ASCII's NL
convention, not an influencer of it.
Quotation from "Proposed revised American standard for information
interchange", CACM 8 (April 1965) 207-214:
The controls CR and LF are intended for printer equipment
which requires separate combinations to return the carriage
and feed a line.
As an alternative, for equipment which uses a single combination
for a combined carriage-return and line-feed operation
(called New-Line), NL will be coded at FE 2 [LF]. Then FE 5
[CR] will be regarded as Backspace BS.
If the latter type of equipment has to interwork with the
former, it may be necessary to take steps to introduce the
CR character.
One might read the preceding paragraph as advice not only to
writers of driver software but also to a future standards
committee to undo the curious notion of regarding CR
as BS. Unix effectively took it both ways, and kept the
original meaning of CR.
doug
> troff has a substantial history. Significant
changes in troff could invalidate most of the old documents leaving troff
with no usage base, and a poor tool at rendering all of the troff documents
out there.
As a living example, I have troff files from as far back as 1975 that
still work, and perhaps some even older that have lost their dates due
to careless copying. The only incompatibility with groff is easy to
fix: inserting a space before the arguments of a troff request. The
few other incompatibilities I've encouuntered have been graciously
corrected by groff maintainers. You get no such help for old Word files.
doug
On 02/09/2017, Dave Horsfall <dave(a)horsfall.org> wrote:
> On Thu, 31 Aug 2017, Nemo wrote:
>
>> (By the way, why all the ^M is the files?)
>
> Err, because CR/LF was the line terminator?
Hhhmmm... This begs the historical question: When did LF replace CR/LF in UNIX?
N.
>
> --
> Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
> suffer."
>
> When did LF replace CR/LF in UNIX?
Never. Unix always took LF as newline--an interpretation
blessed by the ASCII standard. The convention was
inherited from Multics.
Interpolation of CRs was the business of drivers, not file
formats.
As far as I know, the only CR/LF terminal that original
Unix dealt with was the model 33 console. That was identified
by the fact that the login name was received in all caps.
IIRC the TTY 37 conformed to Multics practice on the advice
of Joe Ossanna.
Because of the model 33, login names were case-insesitive.
Come to think of it, I don't know whether they still are
in general, though they must be for email to be delivered by
login name.
Doug
