Timeline for Does an Operating System inject its own machine code when you open a program?
Current License: CC BY-SA 3.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 18, 2017 at 1:09 | comment | added | David Richerby | @Melab As I said, the undecidability of the halting problem means you can't compute in advance how many times any given loop will run. So you don't know how long the loop will run for (or even if it will run for ever or not), which means you don't know if it's safe to wait until after the loop before returning to the OS. | |
| Jan 18, 2017 at 0:54 | comment | added | Melab | @DavidRicherby I am still not seeing how the halting problem is relevant. All you'd have to do is look for where in the program it needs to jump back to the OS. If the routine can't be in the loop, then insert it after the loop. | |
| Jan 12, 2017 at 8:13 | comment | added | David Richerby |
@Melab The proposal in the question was that the OS would insert instructions into the process that would periodically jump back to the OS. To do that, it would need to figure out where to insert those instructions, before executing the code. However, the undecidability of the halting problem means that you can't tell in advance how many times a loop will run, so you don't know where to insert these instructions. All you could do would be something like count++; if (count==1000) { count=0; return_to_OS(); } before every instruction, which would be grossly inefficient.
|
|
| Jan 12, 2017 at 3:17 | comment | added | Melab | Why does the halting problem need to be solvable for this to work? | |
| Jul 14, 2014 at 8:40 | vote | accept | Revering Sumoda | ||
| S Jul 9, 2014 at 9:19 | history | suggested | Vladislavs Burakovs | CC BY-SA 3.0 |
Pointed out that cooperative multitasking == non-preemptive multitasking
|
| Jul 9, 2014 at 9:17 | review | Suggested edits | |||
| S Jul 9, 2014 at 9:19 | |||||
| Jul 7, 2014 at 13:18 | comment | added | jwg | Some good information in this answer, but the reasons why OS don't inject code into executables are all pretty bogus. The halting problem is not really a practical consideration, it being 'time-consuming' is pretty nebulous, and I'm sure anti-virus systems were not a consideration when this design decision was made. | |
| Jul 7, 2014 at 11:52 | comment | added | user19954 | I created an account here just to upvote you for "people are not gigahertz beings". | |
| Jul 7, 2014 at 11:21 | comment | added | Luaan |
@BiAiB Actually, you're wrong. Desktop CPUs don't run code sequentially and synchronously since about the i486. However, even older CPUs still had asynchronous inputs - interrupts. Imagine a hardware interrupt request (IRQ) just like a pin on the CPU itself - when it gets 1, the CPU stops whatever it's doing, and starts processing the interrupt (which basically means "preserve state and jump to an address in memory"). The interrupt handling itself is not x86 or whatever code, it's literally hardwired. After jumping, it again executes (any) x86 code. Threads are a way higher abstraction.
|
|
| Jul 7, 2014 at 10:04 | comment | added | BiAiB | @Luaan thx, I'm getting a better picture, but still:*it can also be interrupted asynchronously from a separate source*. First, I'm puzzled since the CPU (no multicore/multiproc/multithread) runs code sequentially and synchrnously. Also, what source is exactly ? From what I understood, the OS code says '1) schedule an interrupt in 100cycles, then switch to the process context and code'. Am I right ? (sorry to insist but the wikipedia article is very generic and I can't find precise reference on clock interrupts) | |
| Jul 7, 2014 at 1:44 | comment | added | hdgarrood | See: twitter.com/CompSciFact/status/454605431076581376 | |
| Jul 7, 2014 at 1:43 | comment | added | hdgarrood | @JasonC I don't see how that answers my question. | |
| S Jul 6, 2014 at 21:30 | history | suggested | Paul Manta | CC BY-SA 3.0 |
Clarified how the OS uses timer interrupts
|
| Jul 6, 2014 at 21:07 | review | Suggested edits | |||
| S Jul 6, 2014 at 21:30 | |||||
| Jul 6, 2014 at 18:27 | comment | added | Flexo - Save the data dump | This overlooks the VDSO mechanism on modern Linux that basically is OS initiated code injection with the dynamic linker for the runtime fixups. | |
| Jul 6, 2014 at 15:11 | comment | added | Jason C | @hdgarrood I think because the OP was asking if the OS injected code into a program to return control of the program to the OS when the program was complete, although this answer may have muddled that point a bit. | |
| Jul 5, 2014 at 22:08 | comment | added | hdgarrood | What does the halting problem have to do with deciding whether it's safe to inject code into a program? | |
| Jul 5, 2014 at 21:52 | comment | added | joeytwiddle | Even my old 8-bit machine used interrupts. If I remember correctly, the state of the running process was pushed onto the stack while the interrupt ran, and popped back off the stack when execution returned to the process. | |
| Jul 5, 2014 at 18:31 | comment | added | Palec | I think that links to en.wikipedia.org/wiki/Interrupt and en.wikipedia.org/wiki/Halting_problem would be of use for audience of this answer. | |
| Jul 5, 2014 at 6:41 | comment | added | Jason C | (Well, it seems 2.1 had limited support, and it was rather fuzzy and strange with increasingly better support up to '95.) | |
| Jul 5, 2014 at 6:25 | comment | added | Jason C | Adding to this answer; the style of multitasking referred to in points 2 and 3 is called "preemptive multitasking", the name refers to the OS's ability to preempt a running process. Cooperative multitasking was used frequently on older operating systems; on Windows at least preemptive multitasking wasn't introduced until Windows 95. I've read of at least one industrial control system in use today that still uses Windows 3.1 solely for its real-time cooperative multitasking behavior. | |
| Jul 4, 2014 at 14:13 | comment | added | Luaan | @BiAiB The key word here is "interrupt". The CPU is not just something that processes a given stream of instructions, it can also be interrupted asynchronously from a separate source - most importantly for us, I/O and clock interrupts. Since only kernel-space code can handle interrupts, Windows can be sure to be able to "steal" work from any running process any time it wants to. The interrupt handlers can execute whatever code they want to, including "store the CPU's registers somewhere and restore them from here (another thread)". Extremely simplified, but that's the context switch. | |
| Jul 4, 2014 at 12:59 | comment | added | Ian Ringrose | Some OSs do, most OS at least mess about with the code to do "linking", so the program can be loaded at any address | |
| Jul 4, 2014 at 12:40 | comment | added | BiAiB | Can you develop more on you last 2. point? I'm curious about this question, and am feeling the explanation is skipped here. It seems to me like the question is "how the OS take back the CPU from process" and your answer tells "The OS handles it". but how? Take the infinite loop in your first example: how does it not freeze the computer? | |
| Jul 4, 2014 at 11:01 | history | edited | David Richerby | CC BY-SA 3.0 |
Incorporated comment about fixed-time simulation.
|
| Jul 4, 2014 at 7:26 | history | answered | David Richerby | CC BY-SA 3.0 |