- Ros-dev - ReactOS.org

Re: [ros-dev] Request for a project
by sudheer kumar 16 Jan '10

16 Jan '10

hello, Thank you very much for all the help guys. I am interested in the Fast FAT project. Also arty and colibri gave me an idea to work on partmgr.sys. I am more interested towards Fast FAT as I have prior experience on file systems and I can show something concrete to my professor. The other thing is for partmgr.sys I need to start from the scratch and there isnt much info about it. Is it fine for others ??(since some one might be working on it).The idea of adding list of all the medium sized task to the wiki is good as its going to help people like me. Thanks & Regards, sudhir.

6 10

Re: [ros-dev] [ros-diffs] [spetreolle] 45091: Disable spooler service. This allows bootcdregtest to start here under qemu-kvm.
by Ged Murphy 16 Jan '10

16 Jan '10

This sounds like a hack. Why would disabling a service fix an operating system? Also, don't we need this service for certain Wine tests? -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of spetreolle(a)svn.reactos.org Sent: 15 January 2010 22:17 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [spetreolle] 45091: Disable spooler service. This allows bootcdregtest to start here under qemu-kvm. Author: spetreolle Date: Fri Jan 15 23:17:16 2010 New Revision: 45091 URL: http://svn.reactos.org/svn/reactos?rev=45091&view=rev Log: Disable spooler service. This allows bootcdregtest to start here under qemu-kvm. Modified: trunk/reactos/boot/bootdata/hivesys_i386.inf Modified: trunk/reactos/boot/bootdata/hivesys_i386.inf URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys_i386… ============================================================================== --- trunk/reactos/boot/bootdata/hivesys_i386.inf [iso-8859-1] (original) +++ trunk/reactos/boot/bootdata/hivesys_i386.inf [iso-8859-1] Fri Jan 15 23:17:16 2010 @@ -1198,7 +1198,7 @@ HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","Group",0x00000000,"SpoolerGroup" HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","ImagePath",0x00020000,"%SystemRoot%\system32\spoolsv.exe" HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","ObjectName",0x00000000,"LocalSystem" -HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","Start",0x00010001,0x00000002 +HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","Start",0x00010001,0x00000004 HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","Type",0x00010001,0x00000110 ; WLAN service

2 1

[ros-diffs] [sir_richard] 45052: Patch that fixes VMWare boot (and
by Dmitry Gorbachev 14 Jan '10

14 Jan '10

Hi, sir_richard wrote: > * We really have to get a good DS/ES first before touching any data. > * > * These two reads will either go in a register (with optimizations ON) or > * a stack variable (which is on SS:ESP, guaranteed to be good/valid). > * > * Because the assembly is marked volatile, the order of instructions is > * as-is, otherwise the optimizer could simply get rid of our DS/ES. Timo Kreuzer wrote: > 2.) Segements should be fixed up before entering C code, as not doing so > may introduce possible compiler dependend breakages. It's also much > cleaner and there's no reason to do the same stuff later in inline assembly > instead of direcly in the asm entry point. Ros Arm wrote: > Regarding #2, I unfortunately do not see the need to add more assembly > when it is not needed. There are no subtle compiler breakages involved, > since it is impossible for the compiler to add a DS/ES access for no reason > at all (can you come up with an example?), this is part of the contract the > compiler has to make (if compilers did this, it would break a whole class of > embedded and real-mode software). Because the stack is safe, I think it's > worth avoiding the extra lines of assembly. The C inlines will produce > exactly the same code anyway. Not as a guide to action, simply to note — there is no guarantee that volatile asm statements (and code around them) will never be reordered. As only two registers are needed to keep Ds and Es, it seems to work there. But in a general case, GCC does not hesitate to rearrange such stuff…

1 0

Request for a project
by sudheer kumar 14 Jan '10

14 Jan '10

Hi, I am interested to work on reactos developement. I want to take my work on reactos as a credit in my university. I spoke toAleksey Bragin (Fireball) regarding this. He asked me to mail to the developer mailing list. I need some concrete work to work for like five months or more so that I can show to professor to get his acceptance. My skills involve mostly on developing .I am mostly a C++ programmer with some experience in assembly language. I have some prior experience on filesystems and kernel but mostly linux. I have some experience on windows drivers too. By the way I am a masters student in computer science from US. Thanks & Regards, sudhir. .

8 11

bug in KiTrap0DHandler
by Timo Kreuzer 13 Jan '10

13 Jan '10

@Sir Richard, While fixing trunk breakage, I also fixed another bug in KiTrap0DHandler, which was always only checking one prefix. I attached the patch. Regards, Timo Index: traphdlr.c =================================================================== --- traphdlr.c (Revision 45057) +++ traphdlr.c (Arbeitskopie) @@ -1103,19 +1103,23 @@ /* Skip prefix instructions */ for (j = 0; j < sizeof(KiTrapPrefixTable); j++) { - /* Is this NOT a prefix instruction? */ - if (Instructions[i] != KiTrapPrefixTable[j]) + /* Is this a prefix instruction? */ + if (Instructions[i] == KiTrapPrefixTable[j]) { - /* We can go ahead and handle the fault now */ - Instruction = Instructions[i]; + /* Stop looking */ break; } } - /* Do we need to keep looking? */ - if (Instruction) break; + /* Is this NOT any prefix instruction? */ + if (Instructions[i] != KiTrapPrefixTable[j]) + { + /* We can go ahead and handle the fault now */ + Instruction = Instructions[i]; + break; + } } - + /* If all we found was prefixes, then this instruction is too long */ if (!Instruction) {

1 0

Fwd: removing ReactOS (for lulz)
by Aleksey Bragin 13 Jan '10

13 Jan '10

:) Begin forwarded message: > From: Max Winter <maxwinter2001(a)yahoo.com> > Date: January 13, 2010 1:26:11 AM GMT+03:00 > To: xxxxxxx(a)reactos.org > Subject: removing ReactOS > > How do I get ReactOS off my computer? I downloaded a third of it > and for various reasons stopped the download. I want to get it off > my computer now but it is not giving me delete or cut options. > This is as bad as malware, or Hotel California, you can check it > in but you can't check out. > > M >

2 1

Re: [ros-dev] [ros-diffs] [sir_richard] 45057: [NTOS]: Fix some bugs and cleanup V8086 code in regards to flags usage. [NTOS]: Add VDM debug spew to see why there's now an invalid opcode on Windows builds of VMWare and certain QEmu combinations. (Not
by James Tabor 13 Jan '10

13 Jan '10

Go into ntoskrnl and svn up -r 45013 should take care of it....... On Wed, Jan 13, 2010 at 3:31 AM, Ged Murphy <gedmurphy(a)gmail.com> wrote: > sir_richard, > > Trunk is still broken and is causing issues for some of the dev team. > > You can see the problems in our buildbot test machine: > - Go to the following address : http://build.reactos.org:8010 > - under the x86_(Test) machine, click on the stdio for the 'test' stage. > - You'll see stage 1 complete, the stage 2 bugchecks. > > Could you please address this problem before continuing your work as it's ruining the test system. > The problem is that because our test machine can't run we aren't able to monitor other commits in other areas, meaning we're potentially introducing other bugs that we're now missing. > According to our policy, failure to fix this soon (it's normally 24 hours) will result in us having to freeze development on trunk until the bug is fixed. If we're unable to fix it in a reasonable amount of time then the changes need to be reverted until we have a bootable OS again. > > Regards, > Ged Murphy. > > >

2 1

Re: [ros-dev] [ros-diffs] [sir_richard] 45057: [NTOS]: Fix some bugs and cleanup V8086 code in regards to flags usage. [NTOS]: Add VDM debug spew to see why there's now an invalid opcode on Windows builds of VMWare and certain QEmu combinations. (Note: the double f
by Ged Murphy 13 Jan '10

13 Jan '10

sir_richard, Trunk is still broken and is causing issues for some of the dev team. You can see the problems in our buildbot test machine: - Go to the following address : http://build.reactos.org:8010 - under the x86_(Test) machine, click on the stdio for the 'test' stage. - You'll see stage 1 complete, the stage 2 bugchecks. Could you please address this problem before continuing your work as it's ruining the test system. The problem is that because our test machine can't run we aren't able to monitor other commits in other areas, meaning we're potentially introducing other bugs that we're now missing. According to our policy, failure to fix this soon (it's normally 24 hours) will result in us having to freeze development on trunk until the bug is fixed. If we're unable to fix it in a reasonable amount of time then the changes need to be reverted until we have a bootable OS again. Regards, Ged Murphy. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of sir_richard(a)svn.reactos.org Sent: 13 January 2010 03:43 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [sir_richard] 45057: [NTOS]: Fix some bugs and cleanup V8086 code in regards to flags usage. [NTOS]: Add VDM debug spew to see why there's now an invalid opcode on Windows builds of VMWare and certain QEmu combinations. (Note: the double fault Author: sir_richard Date: Wed Jan 13 04:43:03 2010 New Revision: 45057 URL: http://svn.reactos.org/svn/reactos?rev=45057&view=rev Log: [NTOS]: Fix some bugs and cleanup V8086 code in regards to flags usage. [NTOS]: Add VDM debug spew to see why there's now an invalid opcode on Windows builds of VMWare and certain QEmu combinations. (Note: the double fault issue is fixed, this is a new issue). Modified: trunk/reactos/ntoskrnl/ke/i386/v86vdm.c Modified: trunk/reactos/ntoskrnl/ke/i386/v86vdm.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/v86vdm.c?… ============================================================================== --- trunk/reactos/ntoskrnl/ke/i386/v86vdm.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/ke/i386/v86vdm.c [iso-8859-1] Wed Jan 13 04:43:03 2010 @@ -12,6 +12,9 @@ #include <ntoskrnl.h> #define NDEBUG #include <debug.h> + +#define KiVdmGetInstructionSize(x) ((x) & 0xFF) +#define KiVdmGetPrefixFlags(x) ((x) & 0xFFFFFF00) /* GLOBALS ********************************************************************/ @@ -51,6 +54,7 @@ ULONG Esp, V86EFlags, TrapEFlags; /* Get current V8086 flags and mask out interrupt flag */ + DbgPrint("VDM: Handling PUSHF (PREFIX [0x%lx])\n", KiVdmGetPrefixFlags(Flags)); V86EFlags = *KiNtVdmState; V86EFlags &= ~EFLAGS_INTERRUPT_MASK; @@ -67,7 +71,7 @@ Esp -= 2; /* Check for OPER32 */ - if (Flags & PFX_FLAG_OPER32) + if (KiVdmGetPrefixFlags(Flags) & PFX_FLAG_OPER32) { /* Save EFlags */ Esp -= 2; @@ -81,7 +85,7 @@ /* Set new ESP and EIP */ TrapFrame->HardwareEsp = (USHORT)Esp; - TrapFrame->Eip += (Flags & 0xFF); + TrapFrame->Eip += KiVdmGetInstructionSize(Flags); /* We're done */ return TRUE; @@ -95,6 +99,7 @@ ULONG Esp, V86EFlags, EFlags, TrapEFlags; /* Build flat ESP */ + DbgPrint("VDM: Handling POPF (PREFIX [0x%lx])\n", KiVdmGetPrefixFlags(Flags)); Esp = (TrapFrame->HardwareSegSs << 4) + (USHORT)TrapFrame->HardwareEsp; /* Read EFlags */ @@ -102,7 +107,7 @@ Esp += 4; /* Check for OPER32 */ - if (!(Flags & PFX_FLAG_OPER32)) + if (!(KiVdmGetPrefixFlags(Flags) & PFX_FLAG_OPER32)) { /* Read correct flags and use correct stack address */ Esp -= 2; @@ -140,7 +145,7 @@ /* FIXME: Check for VDM interrupts */ /* Update EIP */ - TrapFrame->Eip += (Flags & 0xFF); + TrapFrame->Eip += KiVdmGetInstructionSize(Flags); /* We're done */ return TRUE; @@ -187,7 +192,7 @@ /* Push IP */ Esp -= 2; - *(PUSHORT)(Esp) = (USHORT)TrapFrame->Eip + (Flags & 0xFF) + 1; + *(PUSHORT)(Esp) = (USHORT)TrapFrame->Eip + KiVdmGetInstructionSize(Flags) + 1; /* Update ESP */ TrapFrame->HardwareEsp = (USHORT)Esp; @@ -196,11 +201,12 @@ Eip = (TrapFrame->SegCs << 4) + TrapFrame->Eip; /* Now get the *next* EIP address (current is original + the count - 1) */ - Eip += (Flags & 0xFF); + Eip += KiVdmGetInstructionSize(Flags); /* Now read the interrupt number */ Interrupt = *(PUCHAR)Eip; - + DbgPrint("VDM: Handling INT [0x%lx]\n", Interrupt); + /* Read the EIP from its IVT entry */ Interrupt = *(PULONG)(Interrupt * 4); TrapFrame->Eip = (USHORT)Interrupt; @@ -240,12 +246,13 @@ IN ULONG Flags) { ULONG Esp, V86EFlags, EFlags, TrapEFlags, Eip; - + /* Build flat ESP */ + DbgPrint("VDM: Handling IRET (PREFIX [0x%lx])\n", KiVdmGetPrefixFlags(Flags)); Esp = (TrapFrame->HardwareSegSs << 4) + TrapFrame->HardwareEsp; /* Check for OPER32 */ - if (Flags & PFX_FLAG_OPER32) + if (KiVdmGetPrefixFlags(Flags) & PFX_FLAG_OPER32) { /* Build segmented EIP */ TrapFrame->Eip = *(PULONG)Esp; @@ -292,6 +299,7 @@ /* Build flat EIP and check if this is the BOP instruction */ Eip = (TrapFrame->SegCs << 4) + TrapFrame->Eip; + DbgPrint("VDM: Handling IRET EIP @ 0x%p [OPCODE: %lx]\n", Eip, *(PUSHORT)Eip); if (*(PUSHORT)Eip == 0xC4C4) { /* Dispatch the BOP */ @@ -313,11 +321,12 @@ { /* FIXME: Support VME */ - /* disable interrupts */ + /* Disable interrupts */ + DbgPrint("VDM: Handling CLI\n"); KiVdmClearVdmEFlags(EFLAGS_INTERRUPT_MASK); /* Skip instruction */ - TrapFrame->Eip += (Flags & 0xFF); + TrapFrame->Eip += KiVdmGetInstructionSize(Flags); /* Done */ return TRUE; @@ -331,10 +340,11 @@ /* FIXME: Support VME */ /* Enable interrupts */ + DbgPrint("VDM: Handling STI\n"); KiVdmSetVdmEFlags(EFLAGS_INTERRUPT_MASK); /* Skip instruction */ - TrapFrame->Eip += (Flags & 0xFF); + TrapFrame->Eip += KiVdmGetInstructionSize(Flags); /* Done */ return TRUE; @@ -351,7 +361,8 @@ /* Get flat EIP of the *current* instruction (not the original EIP) */ Eip = (TrapFrame->SegCs << 4) + TrapFrame->Eip; - Eip += (Flags & 0xFF) - 1; + DbgPrint("VDM: Handling Opcode @ 0x%p\n", Eip); + Eip += KiVdmGetInstructionSize(Flags) - 1; /* Read the opcode entry */ switch (*(PUCHAR)Eip) @@ -409,6 +420,7 @@ IN ULONG Flags) { /* Increase instruction size */ + DbgPrint("VDM: Handling PREFIX [%lx] Opcode @ 0x%p\n", KiVdmGetPrefixFlags(Flags), TrapFrame->Eip); Flags++; /* Handle the next opcode */ @@ -623,7 +635,9 @@ Tss->IoMapBase = (USHORT)IOPM_OFFSET; /* Switch stacks and work the magic */ + DbgPrint("VDM: Entering V8086 Mode\n"); Ki386SetupAndExitToV86Mode(VdmTeb); + DbgPrint("VDM: Exiting V8086 Mode\n"); /* Restore IOPM */ RtlCopyMemory(&Tss->IoMaps[0].IoMap, Ki386IopmSaveArea, PAGE_SIZE * 2);

1 0

Re: [ros-dev] [ros-diffs] [sir_richard] 45052: Patch that fixes VMWare boot (and should fix QEMu/KVM boot on the testbot): [NTOS]: A trap can get us into a state where DS/ES are invalid, making any pointer dereference (on DS/ES segmented memory, not SS, the stack) crash (and probably double-fault). Therefore, we have to be careful to switch to a good DS/ES before touching the TrapFrame pointer, which we don't have in ESP like the ASM code, but in a DS/ES-segmented register. For V8086 traps we can switch to
by Timo Kreuzer 12 Jan '10

12 Jan '10

Hi, I suggest the following changes to the current implementation: 1.) Replace the PUSHA in the trap entry code, by a series of MOVs to the correct stack positions. The same for the trap exit code. KiTrapFrameFromPushaStack can be removed then. This would result in more clear, less complex and faster code, with only a few additional assembly instructions in the trap entry macro. The exit could be done either by normal call/return or by a jmp to an exit handler. 2.) Segements should be fixed up before entering C code, as not doing so may introduce possible compiler dependend breakages. It's also much cleaner and there's no reason to do the same stuff later in inline assembly instead of direcly in the asm entry point. The resulting code might looks something like this: /* Allocate KTRAP_FRAME */ sub esp, KTRAP_FRAME_LENGTH - 10 * 4 /* Save integer registers */ mov [esp + KTRAP_FRAME_EBP], ebp mov [esp + KTRAP_FRAME_EBX], ebx mov [esp + KTRAP_FRAME_ESI], esi mov [esp + KTRAP_FRAME_EDI], edi mov [esp + KTRAP_FRAME_EAX], eax mov [esp + KTRAP_FRAME_ECX], ecx mov [esp + KTRAP_FRAME_EDX], edx mov [esp + KTRAP_FRAME_EBX], ebx /* Save segment regs */ mov [esp + KTRAP_FRAME_SEGDS], ds mov [esp + KTRAP_FRAME_SEGES], es /* Fixup segment regs */ mov ax, KGDT_R3_DATA | RPL_MASK mov ds, ax mov es, ax Timo

8 11

Re: [ros-dev] [ros-diffs] [dreimer] 45050: Ok, last time I delete my built main tree while playing with clean in a branch! Now clean cleans the branch you are in!
by Colin Finck 12 Jan '10

12 Jan '10

dreimer(a)svn.reactos.org wrote: > URL: http://svn.reactos.org/svn/reactos?rev=45050&view=rev FYI, I already have a change like this ready for some months, see http://reactos.colinfinck.de/files/Other_Stuff/Clean.cmd I won't commit it though, because after a suggestion from KJK, I agree that it would be the best if RosBE's basic clean logic goes into the Makefile itself and RosBE's clean scripts only call "make rosbe-clean" (or whatever it'll be called) afterwards. Then no RosBE clean script would ever need to care about the environment variables for object and output pathes again. We would stop duplicating logic in the Makefile and in RosBE and a simple "clean" would always operate on the same tree as a "make" by design. This is another change that should be finished before we release RosBE 1.5, because it'll break compatibility with older revisions (just like the new toolchain will do), and I want to avoid doing this too often. Best regards, Colin

3 2

Re: [ros-dev] [ros-diffs] [dreimer] 45050: Ok, last time I delete my built main tree while playing with clean in a branch! Now clean cleans the branch you are in!
by Timo Kreuzer 11 Jan '10

11 Jan '10

\o/ <3 <3 <3 dreimer(a)svn.reactos.org schrieb: > Author: dreimer > Date: Mon Jan 11 22:22:52 2010 > New Revision: 45050 > > URL: http://svn.reactos.org/svn/reactos?rev=45050&view=rev > Log: > Ok, last time I delete my built main tree while playing with clean in a branch! > Now clean cleans the branch you are in! > >

1 0

Re: [ros-dev] [ros-diffs] [sir_richard] 45041: [NTOS]: Put ASM macros back since the HAL also uses them.
by Gabriel ilardi 11 Jan '10

11 Jan '10

Hi, Just for the record, with this revision I can't enter in graphic mode in 2nd stage, I always get this at the end of the drivers loading: (subsystems/win32/win32k/ntuser/sysparams.c:1499) UserSystemParametersInfo called without active windowstation. PuTTYEntered debugger on last-chance exception (Exception Code: 0xc000001d) (Invalid Opcode) kdb:> bt Eip: <00010002> Frames: <43504420> Couldn't access memory at 0x2A2A2A0E! kdb:> Best regards, Gabriel. > Date: Mon, 11 Jan 2010 06:41:19 +0000 > To: ros-diffs(a)reactos.org > From: sir_richard(a)svn.reactos.org > Subject: [ros-diffs] [sir_richard] 45041: [NTOS]: Put ASM macros back since the HAL also uses them. > > Author: sir_richard > Date: Mon Jan 11 07:41:19 2010 > New Revision: 45041 > > URL: http://svn.reactos.org/svn/reactos?rev=45041&view=rev > Log: > [NTOS]: Put ASM macros back since the HAL also uses them. > > > Modified: > trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S > > Modified: trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S [iso-8859-1] Mon Jan 11 07:41:19 2010 > @@ -114,6 +114,28 @@ > .endm > > // > +// @name UNHANDLED_V86_PATH > +// > +// This macro prints out that the current code path is for unhandled VDM support > +// > +// @param None > +// > +// @remark None. > +// > +.macro UNHANDLED_V86_PATH > + /* Get EIP */ > + call $+5 > + > + /* Print debug message */ > + push offset _V86UnhandledMsg > + call _DbgPrint > + add esp, 8 > + > + /* Loop indefinitely */ > + jmp $ > +.endm > + > +// > // @name IDT > // > // This macro creates an IDT entry for the given handler > @@ -255,6 +277,58 @@ > .endm > > // > +// @name INVALID_V86_OPCODE > +// > +// This macro creates one or more entries for unhandled V86 Opcodes > +// in the V86 Opcode Table. > +// > +// @param count. > +// Number of entries to generate. > +// > +// @remark None. > +// > +.macro INVALID_V86_OPCODE count > + .rept \count > + .byte 0 > + .endr > +.endm > + > +// > +// @name GENERATE_PREFIX_HANDLER > +// > +// This macro creates a prefix opcode handler. > +// > +// @param None. > +// > +// @remark None. > +// > +.macro GENERATE_PREFIX_HANDLER Name > +.func Opcode&Name&PrefixV86 > +_Opcode&Name&PrefixV86: > + or ebx, PREFIX_FLAG_&Name > + jmp _OpcodeGenericPrefixV86 > +.endfunc > +.endm > + > +// > +// @name INVALID_V86_OPCODE > +// > +// This macro prints out visible message and hangs the computer. > +// > +// @param None. > +// > +// @remark Temporary debugging use. > +// > +.macro UNHANDLED_V86_OPCODE > + /* Print debug message, breakpoint and freeze */ > + push ecx > + push offset V86DebugMsg > + call _DbgPrint > + add esp, 8 > + jmp $ > +.endm > + > +// > // @name TRAP_FIXUPS > // > // This macro contains out-of-line code for various Trap Frame Fixups, such as: > @@ -448,6 +522,96 @@ > cli > jmp 1b > 2: > +.endm > + > +// > +// @name TRAP_PROLOG > +// > +// This macro creates a standard trap entry prologue. > +// It should be used for entry into any kernel trap (KiTrapXx), but not for > +// system calls, which require special handling. > +// > +// @param Label > +// Identifying name of the caller function; will be used to append > +// to the name V86 and DR helper functions, which must already exist. > +// > +// @remark Use as follows: > +// _KiTrap00: > +// /* Push fake error code */ > +// push 0 > +// > +// /* Enter common prologue */ > +// TRAP_PROLOG(0) > +// > +// /* Handle trap */ > +// <Your Trap Code Here> > +// > +.macro TRAP_PROLOG Label EndLabel > + /* Just to be safe, clear out the HIWORD, since it's reserved */ > + mov word ptr [esp+2], 0 > + > + /* Save the non-volatiles */ > + push ebp > + push ebx > + push esi > + push edi > + > + /* Save FS and set it to PCR */ > + push fs > + mov ebx, KGDT_R0_PCR > + .byte 0x66 > + mov fs, bx > + > + /* Save exception list and bogus previous mode */ > + push fs:[KPCR_EXCEPTION_LIST] > + push -1 > + > + /* Save volatiles and segment registers */ > + push eax > + push ecx > + push edx > + push ds > + push es > + push gs > + > + /* Set the R3 data segment */ > + mov ax, KGDT_R3_DATA + RPL_MASK > + > + /* Skip debug registers and debug stuff */ > + sub esp, 0x30 > + > + /* Load the segment registers */ > + .byte 0x66 > + mov ds, ax > + .byte 0x66 > + mov es, ax > + > + /* Check if this interrupt happened in 16-bit mode */ > + cmp esp, 0x10000 > + jb _Ki16BitStackException > + > + /* Set up frame */ > + mov ebp, esp > + > + /* Check if this was from V86 Mode */ > + test dword ptr [ebp+KTRAP_FRAME_EFLAGS], EFLAGS_V86_MASK > + jnz V86_&Label > + > +V86_&EndLabel: > + /* Get current thread */ > + mov ecx, fs:[KPCR_CURRENT_THREAD] > + cld > + > + /* Flush DR7 */ > + and dword ptr [ebp+KTRAP_FRAME_DR7], 0 > + > + /* Check if the thread was being debugged */ > + test byte ptr [ecx+KTHREAD_DEBUG_ACTIVE], 0xFF > + jnz Dr_&Label > + > + /* Set the Trap Frame Debug Header */ > +Dr_&EndLabel: > + SET_TF_DEBUG_HEADER > .endm > > // > @@ -735,6 +899,164 @@ > .endm > > // > +// @name V86_TRAP_PROLOG > +// > +// This macro creates a V86 Trap entry prologue. > +// It should be used for entry into any fast-system call (KiGetTickCount, > +// KiCallbackReturn, KiRaiseAssertion) and the generic system call handler > +// (KiSystemService) > +// > +// @param Label > +// Unique label identifying the name of the caller function; will be > +// used to append to the name of the DR helper function, which must > +// already exist. > +// > +// @remark None. > +// > +.macro V86_TRAP_PROLOG Label EndLabel > + > + /* Skip everything to the error code */ > + sub esp, KTRAP_FRAME_ERROR_CODE > + > + /* Clear the error code */ > + mov word ptr [esp+KTRAP_FRAME_ERROR_CODE+2], 0 > + > + /* Save the registers we'll trample */ > + mov [esp+KTRAP_FRAME_EBX], ebx > + mov [esp+KTRAP_FRAME_EAX], eax > + mov [esp+KTRAP_FRAME_EBP], ebp > + mov [esp+KTRAP_FRAME_ESI], esi > + mov [esp+KTRAP_FRAME_EDI], edi > + > + /* Save PCR and Ring 3 segments */ > + mov ebx, KGDT_R0_PCR > + mov eax, KGDT_R3_DATA + RPL_MASK > + > + /* Save ECX and EDX too */ > + mov [esp+KTRAP_FRAME_ECX], ecx > + mov [esp+KTRAP_FRAME_EDX], edx > + > + /* Set debugging markers */ > + mov dword ptr [esp+KTRAP_FRAME_PREVIOUS_MODE], -1 > + mov dword ptr [esp+KTRAP_FRAME_DEBUGARGMARK], 0xBADB0D00 > + > + /* Now set segments (use OVERRIDE, 0x66) */ > + .byte 0x66 > + mov fs, bx > + .byte 0x66 > + mov ds, ax > + .byte 0x66 > + mov es, ax > + > + /* Set the trap frame in the stack and clear the direction flag */ > + mov ebp, esp > + cld > + > + /* Save the exception list */ > + mov eax, fs:[KPCR_EXCEPTION_LIST] > + mov [esp+KTRAP_FRAME_EXCEPTION_LIST], eax > + > + /* Check if we need debugging */ > + mov eax, dr7 > + test eax, ~DR7_RESERVED_MASK > + mov [esp+KTRAP_FRAME_DR7], eax > + jnz Dr_&Label > + > +Dr_&EndLabel: > +.endm > + > +// > +// @name V86_TRAP_EPILOG > +// > +// This macro creates an epilogue for leaving V86 traps > +// > +// @param None. > +// > +// @remark None. > +// > +.macro V86_TRAP_EPILOG > + > + /* Get the current thread and make it unalerted */ > +ExitBegin: > + mov ebx, PCR[KPCR_CURRENT_THREAD] > + mov byte ptr [ebx+KTHREAD_ALERTED], 0 > + > + /* Check if it has User-mode APCs pending */ > + cmp byte ptr [ebx+KTHREAD_PENDING_USER_APC], 0 > + jne PendingUserApc > + > + /* It doesn't, pop the frame */ > + add esp, KTRAP_FRAME_EDX > + pop edx > + pop ecx > + pop eax > + > + /* Check if DR registers should be restored */ > + test dword ptr [ebp+KTRAP_FRAME_DR7], ~DR7_RESERVED_MASK > + jnz V86DebugRestore > + > + /* Finish popping the rest of the frame, and return to P-mode */ > +V86DebugContinue: > + add esp, 12 > + pop edi > + pop esi > + pop ebx > + pop ebp > + add esp, 4 > + iretd > + > +V86DebugRestore: > + > + /* Get DR0, 1 */ > + xor ebx, ebx > + mov esi, [ebp+KTRAP_FRAME_DR0] > + mov edi, [ebp+KTRAP_FRAME_DR1] > + > + /* Clear DR 7 */ > + mov dr7, ebx > + > + /* Get DR2 and load DR0-2 */ > + mov ebx, [ebp+KTRAP_FRAME_DR2] > + mov dr0, esi > + mov dr1, edi > + mov dr2, ebx > + > + /* Get DR3-7 */ > + mov esi, [ebp+KTRAP_FRAME_DR0] > + mov edi, [ebp+KTRAP_FRAME_DR1] > + mov ebx, [ebp+KTRAP_FRAME_DR7] > + > + /* Load them */ > + mov dr3, esi > + mov dr6, edi > + mov dr7, ebx > + jmp V86DebugContinue > + > +PendingUserApc: > + > + /* Raise to APC level */ > + mov ecx, APC_LEVEL > + call @KfRaiseIrql@4 > + > + /* Save KIRQL and deliver APCs */ > + push eax > + sti > + push ebp > + push 0 > + push UserMode > + call _KiDeliverApc@12 > + > + /* Restore IRQL */ > + pop ecx > + call @KfLowerIrql@4 > + cli > + > + /* Check if we're not in V86 anymore */ > + test dword ptr [ebp+KTRAP_FRAME_EFLAGS], EFLAGS_V86_MASK > + jnz ExitBegin > +.endm > + > +// > // @name TRAP_EPILOG > // > // This macro creates an epilogue for leaving any system trap. > > _________________________________________________________________ Non sei a casa? Prova il nuovo Web Messenger http://www.messenger.it/web/default.aspx

2 1

Re: [ros-dev] [ros-diffs] [dreimer] 45031: R.I.P. raddr2line.
by Timo Kreuzer 11 Jan '10

11 Jan '10

Please keep raddr2line. dreimer(a)svn.reactos.org schrieb: > Author: dreimer > Date: Sun Jan 10 17:21:53 2010 > New Revision: 45031 > > URL: http://svn.reactos.org/svn/reactos?rev=45031&view=rev > Log: > R.I.P. raddr2line. > > Modified: > trunk/tools/RosBE/RosBE-Windows/Powershell/reladdr2line.ps1 > trunk/tools/RosBE/RosBE-Windows/Root/ChangeLog.txt > trunk/tools/RosBE/RosBE-Windows/Root/raddr2line.cmd > trunk/tools/RosBE/RosBE-Windows/RosBE.nsi > > Modified: trunk/tools/RosBE/RosBE-Windows/Powershell/reladdr2line.ps1 > URL: http://svn.reactos.org/svn/reactos/trunk/tools/RosBE/RosBE-Windows/Powershe… > ============================================================================== > --- trunk/tools/RosBE/RosBE-Windows/Powershell/reladdr2line.ps1 [iso-8859-1] (original) > +++ trunk/tools/RosBE/RosBE-Windows/Powershell/reladdr2line.ps1 [iso-8859-1] Sun Jan 10 17:21:53 2010 > @@ -35,11 +35,11 @@ > $baseaddr = (objdump -p $FILEPATH | select-string "ImageBase").tostring().split() > $baseaddr = "0x" + ($baseaddr.get($baseaddr.length - 1)) > if ($baseaddr -lt $ADDRESS) { > - IEX "& '$_ROSBE_BASEDIR\Tools\raddr2line.exe' '$FILEPATH' '$ADDRESS'" > + IEX "& '$_ROSBE_BASEDIR\Tools\log2lines.exe' '$FILEPATH' '$ADDRESS'" > } else { > $baseaddr = ($baseaddr | % {[Convert]::ToInt32($_,16)}) + ($ADDRESS | % {[Convert]::ToInt32($_,16)}) > $relbase = "0x" + ("{0:X}" -f $baseaddr) > - IEX "& '$_ROSBE_BASEDIR\Tools\raddr2line.exe' '$FILEPATH' '$relbase'" > + IEX "& '$_ROSBE_BASEDIR\Tools\log2lines.exe' '$FILEPATH' '$relbase'" > } > > $host.ui.RawUI.WindowTitle = "ReactOS Build Environment $_ROSBE_VERSION" > > Modified: trunk/tools/RosBE/RosBE-Windows/Root/ChangeLog.txt > URL: http://svn.reactos.org/svn/reactos/trunk/tools/RosBE/RosBE-Windows/Root/Cha… > ============================================================================== > --- trunk/tools/RosBE/RosBE-Windows/Root/ChangeLog.txt [iso-8859-1] (original) > +++ trunk/tools/RosBE/RosBE-Windows/Root/ChangeLog.txt [iso-8859-1] Sun Jan 10 17:21:53 2010 > @@ -6,7 +6,7 @@ > - Updated w32api to 3.14 (Daniel Reimer) > - Updated NSIS to 2.46 (Daniel Reimer) > - Added Remake command (Daniel Reimer) > -- Added log2lines v1.9 to RosBE (Daniel Reimer) > +- Replaced raddr2line with log2lines v1.9 (Daniel Reimer) > - Added a chinese translation to the options tool (Elton Chung) > - Added ARM Arch support to RosBE (Daniel Reimer) > - Added ARM Settings to options.exe, too (Daniel Reimer) > > Modified: trunk/tools/RosBE/RosBE-Windows/Root/raddr2line.cmd > URL: http://svn.reactos.org/svn/reactos/trunk/tools/RosBE/RosBE-Windows/Root/rad… > ============================================================================== > --- trunk/tools/RosBE/RosBE-Windows/Root/raddr2line.cmd [iso-8859-1] (original) > +++ trunk/tools/RosBE/RosBE-Windows/Root/raddr2line.cmd [iso-8859-1] Sun Jan 10 17:21:53 2010 > @@ -63,12 +63,12 @@ > for /f "tokens=2" %%i in ('"objdump -p "%FILEPATH%" 2>NUL | findstr ImageBase"') do set BASEADDRESS=0x%%i > > if %%i lss %ADDRESS% ( > - "%_ROSBE_BASEDIR%\Tools\raddr2line.exe" "%FILEPATH%" "%ADDRESS%" > + "%_ROSBE_BASEDIR%\Tools\log2lines.exe" "%FILEPATH%" "%ADDRESS%" > ) else ( > set /a BASEADDRESS+=0x%ADDRESS% > > for /f %%i in ('""%_ROSBE_BASEDIR%\Tools\echoh.exe" !BASEADDRESS!"') do set RELBASE=%%i > - "%_ROSBE_BASEDIR%\Tools\raddr2line.exe" "!FILEPATH!" "!RELBASE!" > + "%_ROSBE_BASEDIR%\Tools\log2lines.exe" "!FILEPATH!" "!RELBASE!" > ) > > :EOC > > Modified: trunk/tools/RosBE/RosBE-Windows/RosBE.nsi > URL: http://svn.reactos.org/svn/reactos/trunk/tools/RosBE/RosBE-Windows/RosBE.ns… > ============================================================================== > --- trunk/tools/RosBE/RosBE-Windows/RosBE.nsi [iso-8859-1] (original) > +++ trunk/tools/RosBE/RosBE-Windows/RosBE.nsi [iso-8859-1] Sun Jan 10 17:21:53 2010 > @@ -269,7 +269,6 @@ > SetOutPath "$INSTDIR\Tools" > SetOverwrite try > File /r Components\Tools\echoh.exe > - File /r Components\Tools\raddr2line.exe > File /r Components\Tools\log2lines.exe > File /r Components\Tools\chkslash.exe > SectionEnd > > > >

2 2

Re: [ros-dev] [ros-diffs] [ekohl] 45020: Removed outdated email addresses.
by Aleksey Bragin 11 Jan '10

11 Jan '10

What do you all think about developer's email in source code? Is there a need for it at all there? WBR, Aleksey. On Jan 10, 2010, at 1:43 AM, ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Sat Jan 9 23:43:16 2010 > New Revision: 45020 > > URL: http://svn.reactos.org/svn/reactos?rev=45020&view=rev > Log: > Removed outdated email addresses. > Modified: trunk/reactos/ntoskrnl/ke/queue.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/ > queue.c?rev=45020&r1=45019&r2=45020&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/ke/queue.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/queue.c [iso-8859-1] Sat Jan 9 > 23:43:16 2010 > @@ -5,7 +5,7 @@ > * PURPOSE: Implements kernel queues > * PROGRAMMERS: Alex Ionescu (alex.ionescu(a)reactos.org) > * Gunnar Dalsnes > - * Eric Kohl (ekohl(a)rz-online.de) > + * Eric Kohl > */

4 3

Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 44861: NMI Support Patch 7: [NTOS]: Improve UNHANDLED_PATH macro with a new "Reason" parameter which displays why the path is unhandled (ie: what the unexpected/unlikely/untested scenario is). This is better than just displaying the current PC which is typically useless. [NTOS]: Separate UNHANDLED_PATH from UNHANDLED_V86_PATH which is specifically for paths that are unimplemented due to lack of VDM support. [HAL]: Update to new macros in V8086 support, and handle
by Alexander Potashev 10 Jan '10

10 Jan '10

On 21:03 Fri 01 Jan , ros-arm-bringup(a)svn.reactos.org wrote: > Author: ros-arm-bringup > Date: Fri Jan 1 22:03:22 2010 > New Revision: 44861 > > Modified: trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S > @@ -87,18 +87,47 @@ > // > // @name UNHANDLED_PATH > // > -// This macro TODO > +// This macro prints out that the current code path is not expected yet > // > // @param None > // > // @remark None. > // > -.macro UNHANDLED_PATH > +.macro UNHANDLED_PATH Reason > + > + /* Push reason */ > + push offset 1f > + > /* Get EIP */ > call $+5 > > /* Print debug message */ > push offset _UnhandledMsg > + call _DbgPrint > + add esp, 12 > + > + /* Loop indefinitely */ > + jmp $ > + > +1: > + .asciz \Reason I think, this should be: .asciz "\Reason" I don't know why, but this line (both variants) doesn't compile for me with RosBE 1.4.2 (Linux): ntoskrnl/ke/i386/trap.s: Assembler messages: ntoskrnl/ke/i386/trap.s:290: Error: junk at end of line, first unrecognized character is `o' ntoskrnl/ke/i386/trap.s:290: Error: junk at end of line, first unrecognized character is `j' ntoskrnl/ke/i386/trap.s:290: Error: junk at end of line, first unrecognized character is `o' ntoskrnl/ke/i386/trap.s:425: Error: junk at end of line, first unrecognized character is `j' ntoskrnl/ke/i386/trap.s:425: Error: junk at end of line, first unrecognized character is `j' ntoskrnl/ke/i386/trap.s:425: Error: junk at end of line, first unrecognized character is `j' ntoskrnl/ke/i386/trap.s:439: Error: junk at end of line, first unrecognized character is `j' ntoskrnl/ke/i386/trap.s:439: Error: junk at end of line, first unrecognized character is `j' ntoskrnl/ke/i386/trap.s:439: Error: junk at end of line, first unrecognized character is `j' ntoskrnl/ke/i386/trap.s:467: Error: junk at end of line, first unrecognized character is `A' ntoskrnl/ke/i386/trap.s:1677: Error: junk at end of line, first unrecognized character is `R' ntoskrnl/ke/i386/trap.s:1677: Error: junk at end of line, first unrecognized character is `j' ntoskrnl/ke/i386/trap.s:1677: Error: junk at end of line, first unrecognized character is `R' ntoskrnl/ke/i386/trap.s:2415: Error: junk at end of line, first unrecognized character is `c' ntoskrnl/ke/i386/trap.s:2594: Error: junk at end of line, first unrecognized character is `m' make: *** [obj-i386/ntoskrnl/ke/i386/trap_ntoskrnl.o] Error 1 -- Alexander Potashev

1 0

Move from GPL Permission Denied
by James Tabor 09 Jan '10

09 Jan '10

Public Notice: First and last warning! You do not have my permission to switch from GPL unless it is LGPL! I've coded most of all parts of the project and hold the copyrights with other developers from this project. We have a primary copyright to GPL, take it or leave it! I've imported other projects code into ReactOS and kept and respected their copyrights! Flamed baited by wine for forgetting to pass on copyrights as well and having to recommit them back into code! If it is good for me it is good for you! If you have a problem with this I will have my people contact your people! You have my email address! James

3 2

Re: [ros-dev] [ros-diffs] [martinf] 45001: define _tcscpy_s and _tsplitpath_s again for native VC++ builds
by Gabriel ilardi 08 Jan '10

08 Jan '10

Hi Martin, With latest changes, after booting to third stage I get two identical message boxes with no text, just "ROS Explorer" as the title and ok (before seeing explorer) after clicking on ok both times explorer comes up. Regards, Gabriel. > Date: Fri, 8 Jan 2010 15:10:50 +0000 > To: ros-diffs(a)reactos.org > From: martinf(a)svn.reactos.org > Subject: [ros-diffs] [martinf] 45001: define _tcscpy_s and _tsplitpath_s again for native VC++ builds > > Author: martinf > Date: Fri Jan 8 16:10:50 2010 > New Revision: 45001 > > URL: http://svn.reactos.org/svn/reactos?rev=45001&view=rev > Log: > define _tcscpy_s and _tsplitpath_s again for native VC++ builds > > Modified: > trunk/reactos/base/shell/explorer/utility/utility.h > > Modified: trunk/reactos/base/shell/explorer/utility/utility.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/explorer/utilit… > ============================================================================== > --- trunk/reactos/base/shell/explorer/utility/utility.h [iso-8859-1] (original) > +++ trunk/reactos/base/shell/explorer/utility/utility.h [iso-8859-1] Fri Jan 8 16:10:50 2010 > @@ -194,10 +194,20 @@ > #define strcpy_s(d, l, s) strcpy(d, s) > #define wcscpy_s(d, l, s) wcscpy(d, s) > #define wcsncpy_s(d, l, s, n) wcsncpy(d, s, n) > + > +#if defined(_tcscpy) && !defined(_tcscpy_s) > +#define _tcscpy_s(d, l, s) _tcscpy(d, s) > +#endif > + > +#if defined(_tsplitpath) && !defined(_tsplitpath_s) > +#define _tsplitpath_s(f, d,dl, p,pl, n,nl, e,el) _tsplitpath(f, d, p, n, e) > +#else > +#define _wsplitpath_s(f, d,dl, p,pl, n,nl, e,el) _wsplitpath(f, d, p, n, e) > +#define _splitpath_s(f, d,dl, p,pl, n,nl, e,el) _splitpath(f, d, p, n, e) > +#endif > + > #define _stprintf_s1(b, l, f, p1) _stprintf(b, f, p1) > #define _stprintf_s2(b, l, f, p1,p2) _stprintf(b, f, p1,p2) > -#define _wsplitpath_s(f, d,dl, p,pl, n,nl, e,el) _wsplitpath(f, d, p, n, e) > -#define _splitpath_s(f, d,dl, p,pl, n,nl, e,el) _splitpath(f, d, p, n, e) > > #endif // __STDC_WANT_SECURE_LIB__ > > > _________________________________________________________________ Un mondo di personalizzazioni per Messenger, PC e cellulare http://www.pimpit.it/

1 0

Re: [ros-dev] [ros-diffs] [martinf] 44998: update XMLStorage to 2010 version
by Ged Murphy 08 Jan '10

08 Jan '10

martinf(a)svn.reactos.org wrote: > -#if defined(__STDC_WANT_SECURE_LIB__) && defined(_MS_VER) // secure CRT functions using VS 2005 > +#ifdef __STDC_WANT_SECURE_LIB__ > if (_tfopen_s(&_pfile, path, mode) != 0) Hi Martin, This change will break the build, reactos now has partial but not full support for secure CRT functions. __STDC_WANT_SECURE_LIB__ is now defined in our build headers, but some areas are missing, _wfopen_s being one of these. I added the '&& defined(_MS_VER)' check to get around this for our build env until we support it. Regards, Ged.

1 0

Re: [ros-dev] [ros-priv] [ros-diffs] [ros-arm-bringup] 44841: NMI Support Patch 1: [HAL]: T #2
by Daniel Reimer 08 Jan '10

08 Jan '10

And now we all get back to a polite discussion about this topic and stop comparing the lengths of our wieners, ok? I hate the way all this goes to... last time we came to that point in the past, we lost some long term devs and put the whole project into a big crisis. So PLEASE, I just expect a mature talk and no kindergarten from you all. (OK, its a bit funny that I say something like that :-P ) Ros Arm Devs: I understand that you don't wanna tell us who exactly you are are, whatever your reasons are and I accept that, but you have to understand that some here fear harm for the project if ppl noone ever saw write risky components with the highest possibility to copyright problems. Almost every kernel dev in here was suspected to write tainted code at least once in their whole time here. That's the result of some big crisis we had in the past, we became a bit afraid of great code outta nowhere which just works. So don't take it personally, plz. *fearabigdramacoming* Regarding the Devs in the header and the license. Why not just readd the ppl if some of their code still exists in the file? Noone would have any harm if there's one more guy in this list. Lets discuss the relicense after the guys are in the headers again. But, and this goes out to all ppl, in a kind and mature way. You all, forget your "He stepped on my tail!!" behavior just for a moment and think about the project we all code for and we try to get mature. We can talk about anything, but not in this way. Thank you very much. Daniel Reimer Not soo 1337 ReactOS Dev

1 0

Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 44841: NMI Support Patch 1: [HAL]: The I/O Permissions Map on a typical Privileged Mode x86 OS is all 0xFF's, so it's quite wasteful to copy-in/out the entire map each single BIOS Call. As an optimization, only save and restore non-0xFF entries. [NTOS]: Define and use constants for different IOPM values, instead of using hardcoded values.
by Alex Ionescu 08 Jan '10

08 Jan '10

"You may relicense my code as BSD" != "You make strip away copyright/ownership of my code". Revert this. On 2009-12-31, at 6:51 PM, ros-arm-bringup(a)svn.reactos.org wrote: > > - * PROGRAMMERS: Alex Ionescu (alex.ionescu(a)reactos.org) > + * PROGRAMMERS: ReactOS Portable Systems Group Best regards, Alex Ionescu

9 11

Re: [ros-dev] [ros-diffs] [dgorbachev] 44974: [freeldr] - Do not use GetSystemMemorySize(), which truncates size to 32 bit. - Other minor changes.
by Aleksey Bragin 06 Jan '10

06 Jan '10

On Jan 6, 2010, at 2:44 PM, dgorbachev(a)svn.reactos.org wrote: > - // Always contigiously map low 1Mb of memory > + // Always contiguously map low 1Mb of memory Thanks for fixing my typos ;)

1 0

Unable to compile; infcore error
by Evans Jahja 04 Jan '10

04 Jan '10

Hi, I'm trying to compile React OS, however I encountered this error when I'm trying to compile: [HOST-CC] lib/inflib/infcore.c lib/inflib/infcore.c: In function `InfpAddSection': lib/inflib/infcore.c:184: warning: implicit declaration of function `__builtin_offsetof' lib/inflib/infcore.c:184: error: parse error before "INFCACHESECTION" lib/inflib/infcore.c:184: error: parse error before ']' token lib/inflib/infcore.c: In function `InfpAddFieldToLine': lib/inflib/infcore.c:289: error: parse error before "INFCACHEFIELD" lib/inflib/infcore.c:289: error: parse error before ']' token make: *** No rule to make target `makefile.auto', needed by `all'. Stop. Please help me, thanks. Evans Get your new Email address! Grab the Email name you've always wanted before someone else does! http://mail.promotions.yahoo.com/newdomains/aa/

4 4

Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 44841: NMI Support Patch 1: [HAL]: The I/O Permissions Map on a typical Privileged Mode x86 OS is all 0xFF's, so it's quite wasteful to copy-in/out the entire map each single BIOS Call. As an optimization,
by Matthieu Suiche 04 Jan '10

04 Jan '10

I <3 this commit. -- Matthieu Suiche On Fri, Jan 1, 2010 at 6:31 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote: > "You may relicense my code as BSD" != "You make strip away > copyright/ownership of my code". > Revert this. > On 2009-12-31, at 6:51 PM, ros-arm-bringup(a)svn.reactos.org wrote: > > - * PROGRAMMERS: Alex Ionescu (alex.ionescu(a)reactos.org) > + * PROGRAMMERS: ReactOS Portable Systems Group > > Best regards, > Alex Ionescu > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

Re: [ros-dev] [ros-diffs] [jimtabor] 44902: [Win32k] - Patch by Dan Kegel: Fix minor read buffer overrun in CombineRgn. http://bugs.winehq.org/show_bug.cgi?id=20851 - When locking and unlocking regions, use probe to check attribute space first before
by James Tabor 03 Jan '10

03 Jan '10

To slow things down. ATM there is a fault created when the mouse moves with updates, creates and destroying region handles. The kernel fault occurs inside SEH which should not happen right? What we need is a semaphore that is used for the whole handle manager. This is my point over the years about the stability inside win32k. It running full bore, spinning out of control. Surprised it still works after turning everything on in my tree. On Sun, Jan 3, 2010 at 3:26 AM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote: > > Why the KeEnterCriticalRegion? > > jimtabor(a)svn.reactos.org wrote: >> - if (pAttr) FreeObjectAttr(pAttr); >> + if (pAttr) >> + { >> + KeEnterCriticalRegion(); >> + FreeObjectAttr(pAttr); >> + KeLeaveCriticalRegion(); >> + } >> break; >> >

1 0

Re: [ros-dev] [ros-diffs] [fireball] 44917: [NDK] - Add forgotten HalSetTimeIncrement prototype to NDK.
by Aleksey Bragin 03 Jan '10

03 Jan '10

Sorry, it's not "forgotten" but rather "missing". WBR, Aleksey Bragin. On Jan 3, 2010, at 9:17 PM, fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Sun Jan 3 19:17:21 2010 > New Revision: 44917 > > URL: http://svn.reactos.org/svn/reactos?rev=44917&view=rev > Log: > [NDK] > - Add forgotten HalSetTimeIncrement prototype to NDK. > > Modified: > trunk/reactos/include/ndk/halfuncs.h > > Modified: trunk/reactos/include/ndk/halfuncs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ndk/ > halfuncs.h?rev=44917&r1=44916&r2=44917&view=diff > ====================================================================== > ======== > --- trunk/reactos/include/ndk/halfuncs.h [iso-8859-1] (original) > +++ trunk/reactos/include/ndk/halfuncs.h [iso-8859-1] Sun Jan 3 > 19:17:21 2010 > @@ -274,5 +274,12 @@ > IN PTIME_FIELDS RtcTime > ); > > -#endif > -#endif > +NTHALAPI > +ULONG > +NTAPI > +HalSetTimeIncrement( > + IN ULONG Increment > +); > + > +#endif > +#endif > >

1 0

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