Custom Query (80 matches)

Build of ntdll is no longer possible with gcc 4.x; still working with gcc 3.x

Revision 21376 compiles also with gcc 4.x; I think there is something not working correctly with NAMELESS structures support. Maybe some header with wrong defines.

There is a bunch of constants (such as IP_ADD_MEMBERSHIP) that were redefined by Microsoft in WinSock2 and have values incompatible with WinSock1. We miss these new defines in Odin headers and simply fall back to old ones.

While it seems to work at binary level (because the values for constants supplied to Odin by the application are taken from the real MS SDK when the application is built and get properly recognized by the new WinSock2 APIs in the Odin code), compiling applications at source level drags the old constants in while actually calling the new WinSock2 APIs and as a result these APIs get wrong parameters and return a failure.

It is known that there are two system encodings in Windows: the ANSI encoding (used all over in the GUI APIs) and the OEM encoding (used for compatibility with DOS applications and in particular in the command line sessions for file and console output). For God knows what reasons, in some locales, these two encodings differ. For example, in .ru, we have cp1251 (windows-1251) for ANSI and IBM-866 for OEM (this is the same as in OS/2 and MS/PC DOS).

I found out that at least one UI function, MessageBox?(), expects two encodings at the same time for two its different arguments: the window title bar should be in IBM866 while the message text itself -- in windows-1251. I guess this happened to be like that because message text is drawn by Odin on its own (and hence the ANSI encoding is expected) while the title bar is drawn by the system (using the OS/2 encoding which is the same as OEM). This is completely wrong and needs to be fixed. According to Win32 docs, ANSI should be supplied in both cases.