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

51–60 of 86 posts

Re: Win16 Memory Management

#51

Post by toast0 »

hnthrowaway0315 wrote: post #31
kev009 wrote: post #3

Earlier quoted context omitted.

Attention spans were longer.

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 th…

> 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

Re: Win16 Memory Management

#52

Post by skissane »

JdeBP wrote: post #43
kalleboo wrote: post #39

Earlier quoted context omitted.

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…

Yes, outwith the idea of Family API programs (which couldn't use Presentation Manager and whatnot anyway) OS/2 1.x did target the 286 as a minimum. But that doesn't mean that DOS+Windows didn't use the features. It did. It was bi-modal. There were at one point switches to the WIN command to tell it whether to come up in real mode or 286 protected mode. In the latter it definitely did use the features of protected mod…

> There were at one point switches to the WIN command to tell it whether to come up in real mode or 286 protected mode. In the latter it definitely did use the features of protected mode.

Windows 3.0’s WIN.COM supported:

/R for real mode (8086)

/S for standard mode (16-bit protected mode)

/E for 386 Enhanced Mode (32-bit virtual machine manager (VMM), running Windows in VM1, and DOS apps in VM2+)

Re: Win16 Memory Management

#53

Post by vardump »

bluedino wrote: post #45
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.

And the 32-bit 4GB limit was often really "just a bit under 2GB" depending on the hardware, OS, etc

3/1 split was common, though. Especially towards the end of 32-bit era.

Re: Win16 Memory Management

#54

Post by trumpdong »

senfiaj wrote: post #12
barrkel wrote: post #10

Earlier quoted context omitted.

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…

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

Re: Win16 Memory Management

#55

Post by canucker2016 »

kalleboo wrote: post #39
JdeBP wrote: post #35

Earlier quoted context omitted.

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…

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…

But like real-mode Windows, the Macintosh OS was designed with small amounts of RAM. 32K limits pop up in various APIs. Handle memory allocation.

Not as much of a strait jacket as Windows segmented-memory programming, but compared to Unix, it did feel constricting.

Re: Win16 Memory Management

#56

Post by canucker2016 »

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

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

Re: Win16 Memory Management

#57

Post by ack_complete »

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

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.

Re: Win16 Memory Management

#58

Post by jlokier »

canucker2016 wrote: post #56
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

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…

  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.

Re: Win16 Memory Management

#59

Post by canucker2016 »

jlokier wrote: post #58
canucker2016 wrote: post #56

Earlier quoted context omitted.

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…

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…

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

Re: Win16 Memory Management

#60

Post by the-smug-one »

hnthrowaway0315 wrote: post #33
GordonS wrote: post #5

Earlier quoted context omitted.

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 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 read…

6 is pretty early to enjoy reading books, so I wouldn't worry.
Post reply on HN