How many instructions are there ?

[NoTime]

I just wonder how it might have evolved if all those full screen DOS programs were ported as exact replicas to unix, unix - prompt. Like turbo pascal, or quick basic, etc.

DOS had access to the video buffer and the keystroke buffer.
IIRC the first CRT TTY terminals used for UNIX (and other applications) only transmitted the line the cursor was on when the enter key was hit.
This was a carry over from paper termiminals.
The arrow keys and whatnot were only available to the TTY terminal and not the OS.

 

[AlephZero]

The IBM 360 was constrained to a max of 64k memory.

I find that very hard to believe. I was working for a company that used 360/65s round about 1970 (before they had virtual memory operating systems) and the standard sized job streams were set at 100 180 and 240k memory (several streams running at once). That makes no sense if the machine had a max of 64k.

Even our little IBM 1130s had 32k words (not bytes) of memory.

Quite possibly the smaller models of 360 (models 20 and 30) were more contrained though.

By 1985, a Cray 2 super computer had 512MB of memory

Nope, it had 512 Mwords (64 bit) = 4 GB.

 

[NoTime]

Quite possibly the smaller models of 360 (models 20 and 30) were more contrained though.

The ones I was thinking of were models 20 and 30.

 

[Hurkyl]

With linux the possibility of porting any DOS to unix became virtually zero because DOS was no longer even on the radar and because of hostility for anything DOS by OSS programmers.

I wonder, then, how the DOSBox project exists.

 

[graphic7]

PS: vi is a horrible editor.
It was, however, a lot better than card punch.
Considering modern editors, I find it hard to believe it's still around for use.

You either seem to be forgetting or don't know that standards "typically" dominate the UNIX world (note, I said UNIX world, which excludes UNIX-like operating systems, such as Linux) and what dominates standards usually are tools that are on multiple variations of the said operating system over a long period of time prior to the formation of the standard. In this case we are talking about ed/ex/vi, which were around for some time before POSIX 1003.2-1992 (the specific POSIX standard that mandates which commands/utilities should exist on a POSIX 1003.2-1992 compliant system).

Simply said, the reason editors like ed, ex, and vi are still around is the standard that most UNIX variants follow mandates them, and users of those systems are guaranteed to always have such editors around. Even if the said system isn't POSIX-compliant, such as a BSD release that predates POSIX, vi will still be around, because vi originated on a very, very old BSD release (2BSD or so, I think). If a user is going to choose an editor to learn, it would be reasonable and advantageous to choose the editor that will be available everywhere.

Also, more 'modern' editors like emacs, nedit, etc. are not going to be available on every system, even modern systems, like AIX or Solaris without installing additional freeware, which may or may not be practical in a production environment with strict standards specifying what can be installed on systems within the production environment.

 

[chroot]

I wonder, then, how the DOSBox project exists.

Excellent find! There's oldtobor's EDIT right there, running on Linux. As if, somehow, pico isn't similar enough.

- Warren

 

[Hurkyl]

Scary, but true: Some flight software is now written in C++. Fortunately, many of the features of C++ that are touted as "attributes" of the language are forbidden in this use: operator overloading, multiple inheritance, templates, runtime binding: all verbotten. Some of these features are often touted as attributes of Python.

Huh? You say it like those are bad things.

Yes, a programmer inexperienced with those tools can do a lot of damage, but so can someone inexperienced with a circular saw. That doesn't make circular saws a bad thing.

 

[rcgldr]

runtime binding

How is runtime binding signficantly different than using pointers to functions? In the old days on some systems where every instruction cycle counted, one way to speed up interrupt processing was to change the interrupt vector address (pointer to function) at each step to eliminate the extra time it would take to do an indirect jump via software.

 

[D H]

Huh? You say it like those are bad things.

They (operator overloading, multiple inheritence) have the potential to be very bad things. Why do you think operator overloading and multiple inheritence were intentionally left out of Java?

For some rather stong opinions regarding operator overloading, read these thread on operator overloading in Java:
http://forum.java.sun.com/thread.jspa?forumID=54&threadID=489919" .

 

[Hurkyl]

They (operator overloading, multiple inheritence) have the potential to be very bad things. Why do you think operator overloading and multiple inheritence were intentionally left out of Java?

Circular saws have the potential to do very bad things too. That doesn't make them a bad tool. (Wait, didn't I already say that?)

Operator overloading and a certain portion of multiple inheritance functionality was intentionally left out of java because java has different design goals.

 

[AlephZero]

No comment on the advisability of building flight software using circular saws.

However, I did once spend a long night helping ferry the "walking wounded" to hospital, after a plane crash caused partly by the fact that somebody managed to wire up the flight deck on a commercial airliner so a problem with engine 1 lit up the warning indicators for engine 2, and somebody else inspected what they had done and said "yeah, that's OK". The consequence was the flight crew attempted a one-engine landing, except they shut down the engine that was working properly, not the other one.

By all means tell me that sort of thing will never happen with modern software design methodologies, but I won't necessarily believe you.

 

[NoTime]

You either seem to be forgetting or don't know that standards "typically" dominate the UNIX world.

I had admin responsibilities for a couple years.
AIX and SUN.
I got to do a lot of work for things that should have evolved to no-brainers.
I would think, that after 25 years or so they could come up with better "standards".

 

[NoTime]

Circular saws have the potential to do very bad things too. That doesn't make them a bad tool. (Wait, didn't I already say that?)

Operator overloading and a certain portion of multiple inheritance functionality was intentionally left out of java because java has different design goals.

If you really want to get into multiple inheritance functionality then try some UNIX X-Windows coding.
IMO 3/4 of the development time and half the code is spent overriding inheritance.

IIRC Java's original design goal was as a small interpretive language to run on a consumer set top box imbedded p-engine.
Now it envisions itself as a competitor to C++.
It's original goal seems to have disappeared.

While circular saws may not be a bad tool, they certainly are dangerous.