8 ms·

Win16 Memory Management

151 points by supermatou 4mo ago

jdw64 4mo ago
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
- kev009 4mo ago
  Attention spans were longer.
  - GordonS 4mo ago
    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.
    - Braini 4mo ago
      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.
    - jdw64 4mo ago
      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
    - trumpdong 4mo ago
      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.
    - hnthrowaway0315 4mo ago
      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.
      - GordonS 4mo ago
        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!
      - the-smug-one 4mo ago
        6 is pretty early to enjoy reading books, so I wouldn't worry.
  - hnthrowaway0315 4mo ago
    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.
    - toast0 4mo ago
      > 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. Some potential ideas to explore. Take what you want, leave what you don't. a) if you're training for attention span, make sure the target is appropriate and also within reach of your child. b) have a plan for the visit: when I helped at a school library, classes for kids in your kid's age group would come in, the librarian would read them a story, then the kids would look for a book, check out at the desk and read (or look at the book anyway) quietly until the end of the visit. I think we'd get about 40 minutes for a visit. Most days, at least some of the kids would be getting ansy before it was time to go. c) Plan around your kid's activity needs. Some kids will do long still antention tasks better after doing some amount of physical activity. Some kids will do these kinds of things better after a meal. Some will do it better in the morning or the afternoon. Many kids will have a harder time if the library visit was a surprise. You know your kid, try to have your library visits when they're likely to work well. If he likes story time, try to visit when there's a story time available. d) don't expect that you can both go to the library and work independently. You're going to the library with him, and he's going to need you to help him out for much of the time. But you might be able to find him a book together, then find you a book together, then sit down and read for a bit together. e) if all you can get done is finding a book, no big deal. You can read at home too. If a lion can figure out how to behave in the library, so can your kid ;) https://www.michelleknudsen.com/library_lion_77788.htm https://www.michelleknudsen.com/library_lion_77788.htm
- hnlmorg 4mo ago
  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.
  - barrkel 4mo ago
    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 4mo ago
      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-about-pae/ https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-ab...
      - trumpdong 4mo ago
        "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 4mo ago
        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.
- markus_zhang 4mo ago
  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.
  - JdeBP 4mo ago
    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.
    - markus_zhang 4mo ago
      Yeah you are right. I just listed two random books.
- rvba 4mo ago
  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.
- bananaflag 4mo ago
  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).
- bitwize 4mo ago
  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.
- jchw 4mo ago
  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.
  - hnthrowaway0315 4mo ago
    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.
    - FpUser 4mo ago
      >"by deliberately writing in low level C and assembly for a few years" Ha. kid's stuff. I started with punching machine codes straight into memory
  - cogman10 4mo ago
    I think it'd be mixed. I think the knowledge of underlying hardware is useful and good to know. But also that sort of knowledge got dated pretty quickly in the early computer era. Further, the capabilities of things like optimizing compilers quickly got to a point where they'd outpace most hand written assembly. Today, it's basically just floating point operations where you can still do better than a compiler. In the early days, you'd have the correct impression that the C compilers spat out utter garbage which was a lot slower than what you could hand craft. As optimization techniques got better and better, the work you did because the compiler was dumb ultimately would have gotten in the way.
- icelusxl 4mo ago
  Memory mapping/bank switching was fairly common on 8-bit and 16-bit systems, where a small memory window was used to select different memory banks, allowing a program to access more memory in chunks. Game consoles like NES, SNES and Game Boy had additional hardware built in the cartridge to support memory mapping/bank switching. For PCs, EMS (memory) provided a similar concept. It reserved a 64 kB window divided in 16 kB pages in the first 1 MB and allowed to map up to 32 MB.
- rramadass 4mo ago
  https://news.ycombinator.com/item?id=48435428 https://news.ycombinator.com/item?id=48435428
- unleaded 4mo ago
  It's easy when it's the only way to get things done. Think about how nobody who was learning programming before 2023 was seriously thinking "This would be so much easier if the computer wrote it all for me".
- canucker2016 4mo ago
  You just had to live with the constraints. It biased your selection of data structures and algorithms. Max 64KB array size meant pointers to allocated structs and linked lists were much more popular back then versus 1 large array of structs. The Win16 HANDLE memory allocation also meant you had to worry about how you handle structs which had pointers to others structs (a FAR ptr may not be a stable value, unless you locked the HANDLE for the duration of the allocation) Then you had to worry about stuff that no college programming book talked about (ignore the lack of error checking): char FAR *p; char FAR *mem = farmalloc(65536); for (p = &mem[65535]; p >= &mem[0]; p--) { dostuff(p); } Welcome to an infinite loop...
  - jlokier 4mo ago
    char FAR *p; char FAR *mem = farmalloc(65536); for (p = &mem[65535]; p >= &mem[0]; p--) { dostuff(p); } Nice one. To be fair to Windows, good C courses should still teach this, but I'm not sure if they do :-) It's UB to set a pointer to before the first element of an array, or after the last element plus one. So, if it knows the call to farmalloc/malloc returns the start of an object, a modern C compiler on a modern architecture may, in principle, optimise the above to an infinite loop. I've seen something similar on architectures (long ago) where a zero-bit-pattern pointer was a valid memory address you might actually access. Of course p-1 is not less than p when p is zero.
    - canucker2016 4mo ago
      None of my college CS courses used programming languages that featured FAR pointers. The above example would cause an infinite loop on Win16's seg:off far memory model, but compiling on Win32 would not cause an infinite loop. Problem is that far pointers only affect the offset, not the segment. So decrementing a 0 value offset would just wrap around to 0xFFFF and the segment would stay the same, so you're going from mem[0] to mem[65535] not mem[-1].
      - jlokier 4mo ago
        My point is the example code has a generic C bug, not depending on FAR, which is why it should be taught in good C courses. Although the code worked on Win32, and works on most modern C compilers, it's not guaranteed to work on modern C compilers, especially with aggressive optimisation turned on.
- ack_complete 4mo ago
  Some of this was automatically handled by the compiler and wouldn't have been an issue. Current x86-64 ABIs, for instance, require function entry to use specific forms annotated by metadata to support stack walking to support exception handling. Like the far entry here, this is invisible to most programmers -- the compiler does it for you. Similarly, while locking and unlocking memory blocks is no longer generally a concern, most programs still deal with files, and graphics programs still have to call map/unmap functions to access graphics data. All the same tools apply -- helper functions/libraries, RAII, and leak/sanitizer tools to dynamically detect usage errors.
- vjvjvjvjghv 4mo ago
  I think programming often was easier back then. You didn’t have to know about 120 AWS services or security issues. The world was pretty small and you could mostly understand all details of the system you worked on. But it was more tedious for sure.
  - icedchai 4mo ago
    It was. I learned so much by reading books and computer magazines. Now we have layers of layers of cruft to wade through.
- Timwi 4mo ago
  I can tell you about my experiences with this, which from what I hear are unusual. I first learned programming in C128 BASIC. Then on the PC it was QBasic and Turbo Pascal, and later Perl. What all of these languages have in common is that you can write meaningful programs entirely without pointers or manual memory management. In particular, all of these languages handle strings in a natural, high-level way (treating them as a value) and don't require you to allocate and free buffers for them. Perl goes a step further with arrays and hashmaps and employs a full garbage collector. I have vague memories of trying C for the first time and getting completely lost and bogged down by all the pointers and memory management. My reaction was the same as yours: how does anyone program in this. Why bother with this complexity when you can just use Pascal where you simply don't have to. Of course, the Pascal compiler was likely written in C or assembly and all the memory management still had to happen even if it was hidden away from me. To some people, this might mean that I “lost” something, but to me, it meant greater freedom as I was able to explore the world of higher-level programming which I found interesting, and not have to bother with the low-level details which I found tedious and even infuriating.
  - andrewshadura 4mo ago
    On the contrary, Pascal compilers were usually written Pascal with a bit of assembly where needed :)
unleaded 4mo ago
Thank god for the 386.
atan2 4mo ago
I posted the same thing a few days ago: https://news.ycombinator.com/item?id=48424862 https://news.ycombinator.com/item?id=48424862 I'll just stop posting on HN.
- lloydatkinson 4mo ago
  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.
  - atan2 4mo ago
    This has happened at least 4 times to my posts just last month.
- JdeBP 4mo ago
  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.
- hnthrowaway0315 4mo ago
  I think it's just bad timing.
- pjmlp 4mo ago
  It is always a matter of luck.
- elzbardico 4mo ago
  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.
kalleboo 4mo ago
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 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 https://bitbang.social/@kalleboo/116302075194704555
- JdeBP 4mo ago
  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.
  - kalleboo 4mo ago
    I understood it as Windows developers had to manually deal with segment limitations since Windows supported running on pre-286 CPUs without protected mode (Wikipedia says Windows 1-3 all supported the 8088). OS/2 just made the 286 a minimum requirement so they could rely on a CPU with more modern features. The 68k didn't come with an MMU like the 286 so MacOS couldn't rely on virtual memory like OS/2 did but at least the flat memory space meant you didn't have to juggle 64k segments
    - 4mo ago
Aegis_Labs 4mo ago
[flagged]
chiph 4mo ago
> 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.
summa_tech 4mo ago
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 :-)
zabzonk 4mo ago
If you think programming in Win16 (or whatever we want to call it), you should try teaching people to do it. I worked as a commercial trainer on C and Windows way back when - C and the Windows API were no bed of roses, but the different memory models were mind-numbing for us tutors and the poor punters, many of whom didn't know C!
boutell 4mo ago
In 1994 I was 2 years out of school. I'd written one windows shareware application and a whole lot of unix-y things. People were excited about the internet but most people didn't have access. Unix shell accounts via dialup were common though. One day I was encouraged to write a Windows Sockets emulation layer for ordinary dial-up shell accounts like those offered by netcom. The idea was to allow the use of the recently released Mosaic browser without an actual internet connection. I figured sure, no problem. I'll use curl or some other tool in the shell account to do the actual fetching of URLs, transfer styles over zmodem, and simulate all the tcp/ip calls in the DLL. I couldn't even get started. The reason is that I couldn't understand how the different Windows applications could all share memory allocated at runtime in the winsock.dll. I asked a highly experienced ex Microsoft person, and he just said what are you talking about. There's no API to allocate shared memory. So I gave up. 6 months later someone else did it. Around then I realized the truth: Windows 3.1 had no memory protection at all. Specifically all global variables in DLLs were shared by default. The hard part wasn't sharing memory among users of a DLL. If anything, the hard part was having good discipline to avoid sharing it. Since I'd only used multiuser Unix in school, and I knew Windows supported multitasking (even if only the cooperative kind), I just couldn't wrap my head around the idea that I'm multitasking operating system could exist without memory protection.
- leeter 4mo ago
  > Windows 3.1 had no memory protection at all All of the below is... IIRC Win16, even in protected mode, in general didn't unless you opted out of the shared VDM. This was to preserve compatibility with how non-protected mode code worked. That said 32bit code or code that specifically marked itself as protected mode got it's own memory space. > I just couldn't wrap my head around the idea that I'm multitasking operating system could exist without memory protection NGL... I was shocked when I found out that MacOS before 10... really didn't have much protections at all.
- pjmlp 4mo ago
  Owning reference books like Petzold, already doing C++ and TP coding on Windows 3.x, I am quite sure that the protection was there for Win16 applications in 386 Enhanced mode. Now in regards to DLLs it all depended on which memory segments were being used, and the respective code on DllMain in regards to the thread/process attachment code and related handles. Knowing what to search for quickly gave me this article from back in the day, https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/july/under-the-hood-happy-10th-anniversary-windows https://learn.microsoft.com/en-us/archive/msdn-magazine/2000...
rramadass 4mo ago
Good informative article. Win16 programming was an important formative phase in my career. There is a lot of wisdom in old solutions to thorny problems and knowing them often clues you to how one may adapt them to today's problem. For example, when CPU+GPU programming appeared i immediately imagined CPU memory accessed with "near" pointers and GPU memory accessed with "far" pointers with a switch to a pseudo-segment register. It also conditioned a programmer to learn about various complexities involved and be careful in their programming i.e. it taught you discipline. You understood your compiler, OS and hardware better and how to write code keeping them all in mind. For example, i often say my study of embedded programming started with Win16! Another bit of cleverness was "Thunking" between 16-bit and 32-bit code. Here is Raymond Chen on how it worked there and Why can’t you thunk between 32-bit and 64-bit Windows? - https://devblogs.microsoft.com/oldnewthing/20081020-00/?p=20523 https://devblogs.microsoft.com/oldnewthing/20081020-00/?p=20...
userbinator 4mo ago
Windows never had a global name space for dynamic symbol resolution. IMHO one of the best design decisions they made; the Unix dynamic linking model seems absolutely like an absurd workaround in comparison. Also, no mention of FixDS? https://www.geary.com/fixds.html https://www.geary.com/fixds.html
- Joker_vD 4mo ago
  > the Unix dynamic linking model What? It's just like static linking! Only, you know, we do it at load time. At least the filenames of the shared objects to load are included into the executable — we could instead just load and search the whole of /usr/lib in unspecified order, you know!
- pjmlp 4mo ago
  Not all UNIXes, Aix dynamic link model is XCOFF and quite similar to Windows.

151 points by supermatou 4mo ago

jdw64 4mo ago

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

kev009 4mo ago
Attention spans were longer.
- GordonS 4mo ago
  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.
  - Braini 4mo ago
    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.
  - jdw64 4mo ago
    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
  - trumpdong 4mo ago
    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.
  - hnthrowaway0315 4mo ago
    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.
    - GordonS 4mo ago
      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!
    - the-smug-one 4mo ago
      6 is pretty early to enjoy reading books, so I wouldn't worry.
- hnthrowaway0315 4mo ago
  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.
  - toast0 4mo ago
    > 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. Some potential ideas to explore. Take what you want, leave what you don't. a) if you're training for attention span, make sure the target is appropriate and also within reach of your child. b) have a plan for the visit: when I helped at a school library, classes for kids in your kid's age group would come in, the librarian would read them a story, then the kids would look for a book, check out at the desk and read (or look at the book anyway) quietly until the end of the visit. I think we'd get about 40 minutes for a visit. Most days, at least some of the kids would be getting ansy before it was time to go. c) Plan around your kid's activity needs. Some kids will do long still antention tasks better after doing some amount of physical activity. Some kids will do these kinds of things better after a meal. Some will do it better in the morning or the afternoon. Many kids will have a harder time if the library visit was a surprise. You know your kid, try to have your library visits when they're likely to work well. If he likes story time, try to visit when there's a story time available. d) don't expect that you can both go to the library and work independently. You're going to the library with him, and he's going to need you to help him out for much of the time. But you might be able to find him a book together, then find you a book together, then sit down and read for a bit together. e) if all you can get done is finding a book, no big deal. You can read at home too. If a lion can figure out how to behave in the library, so can your kid ;) https://www.michelleknudsen.com/library_lion_77788.htm https://www.michelleknudsen.com/library_lion_77788.htm
hnlmorg 4mo ago
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.
- barrkel 4mo ago
  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 4mo ago
    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-about-pae/ https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-ab...
    - trumpdong 4mo ago
      "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 4mo ago
        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.
markus_zhang 4mo ago
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.
- JdeBP 4mo ago
  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.
  - markus_zhang 4mo ago
    Yeah you are right. I just listed two random books.
rvba 4mo ago
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.
bananaflag 4mo ago
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).
bitwize 4mo ago
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.
jchw 4mo ago
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.
- hnthrowaway0315 4mo ago
  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.
  - FpUser 4mo ago
    >"by deliberately writing in low level C and assembly for a few years" Ha. kid's stuff. I started with punching machine codes straight into memory
- cogman10 4mo ago
  I think it'd be mixed. I think the knowledge of underlying hardware is useful and good to know. But also that sort of knowledge got dated pretty quickly in the early computer era. Further, the capabilities of things like optimizing compilers quickly got to a point where they'd outpace most hand written assembly. Today, it's basically just floating point operations where you can still do better than a compiler. In the early days, you'd have the correct impression that the C compilers spat out utter garbage which was a lot slower than what you could hand craft. As optimization techniques got better and better, the work you did because the compiler was dumb ultimately would have gotten in the way.
icelusxl 4mo ago
Memory mapping/bank switching was fairly common on 8-bit and 16-bit systems, where a small memory window was used to select different memory banks, allowing a program to access more memory in chunks. Game consoles like NES, SNES and Game Boy had additional hardware built in the cartridge to support memory mapping/bank switching. For PCs, EMS (memory) provided a similar concept. It reserved a 64 kB window divided in 16 kB pages in the first 1 MB and allowed to map up to 32 MB.
rramadass 4mo ago
https://news.ycombinator.com/item?id=48435428 https://news.ycombinator.com/item?id=48435428
unleaded 4mo ago
It's easy when it's the only way to get things done. Think about how nobody who was learning programming before 2023 was seriously thinking "This would be so much easier if the computer wrote it all for me".
canucker2016 4mo ago
You just had to live with the constraints. It biased your selection of data structures and algorithms. Max 64KB array size meant pointers to allocated structs and linked lists were much more popular back then versus 1 large array of structs. The Win16 HANDLE memory allocation also meant you had to worry about how you handle structs which had pointers to others structs (a FAR ptr may not be a stable value, unless you locked the HANDLE for the duration of the allocation) Then you had to worry about stuff that no college programming book talked about (ignore the lack of error checking): char FAR *p; char FAR *mem = farmalloc(65536); for (p = &mem[65535]; p >= &mem[0]; p--) { dostuff(p); } Welcome to an infinite loop...
- jlokier 4mo ago
  char FAR *p; char FAR *mem = farmalloc(65536); for (p = &mem[65535]; p >= &mem[0]; p--) { dostuff(p); } Nice one. To be fair to Windows, good C courses should still teach this, but I'm not sure if they do :-) It's UB to set a pointer to before the first element of an array, or after the last element plus one. So, if it knows the call to farmalloc/malloc returns the start of an object, a modern C compiler on a modern architecture may, in principle, optimise the above to an infinite loop. I've seen something similar on architectures (long ago) where a zero-bit-pattern pointer was a valid memory address you might actually access. Of course p-1 is not less than p when p is zero.
  - canucker2016 4mo ago
    None of my college CS courses used programming languages that featured FAR pointers. The above example would cause an infinite loop on Win16's seg:off far memory model, but compiling on Win32 would not cause an infinite loop. Problem is that far pointers only affect the offset, not the segment. So decrementing a 0 value offset would just wrap around to 0xFFFF and the segment would stay the same, so you're going from mem[0] to mem[65535] not mem[-1].
    - jlokier 4mo ago
      My point is the example code has a generic C bug, not depending on FAR, which is why it should be taught in good C courses. Although the code worked on Win32, and works on most modern C compilers, it's not guaranteed to work on modern C compilers, especially with aggressive optimisation turned on.
ack_complete 4mo ago
Some of this was automatically handled by the compiler and wouldn't have been an issue. Current x86-64 ABIs, for instance, require function entry to use specific forms annotated by metadata to support stack walking to support exception handling. Like the far entry here, this is invisible to most programmers -- the compiler does it for you. Similarly, while locking and unlocking memory blocks is no longer generally a concern, most programs still deal with files, and graphics programs still have to call map/unmap functions to access graphics data. All the same tools apply -- helper functions/libraries, RAII, and leak/sanitizer tools to dynamically detect usage errors.
vjvjvjvjghv 4mo ago
I think programming often was easier back then. You didn’t have to know about 120 AWS services or security issues. The world was pretty small and you could mostly understand all details of the system you worked on. But it was more tedious for sure.
- icedchai 4mo ago
  It was. I learned so much by reading books and computer magazines. Now we have layers of layers of cruft to wade through.
Timwi 4mo ago
I can tell you about my experiences with this, which from what I hear are unusual. I first learned programming in C128 BASIC. Then on the PC it was QBasic and Turbo Pascal, and later Perl. What all of these languages have in common is that you can write meaningful programs entirely without pointers or manual memory management. In particular, all of these languages handle strings in a natural, high-level way (treating them as a value) and don't require you to allocate and free buffers for them. Perl goes a step further with arrays and hashmaps and employs a full garbage collector. I have vague memories of trying C for the first time and getting completely lost and bogged down by all the pointers and memory management. My reaction was the same as yours: how does anyone program in this. Why bother with this complexity when you can just use Pascal where you simply don't have to. Of course, the Pascal compiler was likely written in C or assembly and all the memory management still had to happen even if it was hidden away from me. To some people, this might mean that I “lost” something, but to me, it meant greater freedom as I was able to explore the world of higher-level programming which I found interesting, and not have to bother with the low-level details which I found tedious and even infuriating.
- andrewshadura 4mo ago
  On the contrary, Pascal compilers were usually written Pascal with a bit of assembly where needed :)

unleaded 4mo ago

Thank god for the 386.

atan2 4mo ago

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

lloydatkinson 4mo ago
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.
- atan2 4mo ago
  This has happened at least 4 times to my posts just last month.
JdeBP 4mo ago
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.
hnthrowaway0315 4mo ago
I think it's just bad timing.
pjmlp 4mo ago
It is always a matter of luck.
elzbardico 4mo ago
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.

kalleboo 4mo ago

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 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 https://bitbang.social/@kalleboo/116302075194704555

JdeBP 4mo ago
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.
- kalleboo 4mo ago
  I understood it as Windows developers had to manually deal with segment limitations since Windows supported running on pre-286 CPUs without protected mode (Wikipedia says Windows 1-3 all supported the 8088). OS/2 just made the 286 a minimum requirement so they could rely on a CPU with more modern features. The 68k didn't come with an MMU like the 286 so MacOS couldn't rely on virtual memory like OS/2 did but at least the flat memory space meant you didn't have to juggle 64k segments
  - 4mo ago

Aegis_Labs 4mo ago

[flagged]

chiph 4mo ago

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

summa_tech 4mo ago

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 :-)

zabzonk 4mo ago

If you think programming in Win16 (or whatever we want to call it), you should try teaching people to do it. I worked as a commercial trainer on C and Windows way back when - C and the Windows API were no bed of roses, but the different memory models were mind-numbing for us tutors and the poor punters, many of whom didn't know C!

boutell 4mo ago

In 1994 I was 2 years out of school. I'd written one windows shareware application and a whole lot of unix-y things. People were excited about the internet but most people didn't have access. Unix shell accounts via dialup were common though. One day I was encouraged to write a Windows Sockets emulation layer for ordinary dial-up shell accounts like those offered by netcom. The idea was to allow the use of the recently released Mosaic browser without an actual internet connection. I figured sure, no problem. I'll use curl or some other tool in the shell account to do the actual fetching of URLs, transfer styles over zmodem, and simulate all the tcp/ip calls in the DLL. I couldn't even get started. The reason is that I couldn't understand how the different Windows applications could all share memory allocated at runtime in the winsock.dll. I asked a highly experienced ex Microsoft person, and he just said what are you talking about. There's no API to allocate shared memory. So I gave up. 6 months later someone else did it. Around then I realized the truth: Windows 3.1 had no memory protection at all. Specifically all global variables in DLLs were shared by default. The hard part wasn't sharing memory among users of a DLL. If anything, the hard part was having good discipline to avoid sharing it. Since I'd only used multiuser Unix in school, and I knew Windows supported multitasking (even if only the cooperative kind), I just couldn't wrap my head around the idea that I'm multitasking operating system could exist without memory protection.

leeter 4mo ago
> Windows 3.1 had no memory protection at all All of the below is... IIRC Win16, even in protected mode, in general didn't unless you opted out of the shared VDM. This was to preserve compatibility with how non-protected mode code worked. That said 32bit code or code that specifically marked itself as protected mode got it's own memory space. > I just couldn't wrap my head around the idea that I'm multitasking operating system could exist without memory protection NGL... I was shocked when I found out that MacOS before 10... really didn't have much protections at all.
pjmlp 4mo ago
Owning reference books like Petzold, already doing C++ and TP coding on Windows 3.x, I am quite sure that the protection was there for Win16 applications in 386 Enhanced mode. Now in regards to DLLs it all depended on which memory segments were being used, and the respective code on DllMain in regards to the thread/process attachment code and related handles. Knowing what to search for quickly gave me this article from back in the day, https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/july/under-the-hood-happy-10th-anniversary-windows https://learn.microsoft.com/en-us/archive/msdn-magazine/2000...

rramadass 4mo ago

Good informative article. Win16 programming was an important formative phase in my career. There is a lot of wisdom in old solutions to thorny problems and knowing them often clues you to how one may adapt them to today's problem. For example, when CPU+GPU programming appeared i immediately imagined CPU memory accessed with "near" pointers and GPU memory accessed with "far" pointers with a switch to a pseudo-segment register. It also conditioned a programmer to learn about various complexities involved and be careful in their programming i.e. it taught you discipline. You understood your compiler, OS and hardware better and how to write code keeping them all in mind. For example, i often say my study of embedded programming started with Win16! Another bit of cleverness was "Thunking" between 16-bit and 32-bit code. Here is Raymond Chen on how it worked there and Why can’t you thunk between 32-bit and 64-bit Windows? - https://devblogs.microsoft.com/oldnewthing/20081020-00/?p=20523 https://devblogs.microsoft.com/oldnewthing/20081020-00/?p=20...

userbinator 4mo ago

Windows never had a global name space for dynamic symbol resolution. IMHO one of the best design decisions they made; the Unix dynamic linking model seems absolutely like an absurd workaround in comparison. Also, no mention of FixDS? https://www.geary.com/fixds.html https://www.geary.com/fixds.html

Joker_vD 4mo ago
> the Unix dynamic linking model What? It's just like static linking! Only, you know, we do it at load time. At least the filenames of the shared objects to load are included into the executable — we could instead just load and search the whole of /usr/lib in unspecified order, you know!
pjmlp 4mo ago
Not all UNIXes, Aix dynamic link model is XCOFF and quite similar to Windows.