Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] [ros-diffs] [jimtabor] 50933: [Win32k|User32] - Clarify the meaning and the
by Johannes Anderwald 07 Mar '11

07 Mar '11

> Author: jimtabor > Date: Mon Feb 28 06:31:44 2011 > New Revision: 50933 > > URL: http://svn.reactos.org/svn/reactos?rev=50933&view=rev > Log: > [Win32k|User32] > - Clarify the meaning and the use of 0, 1 and 2 for user window regions, wine never did. Noticing patches not corresponding in correctness and understanding, leaving potential crashes in the DCE code, which depend on these types. > - Patch based on Rafal Harabien patch, fixes wine msg SetWindowRgn test, see also bug 5959. This change breaks Winamp 5.601: (ntoskrnl/ps/thread.c:119) PS: Unhandled Kernel Mode Exception Pointers = 0xF86A8568 (ntoskrnl/ps/thread.c:126) Code c0000005 Addr F87D4C3E Info0 00000000 Info1 00000020 Info2 00000000 Info3 00000020 *** Fatal System Error: 0x0000007e (0xC0000005,0xF87D4C3E,0xF86A8A50,0xF86A8690) [7hEntered debugger on embedded INT3 at 0x0008:0x808fd45c.bt Eip: <ntoskrnl.exe:fd45d (lib/rtl/i386/debug_asm.S:39 (RtlpBreakWithStatusInstruction))> Frames: <ntoskrnl.exe:a902 (ntoskrnl/ke/bug.c:1110 (KeBugCheckWithTf@24))> <ntoskrnl.exe:aa4d (ntoskrnl/ke/bug.c:1438 (KeBugCheckEx@20))> <ntoskrnl.exe:ead94 (ntoskrnl/ps/thread.c:129 (PspUnhandledExceptionInSystemThread))> <ntoskrnl.exe:eadaf (ntoskrnl/ps/thread.c:159 (_SEHExcept.39966))> <ntoskrnl.exe:fa9fa (lib/pseh/i386/framebased-gcchack.c:132 (_SEH2FrameHandler))> <ntoskrnl.exe:fcecb (lib/rtl/i386/except_asm.s:183 (RtlpExecuteHandler2))> <ntoskrnl.exe:fce9f (lib/rtl/i386/except_asm.s:150 (RtlpExecuteHandlerForUnwind))> <ntoskrnl.exe:3222 (ntoskrnl/ke/i386/exp.c:938 (KiDispatchException@20))> <ntoskrnl.exe:36bd (ntoskrnl/ke/i386/exp.c:1137 (KiDispatchExceptionFromTrapFrame@28))> <ntoskrnl.exe:6941 (ntoskrnl/include/internal/arch/../i386/ke.h:597 (@KiTrap0EHandler@4))> <ntoskrnl.exe:f7408 (ntoskrnl/ke/i386/trap.s:99 (VfIsVerificationEnabled@8))> <win32k.sys:bac39 (subsystems/win32/win32k/objects/region.c:2104 (@RGNOBJAPI_Lock@8))> <win32k.sys:bb0b3 (subsystems/win32/win32k/objects/region.c:3753 (NtGdiPtInRegion@12))> <win32k.sys:71bbb (subsystems/win32/win32k/ntuser/msgqueue.c:248 (@co_MsqInsertMouseMessage@4))> <win32k.sys:5ded4 (subsystems/win32/win32k/ntuser/cursoricon.c:205 (UserSetCursorPos))> <win32k.sys:66630 (subsystems/win32/win32k/ntuser/input.c:1134 (@IntMouseInput@4))> <win32k.sys:66cca (subsystems/win32/win32k/ntuser/input.c:194 (@ProcessMouseInputData@8))> <win32k.sys:66fbf (subsystems/win32/win32k/ntuser/input.c:308 (MouseThreadMain@4))> <ntoskrnl.exe:eac86 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <ntoskrnl.exe:5936 (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <ntoskrnl.exe:eac22 (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> WBR, Johannes

2 9

Re: [ros-dev] [ros-diffs] [jgardou] 50991: [NTOSKRNL] - Print supported CPU features. - Simplify detection of non working but claimed SYSENTER support for intel processors - Workaround a virtualbox "feature" : claim that SY...
by Aleksey Bragin 07 Mar '11

07 Mar '11

On Mar 7, 2011, at 4:33 PM, jgardou(a)svn.reactos.org wrote: > Author: jgardou > /* Check if the CPU is too old to support SYSENTER */ > - if ((Prcb->CpuType < 6) || > - ((Prcb->CpuType == 6) && (Prcb->CpuStep < 0x0303))) > + if ((Reg[0] & 0x0FFF3FFF) < 0x00000633) > { It was intentionally done over CpuType and CpuStep. Now you criptified it back to a raw Reg[0] value and weird hardcoded constant. Could you please 1) elaborate this change and 2) if you still think it's correct, and if you still tihnk(!) Windows does it same way, then rework it to use Prcb->Cpu* instead of these magic values? Not to say adding a hack for VirtualBox is far from being a beautiful, and would need to be *at least* marked so that it's not forgotten. Thanks, Aleksey Bragin.

2 1

07 Mar '11

Am 07.03.2011 14:33, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Mar 7 13:33:10 2011 > New Revision: 50991 > ... > + Reg[3] |= 0x800; > ... > + if ((Reg[0]& 0x0FFF3FFF)< 0x00000633) I'd prefer symbolic constants over these magic numbers. > + > + DPRINT1("Supported CPU features :\n"); > +#define print_supported(kf_value) \ > + if(FeatureBits& kf_value) DPRINT1("\t" #kf_value "\n") > + print_supported(KF_V86_VIS); > + print_supported(KF_RDTSC); > + print_supported(KF_CR4); > + print_supported(KF_CMOV); > + print_supported(KF_GLOBAL_PAGE); > + print_supported(KF_LARGE_PAGE); > + print_supported(KF_MTRR); > + print_supported(KF_CMPXCHG8B); > + print_supported(KF_MMX); > + print_supported(KF_WORKING_PTE); > + print_supported(KF_PAT); > + print_supported(KF_FXSR); > + print_supported(KF_FAST_SYSCALL); > + print_supported(KF_XMMI); > + print_supported(KF_3DNOW); > + print_supported(KF_AMDK6MTRR); > + print_supported(KF_XMMI64); > + print_supported(KF_DTS); > + print_supported(KF_NX_BIT); > + print_supported(KF_NX_DISABLED); > + print_supported(KF_NX_ENABLED); > +#undef print_supported Can we make this more compact please? Like "Supported CPU features: V86_VIS, RDTSC ..." Thanks, Timo

3 2

[ros-diffs] [jimtabor] 50987: [GDI32] - Remove the old SetDIBBits, it severed us well....
by James Tabor 07 Mar '11

07 Mar '11

[GDI32] - Remove the old SetDIBBits, it severed us well.... Hold on to the win32k call. - Tested, Area.exe, wine gdi32 bitmaps test, AbiWord 2.8.6, OOo 2.4.3, SM 2.0.11 and ReactOS applications. - Aimp 2.61.583 (FULL, painted okay), CoolPlayer 219, winamp 0.98d and winamp 2.95 (not FUll). The rest have drawing issue with DIB. See bug 5886. The sound applications have the same issue with revision 50933+ (region unassociated with the DC owner), except CoolPlayer and winamp 0.98d. There is also an issue with vbrun60spX too. I'm not sure how to move on and start compressed bitmaps. Thanks, James

1 0

Re: [ros-dev] [ros-diffs] [fireball] 50967: - Revert 47615. Please fix actual sysreg instead of adding inconsistency between 1st, 2nd and 3rd stages debugging connections. This should fix sysreg3's inability to do backtrace...
by Timo Kreuzer 06 Mar '11

06 Mar '11

Hmm... I remember I added it to enable the possibility for backtraces in 1st stage for sysreg. Why does it now cause the opposite? And why is there an inconsistency? In 2nd stage there is an option for debug mode, in 1st stage there is none, so using kdserial (which imo is appropriate way to do it, I always select it) as default is as consistent as using "normal" debug, getting the input from the keyboard driver. Just my 0,002 ct/kb Timo Am 04.03.2011 17:57, schrieb fireball(a)svn.reactos.org: > Author: fireball > Date: Fri Mar 4 16:57:56 2011 > New Revision: 50967 > > URL: http://svn.reactos.org/svn/reactos?rev=50967&view=rev > Log: > - Revert 47615. Please fix actual sysreg instead of adding inconsistency between 1st, 2nd and 3rd stages debugging connections. This should fix sysreg3's inability to do backtraces. > See issue #5811 for more details. > > Modified: > trunk/reactos/boot/bootdata/txtsetup.sif > > Modified: trunk/reactos/boot/bootdata/txtsetup.sif > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/txtsetup.sif… > ============================================================================== > --- trunk/reactos/boot/bootdata/txtsetup.sif [iso-8859-1] (original) > +++ trunk/reactos/boot/bootdata/txtsetup.sif [iso-8859-1] Fri Mar 4 16:57:56 2011 > @@ -59,7 +59,7 @@ > [SetupData] > DefaultPath = \ReactOS > OsLoadOptions = "/NOGUIBOOT /NODEBUG" > -DbgOsLoadOptions = "/NOGUIBOOT /DEBUGPORT=COM1 /FIRSTCHANCE /KDSERIAL" > +DbgOsLoadOptions = "/NOGUIBOOT /DEBUGPORT=COM1 /FIRSTCHANCE" > ;OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=SCREEN" > ;OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=BOCHS" > > > >

3 5

DHCP not working?
by Javier Agustìn Fernàndez Arroyo 04 Mar '11

04 Mar '11

Hi all, im testing ROS right now in real hardware... As i cannot log into IRC (via webchat.freenode.net, i cant even reach the page, i dont know why), let me post this in ML The think is, i have installed RealTek´s official driver for the NIC, and hardware is recognized... but, dhcp dont get any IP... any idea? log is attached btw, in the log there are many errors ("xxxx failed") about ndis.......

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 50942: [WIN32K] Do raster operation on 4 bytes instead of only 3. Fixes ... maybe noone has noticed yet ; -)
by Colin Finck 01 Mar '11

01 Mar '11

tkreuzer(a)svn.reactos.org wrote: > Do raster operation on 4 bytes instead of only 3. Quoting jgardou's commit before: > - When applying raster operation, do so only on 24 bits, we don't > support alpha channel in win32k I have no idea about DIB code, but just from the commit message I presume that this change to 24 bits has happened deliberately. - Colin

3 2

Heap corruption detector is ready
by Aleksey Bragin 25 Feb '11

25 Feb '11

Hi all, I finished implementing main features of a special mechanism for monitoring uesrmode heap allocations in ReactOS. This mechanism is called Debug Page Heap, after the very similar mechanism present in recent versions of Microsoft Windows NT. Explaining the heap manager, the "usual" heap allocator (the one I also developed earlier) also contains a heap corruption detector, but it works post-factum, only after the respective block is freed its patterns are checked (if such heap flags are specified) and if they are damaged the block is reported. This makes debugging problematic, because a lot of code is executed between the moment the corruption occured and moment when the corrupted block is freed. Also it may be so that block's patterns are untouched, but internal heap structures are damaged. The usual heap allocator won't be able to catch this, but will crash with undetermined exception. Debug page heap (DPH) comes to solve this problem. Simply speaking it guards every block with a no-access page either after or before the block, so that when a badly written app wants to write beyond the allowed area, an exception occurs showing exactly the faulty instruction. Not so simply speaking, it's a rather complicated debugging tool with abilities to catch access-after-free cases also when they happen, and do some other nice tricks too. If you want to read more about it, look for "debug page heap" in MSDN and also visit URLs specified as references in rtl/heappage.c. How to use it? The best way is to use Microsoft's utility gflags.exe which is part of the Debugging package of WDK. To make long things short, just copy gflags.exe to C:\ReactOS\system32, boot your ReactOS installation, fire up cmd prompt and type: gflags /p /enable name.exe /full Now, when you run your app called name.exe, it will use the DPH heap allocator. Detailed information about gflags.exe could be found here: http:// msdn.microsoft.com/en-us/library/ff549557%28VS.85%29.aspx Also, I suggest looking in MSDN for page heap explanation (I provided some references in heappage.c too). Have fun! Aleksey.

1 0

ReactOS Urgent Meeting
by Colin Finck 23 Feb '11

23 Feb '11

ReactOS Urgent Meeting Preamble ========= The following people which are generally considered as ReactOS-related people have called for an urgent project meeting. They agree with the meeting agenda and the rules for this meeting: * Giannis Adamopoulos * Johannes Anderwald * Maciej Białas * Aleksey Bragin * Colin Finck * Ziliang Guo * Kamil Hornicek * Amine Khaldi * Timo Kreuzer * Victor Martinez * Roel Messiant * Sylvain Petreolle * Pierre Schweitzer * Olaf Siejka * James Tabor * Art Yerkes As we have not established any general rules for meetings yet, we consider these demands enough to justify the need for such an urgent meeting. Based on the experiences Colin has from formal ReactOS Deutschland e.V. foundation meetings, we need at least a discussion leader and a minute taker to get an organized meeting done over IRC. General Information ==================== * Date and Time: Tuesday, 22nd February, 2011 - 20:00 UTC * Place: #reactos-meeting on Freenode * Meeting leader: Colin Finck * Minute taker: Amine Khaldi * Allowed Participants The following people are allowed to participate in the discussion on that channel. This list is taken from the people which were recently active on the #reactos-dev IRC channel. Others are not included as they don’t have a chance to know about the recent developments. If you consider yourself a ReactOS-related person, you may still ask Colin Finck to put you on this list. Apart from this, everybody may join as an observer. o Giannis Adamopoulos (smiley1_) o Johannes Anderwald (janderwald) o Maciej Białas (niski) o Aleksey Bragin (abragin) o Colin Finck (Colin_Finck) o Danny Götte (dangerground) o Ziliang Guo (ZWabbit) o Amine Khaldi (AmineKhaldi) o Timo Kreuzer (rosdude) o Matthias Kupfer (Collibri) o Victor Martinez (vicmarcal) o Roel Messiant (Mephisto) o Ged Murphy (GedMurphy) o Sylvain Petreolle (Usurp) o Daniel Reimer (dreimer) o Pierre Schweitzer (HeisSpiter) o Samuel Serapion (encoded) o Olaf Siejka (Caemyr) o James Tabor (jimtabor) o Art Yerkes (arty) Meeting Agenda =============== 1. Agree on a preliminary definition for the term "ReactOS Team Member". To create a basis for the next regular meeting, we need to know who may participate and who may not. As we need to focus on the release right now, this definition should only be preliminary and is subject to change in a future meeting. Some participants will present proposals for such a definition. 2. Establish regular meetings every month. This is the only chance to ensure discussions among a broad range of ReactOS Team members with binding decisions. These meetings should follow the rules of typical meetings, including meeting leaders and minute takers. In contrast to this meeting, all team members should be able to participate. Minutes should also be published on the website. Such regular meetings should begin after CLT2011 (after 20th March) due to the time it takes to prepare this event. 3. Set up binding 0.3.13 Release Plans. The CLT2011 event is a big PR chance for a new ReactOS release, so we should look forward to get a release ready by then. This point includes: 1. Getting information about the most annoying bugs and regressions. Victor Martinez and Olaf Siejka will report on this. 2. Building teams to care about each bug. As soon as a bug is fixed, a team has to report back about this to one of the release engineers. They will then add you to another team. Of course, you may also suggest stuff you want to work on afterwards. 3. Setting deadlines for the bugs. We need to determine what bugs can be realistically fixed in the given time. If a bug is not fixed by then, the appropriate team has to report back about this to one of the release engineers. They are then responsible for finding a solution. We believe that other topics, especially the ones discussed in the "ReactOS Reaction" document should be covered in the first regular meeting, so that we can focus on 0.3.13 right now.

2 4

Re: [ros-dev] [ros-diffs] [pschweitzer] 50867: [KERNEL32] Don't make GetBinaryTypeA() rely on Wine's strings conversions functions
by Aleksey Bragin 23 Feb '11

23 Feb '11

This commit sounds like FilenameA2W is some evil we should get rid of as soon as possible, otherwise it takes over the world. In fact, FilenameA2W is the same stuff which you just unwrapped, so instead of 1 line, there are 20 lines now. The only thing would be setting correct LastError, but for some reason I think Wine did it right too (they have tests). In my opinion, it makes sense to either rewrite the buggy code (buggy being really buggy or questionable origin, if code comes from Wine it doesn't automatically mean it's buggy), or let the shared code be shared and just update it from the latest Wine. WBR, Aleksey Bragin. On Feb 22, 2011, at 9:43 PM, pschweitzer(a)svn.reactos.org wrote: > Author: pschweitzer > Date: Tue Feb 22 18:43:38 2011 > New Revision: 50867 > > URL: http://svn.reactos.org/svn/reactos?rev=50867&view=rev > Log: > [KERNEL32] > Don't make GetBinaryTypeA() rely on Wine's strings conversions > functions > > Modified: > trunk/reactos/dll/win32/kernel32/file/bintype.c > > Modified: trunk/reactos/dll/win32/kernel32/file/bintype.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/ > kernel32/file/bintype.c?rev=50867&r1=50866&r2=50867&view=diff > ====================================================================== > ======== > --- trunk/reactos/dll/win32/kernel32/file/bintype.c [iso-8859-1] > (original) > +++ trunk/reactos/dll/win32/kernel32/file/bintype.c [iso-8859-1] > Tue Feb 22 18:43:38 2011 > @@ -301,23 +301,43 @@ > */ > BOOL > WINAPI > -GetBinaryTypeA ( > - LPCSTR lpApplicationName, > - LPDWORD lpBinaryType > - ) > +GetBinaryTypeA(IN LPCSTR lpApplicationName, > + OUT LPDWORD lpBinaryType) > { > - PWCHAR ApplicationNameW; > - > - if(!lpApplicationName || !lpBinaryType) > - { > - SetLastError(ERROR_INVALID_PARAMETER); > - return FALSE; > - } > - > - if (!(ApplicationNameW = FilenameA2W(lpApplicationName, FALSE))) > - return FALSE; > - > - return GetBinaryTypeW(ApplicationNameW, lpBinaryType); > + ANSI_STRING ApplicationNameString; > + UNICODE_STRING ApplicationNameW; > + BOOL StringAllocated = FALSE, Result; > + NTSTATUS Status; > + > + RtlInitAnsiString(&ApplicationNameString, lpApplicationName); > + > + if (ApplicationNameString.Length * sizeof(WCHAR) >= > NtCurrentTeb()->StaticUnicodeString.MaximumLength) > + { > + StringAllocated = TRUE; > + Status = RtlAnsiStringToUnicodeString(&ApplicationNameW, > &ApplicationNameString, TRUE); > + } > + else > + { > + Status = RtlAnsiStringToUnicodeString(&(NtCurrentTeb()- > >StaticUnicodeString), &ApplicationNameString, FALSE); > + } > + > + if (!NT_SUCCESS(Status)) > + { > + BaseSetLastNTError(Status); > + return FALSE; > + } > + > + if (StringAllocated) > + { > + Result = GetBinaryTypeW(ApplicationNameW.Buffer, > lpBinaryType); > + RtlFreeUnicodeString(&ApplicationNameW); > + } > + else > + { > + Result = GetBinaryTypeW(NtCurrentTeb()- > >StaticUnicodeString.Buffer, lpBinaryType); > + } > + > + return Result; > } > > /* EOF */ > >

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev