Ros-dev

ros-dev@reactos.org

5791 discussions

dmesg of #6018 Re: [ros-diffs] [rharabien] 52409: [BOOTVID] - Revert part of r52239: Fix support for \r and do not handle backspace - Simplify it a bit [NTOSKRNL] - Add backspace support to KdpScreenPrint - Do not draw boot text...
by Minas Abrahamyan 21 Jun '11

21 Jun '11

Dear Rafal, Since you are touching the code of /ntoskrnl/kd/kdio.c, wouldn't you be kind enough to review and possibly apply my "dmesg command patch"? Issue in bugzilla: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 patch itself: http://www.reactos.org/bugzilla/attachment.cgi?id=6055 It contains much of code of KdbpPrint() function, in function KdbpPager(), etc. The is explanations about it in issue description. *** To all: This patch is suspended in bugzilla from March, although I noticed some weak attempts to do something with it, say reassign to somebody, but yet without any advance. Hope something will be changed with this. Thanks for attention -Minas Abrahamyan On Wed, Jun 22, 2011 at 12:47 AM, <rharabien(a)svn.reactos.org> wrote: > Author: rharabien > Date: Tue Jun 21 19:47:13 2011 > New Revision: 52409 > > URL: http://svn.reactos.org/svn/reactos?rev=52409&view=rev > Log: > [BOOTVID] > - Revert part of r52239: Fix support for \r and do not handle backspace > - Simplify it a bit > > [NTOSKRNL] > - Add backspace support to KdpScreenPrint > - Do not draw boot text bitmap if InbvDisplayString is called with "" or "." (matches NT behavior) > > Modified: > trunk/reactos/drivers/base/bootvid/i386/vga.c > trunk/reactos/ntoskrnl/inbv/inbv.c > trunk/reactos/ntoskrnl/kd/kdio.c > > Modified: trunk/reactos/drivers/base/bootvid/i386/vga.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/bootvid/i386/… > ============================================================================== > --- trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] Tue Jun 21 19:47:13 2011 > @@ -66,6 +66,7 @@ > ULONG TextColor = 0xF; > ULONG curr_x = 0; > ULONG curr_y = 0; > +BOOLEAN CarriageReturn = FALSE; > ULONG_PTR VgaRegisterBase = 0; > ULONG_PTR VgaBase = 0; > > @@ -279,14 +280,8 @@ > NTAPI > VgaScroll(ULONG Scroll) > { > - ULONG Top; > - ULONG SourceOffset, DestOffset; > - ULONG Offset; > - ULONG i, j; > - > - /* Set memory positions of the scroll */ > - SourceOffset = VgaBase + (ScrollRegion[1] * 80) + (ScrollRegion[0] >> 3); > - DestOffset = SourceOffset + (Scroll * 80); > + ULONG Top, RowSize, i; > + PUCHAR OldPosition, NewPosition; > > /* Clear the 4 planes */ > __outpw(0x3C4, 0xF02); > @@ -296,56 +291,27 @@ > > /* Set Mode 1 */ > ReadWriteMode(1); > - > - /* Save top and check if it's above the bottom */ > - Top = ScrollRegion[1]; > - if (Top > ScrollRegion[3]) return; > + > + RowSize = (ScrollRegion[2] - ScrollRegion[0] + 1) / 8; > > /* Start loop */ > - do > - { > - /* Set number of bytes to loop and start offset */ > - Offset = ScrollRegion[0] >> 3; > - j = SourceOffset; > - > - /* Check if this is part of the scroll region */ > - if (Offset <= (ScrollRegion[2] >> 3)) > - { > - /* Update position */ > - i = DestOffset - SourceOffset; > - > - /* Loop the X axis */ > - do > - { > - /* Write value in the new position so that we can do the scroll */ > - WRITE_REGISTER_UCHAR(UlongToPtr(j), > - READ_REGISTER_UCHAR(UlongToPtr(j + i))); > - > - /* Move to the next memory location to write to */ > - j++; > - > - /* Move to the next byte in the region */ > - Offset++; > - > - /* Make sure we don't go past the scroll region */ > - } while (Offset <= (ScrollRegion[2] >> 3)); > - } > - > - /* Move to the next line */ > - SourceOffset += 80; > - DestOffset += 80; > - > - /* Increase top */ > - Top++; > - > - /* Make sure we don't go past the scroll region */ > - } while (Top <= ScrollRegion[3]); > + for(Top = ScrollRegion[1]; Top <= ScrollRegion[3]; ++Top) > + { > + /* Calculate the position in memory for the row */ > + OldPosition = (PUCHAR)VgaBase + (Top + Scroll) * 80 + ScrollRegion[0] / 8; > + NewPosition = (PUCHAR)VgaBase + Top * 80 + ScrollRegion[0] / 8; > + > + /* Scroll the row */ > + for(i = 0; i < RowSize; ++i) > + WRITE_REGISTER_UCHAR(NewPosition + i, READ_REGISTER_UCHAR(OldPosition + i)); > + } > } > > VOID > NTAPI > PreserveRow(IN ULONG CurrentTop, > - IN ULONG TopDelta) > + IN ULONG TopDelta, > + IN BOOLEAN Direction) > { > PUCHAR Position1, Position2; > ULONG Count; > @@ -359,9 +325,19 @@ > /* Set Mode 1 */ > ReadWriteMode(1); > > - /* Calculate the position in memory for the row */ > - Position1 = (PUCHAR)VgaBase + 0x9600; > - Position2 = (PUCHAR)VgaBase + CurrentTop * 80; > + /* Check which way we're preserving */ > + if (Direction) > + { > + /* Calculate the position in memory for the row */ > + Position1 = (PUCHAR)VgaBase + CurrentTop * 80; > + Position2 = (PUCHAR)VgaBase + 0x9600; > + } > + else > + { > + /* Calculate the position in memory for the row */ > + Position1 = (PUCHAR)VgaBase + 0x9600; > + Position2 = (PUCHAR)VgaBase + CurrentTop * 80; > + } > > /* Set the count and make sure it's above 0 */ > Count = TopDelta * 80; > @@ -378,33 +354,6 @@ > Position1++; > } while (--Count); > } > -} > - > -VOID > -NTAPI > -CleanCharacter(IN ULONG Left, > - IN ULONG Top, > - IN ULONG TopDelta) > -{ > - PUCHAR Position1, Position2; > - ULONG i; > - > - /* Clear the 4 planes */ > - __outpw(0x3C4, 0xF02); > - > - /* Set the bitmask to 0xFF for all 4 planes */ > - __outpw(0x3CE, 0xFF08); > - > - /* Set Mode 1 */ > - ReadWriteMode(1); > - > - /* Calculate the position in memory for the character */ > - Position1 = (PUCHAR)VgaBase + 0x9600 + Left / 8; > - Position2 = (PUCHAR)VgaBase + Top * 80 + Left / 8; > - > - /* Copy data from preserved row */ > - for(i = 0; i < TopDelta; ++i) > - WRITE_REGISTER_UCHAR(Position2 + i * 80, READ_REGISTER_UCHAR(Position1)); > } > > VOID > @@ -772,35 +721,34 @@ > } > else > { > - /* Preserve the current row */ > - PreserveRow(curr_y, TopDelta); > + /* Preserve row */ > + PreserveRow(curr_y, TopDelta, FALSE); > } > > /* Update current X */ > curr_x = ScrollRegion[0]; > + > + /* Do not clear line if "\r\n" is given */ > + CarriageReturn = FALSE; > } > else if (*String == '\r') > { > /* Update current X */ > curr_x = ScrollRegion[0]; > - } > - else if (*String == '\b') > - { > - /* Update current X */ > - if (curr_x > ScrollRegion[0]) > - curr_x -= 8; > - else > - { > - /* We are at line begin - move to previous row */ > - curr_x = ScrollRegion[0]; > - curr_y -= TopDelta; > + > + /* Check if we're being followed by a new line */ > + CarriageReturn = TRUE; > + } > + else > + { > + /* check if we had a '\r' last time */ > + if (CarriageReturn) > + { > + /* We did, clear the current row */ > + PreserveRow(curr_y, TopDelta, TRUE); > + CarriageReturn = FALSE; > } > - > - /* Clean current character */ > - CleanCharacter(curr_x, curr_y, TopDelta); > - } > - else > - { > + > /* Display this character */ > DisplayCharacter(*String, curr_x, curr_y, TextColor, 16); > curr_x += 8; > @@ -819,7 +767,7 @@ > else > { > /* Preserve the current row */ > - PreserveRow(curr_y, TopDelta); > + PreserveRow(curr_y, TopDelta, FALSE); > } > > /* Update X */ > > Modified: trunk/reactos/ntoskrnl/inbv/inbv.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/inbv/inbv.c?rev=5… > ============================================================================== > --- trunk/reactos/ntoskrnl/inbv/inbv.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/inbv/inbv.c [iso-8859-1] Tue Jun 21 19:47:13 2011 > @@ -717,11 +717,15 @@ > INIT_FUNCTION > DisplayFilter(PCHAR *String) > { > - /* Remove the filter */ > - InbvInstallDisplayStringFilter(NULL); > - > - /* Draw text screen */ > - DisplayBootBitmap(TRUE); > + /* Ignore empty and "." strings */ > + if(*String && strcmp(String, ".") != 0) > + { > + /* Remove the filter */ > + InbvInstallDisplayStringFilter(NULL); > + > + /* Draw text screen */ > + DisplayBootBitmap(TRUE); > + } > } > > VOID > > Modified: trunk/reactos/ntoskrnl/kd/kdio.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdio.c?rev=524… > ============================================================================== > --- trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] Tue Jun 21 19:47:13 2011 > @@ -28,6 +28,10 @@ > > /* Current Port in use. FIXME: Do we support more then one? */ > ULONG KdpPort; > + > +#define KdpScreenLineLenght 80 > +CHAR KdpScreenLineBuffer[KdpScreenLineLenght + 1] = ""; > +ULONG KdpScreenLineBufferPos = 0, KdpScreenLineLength = 0; > > /* DEBUG LOG FUNCTIONS *******************************************************/ > > @@ -316,8 +320,50 @@ > KdpScreenPrint(LPSTR Message, > ULONG Length) > { > - /* Call HAL */ > - HalDisplayString(Message); > + PCHAR pch = (PCHAR) Message; > + > + while (*pch) > + { > + if(*pch == '\b') > + { > + /* HalDisplayString does not support '\b'. Workaround it and use '\r' */ > + if(KdpScreenLineLength > 0) > + { > + /* Remove last character from buffer */ > + KdpScreenLineBuffer[--KdpScreenLineLength] = '\0'; > + KdpScreenLineBufferPos = KdpScreenLineLength; > + > + /* Clear row and print line again */ > + HalDisplayString("\r"); > + HalDisplayString(KdpScreenLineBuffer); > + } > + } > + else > + { > + KdpScreenLineBuffer[KdpScreenLineLength++] = *pch; > + KdpScreenLineBuffer[KdpScreenLineLength] = '\0'; > + } > + > + if(*pch == '\n' || KdpScreenLineLength == KdpScreenLineLenght) > + { > + /* Print buffered characters */ > + if(KdpScreenLineBufferPos != KdpScreenLineLength) > + HalDisplayString(KdpScreenLineBuffer + KdpScreenLineBufferPos); > + > + /* Clear line buffer */ > + KdpScreenLineBuffer[0] = '\0'; > + KdpScreenLineLength = KdpScreenLineBufferPos = 0; > + } > + > + ++pch; > + } > + > + /* Print buffered characters */ > + if(KdpScreenLineBufferPos != KdpScreenLineLength) > + { > + HalDisplayString(KdpScreenLineBuffer + KdpScreenLineBufferPos); > + KdpScreenLineBufferPos = KdpScreenLineLength; > + } > } > > VOID > > >

1 0

Re: [ros-dev] [ros-diffs] [sir_richard] 52098: [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms wou...
by Gabriel ilardi 21 Jun '11

21 Jun '11

Hi sir_richard and welcome back! Just to make sure you know, it seems this commit introduces a regression, ros hangs while loading ndis.sys, see testbot logs: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/1342/s… I've filed http://www.reactos.org/bugzilla/show_bug.cgi?id=6292 Could you please take a look? Thanks. > Date: Sun, 5 Jun 2011 20:48:34 +0000 > To: ros-diffs(a)reactos.org > From: sir_richard(a)svn.reactos.org > Subject: [ros-diffs] [sir_richard] 52098: [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms wou... > > Author: sir_richard > Date: Sun Jun 5 20:48:34 2011 > New Revision: 52098 > > URL: http://svn.reactos.org/svn/reactos?rev=52098&view=rev > Log: > [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms would build FreeLDR "page entries" for every page from 0 to 0x7FFF0000 and mark it as unusable, then build the actual valid entries from 0x80000000 -> end of RAM, thus resulting in large memory consumption (and in the bloat of the PFN database later once NTOS loads) and boot time. Therefore, the algorithm is changed to start the PFN database at the lowest valid RAM page described by the Firemware descriptors, and entries therefore will be offset. This means a 128MB embedded system no longer appears to have 2048+128MB of RAM worth of PFN entries. > NOTE: Windows does not do this, opting instead to force manufacturers/use pull-up resistors/reconfigure the ARM Bus to map RAM at 0x00000000. For wider portability, I believe it makes more sense to simply do this "trick" in the boot loader. > > Modified: > trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c > trunk/reactos/boot/freeldr/freeldr/mm/meminit.c >

1 1

freeldr
by Timo Kreuzer 20 Jun '11

20 Jun '11

Hi, I'd like to change the Vtbl based architecture of freeldr into a normal function call system. Currently we have stuff like #define MachHwDetect() MachVtbl.HwDetect() MachVtbl.HwDetect = PcHwDetect; This is IHO simply useless, since these functions don't change. I suggest simply renaming PcHwDetect to MachHwDetect and do that will all of those and get rid of the MachVtbl. Any objections? Regards, Timo

5 10

Re: [ros-dev] [ros-diffs] [gedmurphy] 52364: [BROWSEUI] - Set the prototypes to be long instead of LONG. This only worked in rbuild previously because WIDL incorrectly generates a LONG for long types. - define SHANDLE_PTR a...
by Colin Finck 19 Jun '11

19 Jun '11

gedmurphy(a)svn.reactos.org wrote: > +// WIDL temp hack : [...] Even though we all like to see a full MSVC build in the future, does this really justify such an even bigger hack on top of the existing ones? Would a proper fix really require that much more time? If we don't want to end up in a new mess, this pretty much forces someone to fix it in the coming days or the hack/commit will be forgotten again. I'm certain about this, because nobody on #reactos-dev really knew the reason behind the older __ROS_LONG64__ hack either. Alternatively, you could open a detailed bug report about this issue and assign some CMake people to it. But in any case, such hacks should be tracked in our Bugzilla, in particular when more information about a solution is known already. - Colin

3 4

Re: [ros-dev] [ros-diffs] [jgardou] 52365: [GDI32] - remove useless check.
by Timo Kreuzer 19 Jun '11

19 Jun '11

Am 19.06.2011 15:11, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Sun Jun 19 13:11:39 2011 > New Revision: 52365 > > URL: http://svn.reactos.org/svn/reactos?rev=52365&view=rev > Log: > [GDI32] > - remove useless check. > > > + _SEH2_TRY > + { > + RtlCopyMemory( pvSafeBits, Bits, cjBmpScanSize); > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Hit = TRUE; > + } > + _SEH2_END > + > + if (Hit) > + { > + // We don't die, we continue on with a allocated safe pointer to kernel > + // space..... > + DPRINT1("SetDIBitsToDevice fail to read BitMapInfo: %x or Bits: %x& Size: %d\n",pConvertedInfo,Bits,cjBmpScanSize); > + } > + DPRINT("SetDIBitsToDevice Allocate Bits %d!!!\n", cjBmpScanSize); > + } > > if (!GdiGetHandleUserData(hdc, GDI_OBJECT_TYPE_DC, (PVOID)&pDc_Attr)) > { This code looks retarded as well. Especially the comment about the "safe" pointer...

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 52339: [NTOSKRNL] - don't rely on a boolean being 1 or 0, it's a bad idea (tm)
by Alex Ionescu 19 Jun '11

19 Jun '11

??? This is retarded. You're doing 0 ? 0 : 1 Best regards, Alex Ionescu On Sat, Jun 18, 2011 at 3:45 PM, <jgardou(a)svn.reactos.org> wrote: > Author: jgardou > Date: Sat Jun 18 14:45:08 2011 > New Revision: 52339 > > URL: http://svn.reactos.org/svn/reactos?rev=52339&view=rev > Log: > [NTOSKRNL] > - don't rely on a boolean being 1 or 0, it's a bad idea (tm) > > Modified: > trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > > Modified: trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/traphdlr.… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] Sat Jun 18 14:45:08 2011 > @@ -1510,7 +1510,7 @@ > > /* Set thread fields */ > Thread->TrapFrame = TrapFrame; > - Thread->PreviousMode = KiUserTrap(TrapFrame); > + Thread->PreviousMode = KiUserTrap(TrapFrame) ? UserMode : KernelMode; > > /* Enable interrupts */ > _enable(); > > >

2 4

Suggestion for signed driver
by Javier Agustìn Fernàndez Arroyo 17 Jun '11

17 Jun '11

Hi folks, have you taken a look into this driver? what about signing it? http://code.google.com/p/cmediadrivers/

4 3

Re: [ros-dev] [ros-diffs] [cgutman] 52288: [FILESYSTEMS] - Handle IRP_MN_KERNEL_CALL for k
by Pierre Schweitzer 17 Jun '11

17 Jun '11

FAT & CDFS FSDs are not supposed to handle IRP_MN_KERNEL_CALL.

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 52277: [NTOSKRNL] - Use the IopParseDevice hack for floppies too (needed for format and chkdsk to work)
by Alex Ionescu 16 Jun '11

16 Jun '11

You think they might try requesting valid attributes instead? :) Best regards, Alex Ionescu On Thu, Jun 16, 2011 at 9:31 AM, <cgutman(a)svn.reactos.org> wrote: > Author: cgutman > Date: Thu Jun 16 13:31:12 2011 > New Revision: 52277 > > URL: http://svn.reactos.org/svn/reactos?rev=52277&view=rev > Log: > [NTOSKRNL] > - Use the IopParseDevice hack for floppies too (needed for format and chkdsk to work) > > Modified: > trunk/reactos/ntoskrnl/io/iomgr/file.c > > Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?r… > ============================================================================== > --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Thu Jun 16 13:31:12 2011 > @@ -408,7 +408,8 @@ > if (!(DirectOpen) && > !(RemainingName->Length) && > !(OpenPacket->RelatedFileObject) && > - ((wcsstr(CompleteName->Buffer, L"Harddisk"))) && > + ((wcsstr(CompleteName->Buffer, L"Harddisk")) || > + (wcsstr(CompleteName->Buffer, L"Floppy"))) && > !(UseDummyFile)) > { > DPRINT1("Using IopParseDevice() hack. Requested invalid attributes: %lx\n", > > >

1 0

Removing usbdriver.sys from build
by Colin Finck 15 Jun '11

15 Jun '11

Hello all, Edijus from #reactos has just tried ReactOS on his system, but the boot process got stuck at "usbdriver.sys". When reading his notice, I was wondering why we still include this ancient driver in every ReactOS build. As far as I know ... * it has never worked for us * it is incomplete and not well-tested * it has obvious code bugs (e.g. just look in ehci.c:3465 how it enumerates more PCI devices and functions than possible, consequently enumerating the first function twice due to bitshifts) * better USB work by Johannes and Michael is progressing well Although it might be useful as a testcase for the legacy HAL functions (like HalAssignSlotResources), it should still be removed from the build process for now. If there are no objections, I'll do this change on the weekend. - Colin

2 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev