Hello!

Can somebody explain why Fasm and Fresh examples save ebx, esi, and edi registers on stack at the start of WindowProc and restore them at the end?
Is it some kind of Windows API requirement?

yes, these registers are used internally by system, destroing their values may cause process fault.

I've tried to compile and run a few programs without these pushes and pops and everything seems to be Ok.
Is there any official document concerning this issue?

if you do not change these registers that saving has no sense, except for the reason "to not forget".
ebx is not used in w9x and wxp, but used in w2k (wnt - just do not know) it all depends on current usage of these registers by system: there could be a problem, but you may not see it if it is not fatal, but it may cause fault later. i heard about calling conventions (but did not see them) - if you will call win api function it will (may) destroy ecx, eax and edx (eax and edx/eax are used to return result) and will preserve ebx, edi and esi, so, do it same.
personally, i do not preserve these registers when i do not use them inside winproc, and if i do - i preserve exactly in place where i'm using them.

I've googled a lot of documents about the subject but none from MS. All I've found in MSDN is that "if you use asm-inlines in your C-program then you should preserve these registers because C-compilers use this convention to keep some internal data in these registers between function calls" - I'm not using any C-compiler, just FAsm . Also have found in MSDN a preliminary specification for developing drivers for 64-bit Windows which says that RBX, RSI, and RDI (as well as a few additional Rn registers) must be preserved. But there's nothing about 32-bit Windows register preserving requirements. Maybe there is, but I couldn't find it.
In my programs I have changed ebx register without preserving its' content and it worked fine, but that's probably because I have XP on my machine.
Anyway, thanks for your answer.

As for your own functions which only you call and use, you're free to use registers in any way you want. When you call any official API, you can be sure that it preserves EBX, ESI and EDI - what makes things easier sometimes when you have to do many API calls in a row. And when you create any function that may get called by Windows or some other application (like the WindowProc, DialogProc, any hooks etc.), you also need to preserve those registers.

This is part of the so-called standard calling convention specification.
Quoted from WinDbg documentation:

Calling Conventions
The x86 architecture has several different calling conventions. Fortunately, they all follow the same register preservation and function return rules:

Functions must preserve all registers, except for eax, ecx, and edx, which can be changed across a function call, and esp, which must be updated according to the calling convention.
The eax register receives function return values if the result is 32 bits or smaller. If the result is 64 bits, then the result is stored in the edx:eax pair.

The following is a list of calling conventions used on the x86 architecture:

Win32 (__stdcall)
Function parameters are passed on the stack, pushed right to left, and the callee cleans the stack.

Native C++ method call (also known as thiscall)
Function parameters are passed on the stack, pushed right to left, the "this" pointer is passed in the ecx register, and the callee cleans the stack.

COM (__stdcall for C++ method calls)
Function parameters are passed on the stack, pushed right to left, then the "this" pointer is pushed on the stack, and then the function is called. The callee cleans the stack.

__fastcall
The first two DWORD-or-smaller arguments are passed in the ecx and edx registers. The remaining parameters are passed on the stack, pushed right to left. The callee cleans the stack.

__cdecl
Function parameters are passed on the stack, pushed right to left, and the caller cleans the stack. The __cdecl calling convention is used for all functions with variable-length parameters.

Thanks for your comments.
I already got the point. I only wonder, why it is so hard (if possible at all) to get this information from MS.