Re: [ros-dev] SendMessageW doubt/bug with ANSI LPARAM.
Hi, this is still not correct. SendMessage is not a function but a macro. When the PROGRAM is compiled as unicode SendMessage is translated to SendMessageW and otherwise it is translated to SendMessageA. Now regarding the convertion fron ansi to unicode or unicode to ansi, this is done when win32k calls user32 in the receiving process here: http://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/user32/windows/message.c;h=4e5e3430ced3df5242ace2f6c3725357ca01f024;hb=HEAD#l497 and http://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/user32/windows/message.c;h=4e5e3430ced3df5242ace2f6c3725357ca01f024;hb=HEAD#l828 ReactOS Development List ros-dev@reactos.org wrote on Thu, November 17th, 2011, 3:09 AM: Thanks Timo for your explanation. So let me see if I understood correctly. When TC calls SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext); it could be translated to SendMessageW or to SendMessageA accordingly to the window(*) that receives the message: -If the receiving window is ANSI the SendMessage is translated to SendMessageA and the Lparam is converted to ANSI(in this case there isn't needed any translation as it was originally ANSI). -If the receiving window is UNICODE the SendMessage is translated to SendMessageW and the Lparam is converted(**),in this case, from ANSI to UNICODE, so SendMessageW is receiving an UNICODE string instead the original ANSI one. Feel free to correct me if I am wrong. My doubts are: (*)When talking about the receiving Window...Which Window are we talking about in this particular case?Isn't the SendMessage supposed to be sent to the ComboBox window? (**)If I understood correctly, the LParam originally ANSI is translated to UNICODE before being sent to the SendMessageW. Which function/macro does this translation?Just curious... So the problem maybe is in the **p*rintf function that prints the line in the Combobox? Thanks again for your time Víctor Date: Wed, 16 Nov 2011 21:14:07 +0100 From: timo.kreu...@web.de To: ros-dev@reactos.org Subject: Re: [ros-dev] SendMessageW doubt/bug with ANSI LPARAM. Am 16.11.2011 16:12, schrieb victor martinez: The Total Commander comboboxes for the left and right drive list are Unicode. However, Total Commander calls SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext); to add items as ANSI text. This seems to work, but it's adding some extra text at the end. If I understand correctly, Total Commander is calling SendMessage, which in this case is translated to SendMessageW (as the comboboxes are Unicode). No, the fact that the combo boxes are unicode, doesn't mean TC is calling SendMessageW, It could very well call SendMessageA and pass an ansi string. If it passes an ANSI string to SendMessageW then it's doing it wrong. The message is supposed to be translated accordingly when it's passed to the recevier, based on whether the receiving window is ANSI or unicode. The problem also doesn't seem to be ANSI vs unicode, but the extra text at the end. First thought: someone forgot that UNICODE_STRINGs are not neccessarily 0 terminated. Timo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tfaber] 54401: [ATL] - Fix buffer overflow in CComDynamicUnkArray::Add. Found by Coverity (CID 2474) [NDK] - Remove meaningless const attribute from pointer rvalues to make
On 2011-11-17 12:07, Timo Kreuzer wrote: Am 16.11.2011 22:17, schrieb tfa...@svn.reactos.org: -#define SharedUserData ((KUSER_SHARED_DATA *CONST)USER_SHARED_DATA) +#define SharedUserData ((KUSER_SHARED_DATA *)USER_SHARED_DATA) It is like this (with the const) in wdm.h #define SharedUserData ((KUSER_SHARED_DATA * const) KI_USER_SHARED_DATA) maybe its supposed to express that SharedUserData is a constant and not a variable... although that doesn't make much sense Hmm. Interesting. Didn't spot it in wdm.h. Thanks! Apparently, MS doesn't use Coverity (what a shock :D) It could certainly be argued that it has some value as an annotation. But since the const is neither wrong in any way nor makes any difference at all, I think ~300 Coverity parse warnings are a good reason to remove it. I'll fix it in our wdm.h too later, unless someone disagrees. Thanks, Tom ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] SendMessageW doubt/bug with ANSI LPARAM.
Hi Giannis!So I will check if the MsgiAnsiToUnicodeMessage is being called at all(I've tracked down the code from SendMessageW and SendMessageA and I didnt find any call to this function,yet), if so, I will check if 507 RtlCreateUnicodeStringFromAsciiz(UnicodeString, (LPSTR)AnsiMsg-lParam);is behaving correctly just comparing the UnicodeString vs the AnsiLparam one.Thanks a lot!Debugging time! From: giannis.adamopou...@reactos.org To: ros-dev@reactos.org Date: Thu, 17 Nov 2011 11:53:41 +0100 Subject: Re: [ros-dev] SendMessageW doubt/bug with ANSI LPARAM. Hi, this is still not correct. SendMessage is not a function but a macro. When the PROGRAM is compiled as unicode SendMessage is translated to SendMessageW and otherwise it is translated to SendMessageA. Now regarding the convertion fron ansi to unicode or unicode to ansi, this is done when win32k calls user32 in the receiving process here: http://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/user32/windows/message.c;h=4e5e3430ced3df5242ace2f6c3725357ca01f024;hb=HEAD#l497 and http://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/user32/windows/message.c;h=4e5e3430ced3df5242ace2f6c3725357ca01f024;hb=HEAD#l828 ReactOS Development List ros-dev@reactos.org wrote on Thu, November 17th, 2011, 3:09 AM: Thanks Timo for your explanation. So let me see if I understood correctly. When TC calls SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext); it could be translated to SendMessageW or to SendMessageA accordingly to the window(*) that receives the message: -If the receiving window is ANSI the SendMessage is translated to SendMessageA and the Lparam is converted to ANSI(in this case there isn't needed any translation as it was originally ANSI). -If the receiving window is UNICODE the SendMessage is translated to SendMessageW and the Lparam is converted(**),in this case, from ANSI to UNICODE, so SendMessageW is receiving an UNICODE string instead the original ANSI one. Feel free to correct me if I am wrong. My doubts are: (*)When talking about the receiving Window...Which Window are we talking about in this particular case?Isn't the SendMessage supposed to be sent to the ComboBox window? (**)If I understood correctly, the LParam originally ANSI is translated to UNICODE before being sent to the SendMessageW. Which function/macro does this translation?Just curious... So the problem maybe is in the **p*rintf function that prints the line in the Combobox? Thanks again for your time Víctor Date: Wed, 16 Nov 2011 21:14:07 +0100 From: timo.kreu...@web.de To: ros-dev@reactos.org Subject: Re: [ros-dev] SendMessageW doubt/bug with ANSI LPARAM. Am 16.11.2011 16:12, schrieb victor martinez: The Total Commander comboboxes for the left and right drive list are Unicode. However, Total Commander calls SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext); to add items as ANSI text. This seems to work, but it's adding some extra text at the end. If I understand correctly, Total Commander is calling SendMessage, which in this case is translated to SendMessageW (as the comboboxes are Unicode). No, the fact that the combo boxes are unicode, doesn't mean TC is calling SendMessageW, It could very well call SendMessageA and pass an ansi string. If it passes an ANSI string to SendMessageW then it's doing it wrong. The message is supposed to be translated accordingly when it's passed to the recevier, based on whether the receiving window is ANSI or unicode. The problem also doesn't seem to be ANSI vs unicode, but the extra text at the end. First thought: someone forgot that UNICODE_STRINGs are not neccessarily 0 terminated. Timo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Qemu Recoverable Assertion when Loading Gecko
Head up on this one. It's recoverable by just typing cont and it goes on. (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\system32\oleaut32.dll WARNING: MmFlushVirtualMemory at ntoskrnl/mm/ARM3/virtual.c:1044 is UNIMPLEMENTED! fixme:(dll/win32/wintrust/register.c:1161) stub (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name C:\ReactOS\system32\mshtml.dll (7665 - 014C) (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\System32\setupapi.dll (ntoskrnl/se/semgr.c:299) SidInToken Calls: 4 Assertion 'RtlCheckBit(MiUserPfnBitMap, (ULONG)Page)' failed at ntoskrnl/mm/freelist.c line 127 Entered debugger on embedded INT3 at 0x0008:0x80904efe. kdb: bt Eip: NTOSKRNL.EXE:104eff (lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0)) Frames: NTOSKRNL.EXE:c283d (ntoskrnl/mm/freelist.c:127 (MmRemoveLRUUserPage@4)) NTOSKRNL.EXE:c18de (ntoskrnl/mm/balance.c:134 (MmReleasePageMemoryConsumer@8)) NTOSKRNL.EXE:cbf6a (ntoskrnl/mm/section.c:2365 (MmPageOutSectionView@16)) NTOSKRNL.EXE:c822c (ntoskrnl/mm/rmap.c:143 (MmPageOutPhysicalAddress@4)) NTOSKRNL.EXE:c17a9 (ntoskrnl/mm/balance.c:177 (MmTrimUserMemory)) NTOSKRNL.EXE:c141c (ntoskrnl/mm/balance.c:366 (MiBalancerThread@4)) NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8)) NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0)) NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28)) fcdebd80 NTOSKRNL.EXE:152e5 (ntoskrnl/ke/wait.c:527 (KeWaitForSingleObject@20)) NTOSKRNL.EXE:c524e (ntoskrnl/mm/mminit.c:292 (MmMpwThreadMain@4)) NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8)) NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0)) NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28)) fce4fab0 0001 kdb: cont Assertion 'RtlCheckBit(MiUserPfnBitMap, (ULONG)Page)' failed at ntoskrnl/mm/freelist.c line 127 Entered debugger on embedded INT3 at 0x0008:0x80904efe. kdb: cont (subsystems/win32/win32k/ntuser/keyboard.c:1066) err: No Window for Translate. (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name xul.dll (1000 - 01DB) (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\system32\ \1.0.0\wine_gecko\xpcom.dll ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Qemu Recoverable Assertion when Loading Gecko
Where is the typo? Is it? http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/freelist.c?r1=53734r2=54386 On Thu, Nov 17, 2011 at 6:07 PM, James Tabor jimtabor.ros...@gmail.com wrote: Assertion 'RtlCheckBit(MiUserPfnBitMap, (ULONG)Page)' failed at ntoskrnl/mm/freelist.c line 127 Entered debugger on embedded INT3 at 0x0008:0x80904efe. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cgutman] 54415: [I8042PRT] - Implement support for hot plugging PS/2 mice if one was present at boot (same requirement as Windows) - Fixes bug 1395
Am 18.11.2011 00:41, schrieb cgut...@svn.reactos.org: Author: cgutman Date: Thu Nov 17 23:41:18 2011 New Revision: 54415 URL: http://svn.reactos.org/svn/reactos?rev=54415view=rev Log: [I8042PRT] - Implement support for hot plugging PS/2 mice if one was present at boot (same requirement as Windows) - Fixes bug 1395 Exellent! -- Johannes Anderwald ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
