UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.97 Safari/537.36 Vivaldi/1.94.1008.36

Steps to reproduce the problem:
1. Create a dialog in an rc file (e.g. setup.rc)
2. Add LTEXT string element that is broken across two or more lines using the backslash line continuation method, and indent the lines of the string so that the text string of all parts of the string starts at the same line position
3. Build the executable with the new rc.exe in v64

pseudo code:

IDD_DIALOG1 DIALOGEX 0, 0, 360, 290
STYLE DS_SETFONT | DS_MODALFRAME | DS_3DLOOK | DS_FIXEDSYS | DS_CENTER | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "Foo"
FONT 8, "MS Shell Dlg", 400, 0, 0x1
BEGIN
    LTEXT           "First part of string. \
                     Second part of string. There should only be a single space in front of this part of the string.", IDC_STATIC_INFO, 32, 185, 305, 25, SS_LEFT
END

What is the expected behavior?
Visual Studio 2017 rc.exe will ignore all indentation on the second line of the continued string, and just use the whitespace *before* the backslash, and continue with the text when encountering the first non-whitespace character of the string.

What went wrong?
When building an rc file with such an LTEXT element, Chromium 64 rc.exe will keep the spaces in the indentation. 

Since VS rc.exe will not keep the indentation, the following binary compare of the two results will fail due to the different strings, and the build will fail.

If the resulting file had been used in an executable, the dialog element would have contained a large space section in the middle of the displayed string.

Did this work before? Yes 63.0.3239.84

Chrome version: 64.0.3282.2  Channel: dev
OS Version: 10.0
Flash Version: 

Vivaldi is presently using a dialog in its installer with an LTEXT element formatted this way.

At present we are overriding the use of chromium 64's rc.exe for this file, using VS 2017 instead, mostly due to another issue https://bugs.chromium.org/p/chromium/issues/detail?id=794598 . Once that is solved, provided this issue is not fixed before then, we will likely use one of the workarounds discussed below.

This way of breaking up and formatting a string is used to 1) avoid long lines of text by continuing the text across several lines instead of one long line, and 2) indent the text to make the source more readable.

It is possible to avoid the problem by using either one long line, or by not indenting the text. Both of these methods produce less readable code.