- Ros-dev - ReactOS.org

Changelog 0.2.6
by Steven Edwards 17 Mar '05

17 Mar '05

Hi, Please fill out the changelog. http://reactos.com/wiki/index.php/ChangeLog-0.2.6 Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

RE: [ros-dev] serial driver bug
by Hey Matthew 17 Mar '05

17 Mar '05

The 'Standard' PC serial ports are as follows: COM1 (address 3F8-3FF) and COM3 (address 3E8-3EF) share IRQ4. COM2 (address 2F8-2FF) and COM4 (address 2E8-2EF) share IRQ3. I remember from my DOS days that you can add more serial cards into the system just as long as you kept the address's from overlapping, and your software was configured correctly. As far as I'm aware the BIOS data area only has place for 4 port addresses: 0000:0400 COM1 address 0000:0402 COM2 address 0000:0404 COM3 address 0000:0406 COM4 address -----Original Message----- From: Royce Mitchell III [mailto:royce3@ev1.net] Sent: Thursday, 17 March 2005 12:04 p.m. To: ReactOS Development List Subject: Re: [ros-dev] serial driver bug Robert Köpferl wrote: > Be aware that it makes a difference wether you have got a so called > multi serial card or several plain old serial HW. I may be wrong, but > isn't 4 the limit. Due to 'reserved' ports for that kind of HW? > It's a multi-serial card. The 4 limit for plain serial is due to reserved/limited irq if I understand correctly. _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you.

1 0

Re: [ros-svn] [arty] 14124: consw has not been needed for a long time.
by ea 16 Mar '05

16 Mar '05

arty(a)svn.reactos.com wrote: >consw has not been needed for a long time. > > > Actually, that was never needed. It was there for a planned extended feature of our Win32 emulator: the possibility to switch back to text mode on the active desktop belonging to the winstation attached to the primary console.

1 0

Map files
by Casper Hornstrup 16 Mar '05

16 Mar '05

Hi. I'd like to know if we need to generate .map files in the new build system. It seems we have better options available now than we used to. Casper

3 3

Re: [ros-dev] OpenOffice.org 1.1.2 Setup Regression
by Jason Filby 16 Mar '05

16 Mar '05

Still getting it: Unhandled UserMode exception, terminating thread. Jason On Wed, 16 Mar 2005 19:30:11 +0200, Jason Filby <jason.filby(a)gmail.com> wrote: > I wanted that record ;) > Great to know though! > > Cheers > Jason > > On Wed, 16 Mar 2005 18:15:50 +0100, Filip Navara <xnavara(a)volny.cz> wrote: > > Jason Filby wrote: > > > > >Hi all > > > > > >Loading up the OpenOffice.org 1.1.2 Setup no longer works; the initial > > >progress bar completes and then nothing happens. I'm sure I've seen > > >this bug before! Any help welcome. > > > > > > > > Just for the record, today I successfully installed OOo 1.1.1, ROS SVN > > revision 14087. > > > > - Filip > > > > >

1 0

Expect Trouble?
by James Tabor 16 Mar '05

16 Mar '05

Hi! I switch to an older serial driver, BTW the new one set the baud to 19.2k. (KERNEL32:mem/global.c:412) Memory Load: 8 CSR: NtOpenProcess() failed for handle duplication Failed to tell csrss about new process. Expect trouble. (KERNEL32:mem/global.c:412) Memory Load: 8 Funny debug message, James

2 3

0.2.6, a call for testers?
by WaxDragon 16 Mar '05

16 Mar '05

Alex's patches are in, and I saw him call for 0.2.6 on irc, but there have been a few regressions discovered. Do we need to have a bughunt / regression test / code freeze? The last couple of releases (that I have been around for) we have created the branch, then applied bugfixes against it, then backported to HEAD. Is this the way we should do this? Should we "freeze" HEAD and then branch? I found that vncviewer no longer starts for me, and Alex said that Abiword doesn't work for him. The wallpaper was reported to have regressed also. I personally will test the wallpaper and all the other things I care about tonight. Maybe we should have others check over things too.. Just curious, WD -- The cheese stands alone.

5 4

OpenOffice.org 1.1.2 Setup Regression
by Jason Filby 16 Mar '05

16 Mar '05

Hi all Loading up the OpenOffice.org 1.1.2 Setup no longer works; the initial progress bar completes and then nothing happens. I'm sure I've seen this bug before! Any help welcome. Thanks Jason

2 1

Re: [ros-dev] Re: combo - implement GetComboBoxInfo
by Steven Edwards 16 Mar '05

16 Mar '05

--- James Tabor <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote: > We don't have this yet? Is there a plan to include this in our > code tree? According to Thomas and Dmitry's tests its not correct so we are waiting to see if someone comes up with a better implementation. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Re: combo - implement GetComboBoxInfo
by James Tabor 16 Mar '05

16 Mar '05

Hi Steven, Steven Edwards wrote: > Changelog: > Christoph von Wittich <Christoph(a)ApiViewer.de> > Implement GetComboBoxInfo > > > We don't have this yet? Is there a plan to include this in our code tree? Looks great! James

1 0

NASM 0.98.39 WARNING
by Royce Mitchell III 15 Mar '05

15 Mar '05

ReactOS will not build on Windows with the latest version of Nasm ( 0.98.39 ), because at least some public releases of that version ( I just downloaded the official from sourceforge.net ), do not support long file names, and we have a long file name in PSEH. We can just shorten that asm's file name, but we could also configure the build system to reject that version. I don't feel like dealing with it, so I thought I would just send a head's up here :)

2 2

Re: [ros-dev] Re: [ros-diffs] [ion] 14047: Dispatching & Queue Rewrite II:
by Steven Edwards 15 Mar '05

15 Mar '05

--- Alex Ionescu <ionucu(a)videotron.ca> wrote: > This goes beyond debug information. This is reproduceable behaviour that > probably any driver developper out there knows. Checked builds are > builds recommended for testing your driver for bugs. If you call that > function with a Queue Object, you WILL see that assert line-by-line on > your screen. From that point on, one should stich his eyes out for > having seen it, and shoot himself for knowing this behaviour? So fix a ReactOS driver to match this behavior and work under Windows and then you will have justification for making related changes in the kernel. > Notwithstanding that they cannot sue the project, and that they would > not sue you. This was a public comment to a friend... why would they sue > Steven when Alex said what he said? And yes, I cannot wait to be sued... > I can see the headlines -- Driver Developer sued for being aware of > Windows Assertion --. I hope they also go after Mark Russinovich for > having used the checked build to generate a tree of the Windows Source > code!! The last time I looked Mr Russinovich was not try to make a replacement for Windows but rather provide more information people wanting to use Windows. > If you aren't, then why am I always the one being targeted with such > comments. There are functions in ROS which are almost copies of their > binary versions. There are structures in ROS which look like clones of > the Windows ones (undocumented ones). There is functionality that was > directly reversed engineered so that it would be compatible. Yes we have reverse engineered quite a bit but the question is what methods are being used to reverse certain behavior. We cannot help but be compatible with the structures in Windows and take any means needed to be compatible. > Yet, nobody says a word; everyone goes after Alex for having a > conversation with a friend and mentionning a reproducible fact in every > driver developer's life -- you do not KeWaitXxx on a Queue. > Probably as much as jumping on a guy who has written some of the highest > quality and most useful code in the OS for the fact he used public > information during an argument. You stated the other day there were regressions that were only found by developing test cases. You would have a lot more good will from developers on this project if you committed test cases for some of the patches you develop and commit them to rosapps/tests or write a dummy driver to show the behavior rather than than pointing to checked builds. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

Re: [ros-dev] Vote: Allow 3rd-party distribution of ROS through XDCC Bot.
by Steven Edwards 15 Mar '05

15 Mar '05

Hi, --- Mike Swanson <mikeonthecomputer(a)gmail.com> wrote: > Just put a trademark on the name but allow it to be used on > derivations on the circumstance that it clearly shows that it is not > _the_ ReactOS. I have looked in to this a bit with the legal council I have on retainer as part of the ReactOS Foundation work. I think it is around $250 to file in a state and around $1000 to file the federal paperwork. I will call the lawyer this week and get numbers and a timeframe on what it would take to make it happen. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 3

Re: [ros-dev] Re: [ros-diffs] [ion] 14047: Dispatching & Queue Rewrite II:
by Steven Edwards 15 Mar '05

15 Mar '05

--- Alex IoIonescuioionucuivideotrona> wrote: > This climate of paranoia is getting to my nerves. You could at least try to be civil in your discussion. Some of us have spent more than a few years on this project and have a right to be a little paranoid about if our lives work might be put in to danger. > As for Steven... WINE, ROS, and any other compatibility product out there is not 100% clean > room. It has never been, will never be, cannot be. Especially if we consider debug information > as being "dirty". Reminds me of people freaking out when I added functions that were in the IFS > -- you'd hope people would've grown up by now--. Still it depends on the source of the information. We have discussed in private my views on using the debug information. I will publicly state I think the law is ambiguous at best and the debug information should be a valid source given Microsoft position of being a monopoly as found by Anti-trust proceedings. That being said a court might not agree with me so any behavior must be 1. Reproduceable or 2. Documented. > I could make a list of over 25 parts of ReactOS Which are not 100% clean. But I won't, because > that would tarnish our image. I would appreciate if you'd stop tarnishing mine and making > accusations. I am not trying to trash your image. I am simply mentioning the truth that everyone already knows but could be deadly to this project and others in a kangaroo court in the US. When your source of information comes from documentation or a third part program exhibiting certain behavior then there is not a legal question as to if a reimplementation is a original work. If you are basing your implementation of a feature only on the debug information then clearly, at least in my mind it runs the danger being found a derived work and everytime you do so it at the very least tarnishes ReactOS's image. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Debug Output to Com1
by James Tabor 15 Mar '05

15 Mar '05

Hi! What happen to the com stuff! 19200 baud! WTH! (++ÄÅÄ+±_.:101) D+ #__+#+ +Å+: PCI\VEN 1106&DEV B198&SUBSYS 00000000&REV 00\0(NT DLL:+_/+++_.:2092) R+Ä#+Å±000 (++ÄÅÄ+±_.:101) D+ #__+#+ + (770000 -> 750000) C:\R#+OS\_<_+Å+: PCI\VEN 1106&DEV 3205&SUBSYS 32051+32\±32.++ 106&REV 00\0000 (NTDLL:+_/+++_.:2092) R+Ä#+Å± (7760000 -> 80000) C:\R#+OS\_<_++32\+__32.++ D_+_B#_ °Ä_ \S<_++RÄÄ+\S<_++32\°_#++°.DLL: 9783000 FIXME: CÄÄ<I+#± Ä_Å'+ _+ÄÄÄ_+ IMAGE ICON Ä__++<! (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å +|M__#± (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å #+|M__#± (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å +|M__#± (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å +M__#± (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å +ÄM__#± (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å +M__#± (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å +ÄM__#± (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å #+|M__#± (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å +|M__#± (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å +M__#± (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å +M__#± (NTDLL:+_/+++_.:1211) L_G+E|ÄÄ_+B<N#+(): °#+ +Ä °Å +ÄM__#± (+ÅÄ+_/ÅÄ++.:97)(G+A_<ÅK<S+#+) _ +Å+Ä++Å+, Ä+#_ +_< #±#Å +#+_. (Å++__/+#__.:114) F#+ +Ä +ÄÄ++Ä +#__ #+Ä+! H#_ _++ ÄÄ+_. N+_± == 0|000 (Å++__/ÄÄ+.:504) NÄ+ +Ä++Å+: HÄÄ+I 3 G+Ä#+ TRUE SHELLHOOK 1 SHELLHOOK 4 SHELLHOOK 1 SHELLHOOK 4 SHELLHOOK 4

2 2

Re: [ros-dev] Re: [ros-diffs] [ion] 14047: Dispatching & Queue Rewrite II:
by Steven Edwards 15 Mar '05

15 Mar '05

--- Alex Ionescu <ionucu(a)videotron.ca> wrote: > What the fsck are you implying. Its hard to claim our implementation is "clean room" if you are basing your implementation on debug information rather than reverse enginered behavior. I am not opposed to observing the implementation via debug information and then writting tests to match behavior but there is a fine line... Thanks Steven __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

2 1

SM and winlogon
by ea 14 Mar '05

14 Mar '05

What if winlogon.exe is run by csrss.exe and not by smss.exe? A winlogon process, in its own desktop, is needed for each Win32 session. If we make csrss.exe multiuser, it must create session 0 (console) or die and therefore run winlogon in it. This change shouldn't have any effect on compatibility with Windows NT. smss will assume only csrss is critical. ea

1 0

Boot Error
by James Tabor 14 Mar '05

14 Mar '05

Wow! Current SVN (Head)! Used memory 1015744Kb (mm/mminit.c:375) Kernel Stack Limits. InitTop = 0x80133000, Init = 0x80130000 (mm/virtual.c:214) FIXME: MEMORY_AREA_SYSTEM case incomplete (or possibly wrong) for NtQueryVirtualMemory() (ke/bug.c:56) Found Bugcheck Resource Data! (ke/bug.c:67) Got Pointer to Bugcheck Resource Data! (ke/clock.c:80) KiInitializeSystemClock() (ke/clock.c:99) Finished KiInitializeSystemClock() No current process Entered debugger on last-chance exception number 14 (Page Fault) Memory at 0x9c could not be read: Page not present. No current process KeBugCheckWithTf at ke/catch.c:224 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,0x8002f410,0x00000000,0x00000018) *** ntoskrnl.exe - Address 0x8002f410 base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:8002f410 <ntoskrnl.exe:2f410> cr2 18 cr3 26000 Proc: 0 DS 10 ES 10 FS 30 GS 10 EAX: 00000000 EBX: 00000680 ECX: 00026000 EDX: 00000064 EBP: 8013245c ESI: 80132834 ESP: 801323ac EDI: 80132be0 EFLAGS: 00210046 kESP 801323ac Frames: <ntoskrnl.exe:300fc> <ntoskrnl.exe:de31> <ntoskrnl.exe:1285> <ntoskrnl.exe:1aff> <ntoskrnl.exe:382d> <ntoskrnl.exe:c4a3e> <46C> KeBugCheckWithTf at ke/catch.c:224 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 (0x80000003,0x80005c47,0x00000000,0x00000000) *** ntoskrnl.exe - Address 0x80005c47 base at 0x80000000, DateStamp 0x0

3 11

Att: Thomas. 2nd Token Bug.
by Alex Ionescu 14 Mar '05

14 Mar '05

Steps to repro: 2nd stage installer, pressing enter really fast to get through the screens. At the last screen: Note that the backtrace seems to be missing kernel-mode stuff beyond the syscall. The crash is actually at token.c:1723. In asm: 800b6657: 3b 02 cmp (%edx),%eax edx is 0x00929004 which is invalid: Entered debugger on last-chance exception number 14 (Page Fault) Memory at 0x929004 could not be read: Page not present. Either this function is missing seh, or something has been changed with the token rewrite which messes things up. More info: KMODE_EXCEPTION_NOT_HANDLED Technical information: *** STOP: 0x0000001E (0xc0000005,0x800b6657,0x00000000,0x00929004) *** ntoskrnl.exe - Address 0x800b6657 base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:800b6657 <ntoskrnl.exe:b6657 (se/token.c:1723 (NtAdjustPrivilegesToken))> cr2 929004 cr3 6d8b000 Proc: 80ab8290 Pid: ac <setup.ex> Thrd: 80aba0c8 Tid: b0 DS 10 ES 10 FS 30 GS 23 EAX: 00000007 EBX: 00000000 ECX: 8cada688 EDX: 00929004 EBP: 9d8c8d54 ESI: 0064ec20 ESP: 9d8c8c88 EDI: 8cada688 EFLAGS: 00000206 kESP 9d8c8c88 kernel stack base 9d8c6000 Frames: <ntoskrnl.exe:39c2 (/home/alex/tmp/cc6fkKWh.s:178 (KiSystemService))> <advapi32.dll:13dca (token/token.c:58 (AdjustTokenPrivileges))> kdb:> bt Frames: <ntoskrnl.exe:39c2 (/home/alex/tmp/cc6fkKWh.s:178 (KiSystemService))> <advapi32.dll:13dca (token/token.c:58 (AdjustTokenPrivileges))> <syssetup.dll:2aff (wizard.c:1164 (DateTimePageDlgProc))> <user32.dll:ea41 (windows/message.c:982 (IntCallWindowProcA))> <user32.dll:eaef (windows/message.c:1031 (CallWindowProcA))> <user32.dll:1717e (windows/dialog.c:1458 (DefDlgProcA))> <user32.dll:ea41 (windows/message.c:982 (IntCallWindowProcA))> <user32.dll:f456 (windows/message.c:1491 (SendMessageA))> <comctl32.dll:28aac (propsheet.c:1713 (PROPSHEET_Next))> <comctl32.dll:28d83 (propsheet.c:3075 (PROPSHEET_DoCommand))> <comctl32.dll:2ab1a (propsheet.c:3412 (PROPSHEET_DialogProc))> <user32.dll:ea06 (windows/message.c:964 (IntCallWindowProcW))> <user32.dll:eb75 (windows/message.c:1057 (CallWindowProcW))> <user32.dll:1700e (windows/dialog.c:1519 (DefDlgProcW))> <user32.dll:ea06 (windows/message.c:964 (IntCallWindowProcW))> <user32.dll:f364 (windows/message.c:1428 (SendMessageW))> <user32.dll:17aca (windows/dialog.c:2220 (IsDialogMessageW))> <user32.dll:17c5a (windows/dialog.c:531 (DIALOG_DoDialogBox))> <user32.dll:17df8 (windows/dialog.c:1608 (DialogBoxIndirectParamW))> <comctl32.dll:27b57 (propsheet.c:729 (PROPSHEET_CreateDialog))> <comctl32.dll:299ce (propsheet.c:2841 (PropertySheetW))> <syssetup.dll:2f4a (wizard.c:1482 (InstallWizard))> <syssetup.dll:172c (install.c:491 (InstallReactOS))>--- Press q to abort, any other key to continue --- <setup.exe:1333 (setup.c:79 (WinMain))> <setup.exe:145b (setup.c:116 (WinMain))> <setup.exe:116a> <setup.exe:1038> <kernel32.dll:20c30 (process/create.c:339 (BaseProcessStart))> <deadbeef> kdb:> regs CS:EIP 0x0008:0x800b6657 SS:ESP 0x0028:0x80105cb9 EAX 0x00000007 EBX 0x00000000 ECX 0x8cada688 EDX 0x00929004 ESI 0x0064ec20 EDI 0x8cada688 EBP 0x9d8c8d54 EFLAGS 0x00000206 PF IF IOPL0 kdb:> cregs CR0 0xe001003b PE MP TS ET NE WP NW CD PG CR2 0x00929004 CR3 0x06d8b000 Pagedir-Base 0x06d8b000 CR4 0x00000080 PGE GDTR Base 0x800d6100 Size 0x0058 LDTR Base 0x00000000 Size 0x0000 IDTR Base 0x80130320 Size 0x0800

2 1

Re: [ros-dev] SM: a blocking bug I can
by ea＠iol.it 14 Mar '05

14 Mar '05

Hi Hartmut, > I'm not sure but a native application can only import ntdll.dll. If you > enable the code, smss will import smdll.dll. You are probably right. It is the time to make smdll static. Thank you. Emanuele ____________________________________________________________ Navighi a 2 MEGA e i primi 3 mesi sono GRATIS. Scegli Libero Adsl Flat senza limiti su http://www.libero.it

1 0

FreeWin
by ea 14 Mar '05

14 Mar '05

This one seems a derivative work of ros. Is it already known? http://gro.clinux.org/projects/freewin

3 3

Mac OS X clone???
by rlangschultz＠cox.net 14 Mar '05

14 Mar '05

I was wondering if there was a project that would be doing a binary compatible OS X system. What reactos does for windows maybe this project can do for OS X. I was just wondering. I know that pearpc emulates a ppc processor, but wether or not a full os exists is the question. I know also that some versions of linux exist for ppc. Thanks Also - is reactos going to do a mips, ppc, arm, ia64 system?

5 6

Re: [ros-svn] [weiden] 14045: Alex Ionescu <ionucu@videotron.ca>
by James Tabor 14 Mar '05

14 Mar '05

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)

2 1

Re: [ros-svn] [weiden] 14045: Alex Ionescu <ionucu@videotron.ca>
by Alex Ionescu 14 Mar '05

14 Mar '05

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

1 0

Vote: Allow 3rd-party distribution of ROS through XDCC Bot.
by Alex Ionescu 14 Mar '05

14 Mar '05

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

6 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev