- Ros-dev - ReactOS.org

0.3.10 branching
by Aleksey Bragin 23 Jun '09

23 Jun '09

Hi, after thorough testing, 41446 appears to be the revision it would make sense to branch 0.3.10 from (according to Victor Martinez). Colin - please do a branch from 41446, and besides applying our usual hacks, revert the most recent wininet sync since it breaks Download! app. If you could do a prerelease iso for testing too, that would be great. WBR, Aleksey Bragin.

4 3

Re: [ros-dev] [ros-diffs] [hyperion] 41564: Don't want to fix all uses of PSEH2 macros, therefore have some curly braces, everyone
by Timo Kreuzer 23 Jun '09

23 Jun '09

Can you explain what's broken with the current usage? Maybe we can avoid it in the future / fix current usage bit by bit? hyperion(a)svn.reactos.org schrieb: > Author: hyperion > Date: Tue Jun 23 00:27:16 2009 > New Revision: 41564 > > URL: http://svn.reactos.org/svn/reactos?rev=41564&view=rev > Log: > Don't want to fix all uses of PSEH2 macros, therefore have some curly braces, everyone > > Modified: > trunk/reactos/include/reactos/libs/pseh/pseh2.h > > Modified: trunk/reactos/include/reactos/libs/pseh/pseh2.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/reactos/libs/pseh/… > ============================================================================== > --- trunk/reactos/include/reactos/libs/pseh/pseh2.h [iso-8859-1] (original) > +++ trunk/reactos/include/reactos/libs/pseh/pseh2.h [iso-8859-1] Tue Jun 23 00:27:16 2009 > @@ -401,10 +401,10 @@ > > #include <excpt.h> > > -#define _SEH2_TRY __try > -#define _SEH2_FINALLY __finally > -#define _SEH2_EXCEPT(...) __except(__VA_ARGS__) > -#define _SEH2_END > +#define _SEH2_TRY __try { > +#define _SEH2_FINALLY } __finally { > +#define _SEH2_EXCEPT(...) } __except(__VA_ARGS__) { > +#define _SEH2_END } > > #define _SEH2_GetExceptionInformation() (GetExceptionInformation()) > #define _SEH2_GetExceptionCode() (GetExceptionCode()) > > >

2 1

Re: [ros-dev] [ros-diffs] [hyperion] 41557: #define inline to __inline for Visual C++ when compiling C sources
by Alex Ionescu 23 Jun '09

23 Jun '09

Why not fix the code instead? I hate these kinds of hacks. GCC understands __inline and static, so just make the code not use STATIC and inline. On 22-Jun-09, at 1:03 PM, hyperion(a)svn.reactos.org wrote: > Author: hyperion > Date: Tue Jun 23 00:03:20 2009 > New Revision: 41557 > > URL: http://svn.reactos.org/svn/reactos?rev=41557&view=rev > Log: > #define inline to __inline for Visual C++ when compiling C sources > > Modified: > trunk/reactos/ReactOS-generic.rbuild > > Modified: trunk/reactos/ReactOS-generic.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ReactOS-generic.rbuild?rev… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/ReactOS-generic.rbuild [iso-8859-1] (original) > +++ trunk/reactos/ReactOS-generic.rbuild [iso-8859-1] Tue Jun 23 > 00:03:20 2009 > @@ -132,6 +132,7 @@ > </group> > > <group compilerset="msc"> > + <define name="inline" compiler="cc">__inline</define> > <compilerflag>/Zl</compilerflag> > <compilerflag>/Zi</compilerflag> > <compilerflag>/W1</compilerflag> > Best regards, Alex Ionescu

2 1

Re: [ros-dev] [ros-diffs] [sginsberg] 41436: - In Win32 DBG is defined to 0 for a non-debug build and to 1 for a debug build. In ReactOS we do this slightly different: DBG is correctly defined to 1 for debug, but not defined at all on non-debug/release build. Because gcc is awesome we can then check for debug compilation with both #ifdef DBG and #if DBG (error free! yay gcc!), and so we have mixed usage all over the tree. - Fix this by defining DBG on non-debug build too and deprecate all usage of #ifdef DB
by Timo Kreuzer 22 Jun '09

22 Jun '09

sginsberg(a)svn.reactos.org wrote: > Author: sginsberg > Date: Wed Jun 17 16:44:05 2009 > New Revision: 41436 > > [...] Because gcc is awesome we can then check for debug compilation with both #ifdef DBG and #if DBG (error free! yay gcc!), and so we have mixed usage all over the tree MSVC behaves exactly the same way ;-P

3 2

Re: [ros-dev] [ros-diffs] [dgorbachev] 41533: Change GDB stub.
by Ged 22 Jun '09

22 Jun '09

You couldn't have made that commit message any less descriptive, even if you'd have just written "Commit something" Hah. Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dgorbachev(a)svn.reactos.org Sent: 22 June 2009 12:32 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [dgorbachev] 41533: Change GDB stub. Author: dgorbachev Date: Mon Jun 22 15:32:25 2009 New Revision: 41533 URL: http://svn.reactos.org/svn/reactos?rev=41533&view=rev Log: Change GDB stub. Modified: trunk/reactos/ntoskrnl/kd/wrappers/gdbstub.c Modified: trunk/reactos/ntoskrnl/kd/wrappers/gdbstub.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/wrappers/gdbst… ============================================================================== --- trunk/reactos/ntoskrnl/kd/wrappers/gdbstub.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/kd/wrappers/gdbstub.c [iso-8859-1] Mon Jun 22 15:32:25 2009 @@ -11,76 +11,17 @@ OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. ****************************************************************************/ - /**************************************************************************** - * Header: remcom.c,v 1.34 91/03/09 12:29:49 glenne Exp $ - * - * Module name: remcom.c $ - * Revision: 1.34 $ - * Date: 91/03/09 12:29:49 $ * Contributor: Lake Stevens Instrument Division$ * * Description: low level support for gdb debugger. $ * - * Considerations: only works on target hardware $ - * * Written by: Glenn Engel $ * ModuleState: Experimental $ - * - * NOTES: See Below $ * * Modified for 386 by Jim Kingdon, Cygnus Support. * Modified for ReactOS by Casper S. Hornstrup <chorns(a)users.sourceforge.net> * - * To enable debugger support, two things need to happen. One, setting - * up a routine so that it is in the exception path, is necessary in order - * to allow any breakpoints or error conditions to be properly intercepted - * and reported to gdb. - * Two, a breakpoint needs to be generated to begin communication. - * - * Because gdb will sometimes write to the stack area to execute function - * calls, this program cannot rely on using the supervisor stack so it - * uses it's own stack area. - * - ************* - * - * The following gdb commands are supported: - * - * command function Return value - * - * g return the value of the CPU Registers hex data or ENN - * G set the value of the CPU Registers OK or ENN - * - * mAA..AA,LLLL Read LLLL bytes at address AA..AA hex data or ENN - * MAA..AA,LLLL: Write LLLL bytes at address AA.AA OK or ENN - * - * c Resume at current address SNN ( signal NN) - * cAA..AA Continue at address AA..AA SNN - * - * s Step one instruction SNN - * sAA..AA Step one instruction from AA..AA SNN - * - * k kill - * - * ? What was the last sigval ? SNN (signal NN) - * - * All commands and responses are sent with a packet which includes a - * Checksum. A packet consists of - * - * $<packet info>#<Checksum>. - * - * where - * <packet info> :: <characters representing the command or response> - * <Checksum> :: < two hex digits computed as modulo 256 sum of <packetinfo>> - * - * When a packet is received, it is first acknowledged with either '+' or '-'. - * '+' indicates a successful transfer. '-' indicates a failed transfer. - * - * Example: - * - * Host: Reply: - * $m0,10#2a +$00010203040506070809101112131415#42 - * ****************************************************************************/ #include <ntoskrnl.h> @@ -88,12 +29,8 @@ #include <debug.h> /************************************************************************/ -/* BUFMAX defines the maximum number of characters in inbound/outbound buffers*/ -/* at least NUMREGBYTES*2 are needed for register packets */ -#define BUFMAX 1000 static BOOLEAN GspInitialized; - static BOOLEAN GspRemoteDebug; static CONST CHAR HexChars[]="0123456789abcdef"; @@ -105,7 +42,12 @@ static FAST_MUTEX GspLock; extern LIST_ENTRY PsActiveProcessHead; -KD_PORT_INFORMATION GdbPortInfo = { 2, 115200, 0 }; /* FIXME hardcoded for COM2, 115200 baud */ + +/* FIXME hardcoded for COM2, 115200 baud */ +KD_PORT_INFORMATION GdbPortInfo = { 2, 115200, 0 }; + +static CHAR GspInBuffer[1000]; +static CHAR GspOutBuffer[1000]; /* Number of Registers. */ #define NUMREGS 16 @@ -178,8 +120,6 @@ return -1; } -static CHAR GspInBuffer[BUFMAX]; -static CHAR GspOutBuffer[BUFMAX]; VOID GdbPutChar(UCHAR Value) @@ -199,7 +139,6 @@ } /* scan for the sequence $<data>#<Checksum> */ - PCHAR GspGetPacket() { @@ -221,7 +160,7 @@ Count = 0; /* now, read until a # or end of Buffer is found */ - while (Count < BUFMAX) + while (Count < sizeof(GspInBuffer) - 1) { ch = GdbGetChar(); if (ch == '$') @@ -260,7 +199,6 @@ } /* send the packet in Buffer. */ - VOID GspPutPacket(PCHAR Buffer) { @@ -314,17 +252,23 @@ GdbPutChar(HexChars[Checksum & 0xf]); } -/* Indicate to caller of GspMem2Hex or GspHex2Mem that there has been an - error. */ +/* Indicate to caller of GspMem2Hex or GspHex2Mem that there has been an error. */ static volatile BOOLEAN GspMemoryError = FALSE; -static volatile void *GspAccessLocation = NULL; static CHAR GspReadMemSafe(PCHAR Address) { - CHAR ch; - KdpSafeReadMemory((ULONG_PTR)Address, 1, &ch); + CHAR ch = 0; + if (!KdpSafeReadMemory((ULONG_PTR)Address, 1, &ch)) + GspMemoryError = TRUE; return ch; +} + +static void +GspWriteMemSafe(PCHAR Address, CHAR Ch) +{ + if (!KdpSafeWriteMemory((ULONG_PTR)Address, 1, Ch)) + GspMemoryError = TRUE; } /* Convert the memory pointed to by Address into hex, placing result in Buffer */ @@ -375,7 +319,6 @@ ULONG CountInPage; ULONG i; CHAR ch; - ULONG OldProt = 0; Current = Address; while (Current < Address + Count) @@ -391,30 +334,24 @@ /* Flows into next page, handle only current page in this iteration */ CountInPage = PAGE_SIZE - (Address - Page); } + + for (i = 0; i < CountInPage && ! GspMemoryError; i++) + { + ch = (*GetContent)(Context, Current - Address); + + if (MayFault) + { + GspWriteMemSafe(Current, ch); + } + else + { + *Current = ch; + } + + Current++; + } if (MayFault) { - OldProt = MmGetPageProtect(NULL, Address); - MmSetPageProtect(NULL, Address, PAGE_EXECUTE_READWRITE); - } - - for (i = 0; i < CountInPage && ! GspMemoryError; i++) - { - ch = (*GetContent)(Context, Current - Address); - - if (MayFault) - { - GspAccessLocation = Current; - } - *Current = ch; - if (MayFault) - { - GspAccessLocation = NULL; - } - Current++; - } - if (MayFault) - { - MmSetPageProtect(NULL, Page, OldProt); if (GspMemoryError) { return Current - Address; @@ -432,8 +369,8 @@ HexValue(*((PCHAR) Context + 2 * Offset + 1))); } -/* Convert the hex array pointed to by Buffer into binary to be placed at Address */ -/* Return a pointer to the character AFTER the last byte read from Buffer */ +/* Convert the hex array pointed to by Buffer into binary to be placed at Address + * Return a pointer to the character AFTER the last byte read from Buffer */ static PCHAR GspHex2Mem(PCHAR Buffer, PCHAR Address, @@ -444,49 +381,6 @@ return Buffer + 2 * Count; } - -static void -GspWriteMemSafe(PCHAR Address, - CHAR Ch) -{ - KdpSafeWriteMemory((ULONG_PTR)Address, 1, Ch); -} - - -/* This function takes the 386 exception vector and attempts to - translate this number into a unix compatible signal value */ -ULONG -GspComputeSignal(NTSTATUS ExceptionCode) -{ - ULONG SigVal; - - switch (ExceptionCode) - { - case STATUS_INTEGER_DIVIDE_BY_ZERO: - SigVal = 8; /* divide by zero */ - break; - case STATUS_SINGLE_STEP: - case STATUS_BREAKPOINT: - SigVal = 5; /* breakpoint */ - break; - case STATUS_INTEGER_OVERFLOW: - case STATUS_ARRAY_BOUNDS_EXCEEDED: - SigVal = 16; /* bound instruction */ - break; - case STATUS_ILLEGAL_INSTRUCTION: - SigVal = 4; /* Invalid opcode */ - break; - case STATUS_STACK_OVERFLOW: - case STATUS_DATATYPE_MISALIGNMENT: - case STATUS_ACCESS_VIOLATION: - SigVal = 11; /* access violation */ - break; - default: - SigVal = 7; /* "software generated" */ - } - return SigVal; -} - /**********************************************/ /* WHILE WE FIND NICE HEX CHARS, BUILD A LONG */ @@ -932,6 +826,15 @@ GspMem2Hex(Buffer, &GspOutBuffer[0], strlen(Buffer), FALSE); } } + else if (strncmp(Request, "Supported", 9) == 0) + { + /* tell maximum incoming packet size */ + sprintf(GspOutBuffer, "PacketSize=%u", sizeof(GspInBuffer) - 1); + } + else if (strncmp(Request, "Rcmd,", 5) == 0) + { + ; + } } VOID @@ -954,6 +857,8 @@ GspOutBuffer[1] = '\0'; } } + +#define DR6_BS 0x00004000 /* Single step */ #define DR7_L0 0x00000001 /* Local breakpoint 0 enable */ #define DR7_G0 0x00000002 /* Global breakpoint 0 enable */ @@ -1011,7 +916,6 @@ #define MAX_SW_BREAKPOINTS 64 static unsigned GspSwBreakpointCount = 0; static GSPSWBREAKPOINT GspSwBreakpoints[MAX_SW_BREAKPOINTS]; -static CHAR GspSwBreakpointsInstructions[MAX_SW_BREAKPOINTS]; static void GspSetHwBreakpoint(ULONG Type, ULONG_PTR Address, ULONG Length) @@ -1085,6 +989,21 @@ strcpy(GspOutBuffer, "E22"); } +static BOOLEAN +GspFindSwBreakpoint(ULONG_PTR Address, PULONG PIndex) +{ + ULONG Index; + + for (Index = 0; Index < GspSwBreakpointCount; Index++) + if (GspSwBreakpoints[Index].Address == Address) + { + if (PIndex) *PIndex = Index; + return TRUE; + } + + return FALSE; +} + static void GspSetSwBreakpoint(ULONG_PTR Address) { @@ -1094,61 +1013,44 @@ { DPRINT1("Trying to set too many software breakpoints\n"); strcpy(GspOutBuffer, "E22"); - } - else - { - unsigned Index; - - for (Index = 0; Index < GspSwBreakpointCount; Index++) - { - if (GspSwBreakpoints[Index].Address == Address) - { - strcpy(GspOutBuffer, "E22"); - return; - } - } - - DPRINT("Stored at index %u\n", GspSwBreakpointCount); - GspSwBreakpoints[GspSwBreakpointCount].Address = Address; - GspSwBreakpoints[GspSwBreakpointCount].Active = FALSE; - GspSwBreakpointsInstructions[GspSwBreakpointCount] = - GspReadMemSafe((PCHAR )Address); - GspWriteMemSafe((PCHAR )Address, 0xCC); - GspSwBreakpointCount++; - strcpy(GspOutBuffer, "OK"); - } + return; + } + + if (GspFindSwBreakpoint(Address, NULL)) + { + strcpy(GspOutBuffer, "E22"); + return; + } + + DPRINT("Stored at index %u\n", GspSwBreakpointCount); + GspSwBreakpoints[GspSwBreakpointCount].Address = Address; + GspSwBreakpoints[GspSwBreakpointCount].Active = FALSE; + GspSwBreakpointCount++; + strcpy(GspOutBuffer, "OK"); } static void GspRemoveSwBreakpoint(ULONG_PTR Address) { - unsigned Index; + ULONG Index; DPRINT("GspRemoveSwBreakpoint(0x%p)\n", Address); - for (Index = 0; Index < GspSwBreakpointCount; Index++) - { - if (GspSwBreakpoints[Index].Address == Address) - { - DPRINT("Found match at index %u\n", Index); - ASSERT(! GspSwBreakpoints[Index].Active); - - GspWriteMemSafe((PCHAR )Address, - GspSwBreakpointsInstructions[Index]); - - if (Index + 1 < GspSwBreakpointCount) - { - memmove(GspSwBreakpoints + Index, - GspSwBreakpoints + (Index + 1), - (GspSwBreakpointCount - Index - 1) * - sizeof(GSPSWBREAKPOINT)); - memmove(GspSwBreakpointsInstructions + Index, - GspSwBreakpointsInstructions + (Index + 1), - (GspSwBreakpointCount - Index - 1) * sizeof(CHAR)); - } - GspSwBreakpointCount--; - strcpy(GspOutBuffer, "OK"); - return; - } + + if (GspFindSwBreakpoint(Address, &Index)) + { + DPRINT("Found match at index %u\n", Index); + ASSERT(! GspSwBreakpoints[Index].Active); + + if (Index + 1 < GspSwBreakpointCount) + { + memmove(GspSwBreakpoints + Index, + GspSwBreakpoints + (Index + 1), + (GspSwBreakpointCount - Index - 1) * + sizeof(GSPSWBREAKPOINT)); + } + GspSwBreakpointCount--; + strcpy(GspOutBuffer, "OK"); + return; } DPRINT1("Not found\n"); @@ -1195,6 +1097,28 @@ } static void +GspLoadSwBreakpoint(ULONG Index) +{ + GspMemoryError = FALSE; + GspSwBreakpoints[Index].PrevContent = GspReadMemSafe((PCHAR) GspSwBreakpoints[Index].Address); + if (! GspMemoryError) + { + GspWriteMemSafe((PCHAR) GspSwBreakpoints[Index].Address, I386_OPCODE_INT3); + } + GspSwBreakpoints[Index].Active = ! GspMemoryError; + if (GspMemoryError) + { + DPRINT1("Failed to set software breakpoint at 0x%p\n", + GspSwBreakpoints[Index].Address); + } + else + { + DPRINT("Successfully set software breakpoint at 0x%p\n", + GspSwBreakpoints[Index].Address); + } +} + +static void GspLoadBreakpoints(PKTRAP_FRAME TrapFrame) { unsigned Index; @@ -1202,6 +1126,7 @@ DPRINT("GspLoadBreakpoints\n"); DPRINT("DR7 on entry: 0x%08x\n", TrapFrame->Dr7); + /* Remove all breakpoints */ TrapFrame->Dr7 &= ~(DR7_L0 | DR7_L1 | DR7_L2 | DR7_L3 | DR7_G0 | DR7_G1 | DR7_G2 | DR7_G3 | @@ -1235,47 +1160,22 @@ for (Index = 0; Index < GspSwBreakpointCount; Index++) { - if (GspHwBreakpointCount + Index < MAX_HW_BREAKPOINTS) - { - DPRINT("Implementing software interrupt using hardware register\n"); - GspLoadHwBreakpoint(TrapFrame, GspHwBreakpointCount + Index, - GspSwBreakpoints[Index].Address, 0, - I386_BP_TYPE_EXECUTE); - GspSwBreakpoints[Index].Active = FALSE; - } - else - { - DPRINT("Using real software breakpoint\n"); - GspMemoryError = FALSE; - GspSwBreakpoints[Index].PrevContent = GspReadMemSafe((PCHAR) GspSwBreakpoints[Index].Address); - if (! GspMemoryError) - { - GspWriteMemSafe((PCHAR) GspSwBreakpoints[Index].Address, I386_OPCODE_INT3); - } - GspSwBreakpoints[Index].Active = ! GspMemoryError; - if (GspMemoryError) - { - DPRINT1("Failed to set software breakpoint at 0x%p\n", - GspSwBreakpoints[Index].Address); - } - else - { - DPRINT("Successfully set software breakpoint at 0x%p\n", - GspSwBreakpoints[Index].Address); - DPRINT1("Successfully set software breakpoint at 0x%p\n", GspSwBreakpoints[Index].Address); - } - } + DPRINT("Using real software breakpoint\n"); + GspLoadSwBreakpoint(Index); } DPRINT("Final DR7 value 0x%08x\n", TrapFrame->Dr7); } static void -GspUnloadBreakpoints(PKTRAP_FRAME TrapFrame) +GspUnloadBreakpoints(void) { unsigned Index; - DPRINT("GspUnloadHwBreakpoints\n"); + DPRINT("GspUnloadBreakpoints\n"); + + /* Disable hardware debugging while we are inside the stub */ + Ke386SetDr7(0); for (Index = 0; Index < GspSwBreakpointCount; Index++) { @@ -1299,9 +1199,67 @@ } } -static BOOLEAN gdb_attached_yet = FALSE; +static void +GspStopReply(NTSTATUS ExceptionCode, PKTRAP_FRAME TrapFrame) +{ + PCHAR ptr = GspOutBuffer; + ULONG SigVal; + LONG Esp; + + switch (ExceptionCode) + { + case STATUS_INTEGER_DIVIDE_BY_ZERO: + SigVal = 8; /* divide by zero */ + break; + case STATUS_SINGLE_STEP: + case STATUS_BREAKPOINT: + SigVal = 5; /* breakpoint */ + break; + case STATUS_INTEGER_OVERFLOW: + case STATUS_ARRAY_BOUNDS_EXCEEDED: + SigVal = 16; /* bound instruction */ + break; + case STATUS_ILLEGAL_INSTRUCTION: + SigVal = 4; /* Invalid opcode */ + break; + case STATUS_STACK_OVERFLOW: + case STATUS_DATATYPE_MISALIGNMENT: + case STATUS_ACCESS_VIOLATION: + SigVal = 11; /* access violation */ + break; + default: + SigVal = 7; /* "software generated" */ + } + + ptr = GspOutBuffer; + + *ptr++ = 'T'; /* notify gdb with signo, PC, FP and SP */ + *ptr++ = HexChars[(SigVal >> 4) & 0xf]; + *ptr++ = HexChars[SigVal & 0xf]; + + *ptr++ = HexChars[ESP]; + *ptr++ = ':'; + + Esp = GspGetEspFromTrapFrame(TrapFrame); /* SP */ + ptr = GspMem2Hex((PCHAR) &Esp, ptr, 4, 0); + *ptr++ = ';'; + + *ptr++ = HexChars[EBP]; + *ptr++ = ':'; + ptr = GspMem2Hex((PCHAR) &TrapFrame->Ebp, ptr, 4, 0); /* FP */ + *ptr++ = ';'; + + *ptr++ = HexChars[PC]; + *ptr++ = ':'; + ptr = GspMem2Hex((PCHAR) &TrapFrame->Eip, ptr, 4, 0); /* PC */ + *ptr++ = ';'; + + *ptr = '\0'; +} + + /* - * This function does all command procesing for interfacing to gdb. + * This function does all command procesing for interfacing to GDB. */ KD_CONTINUE_TYPE NTAPI @@ -1309,34 +1267,23 @@ PCONTEXT Context, PKTRAP_FRAME TrapFrame) { - BOOLEAN Stepping; - LONG Address; - LONG Length; - LONG SigVal = 0; - LONG NewPC; - PCHAR ptr; - - /* FIXME: Stop on other CPUs too */ - - if (STATUS_ACCESS_VIOLATION == (NTSTATUS) ExceptionRecord->ExceptionCode && - NULL != GspAccessLocation && - (ULONG_PTR) GspAccessLocation == - (ULONG_PTR) ExceptionRecord->ExceptionInformation[1]) - { - GspAccessLocation = NULL; - GspMemoryError = TRUE; - Context->Eip += 3; - } - else - { - DPRINT("Thread %p entering stub\n", PsGetCurrentThread()); + static BOOLEAN GdbAttached = FALSE; + BOOLEAN Stepping = FALSE; + NTSTATUS ExceptionCode; + LONG Address; + LONG Length; + PCHAR ptr; + + /* FIXME: Stop on other CPUs too */ + + DPRINT("Thread %p entering stub\n", PsGetCurrentThread()); + ExceptionCode = (NTSTATUS) ExceptionRecord->ExceptionCode; + /* Can only debug 1 thread at a time... */ ExAcquireFastMutex(&GspLock); DPRINT("Thread %p acquired mutex\n", PsGetCurrentThread()); - /* Disable hardware debugging while we are inside the stub */ - Ke386SetDr7(0); - GspUnloadBreakpoints(TrapFrame); + GspUnloadBreakpoints(); /* Make sure we're debugging the current thread. */ if (NULL != GspDbgThread) @@ -1346,67 +1293,29 @@ GspDbgThread = NULL; } - /* ugly hack to avoid attempting to send status at the very - * beginning, right when GDB is trying to query the stub */ - if (gdb_attached_yet) - { - LONG Esp; - - stop_reply: - /* reply to host that an exception has occurred */ - SigVal = GspComputeSignal(ExceptionRecord->ExceptionCode); - - ptr = GspOutBuffer; - - *ptr++ = 'T'; /* notify gdb with signo, PC, FP and SP */ - *ptr++ = HexChars[(SigVal >> 4) & 0xf]; - *ptr++ = HexChars[SigVal & 0xf]; - - *ptr++ = HexChars[ESP]; - *ptr++ = ':'; - - Esp = GspGetEspFromTrapFrame(TrapFrame); /* SP */ - ptr = GspMem2Hex((PCHAR) &Esp, ptr, 4, 0); - *ptr++ = ';'; - - *ptr++ = HexChars[EBP]; - *ptr++ = ':'; - ptr = GspMem2Hex((PCHAR) &TrapFrame->Ebp, ptr, 4, 0); /* FP */ - *ptr++ = ';'; - - *ptr++ = HexChars[PC]; - *ptr++ = ':'; - ptr = GspMem2Hex((PCHAR) &TrapFrame->Eip, ptr, 4, 0); /* PC */ - *ptr++ = ';'; - - *ptr = '\0'; - - GspPutPacket(&GspOutBuffer[0]); - /* DPRINT("------- replied status: (%s) -------\n", GspOutBuffer); */ + if (GdbAttached) + { + GspStopReply(ExceptionCode, TrapFrame); + GspPutPacket(GspOutBuffer); + // DbgPrint(">>> (%s) >>>\n", GspOutBuffer); } else { - gdb_attached_yet = 1; - } - - Stepping = FALSE; + GdbAttached = TRUE; + } while (TRUE) { /* Zero the buffer now so we don't have to worry about the terminating zero character */ - memset(GspOutBuffer, 0, sizeof(GspInBuffer)); + memset(GspOutBuffer, 0, sizeof(GspOutBuffer)); ptr = GspGetPacket(); - /* DPRINT("------- Get (%s) command -------\n", ptr); */ + // DbgPrint("<<< (%s) <<<\n", ptr); switch(*ptr++) { case '?': /* a little hack to send more complete status information */ - goto stop_reply; - GspOutBuffer[0] = 'S'; - GspOutBuffer[1] = HexChars[SigVal >> 4]; - GspOutBuffer[2] = HexChars[SigVal % 16]; - GspOutBuffer[3] = 0; + GspStopReply(ExceptionCode, TrapFrame); break; case 'd': GspRemoteDebug = !GspRemoteDebug; /* toggle debug flag */ @@ -1478,7 +1387,7 @@ if (GspMemoryError) { strcpy(GspOutBuffer, "E03"); - DPRINT("Fault during memory read\n"); + DPRINT1("Fault during memory read\n"); } } @@ -1514,7 +1423,7 @@ if (GspMemoryError) { strcpy(GspOutBuffer, "E03"); - DPRINT("Fault during memory write\n"); + DPRINT1("Fault during memory write\n"); } else { @@ -1537,55 +1446,49 @@ case 'c': { ULONG BreakpointNumber; - ULONG dr6_; - - /* try to read optional parameter, pc unchanged if no parm */ + ULONG Dr6; + + /* try to read optional parameter, pc changed if param */ if (GspHex2Long (&ptr, &Address)) { Context->Eip = Address; } - - NewPC = Context->Eip; + else if (ExceptionCode == STATUS_BREAKPOINT) + { + if (GspReadMemSafe((PCHAR) Context->Eip) == (CHAR) I386_OPCODE_INT3) + { + Context->Eip++; + } + } /* clear the trace bit */ - Context->EFlags &= 0xfffffeff; + Context->EFlags &= ~EFLAGS_TF; /* set the trace bit if we're Stepping */ if (Stepping) { - Context->EFlags |= 0x100; + Context->EFlags |= EFLAGS_TF; } -#if defined(__GNUC__) - asm volatile ("movl %%db6, %0\n" : "=r" (dr6_) : ); -#elif defined(_MSC_VER) - __asm mov eax, dr6 __asm mov dr6_, eax; -#else -#error Unknown compiler for inline assembler -#endif - if (!(dr6_ & 0x4000)) + Dr6 = Ke386GetDr6(); + if (!(Dr6 & DR6_BS)) { - for (BreakpointNumber = 0; BreakpointNumber < 4; ++BreakpointNumber) + for (BreakpointNumber = 0; BreakpointNumber < MAX_HW_BREAKPOINTS; ++BreakpointNumber) { - if (dr6_ & (1 << BreakpointNumber)) + if (Dr6 & (1 << BreakpointNumber)) { - if (GspHwBreakpoints[BreakpointNumber].Type == 0) + if (GspHwBreakpoints[BreakpointNumber].Type == I386_BP_TYPE_EXECUTE) { /* Set restore flag */ - Context->EFlags |= 0x10000; + Context->EFlags |= EFLAGS_RF; break; } } } } + GspLoadBreakpoints(TrapFrame); -#if defined(__GNUC__) - asm volatile ("movl %0, %%db6\n" : : "r" (0)); -#elif defined(_MSC_VER) - __asm mov eax, 0 __asm mov dr6, eax; -#else -#error Unknown compiler for inline assembler -#endif + Ke386SetDr6(0); if (NULL != GspDbgThread) { @@ -1596,14 +1499,19 @@ DPRINT("Thread %p releasing mutex\n", PsGetCurrentThread()); ExReleaseFastMutex(&GspLock); DPRINT("Thread %p leaving stub\n", PsGetCurrentThread()); - return kdContinue; - break; + + if (ExceptionCode == STATUS_BREAKPOINT || + ExceptionCode == STATUS_SINGLE_STEP) + { + return kdContinue; + } + + return kdHandleException; } case 'k': /* kill the program */ strcpy(GspOutBuffer, "OK"); break; - /* kill the program */ case 'H': /* Set thread */ GspSetThread(ptr); @@ -1630,11 +1538,11 @@ GspHex2Long(&ptr, &Length); if (0 == Type) { - GspSetSwBreakpoint((ULONG_PTR) Address); + GspSetSwBreakpoint((ULONG_PTR) Address); } else { - GspSetHwBreakpoint(Type, (ULONG_PTR) Address, Length); + GspSetHwBreakpoint(Type, (ULONG_PTR) Address, Length); } break; } @@ -1652,11 +1560,11 @@ GspHex2Long(&ptr, &Length); if (0 == Type) { - GspRemoveSwBreakpoint((ULONG_PTR) Address); + GspRemoveSwBreakpoint((ULONG_PTR) Address); } else { - GspRemoveHwBreakpoint(Type, (ULONG_PTR) Address, Length); + GspRemoveHwBreakpoint(Type, (ULONG_PTR) Address, Length); } break; } @@ -1667,20 +1575,8 @@ /* reply to the request */ GspPutPacket(GspOutBuffer); - /* DPRINT("------- reply command (%s) -------\n", GspOutBuffer); */ - } - - /* not reached */ - ASSERT(0); - } - - if (NULL != GspDbgThread) - { - ObDereferenceObject(GspDbgThread); - GspDbgThread = NULL; - } - - return kdContinue; + // DbgPrint(">>> (%s) >>>\n", GspOutBuffer); + } } @@ -1754,8 +1650,6 @@ /* Initialize the Port */ KdPortInitializeEx(&GdbPortInfo, 0, 0); - - KdpPort = GdbPortInfo.ComPort; } else if (BootPhase == 1) {

1 0

Attention, Visual C++ support developers and fans
by KJK::Hyperion 21 Jun '09

21 Jun '09

I forgot to add to the commit message for r41520 that I lowered the warning level of Visual C++ from -Wall to -W1. This will let us fix the most serious compatibility issues first. Remember: set ROS_RBUILDFLAGS to -dd -Mcmsc, and make --keep-going is your friend. Now go, and make awesome things with this!

1 0

Re: [ros-dev] [ros-diffs] [hyperion] 41421: modified dll/win32/srclient/srclient_main.c ...
by tamlin＠algonet.se 17 Jun '09

17 Jun '09

timo.kreuzer wrote: >This is what I found: [...] So, essentially, what you found is that all versions you looked at, did indeed define va_list if <stdarg.h> was included? -- Mike

2 1

Re: [ros-dev] [ros-diffs] [hyperion] 41421: modified dll/win32/srclient/srclient_main.c ...
by tamlin＠algonet.se 17 Jun '09

17 Jun '09

timo.kreuzer wrote: >In recent ms crt headers, va_list is defined in crtdefs.h, Also in vadefs.h (at least for VC8), which is then (obvious) included by <stdarg.h>. Do you have an example of an MS env. where including stdarg.h does not define va_list? -- Mike

2 1

Re: [ros-dev] [ros-diffs] [dchapyshev] 41424: - Add Symbol font from Wine
by Steven Edwards 17 Jun '09

17 Jun '09

On Tue, Jun 16, 2009 at 11:41 AM, <dchapyshev(a)svn.reactos.org> wrote: > Author: dchapyshev > Date: Tue Jun 16 19:41:29 2009 > New Revision: 41424 > > URL: http://svn.reactos.org/svn/reactos?rev=41424&view=rev > Log: > - Add Symbol font from Wine Thank you. This will save us a LOT of trouble later with Office applications. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Re: [ros-dev] [ros-diffs] [hyperion] 41421: modified dll/win32/srclient/srclient_main.c What the hell, Arch Blackmann? <windef.h>, <winbase.h> and <winnls.h> are not meant to be included directly. Include <windows.h> instead modified drivers/video/font/ftfd/rosglue.c Move standard C includes before Windows includes, so the required types are defined beforehand modified include/crt/_mingw.h Re-add Visual C++ support va_list is not a built-in type, it does not belong in _mingw.h Do not include intrin.h (screw
by Timo Kreuzer 16 Jun '09

16 Jun '09

hyperion(a)svn.reactos.org wrote: > Author: hyperion > Date: Tue Jun 16 04:24:26 2009 > New Revision: 41421 > > URL: http://svn.reactos.org/svn/reactos?rev=41421&view=rev > Log: > modified dll/win32/srclient/srclient_main.c > What the hell, Arch Blackmann? <windef.h>, <winbase.h> and <winnls.h> are not meant to be included directly. Include <windows.h> instead > > modified drivers/video/font/ftfd/rosglue.c > Move standard C includes before Windows includes, so the required types are defined beforehand > > modified include/crt/_mingw.h > Re-add Visual C++ support > va_list is not a built-in type, it does not belong in _mingw.h > Do not include intrin.h (screw you, Arch) > Removed definition of _USE_32BIT_TIME_T ("ROS HACK!") > > modified include/crt/conio.h > modified include/crt/stdio.h > modified include/crt/wchar.h > Pull in va_list from stdarg.h > In recent ms crt headers, va_list is defined in crtdefs.h, so it's defined by all headers. This might not fit ANSI C, but that's what ms does. So for compatibility reasons we might want to do it the same way(?)

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 41399: - Implement NdisGeneratePartialCancelId
by Aleksey Bragin 14 Jun '09

14 Jun '09

On Jun 13, 2009, at 9:25 AM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Sat Jun 13 09:25:54 2009 > New Revision: 41399 > +UCHAR > +EXPORT > +NdisGeneratePartialCancelId(VOID) > +{ > + static UCHAR CancelId = 0; > + > + CancelId++; I don't think using static var for this purpose is a great idea. WBR, Aleksey Bragin.

1 0

Re: [ros-dev] Development plans for May
by tamlin＠algonet.se 13 Jun '09

13 Jun '09

aicommander wrote: [...] >The main problem with NDIS 5.1 drivers is the lack of S/G support in HAL > (PRO/100 and PRO/1000 XP drivers are affected by this). Could the follwing info from public MSDN help? If so, it seems to be a rather minor hack to make it work: Scatter/gather DMA Scatter/gather DMA is a shortcut method that sets up several packet DMA transfers at once. If you are transferring a packet over the network, for example, each part of the network stack adds its own header (TCP, IP, Ethernet, and so forth). These headers are all allocated from different places in memory. In this case, the scatter/gather DMA saves time by issuing a batch request to the HAL to map each header plus the data segment for access by the hardware. Instead of having to call the packet DMA routines on each part of the packet, this method calls each routine once, and lets the HAL be responsible for mapping each one individually. Note Scatter/gather capability does not mean that the device can use the scatter/gather routines. Scatter/gather capability refers to a flag in the device description that indicates that the device is able to read or write from any area in memory, instead of just a certain range. -------- What I found to be the interesting (and easily hackable) part was "and lets the HAL be responsible for mapping each one individually". -- Mike

1 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class
by Ged 12 Jun '09

12 Jun '09

Ok, I've just read the actual code for NtSetInformationProcess (probably should have done that first) It's right, what threw me was your r41390 commit which contained this : + PriorityClass.PriorityClass = PROCESS_PRIORITY_CLASS_HIGH; + PriorityClass.Foreground = FALSE; + + /* Set priority for process */ + if (!NT_SUCCESS(NtSetInformationProcess(ProcessInfo.ProcessHandle, + ProcessPriorityClass, + &PriorityClass, + sizeof(PROCESS_PRIORITY_CLASS)))) + { + DPRINT1("Unable to set process priority for winlogon.exe\n"); + } I assumed from reading this that our NtSetInformationProcess was setting process priorities via #defines. It turns out that the above is actually wrong. From pstypes.h : #define PROCESS_PRIORITY_CLASS_HIGH 3 You were setting winlogon to have a priority of 3. Clearly not right ... heh. Anyway, I see you've reverted it now. Problem solved. I was just writing this follow up so you didn't start looking into NtSetInformationProcess and scratching your head wondering what my previous mail was about Ged. -----Original Message----- From: Ged [mailto:gedmurphy@gmail.com] Sent: 12 June 2009 18:48 To: 'ros-dev(a)reactos.org' Subject: RE: [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class Hi This change is wrong. ABOVE_NORMAL_PRIORITY_CLASS sets them to a process level of 10 which is too high. Windows actually runs these at a level of 9 to ensure they get proc time before the regular NORMAL_PRIORITY_CLASS(8) processes but below the ABOVE_NORMAL_PRIORITY_CLASS(10) processes. IIRC, you should be able to set the process directly using NtSetInformationProcess although our implementation doesn't seem to reflect this. Is it our implementation or my memory which is wrong ? Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dchapyshev(a)svn.reactos.org Sent: 12 June 2009 16:41 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class Author: dchapyshev Date: Fri Jun 12 19:41:26 2009 New Revision: 41389 URL: http://svn.reactos.org/svn/reactos?rev=41389&view=rev Log: - Start services.exe and lsass.exe with above normal priority class Modified: trunk/reactos/base/system/winlogon/winlogon.c Modified: trunk/reactos/base/system/winlogon/winlogon.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/winlogon/winlo… ============================================================================== --- trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] (original) +++ trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] Fri Jun 12 19:41:26 2009 @@ -49,7 +49,7 @@ NULL, NULL, FALSE, - DETACHED_PROCESS, + DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS, NULL, NULL, &StartupInfo, @@ -97,7 +97,7 @@ NULL, NULL, FALSE, - DETACHED_PROCESS, + DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS, NULL, NULL, &StartupInfo,

1 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class
by Ged 12 Jun '09

12 Jun '09

Hi This change is wrong. ABOVE_NORMAL_PRIORITY_CLASS sets them to a process level of 10 which is too high. Windows actually runs these at a level of 9 to ensure they get proc time before the regular NORMAL_PRIORITY_CLASS(8) processes but below the ABOVE_NORMAL_PRIORITY_CLASS(10) processes. IIRC, you should be able to set the process directly using NtSetInformationProcess although our implementation doesn't seem to reflect this. Is it our implementation or my memory which is wrong ? Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dchapyshev(a)svn.reactos.org Sent: 12 June 2009 16:41 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class Author: dchapyshev Date: Fri Jun 12 19:41:26 2009 New Revision: 41389 URL: http://svn.reactos.org/svn/reactos?rev=41389&view=rev Log: - Start services.exe and lsass.exe with above normal priority class Modified: trunk/reactos/base/system/winlogon/winlogon.c Modified: trunk/reactos/base/system/winlogon/winlogon.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/winlogon/winlo… ============================================================================== --- trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] (original) +++ trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] Fri Jun 12 19:41:26 2009 @@ -49,7 +49,7 @@ NULL, NULL, FALSE, - DETACHED_PROCESS, + DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS, NULL, NULL, &StartupInfo, @@ -97,7 +97,7 @@ NULL, NULL, FALSE, - DETACHED_PROCESS, + DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS, NULL, NULL, &StartupInfo,

1 0

Development plans for May
by Aleksey Bragin 12 Jun '09

12 Jun '09

Hi, as we earlier discussed, there is an idea to make 0.3.10 a "hardware- compatibility" release. There is a full list of 0.3.10 milestones bugs linked from our roadmap page, but here are some possible directions for work: - USB support for keyboard and mouse devices. Right now, it needs fixing the rare crash during booting (bug is bugzilled, comment explaining how to solve the problem is attached, some investigation remains), and more testing on real hardware. - Uniata support: it solves many problems at once, such as a stupid 8Gb limit which is a nonsense for a 2009-year operating system, and Serial ATA support, which greatly enhances possible ReactOS usability (along with the first item of this list). I use it in my builds everyday for more than a month, it works very good. Problems: VirtualBox CDROM support (it doesn't recognize it), on my realhardware it also experiences similar problems. Bug is also bugzilled, a lot of debug logs attached, so everyone can participate. - Common NICs support: Cameron is doing great work, testers too. There are some outstanding problems, which you can see from http:// www.reactos.org/wiki/index.php/Supported_Hardware/Network_cards - Sound support: Johannes knows best, but getting any progress with sound by 0.3.10 release date is greatly appreciated. - Videocards support: Olaf performs some tesitng and bugreporting. Third party drivers support is rather weak, http://www.reactos.org/ wiki/index.php/Supported_Hardware/Video_cards , and usually is limited by VMWare's video driver which is being one of the most supported through the ReactOS development history. Besides of that, Olaf is organizing the Golden Apps testing, so that we won't discover regressions occasionally or by the time the release is branched and everyone is awaiting, but instead that's going to happen on a periodical basis, and he's going to manage this process with help of our fellow testers. Target 0.3.10 release date is month from now on - that means, somewhere in the end of May. Certainly, if our goals aren't met, the release is going to be rescheduled and that's it, but, I'd like to ask to concentrate on the above problems first. They are hard to solve when every problem is being approached by one person, but with a common effort they aren't going to be a problem. Any new developers - welcome! There are very definite goals, enough of information, so please feel free to join and help. With the best regards, Aleksey Bragin.

5 5

Re: [ros-dev] Development plans for May
by Olaf Siejka 11 Jun '09

11 Jun '09

As for Videocards, it seems that our situation is not as bad as it was perceived before. Its not perfect, of course. - currently i can name at least 3 cards working on my ReactOS PC with native XP drivers: ATI Rage II+, Matrox G100 and Matrox G400. With considerable cerainty i can say that all Matrox models inbetween or bit newer than afforementioned model range will also be working, as they are using same driver package; - all vesa 2.0 videocards i tested are working correctly with our VESA driver. Only single cases have issues here; We still have a number of bugs in this area, for your consideration: - lack of VESA 1.2 support: this locks up older PCI cards, like whole S3 family (up to savage) to VGA driver. Only workaround is to use native XP drivers. It succeeded with S3 Trio 64, but uncovered another bug listed belo; (bug no.4447) - if XP video driver is installed (by slipstreaming into bootcd) on installation with VGA driver selected in 1st stage, even though XP driver is loaded, the system will be locked to VGA mode (640x480x4bpp unchangeable). This one is not yet submitted as it needs to be confirmed by other tester first; - VGA driver, if picked in 1st stage, jumps back to VESA on 3rd stage boot. This can be rigged away by replacing VESA driver with vga driver files, leaving the filenames of the former (bug no. - Some Windows VGA drivers will cause ASSERT in Videoprt. In many cases this ASSERT may be cont-ed without any visible side-effect, yet it requires more attention (bug no.4354); - our opengl setup requires only specific opengl setup (bug no. 4574); - Matrox G400 opengl ICD is not cooperating well with our opengl32.dll (fails when DrvDescribePixelFormat is called from the icd), requires more attention and a way to instert breakpoint within ReactOS to an dll that has not been loaded yet, namely a working debugger like Olly); I am also preparing to create a support page for I/O controllers, as soon as i get some components for a few entries.

1 0

Help me test Visual C++ support
by KJK::Hyperion 10 Jun '09

10 Jun '09

As of r41374, Visual C++ suppport in rbuild is almost fully functional (PCH and full dependencies - i.e. rbuild -df - won't work yet. Also, the Microsoft linker is not supported yet). All I need now is people working to make sources compile with it. How to: add option -Mcmsc to variable ROS_RBUILDFLAGS: set ROS_RBUILDFLAGS=%ROS_RBUILDFLAGS% -Mcmsc and build modules! make --keep-going will be very useful for the time being. Now start fixing shit, for the love of god! go go go!

1 0

Help me test Visual C++ support
by KJK::Hyperion 08 Jun '09

08 Jun '09

So you want to make Visual C++ building support a reality. Good. Do you have Visual Studio, Visual C++ Express or any flavor of the DDK? Do you have trunk checked out and updated? Even better. Do the following from a RosBE prompt: * del makefile.auto * set ROS_RBUILDFLAGS=-Mmicrosoft * make rbuild and reply to this message with: * what version of Visual Studio, Visual C++ Express or the DDK you installed * the output of the "[RBUILD] makefile.auto" phase To clean up and resume building as usual: * del makefile.auto * set ROS_RBUILDFLAGS= Thank you

7 6

Help me test Visual C++ support
by victor martinez 08 Jun '09

08 Jun '09

> * what version of Visual Studio, Visual C++ Express or the DDK you > installed Microsoft Visual Studio 2005 Version 8.0.50727.867 (vsvista.050727-8600) > * the output of the "[RBUILD] makefile.auto" phase [RBUILD] makefile.auto Reading build files...done Detecting compiler...detected (cl 14.0.50727.762) Detecting binutils...detected (link 8.0.50727.762) Detecting netwide assembler...detected (nasm 2.05.01) Detecting compiler pre-compiled header support...disabled Processing modules...done Creating directories...done Generating test support code...done Generating compilation unit support code...done Generating syssetup.inf...done Generating proxy makefiles...done Checking automatic dependencies...done Regards, Victor. _________________________________________________________________ Descubre todas las formas en que puedes estar en contacto con amigos y familiares. http://www.microsoft.com/windows/windowslive/default.aspx

1 0

Re: [ros-dev] [ros-diffs] [hyperion] 41344: Fix no-op code for UNIX hosts
by Steven Edwards 08 Jun '09

08 Jun '09

On Sun, Jun 7, 2009 at 7:39 PM, <hyperion(a)svn.reactos.org> wrote: > +#include "../../pch.h" This is really minor but can you fix it by changing the -I path? Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 2

Re: [ros-dev] [ros-diffs] [hyperion] 41343: modified tools/rbuild/backend/mingw/mingw.cpp modified tools/rbuild/backend/mingw/mingw.h From now on, the MinGW back-end will also support the Microsoft command line C/C++ compiler (cl) and incremental linker (link)
by Steven Edwards 08 Jun '09

08 Jun '09

On Sun, Jun 7, 2009 at 7:33 PM, <hyperion(a)svn.reactos.org> wrote: > +#include "../../pch.h" Ditto for here. > + > +// TODO? attempt to support Microsoft tools on non-Windows? > +#if !defined(WIN32) > + > +bool > +MingwBackend::DetectMicrosoftCompiler ( std::string& ) > +{ > + return false; > +} There are some crazy people that run cl under Wine. I know older versions such as the vctoolkit worked. I'm not sure about more recent revs. I'm happy to try to make time to look in to this at some point. It would be nice for us Linux and OS X users to be able to verify things from time to time with msvc without needing a fullblown vm. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Old Code in User32
by James Tabor 05 Jun '09

05 Jun '09

Hi all! I noticed we still have drawing issues even after fixing some gdi code. Well, I guess we need to look at the main windowing side of the house now. I guess, based on a stable release we can sync up wine and patch by hand the forked code too. I know of some Delphi issues that could use a good non static update. Bulk of our user code is from wine and that includes the window positioning bug everyone has had a crack at as well. I notices that most of the syncs in comdlg/controls depend on user code updates. If Richedit breaks windowing, it could be related to user32/win32k code not updated or based on behavior that is wrong. Syncing and updating forked code is not fun, with both, one needs to take into account local fixes. When you find them, mark them like "REACTOS HACK" or "REACTOS ONLY" or "REACTOS ????" what ever. Reading the change logs for each file should help with determining local patches that have been applied and need to be taken into account as well. If you have a bug report, please mark it as WINE SYNC or WINE UPDATE, something to let us know, it's a wine sync of some kind. We have a file in our media doc directory that holds the sync/fork information, please include it with your updates. Thanks, James Ref: README.WINE: User32 - reactos/dll/win32/user32/controls/button.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/controls/combo.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/controls/edit.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/controls/icontitle.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/controls/listbox.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/controls/scrollbar.c # Forked reactos/dll/win32/user32/controls/static.c # Synced at 20071024 reactos/dll/win32/user32/misc/dde.c # Synced to wine 1.1.17 (dde_misc.c) reactos/dll/win32/user32/misc/ddeclient.c # Synced to wine 1.1.17 reactos/dll/win32/user32/misc/ddeserver.c # Synced to wine 1.1.17 reactos/dll/win32/user32/misc/exticon.c # Last sync date unknown reactos/dll/win32/user32/misc/resources.c # Forked? reactos/dll/win32/user32/misc/winhelp.c # Last sync date unknown reactos/dll/win32/user32/misc/wsprintf.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/windows/defwnd.c # Forked reactos/dll/win32/user32/windows/draw.c # Forked at Wine-20020904 (uitools.c) reactos/dll/win32/user32/windows/mdi.c # Synced at 20060703 reactos/dll/win32/user32/windows/menu.c # Forked reactos/dll/win32/user32/windows/messagebox.c # Forked reactos/dll/win32/user32/windows/rect.c # Forked (uitools.c) reactos/dll/win32/user32/windows/text.c # Forked (lstr.c) reactos/dll/win32/user32/windows/winpos.c # Forked

1 0

Re: [ros-dev] [ros-diffs] [jimtabor] 41250: - Hax-implement NtGdiSetPixelFormat and add a support function UserGethWnd with some code cleanup.
by Timo Kreuzer 05 Jun '09

05 Jun '09

This looks like ultra-hax. Can you explain why this should be correct? It would mean DrvSetPixelFormat would be passed a SURFACE rather than a SURFOBJ. jimtabor(a)svn.reactos.org schrieb: > Author: jimtabor > Date: Tue Jun 2 10:50:36 2009 > New Revision: 41250 > > URL: http://svn.reactos.org/svn/reactos?rev=41250&view=rev > Log: > - Hax-implement NtGdiSetPixelFormat and add a support function UserGethWnd with some code cleanup. > > Modified: > [...] > + /* > + Based on some rules! InfoDC to DC or, based on wiki information! > + All pointers, it's a "must be!", (CONTAINING_RECORD +10h = SURFOBJ), the > + pointer will start at SURFOBJ of the SURFACE structure. > + */ > + pso = (SURFOBJ *)pdc->dclevel.pSurface; > + if (!pso) pso = pdc->pSurfInfo; > + if (!pso) pso = ppdev->pSurface; > + } > + > + if (ppdev->flFlags & PDEV_META_DEVICE) > + { > + UNIMPLEMENTED; > + goto Exit; > + } > + > + if (ppdev->DriverFunctions.SetPixelFormat) > + { > + Ret = ppdev->DriverFunctions.SetPixelFormat( > + pso, > + ipfd, > + hWnd); > + } >

2 3

Re: [ros-dev] [ros-diffs] [dgorbachev] 41284: Remove KeBugCheckWithTf() hack, fix VBEResetHw(). Stefan Ginsberg, bug #4581.
by Aleksey Bragin 04 Jun '09

04 Jun '09

He has write access (sginsberg), however he posted that to bugzilla for peer review and comments before committing, not because he lacks time to commit himself. WBR, Aleksey Bragin. On Jun 4, 2009, at 5:54 PM, dgorbachev(a)svn.reactos.org wrote: > Author: dgorbachev > Date: Thu Jun 4 17:54:27 2009 > New Revision: 41284 > > URL: http://svn.reactos.org/svn/reactos?rev=41284&view=rev > Log: > Remove KeBugCheckWithTf() hack, fix VBEResetHw(). Stefan Ginsberg, > bug #4581. > > Modified: > trunk/reactos/drivers/video/miniport/vbe/vbemp.c > trunk/reactos/ntoskrnl/ke/bug.c > > Modified: trunk/reactos/drivers/video/miniport/vbe/vbemp.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/video/ > miniport/vbe/vbemp.c?rev=41284&r1=41283&r2=41284&view=diff > ====================================================================== > ======== > --- trunk/reactos/drivers/video/miniport/vbe/vbemp.c [iso-8859-1] > (original) > +++ trunk/reactos/drivers/video/miniport/vbe/vbemp.c [iso-8859-1] > Thu Jun 4 17:54:27 2009 > @@ -546,56 +546,8 @@ > ULONG Columns, > ULONG Rows) > { > - INT10_BIOS_ARGUMENTS BiosRegisters; > - PVBE_DEVICE_EXTENSION VBEDeviceExtension = > - (PVBE_DEVICE_EXTENSION)DeviceExtension; > - > - if (!VBEResetDevice(DeviceExtension, NULL)) > - return FALSE; > - > - /* Change number of columns/rows */ > - VideoPortZeroMemory(&BiosRegisters, sizeof(BiosRegisters)); > - > - if (Columns == 80 && Rows == 25) > - { > - /* Default text size, don't change anything. */ > - return TRUE; > - } > - else if (Columns == 80 && Rows == 28) > - { > - /* Use 9x14 font (80x28) */ > - BiosRegisters.Eax = 0x1111; > - } > - else if (Columns == 80 && Rows == 43) > - { > - /* Use 8x8 font in 350 scans mode (80x43) */ > - BiosRegisters.Eax = 0x1201; > - BiosRegisters.Ebx = 0x30; > - VBEDeviceExtension->Int10Interface.Int10CallBios( > - VBEDeviceExtension->Int10Interface.Context, > - &BiosRegisters); > - > - BiosRegisters.Eax = 0x3; > - BiosRegisters.Ebx = 0; > - VBEDeviceExtension->Int10Interface.Int10CallBios( > - VBEDeviceExtension->Int10Interface.Context, > - &BiosRegisters); > - > - BiosRegisters.Eax = 0x1112; > - } > - else if (Columns == 80 && Rows == 50) > - { > - /* Use 8x8 font (80x50) */ > - BiosRegisters.Eax = 0x1112; > - } > - else > - return FALSE; > - > - VBEDeviceExtension->Int10Interface.Int10CallBios( > - VBEDeviceExtension->Int10Interface.Context, > - &BiosRegisters); > - > - return TRUE; > + /* Return FALSE to let HAL reset the display with INT10 */ > + return FALSE; > } > > /* > > Modified: trunk/reactos/ntoskrnl/ke/bug.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/ > bug.c?rev=41284&r1=41283&r2=41284&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/ke/bug.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/bug.c [iso-8859-1] Thu Jun 4 > 17:54:27 2009 > @@ -1138,13 +1138,11 @@ > #endif > > /* Display the BSOD */ > - KeLowerIrql(APC_LEVEL); // This is a nastier hack than any > ever before > KiDisplayBlueScreen(MessageId, > IsHardError, > HardErrCaption, > HardErrMessage, > AnsiName); > - KeRaiseIrql(HIGH_LEVEL, &OldIrql); > > /* Check if the debugger is disabled but we can enable it */ > if (!(KdDebuggerEnabled) && !(KdPitchDebugger)) >

1 0

how to use the macro CHECKPOINT
by Zhang Fan 04 Jun '09

04 Jun '09

I find the defination of CHECKPOINT #define CHECKPOINT do { DbgPrint("%s:%d\n",__FILE__,__LINE__); ExAllocatePool(NonPagedPool,0); } while(0); I don't know why alloc memory with 0 byte

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev