Ros-dev

ros-dev@reactos.org

5788 discussions

Re: [ros-svn] [weiden] 14045: Alex Ionescu <ionucu@videotron.ca>

by James Tabor

Hi! Well, this was a surprise! Love the new debugger! My test, building ros on ros two cmd consoles up plus taskmgr. weiden(a)svn.reactos.com wrote: > Alex Ionescu <ionucu(a)videotron.ca> > Entered debugger on last-chance exception number 14 (Page Fault) Memory at 0x54 could not be written: Page not present. kdb:> bt Frames: <ntoskrnl.exe:83727 (mm/ppool.c:598 (RFreeMerge))> <ntoskrnl.exe:837a8 (mm/ppool.c:620 (RPoolReclaim))> <ntoskrnl.exe:83fa7 (mm/ppool.c:926 (RPoolFree))> <ntoskrnl.exe:842b7 (mm/ppool.c:98 (ExFreePagedPool))> <ntoskrnl.exe:8267f (mm/pool.c:244 (ExFreePool))> <ntoskrnl.exe:abe2b (se/token.c:576 (SepDeleteToken))> <ntoskrnl.exe:92ce9 (ob/object.c:981 (ObpDeleteObject))> <ntoskrnl.exe:92eea (ob/object.c:1038 (ObpDeleteObjectDpcLevel))> <ntoskrnl.exe:9314d (ob/object.c:1148 (ObfDereferenceObject))> <ntoskrnl.exe:9a709 (ps/process.c:474 (PiDeleteProcessWorker))> <ntoskrnl.exe:9a7f3 (ps/process.c:502 (PiDeleteProcess))> <ntoskrnl.exe:92ce9 (ob/object.c:981 (ObpDeleteObject))> <ntoskrnl.exe:92eea (ob/object.c:1038 (ObpDeleteObjectDpcLevel))> <ntoskrnl.exe:9314d (ob/object.c:1148 (ObfDereferenceObject))> <ntoskrnl.exe:96092 (ps/create.c:394 (PiDeleteThread))> <ntoskrnl.exe:92ce9 (ob/object.c:981 (ObpDeleteObject))> <ntoskrnl.exe:92eea (ob/object.c:1038 (ObpDeleteObjectDpcLevel))> <ntoskrnl.exe:9314d (ob/object.c:1148 (ObfDereferenceObject))> <ntoskrnl.exe:987f2 (ps/kill.c:52 (PsReapThreads))> <ntoskrnl.exe:9eeaf (ps/thread.c:379 (PiReaperThreadMain))> <ntoskrnl.exe:3880 (/tmp/ccoqgJZs.s:83 (PsBeginThread))> kdb:> proc Current process: PID: 0x00000154 State: Terminated (0x1) Image Filename: rdel.exe kdb:> proc list PID State Filename 0x00000164 Active make.exe 0x00000164 Terminated make.exe 0x0000015c Active ctm.EXE 0x0000012c Active make.EXE 0x0000010c Active taskmgr.exe 0x00000100 Active cmd.exe 0x000000f0 Active cmd.exe 0x000000e4 Active explorer.exe 0x000000d4 Active userinit.exe 0x000000c8 Active umpnpmgr.exe 0x000000bc Active eventlog.exe 0x000000ac Active services.exe 0x0000008c Active winlogon.exe 0x00000070 Active csrss.exe 0x00000058 Active smss.exe 0x00000004 Unknown System kdb:> regs CS:EIP 0x0008:0x80082bce SS:ESP 0x0010:0x9d46bac0 EAX 0x8cfccdb4 EBX 0x80c6abc0 ECX 0x8cfc7bdc EDX 0x00000040 ESI 0x00000000 EDI 0x00000000 EBP 0x9d46bac8 EFLAGS 0x00210202 IF IOPL0 RF ID kdb:> cregs CR0 0x8001003b PE MP TS ET NE WP PG CR2 0x7c900000 CR3 0x1652e000 Pagedir-Base 0x1652e000 CR4 0x00000680 PGE OSFXSR OSXMMEXCPT GDTR Base 0x800cf100 Size 0x0058 LDTR Base 0x00000000 Size 0x0000 IDTR Base 0x8012a320 Size 0x0800 kdb:> sregs CS 0x0008 Index 0x0001 GDT RPL0 DS 0x0010 Index 0x0002 GDT RPL0 ES 0x0010 Index 0x0002 GDT RPL0 FS 0x0030 Index 0x0006 GDT RPL0 GS 0x0010 Index 0x0002 GDT RPL0 SS 0x0010 Index 0x0002 GDT RPL0 kdb:> dregs DR0 0x00000000 DR1 0x00000000 DR2 0x00000000 DR3 0x00000000 DR6 0xffff0ff0 DR7 0x00000400 kdb:> thread Current Thread: TID: 0x00000000 State: Running (0x2) Priority: 8 Affinity: 0xffffffff Initial Stack: 0x8011c570 Stack Limit: 0x80119570 Stack Base: 0x8011c570 Kernel Stack: 0x8011c570 Trap Frame: 0x9d46ba28 NPX State: Invalid (0x1)

19 years, 10 months

Re: [ros-svn] [weiden] 14045: Alex Ionescu <ionucu@videotron.ca>

by Alex Ionescu

weiden(a)svn.reactos.com wrote: >Alex Ionescu <ionucu(a)videotron.ca> > > Dispatcher Objects Rewrite (minus Queues, coming in next patch). > > > There is now only one large patch left + a smaller one related to it, which will complete the Dispatcher fixes. After those two patches, everything in my branch will have been committed. The branch will be destroyed and I will create the Winsock branch on which Arty and I will work. Best regards, Alex Ionescu

19 years, 10 months

Vote: Allow 3rd-party distribution of ROS through XDCC Bot.

by Alex Ionescu

Hi, Right now, someone has set up an XDCC IRC bot to distribute copies of ReactOS. While I welcome the move, it raises a question on who is responsible for the quality of those files. Even if the person means no harm, the files can get corrupted/infected by the following events: 1) Download corruption 2) Viral infection 3) Hard-disk damage And perhaps many more. In all cases, this would result in unusable, dangerous or even damaging releases of ReactOS, which we could not control. As such, I propose a vote: [ ] Yes, allow 3rd-party distribution of the OS through the #ros-xdcc channel and ROS-XDCC-001 bot. (support and encourage this distribution) [ ] Yes, allow 3rd-party distribution of the OS, but it must clearly distance itself from officially supported releases (tolerate but do not support this distribution) [ ] No, only sourceforge and other official ReactOS distribution points should be used. Myself I vote for the first choice, but I would like the following to be done: 1) Create MD5 Hashes to verify authenticity 2) Set up official communications with the bot's maintainer and establish a set of guidelines. Best regards, Alex Ionescu

19 years, 10 months

Re: [ros-svn] [greatlrd] 14043: GetDeviceData

by Richard Campbell

screens? :P greatlrd(a)svn.reactos.com wrote: >GetDeviceData >fix the choppy mouse in UT and fix some other small bugs. >I can now use the mouse with out any problem in UT > > > > >Updated files: >trunk/reactos/lib/dinput/mouse.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > >

19 years, 10 months

Re: [ros-dev] Vote: Allow 3rd-party distribution of ROS through XDCC Bot.

by Steven Edwards

Hi, --- Jason Filby <jason.filby(a)gmail.com> wrote: > Another question is: can we really say limit people from > redistributing ReactOS? I don't think that our license(s) prohibit > this. > > Perhaps some guidelines for such people are all that is needed. I think we should allow use of the name in limited situations. As another poster stated having a "Dropline ReactOS" is not a bad thing provided that we setup standards on what has the right to be called "ReactOS" and what does not. If anyone making or distributing a custom version of ReactOS violates the standards we set forth then we have the right to refuse use of the name. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

19 years, 10 months

Re: [ros-dev] Vote: Allow 3rd-party distribution of ROS through XDCCBot.

by Sylvain Petreolle

Feel free to reread LGPL 2.1 here : http://svn.reactos.com/viewcvs/trunk/reactos/LGPL.txt --- Magnus Olsen <magnus(a)itkonsult-olsen.com> wrote: > ReactOS are not a LPGL but GPL > it is big diffrent in the licen type > > ----- Original Message ----- > From: "Sylvain Petreolle" <spetreolle(a)yahoo.fr> > To: "ReactOS Development List" <ros-dev(a)reactos.com> > Sent: Sunday, March 13, 2005 8:39 PM > Subject: Re: [ros-dev] Vote: Allow 3rd-party distribution of ROS through > XDCCBot. > > > > If all legal conditions are fulfilled : > > - give link to the source > > - (alex's idea) provide md5sum of the file(s) > > > > As some people already said, 3d point cant exist. > > (ros is a LGPL system, some magazines already distribute it, etc.) > > > [ ] Yes, allow 3rd-party distribution of the OS through the #ros-xdcc > > > channel and ROS-XDCC-001 bot. (support and encourage this distribution) > > > > > > [X] Yes, allow 3rd-party distribution of the OS, but it must clearly > > > distance itself from officially supported releases (tolerate but do not > > > support this distribution) > > > > > > [ ] No, only sourceforge and other official ReactOS distribution points > > > should be used. > > > > > > Kind regards, > > > > Usurp (aka Sylvain Petreolle) > > > > humans are like computers, > > yesterday the BIOS was all > > - today its just a word > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.com > > http://reactos.com:8080/mailman/listinfo/ros-dev > > Kind regards, Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

19 years, 10 months

Re: [ros-diffs] [chorns] 14032: * Introduce ROS_OUTPUT

by Royce Mitchell III

chorns(a)svn.reactos.com wrote: >* GNU make don't support depending on a directory, so simulate the dependency using a file > How not? It works on my box as well as on arty's. :(

19 years, 10 months

SM: a blocking bug I can't solve myself

by ea

There is a little piece of code I left in reactos/subsys/smss/initss.c that looks like harmless, but that actually crashes smss.exe and therefore the whole system. The code is in the function SmpRegisterSmss/0. I can't find myself the bug. The code is currently wrapped by a #if 0 ... #endif but it is needed to make the SM self register (to avoid other processaes claim they are the SM). Any hint is welcome! Emanuele

19 years, 10 months

[Fwd: [Fwd: [ros-svn] [hbirr] 13963: Lock the kernel address space - Bug 512 updated]

by Gge

WARNING: This e-mail has been altered by MIMEDefang. Following this paragraph are indications of the actual changes made. For more information about your site's MIMEDefang policy, contact MIMEDefang Administrator <mimedefang(a)deos.tudelft.nl>. For more information about MIMEDefang, see: http://www.roaringpenguin.com/mimedefang/enduser.php3 An attachment of type message/rfc822, named [ros-svn] [hbirr] 13963: Lock the kernel address space instead the process'one, if the pages are located in kernel space. was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it.

19 years, 10 months

RE: Re: [ros-dev] [VOTE] Miscelanea branches

by Sylvain Petreolle

> Let me make it clear that the vote is about wether or not to allow > a particular type of branch which have some bad consequences. Not > branches in general. See > http://reactos.com:8080/archives/public/ros-dev/2005-March/002083.html > for a description of the common branch types. I did read it (otherwise I wouldnt vote) "Bugs that that could have been fixed on trunk are annoying to trunk developers. The bugfixes that go only to the branch are not in trunk (until merged there from the branch" => trunk developers are free to ask for a merge or use ros-diffs to speed up the merge process. "* Risk of duplicating work. We'll have more branches to track bugfixes on so it's harder to know which bugs has been fixed and which hasn't." you can use ros-svn to track it. And you can fix bugs in bugzilla too. "Fixed in branch my_branch, feel free to merge." > > Do you have commit access? > > Casper Kind regards, Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

19 years, 10 months

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