OT: American's are yellow-bellied pansies...

And most of these are due to the missing of any decent string data type in C. It is nearly as bad as standard FORTRAN IV with libraries (of course without the Hollerith constants) but much worse than Fortran 77 string handling.

And while there was some hardware primitives, these were not used.

Lack of proper string type and some shortcuts in library definitions.

While this is true for a writer of a program loader, but how often do you need such features ?

Even by hiring some people from the minicomputer area, they would have been able to tell the worst pitfalls, without significantly hurting the appeal for their system.

VAX/VMS had a proper R/W/E protection for each virtual memory page.

PDP-11/RSX-11M+ could use I and D spaces separately and having good separation (in line parameters did not work with separate I/D space). There was no concept of stack space, since 7 general purpose registers could be used as stack pointers. Some languages (Fortran) put the SP based stacks below 01000, while stack oriented languages (such as Pascal) usually but the stack below 0177777 or if the last page was mapped to I/O devices, below 0157777.

On PDP-11/RSX-11M there was only 8 "segments" each up to 8 KiB, which could have different attributes. Putting the stack at the top and leaving some empty space between the code and stack segment, made it possible to trap a stack overflow before a stack overflow wrote on the code.

I do not understand, what the problem is here ?

In a system with a concept of user and kernel space, why not limit code space writing to kernel mode ?

As far as I understand, in all virtual memory system, the program is loaded by letting it cause page faults starting by the first instruction executed to load pages on demand. This virtual memory handling is handled in kernel mode.

One problem is that C passes args and code pointers and such on the stack. It seems to me that one could write a C compiler that physically segregates data, stack, and code, even in a linear address space... but apparently nobody does.

Dynamic code loads, like DLLs, make it a bit harder.

Given the billions, or trillions, of dollars being lost, it's outrageous that Intel and Microsoft allow things to be this bad. Which means, one of these days, they will go the way of RCA and Kodak.

Every time I load a program :)

M$ hired people from the VMS team to write NT. And here we still are.

You know that. I know that. If we were in a room with a large number of people in that industry at the time, we'd be pretty much alone in that knowledge.

One of the really important things about the microcomputer revolution was that it left the "experts" behind. People did deeply ignorant ( in the good sense of the word ) things that just worked out. It was about what you could *do*, not all the details. This goes back to Wozniak using side effects of parts available at the time to get certain ... performances out of the original Apple I.

It's hackerism of the finest kind.

I read a few years back that the neckbeards of Linux multimedia were still trying to decide what the "atoms" of multimedia are - a non-trivial thing to be sure. But my rickety Win95 machine "knew" what multimedia was 20ish years ago. This is not a shot at the Linux guys - it's just messy.

I have this unfortunate habit of comparing other technological evolution paths with ... weapons. We all seem to want to be creators of fine English fowling pieces, but it's those who make the AK-47s that change the world.

You could use existing 'C' compilers to ( possibly) do this. I am pretty sure GreenHills does this and GNU could be configured to do it.

Will that work on existing O/S distributions? Most likely *not*.

Yes, although loaders have to "be congruent with" linkers and compilers. DLLs are just a mild mixing of the function of linker and loader.

Phhhhffft. Rot. Computer security is not quite trivial, but it's definitely common sense - DON'T HAVE AN INNERNET CONNECTION TO IT!

If you do have to get stuff on/off the internet, just be *careful*. Consider anything connected as infected. I keep "burner" VMs for that here. I do connect my main machine but that is only used for software updates from trusted sources, browsing trusted sources , email and Usenet. Anything I don't *know* to be safe is done in a "burner" VM with tools that have proven to be less likely to be threat vectors. After a span of time, the source is upgraded to "trusted".

The only time I ever had to rebuild a machine from scratch because of an infection, it was that rootkit from a Sony CD. And that was well before I started using VMs.

"Allow"? Both organizations have been based on rabid paranoia about the marketplace. They "allowed" nothing; it was all done with only the least they could do to enable it.

Was Internet security the primary thing you bought a computer based on last time? I'll wager not.

As will all such. Schumpeter waits for us all.

In Fortran, all parameters were passed by reference (pointer), thus, if you write

J = IFOO(5)

The constant 5 is stored in the callers space and a pointer to five is used in the call.

Assuming the calling function is declared as

SUBROUTINE IFOO(I) I = I+1

On every call, the constant 5 is overwritten, so J would contain a increasing number.

In the 1970's RSX-11M+ did exactly that (except for stack separation, which did not make any sense on that architecture anyway).

x86 DLL loading is a bit complicated with various code and data fixups, but still could have been done in a secure way at least in kernel mode.

The problem seems to be that the microprocessor based system performance grew so fast that there simply were not enough people to hire with multiuser (mini)computer experience.

Program loading is done by the OS behalf of you.

Windows NT 3.1 (and later 3.51) were good systems that I liked. Unfortunately MS was faced with the grim task to interface with windows 3.11 WfG, taking something into Win95. The integration process continued at least WIN2000.

As a conscript, I have been carrying an AK-47 copy for nearly a year, and I would absolutely select for combat a real AK-47 instead of the copies or similar US assault rifles, simply due to the AK-47 reliability in dirty conditions.

They need a separate fiber optic network for the infrastructure, that isn't connected to the public internet at any point.

Would you use either of them today? The Commodore 64 had the OS in ROM. There was nothing to infect. Who uses them today?