Ros-dev

ros-dev@reactos.org

5788 discussions

by Javier Agustìn Fernàndez Arroyo

hwy guys, did you hear about this? Maybe toese can be included with ReactOS, they are open source! https://github.com/kxproject http://kxproject.com/index.php?language=en

6 years, 8 months

Postponing December Status Meeting

by Colin Finck

Hi all! If we follow our usual schedule, the December Status Meeting would be today. With such a late announcement and many people still on holidays, I suggest postponing it to next Thursday, January 4, 2018. Time will be 19:00 UTC as always. I already asked on #reactos-dev and got some approvals, so consider this the official meeting invitation :) This also gives you one week from now for agenda proposals. Additionally, we have got some new contributors in the recent months. If you think you should join the meeting or know somebody who should join, please let me know in advance. See you all next year! Colin

6 years, 8 months

Re: [ros-dev] [ros-diffs] [reactos] 01/01: [SETUP] Remove FSDs which have broken dismount implementation. This avoids issues when these partitions are formatted to FAT for setup.

by 7th Element

Hi Pierre, Isn’t this change going to remove ability to boot from those FSs? BR, Peter > On 18 Dec 2017, at 0:16, Pierre Schweitzer <pierre(a)reactos.org> wrote: > > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=806cd16328799771b8939… > > commit 806cd16328799771b89397f5c51a3d46884bce0a > Author: Pierre Schweitzer <pierre(a)reactos.org> > AuthorDate: Sun Dec 17 23:13:56 2017 +0100 > > [SETUP] Remove FSDs which have broken dismount implementation. > This avoids issues when these partitions are formatted to FAT for setup. > > For now, this commit doesn't change anything, but once IopParseDevice hack > gets removed, this will make a difference! > > CORE-6305 > --- > boot/bootdata/txtsetup.sif | 2 -- > drivers/filesystems/btrfs/CMakeLists.txt | 2 +- > drivers/filesystems/ntfs/CMakeLists.txt | 2 +- > 3 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/boot/bootdata/txtsetup.sif b/boot/bootdata/txtsetup.sif > index 3ea62974b5..822c19c8c8 100644 > --- a/boot/bootdata/txtsetup.sif > +++ b/boot/bootdata/txtsetup.sif > @@ -52,7 +52,6 @@ usbstor.sys=,,,,,,x,,,,,,4 > kbdhid.sys=,,,,,,,,,,,,4 > kbdclass.sys=,,,,,,x,,,,,,4 > l_intl.nls=,,,,,,,,,,,,2 > -ntfs.sys=,,,,,,,,,,,,4 > pci.sys=,,,,,,,,,,,,4 > scsiport.sys=,,,,,,x,,,,,,4 > storport.sys=,,,,,,x,,,,,,4 > @@ -69,7 +68,6 @@ ntdll.dll=,,,,,,,,,,,,2 > wmilib.sys=,,,,,,,,,,,,4 > ksecdd.sys=,,,,,,,,,,,,4 > mountmgr.sys=,,,,,,x,,,,,,4 > -btrfs.sys=,,,,,,x,,,,,,4 > reiserfs.sys=,,,,,,x,,,,,,4 > ffs.sys=,,,,,,x,,,,,,4 > udfs.sys=,,,,,,x,,,,,,4 > diff --git a/drivers/filesystems/btrfs/CMakeLists.txt b/drivers/filesystems/btrfs/CMakeLists.txt > index 65e61d255a..123c9f0522 100644 > --- a/drivers/filesystems/btrfs/CMakeLists.txt > +++ b/drivers/filesystems/btrfs/CMakeLists.txt > @@ -41,4 +41,4 @@ add_definitions(-D__KERNEL__) > set_module_type(btrfs kernelmodedriver) > target_link_libraries(btrfs rtlver ntoskrnl_vista zlib_solo wdmguid ${PSEH_LIB}) > add_importlibs(btrfs ntoskrnl hal) > -add_cd_file(TARGET btrfs DESTINATION reactos/system32/drivers NO_CAB FOR all) > +add_cd_file(TARGET btrfs DESTINATION reactos/system32/drivers FOR all) > diff --git a/drivers/filesystems/ntfs/CMakeLists.txt b/drivers/filesystems/ntfs/CMakeLists.txt > index 0b1af78947..5a193b449d 100644 > --- a/drivers/filesystems/ntfs/CMakeLists.txt > +++ b/drivers/filesystems/ntfs/CMakeLists.txt > @@ -25,4 +25,4 @@ set_module_type(ntfs kernelmodedriver) > target_link_libraries(ntfs ${PSEH_LIB}) > add_importlibs(ntfs ntoskrnl hal) > add_pch(ntfs ntfs.h SOURCE) > -add_cd_file(TARGET ntfs DESTINATION reactos/system32/drivers NO_CAB FOR all) > +add_cd_file(TARGET ntfs DESTINATION reactos/system32/drivers FOR all) > >

6 years, 9 months

Small suggestion for the abandoned SVN mirror on GitHub

by Dmitry D. Chernov

Good day everyone. I'm talking about this repo: https://github.com/reactos/reactos-deprecated-gitsvn-dont-use To prevent pull-requesting to it I suggest to use new GitHub feature "archive this repository". To enable it, just open the "Settings" page and go to the bottom. "Archived" repos are marked as read-only and could not be pull-requested. It's also would be nice to disable unused "Projects" tab in this repo for the great justice of perfectionism. ___ Dmitry D. Chernov

6 years, 9 months

ReactOS 0.4.7 to be released tomorrow, 6th December 2017 - Press Kit is online!

by Colin Finck

Hi all! With all release preparations done, we can finally give a release date for ReactOS 0.4.7: Tomorrow, Wednesday, 6th December 2017. During that day (European time), the release will be published. A Press Kit for ReactOS 0.4.7 is already available: https://sourceforge.net/projects/reactos/files/ReactOS/0.4.7/ReactOS-0.4.7-… Feel free to send it to interested parties to let them know about the upcoming release in advance. Best regards, Colin Finck

6 years, 9 months

Re: [ros-dev] [ros-diffs] [reactos] 01/01: [NTOS:MM] Fix NtFreeVirtualMemory() FreeType parameter checks. CORE-13126

by Alex Ionescu

I'm unsure how reducing the two explicit checks into a single one is a better decision. This is much less scalable and much less clear of what the caller did wrong. I'd like to see the old checks (correctly) restored. Best regards, Alex Ionescu On Fri, Dec 15, 2017 at 2:58 AM, Serge Gautherie < reactos-git_serge_171003(a)gautherie.fr> wrote: > https://git.reactos.org/?p=reactos.git;a=commitdiff;h= > 614ace03fa4ec1957f32727ab0975a98c858894d > > commit 614ace03fa4ec1957f32727ab0975a98c858894d > Author: Serge Gautherie <reactos-git_serge_171003(a)gautherie.fr> > AuthorDate: Sat Dec 9 12:16:44 2017 +0100 > > [NTOS:MM] Fix NtFreeVirtualMemory() FreeType parameter checks. > CORE-13126 > --- > ntoskrnl/mm/ARM3/virtual.c | 20 +++++--------------- > 1 file changed, 5 insertions(+), 15 deletions(-) > > diff --git a/ntoskrnl/mm/ARM3/virtual.c b/ntoskrnl/mm/ARM3/virtual.c > index 0e5fe77a23..fc4ea2e6d2 100644 > --- a/ntoskrnl/mm/ARM3/virtual.c > +++ b/ntoskrnl/mm/ARM3/virtual.c > @@ -5108,21 +5108,11 @@ NtFreeVirtualMemory(IN HANDLE ProcessHandle, > PAGED_CODE(); > > // > - // Only two flags are supported > + // Only two flags are supported, exclusively. > // > - if (!(FreeType & (MEM_RELEASE | MEM_DECOMMIT))) > + if (FreeType != MEM_RELEASE && FreeType != MEM_DECOMMIT) > { > - DPRINT1("Invalid FreeType\n"); > - return STATUS_INVALID_PARAMETER_4; > - } > - > - // > - // Check if no flag was used, or if both flags were used > - // > - if (!((FreeType & (MEM_DECOMMIT | MEM_RELEASE))) || > - ((FreeType & (MEM_DECOMMIT | MEM_RELEASE)) == (MEM_DECOMMIT | > MEM_RELEASE))) > - { > - DPRINT1("Invalid FreeType combination\n"); > + DPRINT1("Invalid FreeType (0x%08lx)\n", FreeType); > return STATUS_INVALID_PARAMETER_4; > } > > @@ -5200,8 +5190,8 @@ NtFreeVirtualMemory(IN HANDLE ProcessHandle, > } > } > > - DPRINT("NtFreeVirtualMemory: Process 0x%p, Adress 0x%p, size 0x%x, > FreeType %x.\n", > - Process, PBaseAddress, PRegionSize, FreeType); > + DPRINT("NtFreeVirtualMemory: Process 0x%p, Address 0x%p, Size 0x%Ix, > FreeType 0x%08lx\n", > + Process, PBaseAddress, PRegionSize, FreeType); > > // > // Lock the address space > >

6 years, 9 months

[ros-diffs] [reactos] 01/01: [SDK] pnp.idl: Add a reminder comment about removed Vista/+ functions. CORE-12580

by James Tabor

Hi, Let's try not removing (ZAPPING) API due to future use okay? Just #if it out with the correct __NTZYX__ thing. So if I wish to have VISTA or Server 201X, I can select it while running the configuration script. Do it this way so someone could select Server 2003 (Default now) later on. Same or better TEAM! Think about what will be needed later on. ZAPPING OUT! James

6 years, 9 months

PineappleFund

by Alexander Shaposhnikov

Hi all! Recenly a new Reddit post came up on #reactos IRC: https://redd.it/7jj0oa. Interesting stuff. A person is giving away ~5000 BTC for charitable causes. We can apply via the website but it must be done by someone from ReactOS e.V. -- Cheers, Alexander Shaposhnikov

6 years, 9 months

Merging our x86 HALs

by Colin Finck

Hi all, I have been looking into our HALs recently on the promise that it is a huge mess that needs fixing. Well, as a start I could imagine merging our 6 possible x86 HALs (Legacy, ACPI, APIC, ACPI+APIC, SMP, SMP+ACPI) into a single one, even if Windows ships individual ones. I see many advantages of that: * Less duplications and reduced mess: Right now, the APIC HAL hangs at HalpCalibrateStallExecution during boot, a function that has been fixed and universally implemented in all non-APIC HALs. The APIC HAL also duplicates HalpInitializePICs as HalpInitializeLegacyPIC. If you look at the SMP code, it didn't even receive the last build system changes and has conflicting implementations for APIC functions. A single x86 HAL would ensure that all possible configurations are maintained. * Future-proof: How is one going to implement newer features like x2APIC with a structure like that? Would it get another HAL, be integrated into the APIC HAL, or what? We wouldn't have such problems with a single x86 HAL. * Less setup work and testing: Currently, 1st stage setup detects the computer type and installs the appropriate HAL. As such, every additional HAL needs to be added to 1st stage setup code. The user is also able to select a custom HAL during setup, even if it wouldn't work on the machine. We should give neither the user nor the setup the ability to decide. The HAL itself knows best at boot-up what features to enable and what not. * Convenience: The same ReactOS installation could be used on several different x86 computers. So is this the way to go or do I miss something important? Best regards, Colin

6 years, 9 months

Re: [ros-dev] Merging our x86 HALs

by Alex Ionescu

I would move to the Win8+ HAL Model -- a single HAL for APIC, ACPI with runtime support for UEFI (if present) and MP (if present). If people still want to run on a PIC VM (why???) or old computer, then we can also maintain the HAL PIC x86 for UP. Hence there would only be 2 HALs. Best regards, Alex Ionescu On Mon, Dec 11, 2017 at 1:07 AM, Colin Finck <colin(a)reactos.org> wrote: > Am 11.12.2017 um 01:18 schrieb Hermès BÉLUSCA-MAÏTO:> If you basically > put all the HALs into one, then you obtain bloated stuff (which remains > in memory for the whole life of the OS). Example: standard HAL is 1MB > vs. ACPI HAL which is few kBHave you actually checked what makes up this > difference? > Hint: hal/halx86/legacy/bus/pci_vendors.ids > > > > Note that if Windows nowadays has only one hal, it's because they now > support basically only one "architecture"/platform, namely, ACPI > multiprocessor (to put it simple). It has its pros, but also a lot of cons. > > That doesn't mean we need to do the same. We can have one HAL for all > (Pentium and newer) x86 platforms. The overhead of additional checks at > boot-up is negligible. That should be a solution for 99% of the people > out there. The rest may still go and trim down our HAL to their needs. > > But let's not pretend we can maintain multiple x86 HALs for all x86 > computers out there. Do you really want to test X HALs with Y different > systems? Ensure that a legacy HAL runs on a modern ACPI system? What > would be the point? > > > > Besides this, I've a question about your observation that in the APIC > hal (not ACPI) there's different implementation of > HalpCalibrateStallExecution and HalpInitializePICs / > HalpInitializeLegacyPIC . Isn't it precisely because these stuff are > completely different from the standard PICs used in platforms for which the > standard HAL (and possibly the ACPI HAL) are used? > > Absolutely not! You need to reprogram the standard PICs also on an APIC > system, and this is precisely what both functions do. Put them into a > diff tool to see for yourself. > > The same goes for timers. Even with the introduction of ACPI Timers, > Local APIC Timers, and Time-Stamp Counters, you still need a traditional > one (like RTC or PIT) for calibration at system startup. Simply because > the newer ones don't run at a known fixed frequency. > The Legacy HAL successfully employs an algorithm based on the RTC while > the APIC HAL unsuccessfully tries to use the PIT. > > > > Actually we should, because the detection might not work (of course in > our simple case "ACPI UP/MP" vs. "Standard", it's simple, but think about > other platforms where there can be subtle differences) > > Tell me about a single one we cannot detect and which is worth to > support. I don't recall that we ever recommended our testers to choose a > different HAL at setup. > > > > And normally it's not the setup that decides about the HAL, but the > bootloader. > > That defies your previous point about the setup initializing the > registry depending on the HAL. > If we can let the user select a Legacy HAL in the boot loader after > installing with an ACPI HAL, it is also technically possible to have one > HAL that encompasses both. > > > - Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

6 years, 9 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev