Ros-dev

ros-dev@reactos.org

5789 discussions

Start a nNew thread

[Fwd: Re: [ros-dev] install problem]

by Alex Ionescu

20 years, 1 month

[Fwd: Re: [ros-dev] Re: [ros-svn] [hbirr] 15381: - Reference the file object in IopSecurityFile.]

by Alex Ionescu

20 years, 1 month

Re: [ros-svn] [hbirr] 15381: - Reference the file object in IopSecurityFile.

by Alex Ionescu

hbirr(a)svn.reactos.com wrote: >- Reference the file object in IopSecurityFile. >- Don't set FO_DIRECT_DEVICE_OPEN in IoCreateStreamFileObject. >- Disabled the setting of IRP_NOCACHE, because vfat cannot handle cached and non cached requests for the same file. >- Set the correct device object in NtWriteFile. > > > > > > Hi, This change breaks usetup. As I said, IoCreateStreamFileObject must be left with the current hack intact. Best regards, Alex Ionescu

20 years, 1 month

Re: [ros-svn] [ion] 15395: Object Manager Patch. This patch continues the work done in the previous patch and makes the following changes in order to support OB 2.0 (it basically temporarily fixes a highly incorrect implementation so that caller code will be ready to work with the OB 2.0 without change):

by Hartmut Birr

Hi, I'm not able to boot reactos after your last four commits. - Hartmut (io/pnpreport.c:84) IoReportResourceForDetection partly implemented (io/pnpreport.c:84) IoReportResourceForDetection partly implemented (io/pnpreport.c:84) IoReportResourceForDetection partly implemented (io/pnpreport.c:84) IoReportResourceForDetection partly implemented (cm/ntfunc.c:383) NtCreateKey() doesn't create trees! (found '\' in remaining path:"\DeviceClasses\{86E0D1E0-8089-11D0-9CE4-08003E301F73}\##?#ACPI#PNP0501#1#{86E0D1E0-8089-11D0-9CE4-08003E301F73}"!) KeBugCheckWithTf at ke/catch.c:222 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The problem seems to be caused by the following file: ntoskrnl.exe KMODE_EXCEPTION_NOT_HANDLED Technical information: *** STOP: 0x0000001E (0xc0000005,0x80039e70,0x00000000,0x00000004) *** ntoskrnl.exe - Address 0x80039e70 base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:80039e70 <ntoskrnl.exe:39e70 (io/device.c:86 (IopInitializeDevice))> cr2 4 cr3 34000 Proc: 80806364 Pid: 4 <System> Thrd: 80807680 Tid: 0 DS 10 ES 10 FS 30 GS 10 EAX: 00000000 EBX: 000764dc ECX: 80952008 EDX: 809b9e24 EBP: 800eeba0 ESI: 15b62000 ESP: 800eeb14 EDI: 00000000 EFLAGS: 00210296 kESP 800eeb14 kernel stack base 800ed000 Frames: <ntoskrnl.exe:4b8cf (io/pnpmgr.c:1523 (IopActionInitChildServices))> <ntoskrnl.exe:4b986 (io/pnpmgr.c:1569 (IopActionInitAllServices))> <ntoskrnl.exe:4aa6b (io/pnpmgr.c:695 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:4aaa1 (io/pnpmgr.c:709 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:4aaa1 (io/pnpmgr.c:709 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:4aae7 (io/pnpmgr.c:735 (IopTraverseDeviceTree))> <ntoskrnl.exe:4b9ec (io/pnpmgr.c:1628 (IopInitializePnpServices))> <800AB56A> <800A909C> <ntoskrnl.exe:10544 (ke/main.c:103 (KiSystemStartup))> <800A77AA> <ntoskrnl.exe:104b (D:\DOKUME~1\hb\LOKALE~1\Temp/ccO4aaaa.s:51 (_section_alignment__))>

20 years, 1 month

Recent horrid slowdown

by Phillip Susi

About a week or two ago usetup took about 20 seconds on my system under qemu to copy over the installation files. I thought even that seemed a bit slow, so I started rewriting the code to use memory mapped files to see if I could speed it up. Now that I finished with it, I noticed that the current code in the repository now takes just over 90 seconds to install the files, which my changes reduce back down to 20 seconds. Does anyone have any idea about what revision this huge slowdown was introduced in? I'll try and figure out the problem tonight but it would help if someone could point me towards the vicinity of it now so I don't have to spend time looking when I get home. I'd like to get the normal code back to it's former 20 second install area so I can get a good comparison with my new code. I'd be thrilled if it then could get the install times down to 10 seconds.

20 years, 1 month

Directory name problem.

by WaxDragon

Just recently, (cd "Program Files") has stopped working. It works without the quotes, but when you tab complete the directory name, it quotes it for you automatically. Anyone touch this recently? WD -- "<arty> the tree was touched a lot recently"

20 years, 1 month

Networking is back!

by WaxDragon

Thanks to Alex and Arty! 15407 & 15408 fix the problems I was seeing with ftp. Please check your networking apps again! WD -- "<arty> the tree was touched a lot recently"

20 years, 1 month

r15402 breakage

by Phillip Susi

The changes in this revision broke building, I get this: ntoskrnl: [CC] io/pnpmgr.c io/pnpmgr.c: In function `IoGetDeviceProperty': io/pnpmgr.c:63: warning: 'Data' might be used uninitialized in this function mingw32-make[1]: *** [io/pnpmgr.o] Error 1 mingw32-make: *** [ntoskrnl] Error 2

20 years, 1 month

Dhcp Client

by James Tabor

NOTE: DHCPACK from 10.65.145.76 NOTE: Input: 255.255.255.0 NOTE: got 255.255.255.0 NOTE: got <NULL> NOTE: Input: 10.65.145.1 NOTE: got 10.65.145.1 NOTE: got <NULL> NOTE: Input: 151.164.1.8 151.164.1.7 NOTE: got 151.164.1.8 NOTE: got 151.164.1.7 NOTE: got <NULL> NOTE: Input: 10.65.145.255 NOTE: got 10.65.145.255 NOTE: got <NULL> NOTE: Input: 10.65.145.76 NOTE: got 10.65.145.76 NOTE: got <NULL> (dispatch.c:338)(add_timeout) Adding timeout 428be4f7 0040394b 781fbc NOTE: bound to 10.65.145.106 -- renewal in 21600 seconds. What is there not to like? 8^D James

20 years, 1 month

[Fwd: Re: [ros-dev] Recent horrid slowdown]

by Alex Ionescu

20 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev