Return to Answer

As a programmer, both answers posted so far are incorrect. While it's possible to come up with a hypothetical situation in which pressing Alt-F4 would corrupt a save in progress, actually doing so would require the developers to quite deliberately go out of their way to screw up the saving system.

From a coding perspective, the user pressing Alt-F4 does not "close the active window", nor does it "interrupt the program." What it does is cause Windows to place a WM_CLOSE message onto the program's event queue. That's all.

There are two things to keep in mind here. First is that the event loop is a linear thing: you don't process event #2 until you're finished processing event #1. And the second is that a WM_CLOSE message does not "quit the program". It's a special type of input, nothing more. It tells the program that the user has requested that the program close down the current window. The program is free to respond to this in whatever way its code says to, including ignoring it entirely. (This is a very rude thing to do, but developers occasionally do it.) One of the most common responses is to ask the user "Do you want to save before quitting?" and/or provide a way to cancel the close request.

So what happens if the user presses Alt-F4 while the game is in the middle of saving? Keep in mind the first point: processing is linear. Assuming that the save is taking place in the main thread, (which I'll cover a bit further on,) the code can't even check the event queue to see that it's been sent a WM_CLOSE message until after saving is complete. Therefore there's nothing to interrupt.

TL;DR: If your game already performs autosaves without corrupting itself, it's safe to assume that there is no risk of corruption in politely asking the game to shut down, (which is what ALT-F4 does,) even if you do so in the middle of a save. When warning screens tell you not to shut down the game while saving, it refers to turning off the power or other more drastic ways of terminating gameplay.

As a programmer, both answers posted so far are incorrect. While it's possible to come up with a hypothetical situation in which pressing Alt+F4 would corrupt a save in progress, actually doing so would require the developers to quite deliberately go out of their way to screw up the saving system.

From a coding perspective, the user pressing Alt+F4 does not "close the active window," nor does it "interrupt the program." What it does is cause Windows to place a WM_CLOSE message onto the program's event queue. That's all.

There are two things to keep in mind here. The first is that the event loop is a linear thing: you don't process event #2 until you're finished processing event #1.

And the second is that a WM_CLOSE message does not "quit the program". It's a special type of input, nothing more. It tells the program that the user has requested that the program close down the current window. The program is free to respond to this in whatever way its code says to, including ignoring it entirely. (This is a very rude thing to do, but developers occasionally do it.) One of the most common responses is to ask the user "Do you want to save before quitting?" and/or provide a way to cancel the close request.

So what happens if the user presses Alt+F4 while the game is in the middle of saving? Keep in mind the first point: processing is linear. Assuming that the save is taking place in the main thread—which I'll cover a bit further on—the code can't even check the event queue to see that it's been sent a WM_CLOSE message until after saving is complete. Therefore there's nothing to interrupt.

TL;DR: If your game already performs autosaves without corrupting itself, it's safe to assume that there is no risk of corruption in politely asking the game to shut down, (which is what Alt+F4 does,) even if you do so in the middle of a save. When warning screens tell you not to shut down the game while saving, it refers to turning off the power or other more drastic ways of terminating gameplay.

As a programmer, both answers posted so far are incorrect. While it's possible to come up with a hypothetical situation in which pressing Alt-F4 would corrupt a save in progress, actually doing so would require the developers to quite deliberately go out of their way to screw up the saving system.

From a coding perspective, the user pressing Alt-F4 does not "close the active window", nor does it "interrupt the program." What it does is cause Windows to place a WM_CLOSE message onto the program's event queue. That's all.

So what happens if the user presses Alt-F4 while the game is in the middle of saving? Keep in mind the first point: processing is linear. Assuming that the save is taking place in the main thread, (which I'll cover a bit further on,) the code can't even check the event queue to see that it's been sent a WM_CLOSE message until after saving is complete. Therefore there's nothing to interrupt.

This is actually one of the first things anyone learns about multithreading: never let two threads touch the same data at the same time if one (or both) of them is going to be changing it. Failing to follow this principle creates race conditions where data gets corrupted and things fail in bizarre ways. Any competent developer is going to go out of their way to avoid scenarios in which a race condition would pop up. So one developer checking in code that performs a save on a separate thread would most likely be looked upon with horror by the rest of the dev team!

As a programmer, both answers posted so far are incorrect. While it's possible to come up with a hypothetical situation in which pressing Alt-F4 would corrupt a save in progress, actually doing so would require the developers to quite deliberately go out of their way to screw up the saving system.

From a coding perspective, the user pressing Alt-F4 does not "close the active window", nor does it "interrupt the program." What it does is cause Windows to place a WM_CLOSE message onto the program's event queue. That's all.

So what happens if the user presses Alt-F4 while the game is in the middle of saving? Keep in mind the first point: processing is linear. Assuming that the save is taking place in the main thread, (which I'll cover a bit further on,) the code can't even check the event queue to see that it's been sent a WM_CLOSE message until after saving is complete. Therefore there's nothing to interrupt.

This is actually one of the first things anyone learns about multi-threading: never let two threads touch the same data at the same time if one (or both) of them is going to be changing it. Failing to follow this principle creates race conditions where data gets corrupted and things fail in bizarre ways. Any competent developer is going to go out of their way to avoid scenarios in which a race condition would pop up. So one developer checking in code that performs a save on a separate thread would most likely be looked upon with horror by the rest of the dev team!

There are two things to keep in mind here. First is that the event loop is a linear thing: you don't process event #2 until you're finished processing event #1. And the second is that a WM_CLOSE message does not "quit the program". It's a special type of input, nothing more. It tells the program that the user has requested that the program close down the current window. The program is free to respond to this in whatever way its code says to, including ignoring it entirely. (This is a very rude thing to do, and any game developer who does this seriously sucks, but they do occasionally do it.) One of the most common responses is to ask the user "Do you want to save before quitting?" and/or provide a way to cancel the close request.

It's always possible to have a computer program doing two things at once. This is known as multithreading, running two or more linear "threads" of code execution at the same time. So someone might ask, "what if it's saving in a different thread while the WM_CLOSE message comes in and gets processed?" The answer to that question is that any developer who does this is an idiot whose code is likely to corrupt savefiles left and right even without the user requesting a quit at an inopportune moment. This is because saving means writing out to disc a copy of the state of the game at the moment. If you do this without interrupting the game, it's possible that something can change in between when you start to save and when you finish, and then the save file ends up with some data that refers to the old state of the game and some that refers to the new state, which don't make any sense together, and you now have a corrupted save file.

There are two things to keep in mind here. First is that the event loop is a linear thing: you don't process event #2 until you're finished processing event #1. And the second is that a WM_CLOSE message does not "quit the program". It's a special type of input, nothing more. It tells the program that the user has requested that the program close down the current window. The program is free to respond to this in whatever way its code says to, including ignoring it entirely. (This is a very rude thing to do, but developers occasionally do it.) One of the most common responses is to ask the user "Do you want to save before quitting?" and/or provide a way to cancel the close request.

It's always possible to have a computer program doing two things at once. This is known as multithreading, running two or more linear "threads" of code execution at the same time. So someone might ask, "what if it's saving in a different thread while the WM_CLOSE message comes in and gets processed?" The answer to that question is that any developers who do this, their code is likely to corrupt savefiles left, right and center even without the user requesting a quit at an inopportune moment. This is because saving means writing out to disc a copy of the state of the game at the moment. If you do this without interrupting the game, it's possible that something can change in between when you start to save and when you finish, and then the save file ends up with some data that refers to the old state of the game and some that refers to the new state, which don't make any sense together, and you now have a corrupted save file.