Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Win16 Memory Management

os2museum.com

Post reply on HN
Print view View original

11–20 of 86 posts

Re: Win16 Memory Management

#11

Post by trumpdong »

GordonS wrote: post #5
kev009 wrote: post #3

Earlier quoted context omitted.

Attention spans were longer.

I've been wondering about this lately. As a kid, I spent hour upon hour learning about computing: typing in Basic code from a magazine into a Commodore 64, playing with music on an Atari STe, learning my way around a DOS command line, dabbling with 3D modelling... just so much stuff that my own kids would never have the patience for. I wonder if it's just that kids today (gods that makes me sound old!) are constantly…

I think it's an adaptation. Instead of living in a world with limited valuable information we're now living at the end of a firehose of never-ending near-useless information which has to be filtered at high speed.

Re: Win16 Memory Management

#12

Post by senfiaj »

barrkel wrote: post #10
hnlmorg wrote: post #4

Earlier quoted context omitted.

16 bit programs used 16 bit addresses, generally speaking. Even with 32bit systems where you’d want more than 4GB RAM, application software still had 32 bit addresses (and thus 4GB memory limit). I think it was a lot more common for 8bit systems to allow for 16 bit addressing though. It’s been a while though. So hopefully I’m not misremembering things.

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.

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

Re: Win16 Memory Management

#13

Post by bananaflag »

jdw64 wrote: post #2

Sometimes I think that if it were the old days, I probably wouldn't have been able to program. I remember that these days we program on top of 64bit virtual addresses, but how did developers do it back then

I first found out about segmenting in 16 bit systems in 2016 by reading a lively explanation from an older edition of Duntemann's Assembly Language Step by Step (the newer editions focus largely on Linux and 32/64-bit systems).

Re: Win16 Memory Management

#14

Post by bitwize »

jdw64 wrote: post #2

Sometimes I think that if it were the old days, I probably wouldn't have been able to program. I remember that these days we program on top of 64bit virtual addresses, but how did developers do it back then

16-bit x86 processors took 20-bit pointers, expressed as a 16-bit segment and a 16-bit offset. The segment was shifted four bits left and then the offset added. Which means there are lots of different segment:offset pointers that point to the same address. Segments are loaded into a segment register (one of CS, DS, ES, or SS) and then combined with an offset pointer in another register to create a pointer in this way. For example, 1e37:0008 would become 1e378.

It's complicated and janky as all get-out, but it made more sense if you were coming from 8080/Z80 development, as this was a scheme to ensure some degree of compatibility with 16-bit 8080 addressing while providing access to much more memory. 8086 was not binary compatible with 8080, but was designed so that 8080 programs could be machine converted to 8086 ones.

In languages like C, this took the form of three different types of pointers: NEAR, FAR, and HUGE. NEAR pointers were 16-bit offsets only, and dereferenced with respect to the current segment (usually in DS). FAR pointers were full segment:offset pairs but pointer arithmetic was only done on the offset which meant objects could be 64K max. HUGE pointers allowed for objects larger than 64k but at a significant performance cost.

Re: Win16 Memory Management

#16

Post by andyjohnson0 »

hnlmorg wrote: post #4
jdw64 wrote: post #2

Sometimes I think that if it were the old days, I probably wouldn't have been able to program. I remember that these days we program on top of 64bit virtual addresses, but how did developers do it back then

16 bit programs used 16 bit addresses, generally speaking. Even with 32bit systems where you’d want more than 4GB RAM, application software still had 32 bit addresses (and thus 4GB memory limit). I think it was a lot more common for 8bit systems to allow for 16 bit addressing though. It’s been a while though. So hopefully I’m not misremembering things.

> I think it was a lot more common for 8bit systems to allow for 16 bit addressing though.

The 6502 and Z80 could use 16 bit addressing to access up to 64kb of memory. The 6502 had various other addressing systems, including iirc 8 bits, but none of them were wider tha 16 bits.

Re: Win16 Memory Management

#17

Post by JdeBP »

andyjohnson0 wrote: post #16
hnlmorg wrote: post #4

Earlier quoted context omitted.

16 bit programs used 16 bit addresses, generally speaking. Even with 32bit systems where you’d want more than 4GB RAM, application software still had 32 bit addresses (and thus 4GB memory limit). I think it was a lot more common for 8bit systems to allow for 16 bit addressing though. It’s been a while though. So hopefully I’m not misremembering things.

> I think it was a lot more common for 8bit systems to allow for 16 bit addressing though. The 6502 and Z80 could use 16 bit addressing to access up to 64kb of memory. The 6502 had various other addressing systems, including iirc 8 bits, but none of them were wider tha 16 bits.

Psst! Let's blow their minds and tell them about the MC68008. (-:

Re: Win16 Memory Management

#19

Post by lloydatkinson »

atan2 wrote: post #18

I posted the same thing a few days ago: https://news.ycombinator.com/item?id=48424862 I'll just stop posting on HN.

I've had this experience a few times so I don't post submissions anymore either (including one of my own articles being flagged despite over a hundred comments). I know people will say vote rigging doesn't happen on HN, but I think it's naïve to think any site on the internet is impervious to vote rigging.

Re: Win16 Memory Management

#20

Post by atan2 »

lloydatkinson wrote: post #19
atan2 wrote: post #18

I posted the same thing a few days ago: https://news.ycombinator.com/item?id=48424862 I'll just stop posting on HN.

I've had this experience a few times so I don't post submissions anymore either (including one of my own articles being flagged despite over a hundred comments). I know people will say vote rigging doesn't happen on HN, but I think it's naïve to think any site on the internet is impervious to vote rigging.

This has happened at least 4 times to my posts just last month.
Post reply on HN