[Bug 24369] New: UCS-4 trick not working with resource files

http://bugs.winehq.org/show_bug.cgi?id=24369

Summary: UCS-4 trick not working with resource files
           Product: Wine
           Version: unspecified
          Platform: x86
        OS/Version: Windows 98
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Created an attachment (id=30717)
 --> (http://bugs.winehq.org/attachment.cgi?id=30717)
Resource file for testing

Here there is an extract of my email sent to wine-devel mailing list about this
problem:

==== CUT = CUT = CUT

Let's take for example this piece of code from richedit.h:

#if defined(__GNUC__)
# define RICHEDIT_CLASS20W (const WCHAR []){ 
'R','i','c','h','E','d','i','t','2','0','W',0 }
#elif defined(_MSC_VER)
# define RICHEDIT_CLASS20W      L"RichEdit20W"
#else
static const WCHAR RICHEDIT_CLASS20W[] = { 
'R','i','c','h','E','d','i','t','2','0','W',0 };
#endif

Because the famous UCS-4 "issue", the control name is splitted in its single
letters.
While this can work in almost all situations with C/C++ sources, it is
absolutely not possible to put a richedit control in RC files.
For example, if I put a Richedit control into a dialog box, it will crash since
the letter by letter format won't be recognized by the resource compiler.
> From the above example, I was wondering what you think about doing a change

like this one:

#if defined _MSC_VER || defined RC_INVOKED || sizeof(wchar_t) == 2
# define RICHEDIT_CLASS20W      L"RichEdit20W"
#elif defined(__GNUC__)
# define RICHEDIT_CLASS20W (const WCHAR []){ 
'R','i','c','h','E','d','i','t','2','0','W',0 }
#else
static const WCHAR RICHEDIT_CLASS20W[] = { 
'R','i','c','h','E','d','i','t','2','0','W',0 };
#endif

We will fall in the first case when the name expressed as string is currently
recognized:
1) because we are running under Microsoft Visual C++
2) because it is used by resource compiler
3) because the string format is currently safe since we are under UCS-2 
instead of UCS-4. Perhaps this point is not written as good as you want... I do
not know if you prefer to use some informations emitted by configure script or
you will prefer to simply check the size of wchar_t.

The second case is the specific hack normally used until now with GCC.

The third case is the last chance solution, as it was before.

I moved the __GNUC__ case after the one used by _MSC_VER because __GNUC__ and
RC_INVOKED are both declared in windres.
Now I took this fragment from richedit.h as example, but perhaps I have also
seen other places where the resource compiler could be "rejected".

==== CUT = CUT = CUT

According to the reply I received, I'm creating a bug here and I tried to
create a resource file that could be used for inspecting the problem.

I tried my best but unfortunately, as you can see on top of this bug, I'm not
using directly an operating system that allows the testing of WINE.
The defect has been noticed by me when trying to compile an application with
ReactOS' sources which uses the same exact system include files normally used
by WINE.

I hope all this could be useful.