Ros-dev

ros-dev@reactos.org

5789 discussions

Re: [ros-dev] Re: [ros-diffs] [ion] 14047: Dispatching & Queue Rewrite II:

by Steven Edwards

--- 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

20 years, 3 months

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

by Steven Edwards

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/

20 years, 3 months

Re: [ros-dev] Re: [ros-diffs] [ion] 14047: Dispatching & Queue Rewrite II:

by Steven Edwards

--- 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/

20 years, 3 months

Debug Output to Com1

by James Tabor

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

20 years, 3 months

Re: [ros-dev] Re: [ros-diffs] [ion] 14047: Dispatching & Queue Rewrite II:

by Steven Edwards

--- 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

20 years, 3 months

SM and winlogon

by ea

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

20 years, 3 months

Boot Error

by James Tabor

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

20 years, 3 months

Att: Thomas. 2nd Token Bug.

by Alex Ionescu

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

20 years, 3 months

Re: [ros-dev] SM: a blocking bug I can

by ea＠iol.it

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

20 years, 3 months

FreeWin

by ea

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

20 years, 3 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