
According to the comments in the
article about the notebook , in all versions of Microsoft Excel, starting at least from '97 and up to the newest, you cannot always enter a large letter G. in the name of the sheet. This problem has been discussed on the network for a long time, for example,
on this forum it's funny to watch as some claim that they have no problem, while others have, but not always, and no one understands why. At first glance, you might think that this is just a flaw in the programmers: they wanted to prevent the user from entering the ':' character, and simply did not think that the button was on the same button.
In fact, it turned out to be much worse. It’s almost impossible to describe with normal words what happens in excel when you just press the 'F' button. Therefore, I will try to outline the whole research process, reducing it where possible, and not overloading the article with assembly code. As a result, we will find out why it turns out that not all characters can be entered, and how this can be corrected.
Where to begin? Let's experiment a little. It turns out that sometimes you can enter the in the name of the sheet, and if it worked once, then you can enter it any number and anywhere, until you close Excel. And if it did not work, then no matter how hard you try, it will not be possible to enter this letter in any way. Find out why this happens until you succeed. One thing is known: you can always copy it.
')

Oh well. Since there is an error somewhere in the code for checking symbols, we will try to find it through the really forbidden character ':'. Copy-paste it into the name of the sheet, press Enter, and get a message that such characters are not allowed. Interrupt the program at this place. We get somewhere in the jungle of system calls, led by user32.dll, total nesting 22 in the depth of the stack. We start looking for how we got here. Going up about 15 levels, we find the following code:

Obviously, here in the already typed line, the presence of all characters forbidden in the sheet name is checked. Of course, as we already know, the letter '' does not reach this place, it is cut down even when the key itself is pressed, but it can be assumed that the analysis is similar there. Let's look for a similar code in the program. There are several similar places, and one of them just works when you press a key when we are in editing the name of the sheet:

So far so good. When pressed, the same characters are checked. The code is a little different, well, the compiler worked that way. It's time to find out why the letter 'F' is not entered. We press it, and here we are in for a surprise: the breakpoint does not work! How so? Again you have to go back up the call stack. In this subroutine we get from here:

That is, the subroutine is called at the address that is contained in the rdi plus 8 register. But it turns out that when you press most of the keys, there will be the address of the same “correct” subroutine we saw above. And if we press F with shifty (so that it is large), a completely different subroutine appears in this place. Here she is:

This is a “come on, goodbye!” Subroutine. That is, it ends immediately with code 1, nothing is analyzed, and the pressed key is not saved anywhere.
We found a classic table call. rdi is an index register, its contents point to an address table, and depending on its contents, one or another subroutine is called. Here is the table:

Analyzing the code that works with it, we managed to find out the following: at the beginning of the table - the number of rows (0Eh = 14), though for some reason 2 times. Each line - a description of the key combination. First, the range of scan codes (highlighted in green), then the valid states shift, alt and Ctrl (bits 4,8,20 - blue), the mask for them (red), and at the end the 64-bit address of the subroutine (yellow), which is executed at coincidence of conditions. Big F in this table is in the 6th row.

The scan code 0BAh (VK_OEM_1), when you press the shift (4), leads to a call to 000000013FB0A454 = "goodbye". If none of the combinations passes, then in the last line the code from 0 to FF is triggered, and p / p 000000014039530S is called, part of which we saw above, where everything goes according to the usual plan, and the symbol falls into the name of the sheet.
Here you go. It would seem, everything is clear. Programmers did not take into account the layout, they simply cut off some scan codes and, as a result, an error occurred. Now it only remains to find out how the table is filled. Nowhere in the files of the office is there, then it is generated at the execution stage. The dreary wandering through the multivailable codes, which I will skip again, repeats. In this process, of course, excel had to be restarted many times.
And so, once again stopping somewhere in the depths of the mso.dll, I am surprised to see that there are some completely different numbers in this table! So I finally learned the terrible secret of microsoft excel.

As you can see, there are now not 14, but 13 lines, and in the middle are other scan codes (highlighted in green). Namely, in the sixth line, where the letter F used to be, now shift-6. That is the same colon, only from the Russian layout. Same with the rest of the keys. Now everything really became clear. It quickly became clear that there are not only one such table here, but 43 as many (for each screen area, separately for the main field, formula input fields, etc.). And all of them are filled once, at the first keystroke, and the filling depends on the layout chosen
at that moment and never changes again.
That is, if, after running excel, the first time you press any key, even the down arrow, the English layout is selected, you will no longer see the letter ''. And vice versa, if the layout was Russian, there would be plenty of large 'F', and the shift-b would be “forbidden” and, by the way, shift-7 too. And after that call the sheet, say, "horns & hooves" will not work, although the symbol '&' seems to be allowed.
Let me remind you once again that all of the above applies to entering text in the title of a sheet, and for the rest of the excel screen areas, the tables are different, some 40 or more lines. The fact that there may occur when you press the keys, it is better not to think.
However, this error can be corrected, and even easier than expected. It turned out that the source material for filling in all these tables is a text (!) Table of shortcut keys located in the XLINTL32.DLL file located in one of the office folders. A part of it is just depicted on the KDPV.
Here is a fragment concerning the name of the sheet:
~ Sh + ~ Alt + ~ Ctrl + Return ~ Sh + ~ Alt + ~ Ctrl + Execute ~ Sh + ~ Alt + ~ Ctrl + Escape ~ Sh + ~ Alt + ~ Ctrl + Cancel
~ Sh + ~ Alt + ~ Ctrl + Tab: *? Ctrl +; Ctrl +: Ctrl + 'Ctrl + "F2Default
What does excel do? He parses the parts of this line and makes of it the very table, selecting such scan codes that would lead to the input of the necessary characters, taking into account the layout. Imagine? He analyzes the textual representation in order to make a table of scan codes out of it, so that later, when pressing keys, compare the received code with each line and call the corresponding procedure. Filling all 43 tables with each press is naturally not suitable. Therefore, it is done once. So programmers did not forget about layouts, but did a lot of work with them. Only one thing they did not take into account - during the work of excel, they can be switched.
By the way, it is now clear why the Russian version does not have 14 lines, but 13. One of the forbidden Ctrl + 'combinations is impossible in the Russian layout, because there is basically no apostrophe in it, therefore, there is no scan code for it.
Let us return, however, to the error. In the middle of the text you can see those 3 characters in a row: *? for prohibition. To fix this, it’s enough to replace these 3 characters in the XLINTL32.DLL file: *? for 3 stars, because the asterisk on both layouts in one place. This can be done with the help of any binary editor or even FAR, since it allows you to change the text portion of a binary file using F4, without spoiling it.
After that, excel will cease to discard the necessary scan codes, and it will be possible at any layout to enter a large F, '&', '^' and a comma, while actually forbidden ':' and '?' anyway, 2 checks that are described at the beginning of the article will not pass. In short everything will be fine. And the next time you type some text in a Word or another office application, try not to think about what's going on inside.