[barrkel]

You had to deal with two flavors of pointer, near and far. Far pointers came with segment selector, for accessing more than 64k. Your choice of memory model influenced the defaults. You might use near pointers for internal references in a module, and far pointers for external references.

[senfiaj]

I guess it was awkward to use languages that had higher level than assembly in order to write 16-bit programs that required more than 64KiB of memory. And also not quite portable, since they were all tied to x86 CPU. Those were messy times I guess. A somewhat similar story was 32-bit PAE, where the the CPU could address more than 4GiB physical memory, but software was still 32-bit and virtual addresses were capped at 4GiB. Linus was right that you must have more virtual memory (preferably 10+ times more) than physical, otherwise you have to jump through hoops. https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-ab...

[trumpdong]

"portable" used to mean "able to be ported" rather than the "comes automatically ported if you just change compiler options" that it means today

[hnlmorg]

All software is portable by that former definition.

When people talked about portable before, they meant code that used an abstraction that was platform agnostic. And that’s how it’s still used today. It’s just we have better abstractions now so our expectations of what is “portable” have gotten stricter.

Eg the P in POSIX (which is nearly 40 years old now) is “portable”. The point of POSIX was to provide common abstractions that one could build against to run on multiple different operating systems. It wasn’t about porting software, it was about preventing people from needing to constantly write platform-specific ports.

[trumpdong]

It was about making software easier to port. You still couldn't necessarily just write software for all operating systems at once, but you had less porting work because less stuff was different because of the standardisation. So open(argv[1], O_RDONLY) works on all POSIX systems, but if you want to create a pseudoterminal, it's different on each, and if you want to create a container, they don't even use the same concepts.

[skissane]

> but if you want to create a pseudoterminal, it's different on each

This is somewhat outdated information. POSIX.1-2001 added "posix_openpt" to create a pseudoterminal, and most POSIX implementations now support it–at least Linux, macOS, FreeBSD, NetBSD, OpenBSD, Solaris, z/OS, AIX, HP-UX, QNX, Minix and Cygwin do. (Of course, that's only true of current versions, if you go back a decade or more you'll find many of them hadn't implemented it yet.)

[hnlmorg]

But you’re now arguing the same point I am: Portable means low effort porting.

Saying something “can” be ported doesn’t make it portable. People would port games from the NES to the Master System, to 8 bit Micros but in most cases they were effectively complete rewrites because there wasn’t any common abstractions between those platforms.

Where as tools like POSIX provided abstractions to make code portable.

As I said before, the only reason you think the term has changed over the years is because the abstractions have gotten better and thus people’s expectations for how much effort should be required to port have gotten stricter. But that doesn’t mean the term means something totally new.

And by the way, I have authored portable terminal emulators and $SHELLs. ;)