1 stable 2 super stable

[k5054]

I would think that apps and OS run in their own virtual memory spaces, making it virtually (no pun intended) impossible for a non OS process to mess with OS memory space. Add to that different process execution rights, with user apps having no right to mess with OS memory, then the probability of a user application causing a crash by altering OS RAM contents approaches zero.

Keep Calm and Carry On

[dandy72]

k5054 wrote:

user apps having no right to mess with OS memory

This. User space vs kernel space. Drivers might still overwrite critical OS data, as they share memory with the kernel (that's why BSODs still occur), but a user-mode application should no longer be able to do that like they did back in the Windows 3.x/9x days.

[jschell]

Calin Negru wrote:

Windows XP and it’s predecessors did pretty good at recovering when an application went kaboom

What do you mean? Windows 3.1 would do a hard crash if the network went down. Databases back then were always corrupting the actual data files due to hardware failures. Or even normal hardware operation. Forums were always filled with questions about how someone needed to attempt to recover their database files. This was true for all the databases I saw back then Oracle, SQL Server and MS Access. Standard operating procedure in an editor was to manually save the file every couple of minutes, because if it crashed you lost everything. Editors at some point started adding a standard feature to automatically save the file because of that.

[trønderen]

Any machine with memory paging (on the PC side, that is from 386) keeps the OS pages in pages that does not appear in the user process paging tables. The user process has no way of pointing to the OS data structures. Furthermore, even within a single address space, section may be marked as read-only or execute-only, so even if they are addressable by some process, it cannot overwrite them. Many paging systems (including the 386 and its followers) also has a "ring" system: A process belongs to one "ring" (privilege level), and pages or segments require a minimum ring protection level for any sort of access. There are lots of very good protection mechanisms available in the hardware (and in the software). The problem is to make developers use the available mechanisms (and to use them the correct way).

[Calin Negru]

> Windows 3.1 would... I’m not going to argue. When I said predecessors I had in mind mostly the later versions (Windows95 and Windows98). Things got gradually better, Windows XP was pretty good for an OS thought for single core processors. What I’m trying to say, and this is only an impression, I wasn’t around programming when people were running Windows 98 or XP on their PCs, is that if you were playing the role of a programmer and did not dispose things properly (leaving a mess behind in your app on exit) the OS would have been unforgiving. On Windows 10 if you leave a mess on exit the OS won’t say a thing no dialog boxes or messages telling you about corrupted memory, or that the app has exited with errors.

[obermd]

64 bit versions of Windows don't share memory with the applications. There is a small "communications" buffer between the system and the applications, and this buffer is unique to each application. It's used for those system calls that require the application read from or write data to a system call, but this memory is actually in the application space. 32 bit Windows sometimes allowed applications to read/write directly in system space and the biggest culprits for this were heavy graphics (the 386 didn't have the power to avoid this) and anti-virus software. In fact, the AV folks went ballistic when Microsoft announced this change in Windows Vista because they knew they had been violating Microsoft's documentation on how to write Windows apps.

[Amarnath S]

In Win95, I remember having caused system crash by this single line, in my code:

int *a = 0;

Not sure whether this problem was fixed in Win98. It is precisely these kind of coding issues which got handled better in the Dotnet era.

[Calin Negru]

tronderen, obermd, interesting thanks for sharing.

[Lost User]

Calin Negru wrote:

Both 32 bit and 64 bit OS share the RAM with the app, the common dwelling means that the app can overwrite critical OS data

If that were so then Windows PCs would be crashing in their millions. User apps have no way of overwriting OS data as they exist in separate address spaces, and the non-OS parts have very low privilege levels.

[Calin Negru]

Yeah, a tiny bit left or right from the prescription and doom looming.

[Nelek]

trønderen wrote:

There are lots of very good protection mechanisms available in the hardware (and in the software). The problem is to make developers use the available mechanisms (and to use them the correct way).

That's... that's the right question[^]

M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

[Calin Negru]

Ok, I think I understand

[Jacquers]

And yet we still sometimes get the BSOD due to driver / other issues.

[honey the codewitch]

That all falls apart on embedded when you're dealing with primitive memory protection schemes and an RTOS at best. :( I was just dealing with a buffer overrun this morning.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

[honey the codewitch]

Hard to protect the OS against ill behaved drivers without introducing a nasty performance hit. Drivers basically need to operate in kernel space. Windows does have "user mode" drivers now, but not everything can be run that way. It would destroy your GPU performance, for example.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

[trønderen]

Don't forget the ring protection. Drivers are not supposed to run in ring 0.

[trønderen]

Remember the ring protection. Drivers are not supposed to run in ring 0. The (hardware) ring protection is effective at all times; it is not turned on or activated. Making use of it does not affect performance. Then comes the questions of placing the various OS data structures in the appropriate ring. I wouldn't be surprised if there are essential data structures in ring 1 (/2) that really should be located in ring 0. But then the OS code referencing it must be located in ring 0 as well. If the OS wasn't originally architected with a ring protection in mind, cleaning it up later may be a rather nasty job. I've never been inside Windows source code, but my experiences, not the least with (but certainly not limited to) Windows Docker, seems to indicate that it "Everything is deeply intertwingled" (to quote Ted Nelson). Picking apart a crow's nest to put some of the stick in the "ring 0" pile, without breaking any of the other sticks, requires extreme care. Then learning Zephyr, seeing how it is possible to divide OS functionality into clear cut, small pieces so that you load exactly what you need and nothing more, was a revelation to me. It is the diametrical opposite to Windows. Of course: Zephyr and Windows targets (almost) completely different problem domains. Yet I am quite sure that a general OS like Windows could be built with much more of the Zephyr modular philosophy.

[honey the codewitch]

Maybe I misunderstand how things are laid out but I do know a driver can do a kernel wait without switching between "user mode" and "kernel mode" under windows. I assumed kernel mode was equiv to ring 0 but it sounds like the truth is more complicated.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

[Calin Negru]

k5054, dandy72, tronderen that’s an interesting read guys

[Daniel Pfeffer]

Well, in OS/2 you had the following levels: Level 0: Kernel and (some) drivers Level 1: Most drivers Level 2: IOPL (In, Out instructions) for use programs Level 3: User programs I don't know much about the Windows kernel, but I assumed that it had a similar structure.

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.