How Operating Systems work

[YellowSubmarine]

And suppose you have two iterations of Notepad open on Windows....

This is one reason why I don't like Windows' approach of treating two instances of the same executable as completely distinct.

What about having the grep executable opened up twice? It makes more sense if the application writer takes care of that through IPC with its other instances/sessions.

And suppose you have two iterations of Notepad open on Windows with the same file and you are using one of them to write down information you get over the phone. You might at some point save and close it, forgetting and leaving the other open. Later, when you decide to close the other, you had better not save it, because you'll be destroying information you had recorded and saved. A new OS and GUI should rein in that booby trap. Programmers of some applications know about that problem and don't let it happen with their software.

All editors I've used warn me if the file has been changed before saving using the same approach as Jadzia states. That's a problem with Notepad being a dumb program we shouldn't use. For example, vim checks the last modification time and also creates a swap file which gives you a warning if you open the same file twice, warns you if your last edit session crashed and allows you to restore it. That's job of the application, although the OS also provides one - file locking.

Though locking in Windows was somewhat queer as far as I can remember.

 

[Jadzia]

Always assume the user doesn't know what they're doing. Or rather, always assume the user could be acting maliciously and defend against it.

I find software like that to give an unpleasant user experience. I like software to do what I tell it to do.

 

[Lindley]

Always assume the user doesn't know what they're doing. Or rather, always assume the user could be acting maliciously and defend against it.

I find software like that to give an unpleasant user experience. I like software to do what I tell it to do.

Software should not do anything you tell it to do. The extreme end of that spectrum is software which explicitly allows buffer overflow attacks, since that can literally do *anything* given the right input. Clearly not a good thing.

Software should, however, be written to have the capabilities that you want it to have, and it should not get in the way of you using those capabilities at all. The balance between security and flexibility is a delicate one, but very important.

 

[Lindley]

This is one reason why I don't like Windows' approach of treating two instances of the same executable as completely distinct.

What about having the grep executable opened up twice?

That is true, there are some types of programs for which the multiple-instance paradigm makes perfect sense. However, some OS support for identifying running processes from the same executable is highly useful. At the moment on Windows you can do that but there are a few hoops to jump through.

 

[Jadzia]

This whole idea of storing separate bitmaps for each window is a (relatively) recent invention made possible by larger video memories. I think the old versions of Windows did everything by just directly blitting the rectangle of the current window, automatically covering up anything it overlapped. And I doubt it was ever storing the full bitmap of any window anywhere, beyond the full screen bitmap kept in the video memory itself.

I just wanted to add something to what I wrote above. I realised today that I can monitor what happens to memory usage as forms are created and drawn on. It gives some gives insight into how Windows handles forms.


Forms seem to begin life with no bitmap attached to them.

The first time something is drawn onto a form...

(i) If the form is set to AutoRedraw, the memory usage jumps up quite a bit, presumably because a bitmap is created and attached to the form at that point, and the drawing is being done to that bitmap.

If the window is Sizable, the jump is 6MB, which is the size of the screen (24bit image in 1920x1080 is 6MB). If the window is FixedSize, the memory jump is smaller, presumably because the bitmap is the size of the window now.

(ii) If the form is not set to AutoRedraw, the memory usage doesn't jump at all, suggesting that drawing is done to the screen buffer, and will be lost if that part of the form has something dragged over it.

That's fully consistent with my earlier ideas.

Also, if we call a Form.Cls command to clear any drawings, the bitmap is destroyed at that point, as seen by memory usage dropping down by 6MB.

I guess that explains why Cls is slower than blitting out a drawing. Cls means the bitmap will keep being destroyed and recreated, while blitting will maintain the same bitmap.

 

[Robert Maxwell]

I don't think it ever makes sense to allocate the entire screen resolution to a window unless it's actually taking up that much space on-screen. Why shouldn't you use more dynamic allocation? Think about setups where someone has 2 or 3 monitors. Running a handful of Sizable program windows would chew up all their RAM very quickly.

It would make more sense to only allocate exactly as much as the window needs at that moment, and then change the allocation based on resizing. You would just need a good garbage collection system to reclaim the memory freed up in this way, but the usage would be a lot more efficient.

Something just rubs me the wrong way about allocating that much memory when it might never be used. Programs should be given only as much memory as they need at that moment, not some amount they might need later.

 

[Jadzia]

One advantage is that it allows us to draw beyond the bounds of the form, and have that drawing become visible when we maximise the window.

Dynamic allocation could mean we lose parts of our drawing if a form is temporarily/accidentally resized while we're juggling the window about on the screen.

I haven't tried it with dual monitors (and I'm not going to today) so I don't know what would happen there.


//edit

Running a handful of Sizable program windows would chew up all their RAM very quickly.

Only if they have drawings on them AND are set to AutoRedraw.

In 800x600 256 colour mode, a bitmap will be only 1/2 MB. Compare that with the 8MB minimum memory requirements in Win95.

 

[Robert Maxwell]

But it's bit depth that has increased dramatically, from 8 to 32. Screen resolutions have certainly not gone up a lot, but there's a big difference between 800x600x8 and 1920x1080x32!

 

[Jadzia]

But it's bit depth that has increased dramatically, from 8 to 32. Screen resolutions have certainly not gone up a lot, but there's a big difference between 800x600x8 and 1920x1080x32!

It's a factor of 17

I don't like inefficiency either, but we should put it into perspective: In that same time (15 years), RAM has increased by a factor of 500, so the screen as a bitmap is a quantity of memory that's become less and less significant.

It's (17/500) = 3% of the problem it was 15 years ago.

 

[Robert Maxwell]

But it's bit depth that has increased dramatically, from 8 to 32. Screen resolutions have certainly not gone up a lot, but there's a big difference between 800x600x8 and 1920x1080x32!

It's a factor of 17

I don't like inefficiency either, but we should put it into perspective: In that same time (15 years), RAM has increased by a factor of 500, so the screen as a bitmap is a quantity of memory that's become less and less significant.

It's (17/500) = 3% of the problem it was 15 years ago.

I know, I just thought you were saying you could solve the RAM problem by using 8-bit graphics instead of 32, and I found that a big wrong-headed. I guess I am simply opposed to this idea of allocating memory equivalent to the screen resolution for every window that's resizable. Even if resizing means some flashing or a short delay, I think it's worth the memory savings. Something just rubs me the wrong way about programs being too "greedy" with memory, thinking they can take as much as they want "just in case" they need it.