Pretty good detail in this article! But what really surprises me is how some ideas just keep coming back.
When I wrote a binary translator, I ended up having to keep a translated return stack to optimize RET opcodes. That put me in exactly the same position as the Win16 kernel with regard to having to patch pointers (in case of Win16, just the segment part) on stack.
Of course I did not have the benefit of my guests calling a lock function, so I ended up having to run a garbage collection operation to determine which pointers are in use & take exceptions on now-invalidated segments. Lots of extra work that Windows didn't need: it's nice to be king :-)
> Exports are used for application code which is externally called.
This was the magic moment for me, learning Windows 3.0 programming. The idea that my program is no longer master of it's world, but instead is just something that gets loaded and called by Windows.
I've been recently working with Classic Mac OS programming[0] and just that memory model (also using dealing with the lack of virtual memory using opaque handles to memory that need to be locked when used) is painful enough[1] - having to deal with segment addressing on top of that does not sound like fun. Thank god for the Motorola 68000!
[1]The equivalent to HeapWalker I used was Metroweks ZoneRanger which was bundled with their compiler. It has a nice visualization of how fragmented the memory is https://bitbang.social/@kalleboo/116302075194704555
It wasn't really the processor architecture. Segmented addressing was actually fairly easy if the processor was used only in the way that protected mode was envisioned as working. As the headlined article observes, a lot of this stuff simply wasn't necessary in OS/2 1.x, even though that too had DLLs, callback window procedures, and the multiple tiny/small/medium/large/compact/huge memory models.
The differences were (a) that DOS+Windows was designed so that the same programs could run in both real mode, with overlaying, and 286 protected mode, with segmented virtual memory; and (b) that to really save on RAM DOS+Windows had ideas such as the data segments for DLLs being globally shared across all processes. These added all of the complications mentioned in the headlined article and more besides. It was the operating system, not the processor architecture.
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'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 surrounded by entertaining things to do - gaming, TV/films, music, social media.
Thats correct - and I notice that on myself. There are just much more things reachable at any point in time compared to our youth it takes real effort to focus.
I think that's actually a pretty accurate observation. I'm not a cognitive science expert, so I don't know the details, but there have been articles about 'popcorn brain' due to sustained attention issues, right? Personally, I use LLMs for coding quite often (in my environment, I'm often forced to use them). Compared to the past, when I use an LLM, the answers come immediately, so it seems harder to focus deeply than before. The generation younger than me, which is more focused on Shorts, probably has it even worse
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.
I have been shielding my 6 years old son from electronics, except 40 minutes of TV twice a week. I have no idea how to grow his patience and perseverance, though. He is like me, who doesn't have a lot of patience to begin with, so I can't really guide him through some of the situations. We have been taking him to some activities as well as reading to him but nothing really sticks.
I just hope eventually he loves reading and learns in a more traditional way instead of from laptops and pads.
We struggled to get our son into reading too, but he took straight away to comics, and from there he had a long stint with graphic novels (e.g. Percy Jackson, Artemis Fowl). You can get more mature graphic novels as they mature and progress, e.g. City of Dragons. And eventually he picked up an Alex Rider book, and hasn't stopped since. He's now how I remember myself as a kid - nose stuck in a book, completely engrossed!
I have been wondering how to train my 6-year old son and myself to increase my attention span.
Some rules are obvious -- cutoff mobiles and pads completely (he doesn't have access to them so it's for me), sit in the library and study from books (I believe this is even possible for programming topics as I can write on paper). Basically, cutting off everything electronics definitely helps -- even putting my phone in the bag improves productivity significantly.
But the problem is, my son is unruly. If I put him in the library, most likely he runs around and messes things up, which ends up we leave early without doing anything.
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...
> 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.
I think they learned by reading books such as Undocumented Windows or Windows Internals (not to be confused with Windows NT internals), and Microsoft documents.
In fact, I’d argue it was more fun than programming Javascript these days.
It wasn't really the 'Undocumented' and 'Internals' books. Pretty much everything in the headlined article was to be found in the SDK, Microsoft Press publications, and in many third party books about DOS+Windows programming.
Petzold's Programming Windows book, for example, devoted an entire chapter (chapter 7) to memory management, with diagrams and examples. In the 2nd edition (which I just pulled off the shelf to check) that chapter runs to some 40 pages.
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).
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.
As someone who grew up coding after it was mostly 32-bit, I can't say this with certainty, but my gut feeling is that paradoxically you would have and it would've made you stronger.
Exactly. I'd argue that all those programming Gods and Gods because they went through that period. Whatever didn't kill them made them stronger. We should replicate that experience by deliberately writing in low level C and assembly for a few years.
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.
Check the ID numbers (48410844 < 48424862) and bear in mind that Hacker News has this thing where sometimes submissions get re-cycled for attention. Yes, annoyingly it does seem to make the presented datestamps wrong.
People submit a lot of stuff all the time, very few people go through "New" and thus a new submission probably have a very short life time before it is drowned by newer submissions.
A submission to survive most likely needs some initial push from non-organic voting.
It probably helps if you share you submission early with your colleagues and in other sites.
Pretty good detail in this article! But what really surprises me is how some ideas just keep coming back.
When I wrote a binary translator, I ended up having to keep a translated return stack to optimize RET opcodes. That put me in exactly the same position as the Win16 kernel with regard to having to patch pointers (in case of Win16, just the segment part) on stack.
Of course I did not have the benefit of my guests calling a lock function, so I ended up having to run a garbage collection operation to determine which pointers are in use & take exceptions on now-invalidated segments. Lots of extra work that Windows didn't need: it's nice to be king :-)
> Exports are used for application code which is externally called.
This was the magic moment for me, learning Windows 3.0 programming. The idea that my program is no longer master of it's world, but instead is just something that gets loaded and called by Windows.
I've been recently working with Classic Mac OS programming[0] and just that memory model (also using dealing with the lack of virtual memory using opaque handles to memory that need to be locked when used) is painful enough[1] - having to deal with segment addressing on top of that does not sound like fun. Thank god for the Motorola 68000!
[0]Made an AppleTalk chat client/server https://github.com/kalleboo/GlobalTalk-Chat
[1]The equivalent to HeapWalker I used was Metroweks ZoneRanger which was bundled with their compiler. It has a nice visualization of how fragmented the memory is https://bitbang.social/@kalleboo/116302075194704555
It wasn't really the processor architecture. Segmented addressing was actually fairly easy if the processor was used only in the way that protected mode was envisioned as working. As the headlined article observes, a lot of this stuff simply wasn't necessary in OS/2 1.x, even though that too had DLLs, callback window procedures, and the multiple tiny/small/medium/large/compact/huge memory models.
The differences were (a) that DOS+Windows was designed so that the same programs could run in both real mode, with overlaying, and 286 protected mode, with segmented virtual memory; and (b) that to really save on RAM DOS+Windows had ideas such as the data segments for DLLs being globally shared across all processes. These added all of the complications mentioned in the headlined article and more besides. It was the operating system, not the processor architecture.
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
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 surrounded by entertaining things to do - gaming, TV/films, music, social media.
Thats correct - and I notice that on myself. There are just much more things reachable at any point in time compared to our youth it takes real effort to focus.
I think that's actually a pretty accurate observation. I'm not a cognitive science expert, so I don't know the details, but there have been articles about 'popcorn brain' due to sustained attention issues, right? Personally, I use LLMs for coding quite often (in my environment, I'm often forced to use them). Compared to the past, when I use an LLM, the answers come immediately, so it seems harder to focus deeply than before. The generation younger than me, which is more focused on Shorts, probably has it even worse
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.
I have been shielding my 6 years old son from electronics, except 40 minutes of TV twice a week. I have no idea how to grow his patience and perseverance, though. He is like me, who doesn't have a lot of patience to begin with, so I can't really guide him through some of the situations. We have been taking him to some activities as well as reading to him but nothing really sticks.
I just hope eventually he loves reading and learns in a more traditional way instead of from laptops and pads.
We struggled to get our son into reading too, but he took straight away to comics, and from there he had a long stint with graphic novels (e.g. Percy Jackson, Artemis Fowl). You can get more mature graphic novels as they mature and progress, e.g. City of Dragons. And eventually he picked up an Alex Rider book, and hasn't stopped since. He's now how I remember myself as a kid - nose stuck in a book, completely engrossed!
I have been wondering how to train my 6-year old son and myself to increase my attention span.
Some rules are obvious -- cutoff mobiles and pads completely (he doesn't have access to them so it's for me), sit in the library and study from books (I believe this is even possible for programming topics as I can write on paper). Basically, cutting off everything electronics definitely helps -- even putting my phone in the bag improves productivity significantly.
But the problem is, my son is unruly. If I put him in the library, most likely he runs around and messes things up, which ends up we leave early without doing anything.
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...
> 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. (-:
Oh yeah. I had loads of 6502 and Z80 systems (still do in fact). Can’t believe I forgot about that!
Though in fairness, I do mostly now just use those systems to teach my kids BASIC
Not really. 16-bit programs on x86 used 32-bit pointers (effectively 20-bit due to the segment mechanism).
8-bit microprocessors used 16-bit addresses.
I think they learned by reading books such as Undocumented Windows or Windows Internals (not to be confused with Windows NT internals), and Microsoft documents.
In fact, I’d argue it was more fun than programming Javascript these days.
It wasn't really the 'Undocumented' and 'Internals' books. Pretty much everything in the headlined article was to be found in the SDK, Microsoft Press publications, and in many third party books about DOS+Windows programming.
Petzold's Programming Windows book, for example, devoted an entire chapter (chapter 7) to memory management, with diagrams and examples. In the 2nd edition (which I just pulled off the shelf to check) that chapter runs to some 40 pages.
You had to figure out so much on your own back then - and reinvent the wheel.
For me it is fascinating how today I can learn a foreign language, or how to code by interacting with the LLM.
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).
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.
As someone who grew up coding after it was mostly 32-bit, I can't say this with certainty, but my gut feeling is that paradoxically you would have and it would've made you stronger.
Exactly. I'd argue that all those programming Gods and Gods because they went through that period. Whatever didn't kill them made them stronger. We should replicate that experience by deliberately writing in low level C and assembly for a few years.
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.
Check the ID numbers (48410844 < 48424862) and bear in mind that Hacker News has this thing where sometimes submissions get re-cycled for attention. Yes, annoyingly it does seem to make the presented datestamps wrong.
I think it's just bad timing.
It is always a matter of luck.
People submit a lot of stuff all the time, very few people go through "New" and thus a new submission probably have a very short life time before it is drowned by newer submissions.
A submission to survive most likely needs some initial push from non-organic voting.
It probably helps if you share you submission early with your colleagues and in other sites.
Thank god for the 386.