Ros-dev

ros-dev@reactos.org

5790 discussions

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

freeldr
by Timo Kreuzer 15 Jun '11

15 Jun '11

Hi, While taking a short break from my GSOC work, I like to do some work on freeldr. Final goal is to make it work with MSVC, but first I'd like to do a little cleanup, since its a bit messy. First I'd like to know how the state of the old bootcode is and if we still need it and whats left to do to get rid of it. Then I'd suggest to remove the code that draws purple unicorns like it was done for ARM (afaik, we don't use it anyway) I'd also like to fix formatting (tabs -> spaces) Any remarks, objections, wishes, doubts? Regards, Timo

5 10

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