How many instructions are there ?

[chroot]

It appears to be well-architected. I just don't like it.

You might as well have left it at that, D H. The rest of your arguments are nonsense.

I don't like end-of-line meaning end-of-statement. One of the best things about forgetting how to do Fortran was forgetting how to make continuation statements.

You can use semicolons if you want to. You just don't have to.

I don't like the block structure via indentation. Visually impaired programmers (at least those I have worked with) detest indentation (and case-sensitivity, but that is a topic for another day). I learned long ago to use a pretty-printer to make sense of someone elses' indentation scheme. I learned long ago that forcing an indentation scheme is usually not a good idea.

Everyone who's new to Python follows the same road... most can't even fathom the idea of significant whitespace. The truth is, it removes many pains in the ass (such as figuring out which braces are nested within which braces), but adds a few pains in the ass of its own (such a moving between different editors configured to treat tabs differently). On the whole, it's really not a big enough reason to consider the language with distate. Try it for a couple of weeks, and I guarantee you'll no longer be concerned about it.

I don't like late binding. I would much prefer the compiler to tell me about errors ASAP.

This is a fair issue; but many other languages share it. Good runtime checking eliminates most of the potential problems, though. Late binding opens oh-so-many doorways to powerful, elegant code that it's entirely worth the "risk."

I don't like toy languages. Python, Pascal (oh yeah, and Basic) are toy languages. You can google "toy language" to see what I mean.

That's just asinine. Python is way more useful out of the box than many other supposedly non-toy languages like Perl and C++ and Java. To be honest with you, Java (the most popular language on the planet) is much more what I'd call a toy language than is Python. It sounds to me like you simply have little to no practical experience with the language. Am I correct?

- Warren

 

[D H]

I agree that Java is a "toy language", and for pretty much the same reasons that Kernighan called Pascal a "toy language".

I do not particularly like the way Python is organized. I am not alone in this regard. While proper indentation is nice, it is not something a compiler should use. Yech.

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.

 

[chroot]

I do not particularly like the way Python is organized. I am not alone in this regard. While proper indentation is nice, it is not something a compiler should use. Yech.

Once again, this is just the first stop on the ol' railroad. I was there once, too, and it almost prevented me from even giving the language a serious look. Good thing I opened my mind to it, though, after all.

- Warren

 

[eieio]

You are wrong. One cannot declare something both static and extern. Declaring something extern makes it visible to the linker. Declaring something static makes it invisible to the linker. I don't know what you mean by the word opposite, but I think most people would assume visible and invisible are opposites.

I know you can't use both static and extern at the same time. That would be like saying "hey there is this variable defined in another file, with local linkage, so I can't use it."

Let's turn to an example:

/* A: *declare* to the compiler that there will be an int variable named foo, in some other file*/
extern int foo;

/* B: *define* a variable named bar, with internal linkage */
static int bar;

/* C: *define* a variable named xmas, with external linkage */
int xmas = 25;

int func(void) {
    /* D: *define* a variable named easter, with no linkage */
    static easter = 21;
}

I don't know if there is any way to get this through to you, but for some reason I'm trying anyway.

In case A, there is no actual space reserved for foo at all. In fact, if nothing in the current file makes use of foo, it doesn't even need to be defined in another file, as the linker won't even look for it; it's just a declaration. You can even define it later in the same file if you want. Extern is like a prototype, essentially (and is redundant when used with function prototypes).

In case B, the compiler actually reserves space in the data section (uninitialized data section or BSS/.bss in this case). A symbol is created with local linkage.

In case C, the compiler again reserves space in the data section (initialized data section or DATA/.data). A symbol is created with external linkage. This means that files outside of the of the file can declare this variable extern, and then make use of it.

In case D, the complier again reserves space in the data section (DATA/.data). This is techinically called a static storage duration, but the result is existentially the same as a static global. The difference here is that the symbol is only visible within the scope of the function, and thus has a linkage of none. It's even safe to pass pointers to static locals around, unlike with automatic locals.

Is it not clear how differently static and extern work? Do you notice that case B and D are more silmilar than not? Can you see that the only difference is the symbol scope, which is naturally in line with the scopes of the definitions.

I don't know why you can't accept that static variables within functions are essentially the same as those out side of them. Furthermore, I don't know why you insist there are several different meanings of static. On top of that, I don't see one place in the spec where static is given specifically different meanings. There are several places that expound on the operational meaning, but nothing that indicates in any way that static is "overloaded" in meaning. And I'm not sure what bearing the BNF syntax definition has on how the keyword works. It seems like a thin ploy to misuse the spec to back up a weak argument and lend credence to a personal opinion.

The two terms cannot be used in unison (there are no static auto variables) and one means the variable is allocated/initialized each time the function is called and the other means the variable is allocated/initialized once. Once again, I don't know what you mean by the word opposite. To me, static and auto are opposites.

Ok, so a static local is allocated and initialized once, huh? Pretty much exactly what a static global is, huh? The only difference is the scope, eh? Ok, that really seems like static has a bunch of meanings then, since it has the same result everywhere it is used.

- OMD

 

[rcgldr]

You are incorrect here. The bitwise and/or/xor are higher precedence than the logical and/or. They are, however, lower precedence than relational operators, with good reason. They serve double purpose as non-short-circuit logical operators. For example, f() != 10 && g() == 8 will not execute g() if f() returns 10 , but f() != 10 & g() == 8 will execute g() regardless of the result of f(), with the same overall logical result.

I disagree, I find this usage more common:

if( x & 3 == 0) /* looks like a check for (x modulo 4) == 0*/

& is a bit wise multiply: 0x0=0, 0x1=0, 1x0=0, 1x1=1, so in my opinion (and others), it should have the same precedence as multiply.

^ is a bitwise (finite field) add: 0+0=0, 0+1=1, 1+0=1, 1+1=0, and should have the same precedence as add (or subtract)

| should should also have the same precedence as add (or subtract)

Logical values {FALSE, TRUE}, should have been treated differently than numeric values. Typecasts should be required to treat logical values as numbers.

static

C defines static variables to be initialized to zero. If the target environment doesn't support a zero initialized segment, then static variables have to reside in a initialized data segment. This will increase program size. On a PC, not a big deal, but in embedded applications, space is important. For example:

static int abc; /* initialized to zero, may require program image space */
int xyz; /* uninitialized, normally won't use any program image space */

C provides no means to declare global values

Most linkers include this feature since they auto-generate global values (starting and ending addresses of program segements for example). This can also be done from assembly language (for Masm / ML, simply delcare an equate as public, it will show in the link map as type <absolute>). However, there's no way to do this in C.

Fortran continuation

Place a "*" in the 6th column from the left (column 6 if origin 1 editor, 5 if an origin 0 editor).
Note that C defines require \ at the end of a line for continuation.

pointers in Fortran

Although a bastardization of the language, arrary[0] was the equivalent of a pointer to array in some environments. Delare array[0], and assign array[0]=address to set the pointer, then arrray[index] would access the contents of [address+index-1]. To simplify usages, assign array[0]=address-1 (or - size of variable) so that array[index] == [address+index]

 

[oldtobor]

Hmm, I think you are confusing can't and don't want to. If you want to port EDIT to a UNIX, then go ahead. You'll probably have to learn C if you can get the original source.

If you bothered to look, you would notice a simple editor called PICO, which has many similarities to EDIT, and isn't as difficult for n00bs/fogies as vi can be at first.

- OMD

I have given up a long time ago expecting anything from linux - unix as far as editors. I learned vi. This however is a great example of the linux mindset, we can't do it or do it yourself. Now EDIT for DOS is an old simple program that has been running for years on PCs. How on Earth is it possible that they can't just create a command from any UNIX or LINUX prompt maybe called msedit that opens AN EXACT CLONE OF YOUR GOOD OLD DOS EDITOR ? Why is it so hard ?

Pico sucks (really old fashion, vi is better), and I don't want an editor that has to open in Xwindows, I just want an exact replica of EDIT for DOS!

It can't be done probably for technical reasons, explain so I can understand, maybe it has to do with the terminals, or with how information is going to the screen, I don't know.

It is the same if you try to find a simple keyboard - mouse recorder for linux - unix based GUIs, that is why you can't have something like VBA. Open source rarely progresses any software, open office sucks, and it will stay the same forever. Linux and open source has been a constant dissapointment, and yeah it is always the users fault according to the open source community.

 

[D H]

I disagree, I find this usage more common:

if( x & 3 == 0)

I hope this is a typo. As written, the then branch if the if statement is unreachable. A few parentheses will help. Since == has higher precedence that &, this is the same as
if( x & ( 3 == 0))
Since 3 == 0 is false, this is the same as
if( x & 0)
Since the bitwise and of 0 with anything is 0, this is the same as
if( 0)

If I found anyone writing code like this, I would take that person aside for a little talk.

in my opinion it ("&") should have the same precedence as multiply.

Take your complaints to the standards committee. Until then, live with the precedence rules as they exist.

My rules on precedence are simple (and since I am an old fart, my rules hold sway over a number of people):

1. parentheses
2. element operators (->, .)
3. unary operators
4. multiplicative operators
5. additive operators
6. comparison operators
7. logical operators (&&, ||)
8. assignment operators
9. when in doubt, use rule #1

I don't know and don't care whether && has precedence over || because writing a && b || c is not valid D_H C code.

C provides no means to declare global values

Of course it does: "extern".
Using extern int Foo; in a header file means that the variable "Foo" is defined elsewhere. Including that header file means you don't have to define the variable. You define it by omitting the extern. (Yech.)

Note that C defines require \ at the end of a line for continuation.

No, it does not. Yech.

 

[-Job-]

You know, this is really pointless. Why don't we all spend more time programming and less time arguing.

 

[eieio]

I disagree, I find this usage more common:

if( x & 3 == 0) /* looks like a check for (x modulo 4) == 0*/

& is a bit wise multiply: 0x0=0, 0x1=0, 1x0=0, 1x1=1, so in my opinion (and others), it should have the same precedence as multiply.

I do see the point you are trying to make. However, like I said before, the bitwise operators are also used for non-short-circuit logical operations, which mandates the precedence they have.

And although you may feel like you example is the common case, it really isn't. If you feel up to it, grab any version of any open source operating system or other large C project, and do a regular expression search for all expressions using & and then all expressions using both & and ==. You will find that the vast majority of the expressions will not fit your pattern usage. In fact, bit masking within a conditional is most common, followed by non-short-circuit logical operations.

^ is a bitwise (finite field) add: 0+0=0, 0+1=1, 1+0=1, 1+1=0, and should have the same precedence as add (or subtract)

| should should also have the same precedence as add (or subtract)

That is purely a matter of opinion, which is fine. Most people that do a lot of development in C/C++ perfer the current precedence. Patterns like "(x & 3) == 0" just aren't frequent enough to be worried about having to type some parens.

Logical values {FALSE, TRUE}, should have been treated differently than numeric values. Typecasts should be required to treat logical values as numbers.

That's pure nonsense. As I demonstrated in the bitmask test ("is the device ready or pending"), false == 0 is completely sufficient and even an advantage to concise expression. These kinds of tests happen all of the time--you can use a similar test to above to see this--and it would be quite cumbersome to cast every single bitmask compare. In fact, that's one of the things makes Java so cumbersome for any kind of hardware related development.

C defines static variables to be initialized to zero. If the target environment doesn't support a zero initialized segment, then static variables have to reside in a initialized data segment. This will increase program size. On a PC, not a big deal, but in embedded applications, space is important. For example:

static int abc; /* initialized to zero, may require program image space */
int xyz; /* uninitialized, normally won't use any program image space */

That's not precisely true. Uninitialized globals typically reside in the zero initialized data segment of the image, regardless of wheather they are static or not. Your variable xyz may or may not use image space, depending on if the environment supports uninitialized sections, just like abc.

The behavior can be modified to varying degrees in most compilers, but this is the default behavior for most contemporary compilers.

- OMD

 

[eieio]

I have given up a long time ago expecting anything from linux - unix as far as editors. I learned vi. This however is a great example of the linux mindset, we can't do it or do it yourself.

That's actually a very human mindset. No one wants to port an ill featured editor to Linux for you. There's no benefit for them, since there are perfectly fine editors available. Perhaps if you paid someone, they would port EDIT for you, but you really can't expect something for nothing. People contribute to open source software because they have some interest in what they are producing. No one is interested in EDIT but you, which is why I suggested that you do it.

Now EDIT for DOS is an old simple program that has been running for years on PCs. How on Earth is it possible that they can't just create a command from any UNIX or LINUX prompt maybe called msedit that opens AN EXACT CLONE OF YOUR GOOD OLD DOS EDITOR ? Why is it so hard ?

It has nothing to do with it being hard, it's actually very possible to do. But the point you seem to be unable to grasp it that no one cares to provide EDIT. I've noticed that you have a pattern of coming to the conclusion that people are unable to do something, when they simply don't want to.

Pico sucks (really old fashion, vi is better), and I don't want an editor that has to open in Xwindows, I just want an exact replica of EDIT for DOS!

Hey, it was just a suggestion. And by they way, EMACS can run in a terminal as well as in a window under X.

It can't be done probably for technical reasons, explain so I can understand, maybe it has to do with the terminals, or with how information is going to the screen, I don't know.

Again, it can be done, but no one wants to. You seem to want it a lot though, so maybe you should look into it. It might even be fun for you.

Open source rarely progresses any software, open office sucks, and it will stay the same forever. Linux and open source has been a constant dissapointment, and yeah it is always the users fault according to the open source community.

Well, in one sense you are right, open source is not the answer for everything. But it has produced some very useful projects, especially a large volume of libraries that can benefit everyone's development.

Opinions are fine, if you can keep then in check and not treat them like fact that everyone else should believe and follow. I don't particularly care for Open Office myself. I like MS Word, personally. But I'm not going to bash someone for liking Open Office or thinking that it's good. I will, however, call someone out for making biased assertions or stating incorrect facts to promote their opinions.

I think you would get more positive responses if you tried a more genial approach to things. If you said something like "man, I wish there was something more familiar to me, like EDIT, on Linux. That would be great." You might be surprised, someone might just decide to do it for you; maybe someone wanting to get familiar with the curses library, as an exercise. However, you can't just badmouth things and then expect people to be ready and willing to implement your ideas/requests.

- OMD

 

[chroot]

EDIT on Linux would be what, fewer than 1k lines of curses? It'd be almost trivial.

But EDIT doesn't have syntax highlighting, automatic tabbing, multiple-file searching, or any of the other features that people really want in a text editor; this is why no one has ever bothered to port it to Unix/curses. If all you want is to be able to move the cursor around with the arrow keys, then use pico and get on with your life. Pico is almost exactly the same as EDIT.

- Warren

 

[oldtobor]

Why is it so hard to create an exact clone of EDIT from a unix - linux prompt ? I am sure that there must be some technical reason, maybe the terminals or the way the information goes to the screen, but an EDIT program should be relatively simple for an open source programmer to write, since they are writing operating system software, but I am sure there is a real technical reason. Please explain, because the EDIT program is very simple and convenient.

But what really intrigues me is that there must be some real, technical, fundamental limit of the unix architecture that prevents the creation of a simple program like DOS EDIT from the prompt. It is only 70k under windows (dos) and is a very simple straightforward program. I find it really mysterious that after more than 10 years no one in the unix or linux OSS community of programmers could create an exact replica.

I am absolutely convinced that it cannot be done. It is a simple program that would be handy to many people. There must be some real architectural reason. If you say the entire UNIX and LINUX community in 20 years, millions of people all decide no, it is forbidden to have EDIT, I truly cannot believe that. People are pragmatic, want to get things done fast, have problems to solve, EDIT would be just another quick simple tool you can use.

The funny thing is that the unix philosophy is all about small simple programs that can get a simple job done fast, like grep or awk etc. So it is perfectly within the spirit of unix or linux. Now there are more powerful choices, but in many cases, small scripts, you just don't need the power. After all grep for example finds patterns quickly and easily. There are more powerful database programs, obviously, but for something quick and simple grep is ok.

If on the other hand you are right, no one wants it, it will never be done, then that is a good example of what you can expect from the open source community in the future. They will make thousands of arcane programs and languages, but simple things that any person could appreciate and use like EDIT for DOS, or ACCESS or similar simply will never be done.

It is as if thousands of programmers have exactly the same mind set, the exact same opinions and tastes in everything. Like a religion or as if they were brainwashed against anything even remotely similar to anything PC or windows. Then why are they trying so hard to make the windows emulator WINE ?

 

[chroot]

You're an idiot, oldtobor. Why do you keep repeating things? Are you here for discussion, or just to rant about incoherent nonsense? You think there's something fundamental about Unix operating system that precludes the development of a goddamn trivial text editor? There are many editors for Unix that are so similar to EDIT that there's no reason to write another one! Look at pico. LOOK AT PICO. LOOK AT PICO.

What exactly about pico do you not like?!?

- Warren

 

[rcgldr]

if( x & ( 3 == 0))

As written, the then branch if the if statement is unreachable.

That was my point, it wouldn't work unless C treated the precedence of & the same as *, which it doesn't. My point about the precedence is that &, ^, and | are math operators, and should have been given the same precedence as the other math operators, but that's not the way the C language was defined.

C provides no means to declare global values

Of course it does: "extern". Using "extern int Foo;" ...

Note, I posted global "values", not global "variables". For example, how would you decleare "abc" in this case "#define abc 0x12345"? This is easily done in assembler as prevously posted (public abc ... abc EQU 012345h). One example usage is to implement the equivalent of "sizeof(relocatable function)".

Note that C defines require \ at the end of a line for continuation.

No, it does not.

Yes it does, note I'm referring to "defines", for example, large macros, \ is required to extend a #define across multiple lines.

C defines static variables to be initialized to zero. ... occupies space

That's not precisely true.

Microsoft reference:

When modifying a variable, the static keyword specifies that the variable has static duration (it is allocated when the program begins and deallocated when the program ends) and initializes it to 0 unless another value is specified.

Uninitialized globals typically reside in the zero initialized data segment of the image.

Most wintel environments don't include a zero initialized segment, thus statics end up in the .data segment, and non-initialized variables in the .bss segment.

For the ARM (a risc processor environment, it's not an issue as all zero initialized variables are placed at the end of the .data segment, and the linker defines global values for "end of normal initialized .data / start of zero initialized .data" and "end of zero initialized data" for the start up routine to zero out. It also generates global values to allow code and data relocation for embedded environments.

vi

My main complaint about vi derivatives is that they have to be toggled in and out of text insert / command mode. I prefer using some key sequence to generate commands. I find generic editors like codewright much easier to use (I use it in CUA mode).

getting back on topic

As previously posted, C is a mid-level language, between assembler and true high-end languages. It doesn't include exponentiation, and requires a call. Conversion of mathematical algorithms to C is a pain compared to Fortan, or MatLab. Cobol still has it's place in dealing with database (field oriented) environments on mainframes. Oracle and other SQL languages are also good for database environments. Not all software problems were solved in the 1980's on a PC. Some problems were solved long before that, and some problems were solved more recently.

 

[eieio]

Most wintel environments don't include a zero initialized segment, thus statics end up in the .data segment, and non-initialized variables in the .bss segment.

This is also incorrect. The .bss section IS the uninitialized data section. This section has the IMAGE_SCN_CNT_UNINITIALIZED_DATA bit set in the Characteristics field of the section header. I've implemented PE-COFF executable loaders and object file linkers on several platforms. Here's the official spec, if you're interested: http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
Check out around page 18.

In any case, both globals that are explicitly initialized to zero and uninitialized globals end up there, not in the .data section, unless you specifically override it (__attribute__ ((__section__ (".data"))), in GCC for instance). Furthermore, the zeroing of the section is usually performed as the executable is mapped into the process, and is either part of the loader or an effect of creating a private mapping of the zero page, or similar VM operation.

I haven't done much work with ARM, but the platform doesn't really matter per se, as it is the executable format that provides such features. Most operating systems that run on ARM use ELF, which follows the same general scheme as the PE-COFF description above.

I'm curious about your microsoft reference; you didn't cite it, but it looks like a rather generic functional description of what happens, not actually what happens. Maybe if you provide a citation, I can show you why it's not as definitive as you believe.

- OMD

 

[DaveC426913]

None of it will be maintained forever, it will all be discarded and replaced by new, more capable code.

That's the second(*) biggest mistake in the history of the business.

The whole Y2K thing happened because no rational programmer thought their code could possibly live for 2 or 3 decades.

And yet banks are still running their COBOL applications from the 80s.



(*second only to Bill Gates' gaff of legend)

 

[NoTime]

That's the second(*) biggest mistake in the history of the business.

The whole Y2K thing happened because no rational programmer thought their code could possibly live for 2 or 3 decades.

And yet banks are still running their COBOL applications from the 80s.

(*second only to Bill Gates' gaff of legend)

To both.
Did you know there was a year 10 issue?
Initially they started with 1 digit year

There was a good reason for doing so though.
The first machine I wrote code for had 20k of memory.
That was huge.
It came out of the box with 4k of real core memory.
Little ferrite donuts strung in a wire matrix.

You spent a lot of time trying to scare up a free bit or two somewhere.
Allocating an entire 16 bits for '19' was simply out of the question.

When BG came out with the 640k comment, the multitasking mainframes had just become available with 1 meg memory just a few years prior.
'Only Six computers will ever be sold in the commercial market'
Howard Aiken (The designer of the first IBM computer)


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.

 

[rcgldr]

Most wintel environments don't include a zero initialized segment, thus statics end up in the .data segment, and non-initialized variables in the .bss segment.

This is also incorrect. The .bss section is the uninitialized data section.

I specifically mentioned a zero initialized section, not an unitialized section. However, it appears that the Wintel environment does zero all of the .bss segment. I also discovered that unitialized global variables ended up in the .data segment. In debug builds, the stack is initialized to 0xcccccccc, so local unitialized variables will be set to "c...c", in release builds I assume that no initialization is done.

In any case, both globals that are explicitly initialized to zero and uninitialized globals end up there, not in the .data section

I just tested this with Visual Studio 2005. A static variable ends up in the .bss section if there's no initializer, or it ends up in the .data segment if there is an initializer. As mentioned, I was suprised to find that an uninitialized global variable ended up in the .data segement and set to zero.

The platform doesn't really matter per se, as it is the executable format that provides such features.

Well the linker has to generate global values for a startup program to know what sections need to be zeroed out, or the executable format will need to include all of the .data / .bss sections, including the zeroed out section. I read the document you linked to and in section 5.1, it states that zero only sections images don't have to be included in the object file, which implies the startup routine clears these sections.

As mentioned, the Wintel environment appears to zero out all of .bss section. In the Arm environment, only a portion of the .bss segment is zeroed out, with the remainder remaining truly unitialized, which I assume is to reduce the execution time. Global values are generated by the linker, that indicate the location and size of the zero initialized logical segment which is the first part of the .bss segment.

I'm curious about your microsoft reference

It's from Visual Studio 2005, click on help, search for static, then click on C/C++ link and you get this: http://jeffareid.net/misc/static.jpg .

When BG came out with the 640k comment, the multitasking mainframes had just become available with 1 meg memory just a few years prior.

Back in 1986, when Atari came out with the 68000 based ST1024 system with 1 meg of memory for under $1000, I and other programmer / engineers asked how long it would be before people started commenting, you only have 1 meg of memory in your computer. Eventually the Atari series reached 4MB of ram before it sold off it's computer division to a European company, the only place where sales were still reasonable. The point here is that a lot of engineers realized that home computer memory sizes were going to continue to grow.

Regarding memory sizes on mainframes, high end IBM 360's and 370's had 1MB or more of memory during the 1960's and 1970's. By 1985, a Cray 2 super computer had 512MB of memory.

 

[oldtobor]

You're an idiot, oldtobor. Why do you keep repeating things? Are you here for discussion, or just to rant about incoherent nonsense? You think there's something fundamental about Unix operating system that precludes the development of a goddamn trivial text editor? There are many editors for Unix that are so similar to EDIT that there's no reason to write another one! Look at pico. LOOK AT PICO. LOOK AT PICO.

What exactly about pico do you not like?!?

- Warren

I downloaded and tried a PICO for DOS version. It is not too bad, better than vi, at least simpler. The question ws about an exact replica of DOS, but I think I found out why. During the late 80s, early 90s there were many full screen DOS programs around, but the unix environment was very separated from the PC users (unix being very high end professional). You could more easily find unix utilities (like awk already in 1989 by polytron) ported to DOS than vice versa. It was like someone asking to port DOS basic to IBM MVS, it didn't make sense. Then came windows gui and then linux. 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 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.

 

[NoTime]

Regarding memory sizes on mainframes, high end IBM 360's and 370's had 1MB or more of memory during the 1960's and 1970's. By 1985, a Cray 2 super computer had 512MB of memory.

The IBM 360 was constrained to a max of 64k memory.
In the company I worked for, we had 5 370's, the biggest was 512k until 78 when they upgraded to a meg.
I think they did it to support TCAM the predecessor to VTAM.
The IBM 370 was constrained to 268 meg until around 84 when they came out with XA.
That was a PITA due to all the software that had used the upper 4 bits of the address to pass flags.

 

[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.