Ros-dev

ros-dev@reactos.org

5789 discussions

by Joshua Bailey

If you guys don't know me by know, my name is Joshua Bailey, though you may recognize me better as RaptorEmperor on the forums. I infrequently do software testing for the ReactOS project, and I've also just started teaching myself how to do debugging work. If I knew C, better understood the Windows architecture, and felt more comfortable in my abilities as a programmer I would probably join in development outright. I'm a pretty frequent visitor to the forums, but I don't generally post anything to the ros-dev mailing list because I'd rather not distract the developers with my random questions about GDI support or whatever else crosses my mind and leave this mailing list open to more important matters. For as long as I have been involved with the ReactOS project I've also been a Wikipedia editor. I check on the ReactOS article on Wikipedia periodically to see if there are any points in the article to which I can add relevant information so readers are better informed (and hopefully more interested) in the ReactOS project. A few weeks ago I added a reference to Arwinss in the paragraph of the article detailing the relationship between ReactOS and other projects, more specifically Wine. Tonight I checked the article, and I noticed that the reference to Arwinss was removed by LoneRifle, with the attached comment "Current and future development: Remove information about arwinss on request of the Dev team". I initially linked my reference to Arwinss in the Wikipedia article to the Arwinss wiki page, and another user by the name of XRideBMX changed the reference to Newsletter #62, which was the first announcement on the main page about Arwinss. Both of these sources are publicly available from the ReactOS website. There's nothing dubious about their accuracy or point of view. Considering this, and the outright statement on the article's revision history, I'm left to conclude that the only reason that my edit was removed was censorship on the part of the ReactOS development team. The reason I find this disturbing is that Wikipedia standards dictate a non-point-of-view policy. By having underlings edit the article to best reflect the preferred viewpoints of the developers, the integrity of the article is compromised. If my edits were removed for a more legitimate reason, for example, because someone didn't feel they were relevant, I could argue the point with them personally. But as a source of free information, without intent of bias, seeing the developers complicit in censorship on Wikipedia makes me feel extremely uncomfortable about ReactOS. I'm sure Dick Cheney and the CIA don't appreciate their dirty laundry (waterboarding, etc.) being plastered in a public encyclopedia, but flags would be immediately raised if the waterboarding article was changed with the article history stating "Remove information about CIA waterboarding on the request of George Tenet". Seeing this kind of behavior coming from free and open-source project, and the flagrant nature of it, is extremely disturbing to me. I'm formally asking you, the development team, why my comments were deemed necessary for removal. Since I was the one who made the edit, and considering the concerns I have listed, I deserve some explanation. As far as I can tell, mentioning Arwinss in a public encyclopedia, using publicly available sources, does no harm to the project. What about the existence of Arwinss was deemed too secret for a Wikipedia page? How can Arwinss be considered public enough for the ReactOS front page, but not enough for a Wikipedia page? What legitimate reason is there for removing the reference to Arwinss in Wikipedia? Outside of a sloppy attempt at censorship? I have been very excited about the ReactOS project since I first discovered it around 2005, and with Arwinss on the radar I'm more excited to see what is going to come out of the project than I have been in a long time. However, if the development team is not comfortable enough to trust that people can make their own opinions about ReactOS without censoring irrelevant details on a Wikipedia page, maybe I should consider whether or not ReactOS really adheres to the principles of openness and freedom that I do. As much as I like ReactOS, the I hold the values of open-source first. I apologize if my formatting appears to be poor, because I don't send emails to mailing lists from this email account that often. I would greatly appreciate a response. If there is a misunderstanding here I would very much like to resolve it, to clear up my current reservations about the ReactOS project. If not, I reserve my right to revert the changes to the article. -Joshua Bailey

15 years, 3 months

Wikipedia article changes, censorship

by Joshua Bailey

>yes, I asked LoneRifle to remove the reference because I was preparing much better information (which has just been released yesterday) and >didn't want people to read old incomplete info. So from now on you could use this information in our wikipedia article. If that was the case, that makes sense. Removing the information from the article outright, as opposed to simply waiting and updating the article with more detailed information when it was available might have been a better way of doing things so no red flags pop up, in my mind or the mind of others. Alternately, you, LoneRifle, or whoever is the one most in charge of maintaining the Wikipedia page should have at least noted that the information was going to be replaced with updated information so no other Wikipedia editors were left to assume that the information was simply going to disappear. Probably the only reason I didn't revert the changes immediately was because I wanted to ask the devs about it first to see if there was a misunderstanding. My desire to see ReactOS succeed was tempering my natural instinct to assume the worst about the situation. Betov already made accusations of ReactOS fans tampering with Wikipedia a while back, and while I don't believe that his claims are true, a random person reading Betov's accusations and then seeing that kind of a statement in the article's revision history might be more apt to be apprehensive about the project. Because of the bad rap ReactOS has gotten in the past, we have to be more careful to avoid feeding into any misinformation that has been spread about ReactOS. Hopefully you can see why I was concerned. It's cool now, we'll just have to do things a bit differently in the future. Thanks for getting back to me so quickly. Since that's cleared up, now I can sit around and get excited about Arwinss again. When should us testers expect to see a working Arwinss in the trunk builds to test? -Joshua Bailey

15 years, 3 months

Re: [ros-dev] Request for a project

by sudheer kumar

hello, Thank you very much for all the help guys. I am interested in the Fast FAT project. Also arty and colibri gave me an idea to work on partmgr.sys. I am more interested towards Fast FAT as I have prior experience on file systems and I can show something concrete to my professor. The other thing is for partmgr.sys I need to start from the scratch and there isnt much info about it. Is it fine for others ??(since some one might be working on it).The idea of adding list of all the medium sized task to the wiki is good as its going to help people like me. Thanks & Regards, sudhir.

15 years, 3 months

Re: [ros-dev] [ros-diffs] [spetreolle] 45091: Disable spooler service. This allows bootcdregtest to start here under qemu-kvm.

by Ged Murphy

This sounds like a hack. Why would disabling a service fix an operating system? Also, don't we need this service for certain Wine tests? -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of spetreolle(a)svn.reactos.org Sent: 15 January 2010 22:17 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [spetreolle] 45091: Disable spooler service. This allows bootcdregtest to start here under qemu-kvm. Author: spetreolle Date: Fri Jan 15 23:17:16 2010 New Revision: 45091 URL: http://svn.reactos.org/svn/reactos?rev=45091&view=rev Log: Disable spooler service. This allows bootcdregtest to start here under qemu-kvm. Modified: trunk/reactos/boot/bootdata/hivesys_i386.inf Modified: trunk/reactos/boot/bootdata/hivesys_i386.inf URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys_i386… ============================================================================== --- trunk/reactos/boot/bootdata/hivesys_i386.inf [iso-8859-1] (original) +++ trunk/reactos/boot/bootdata/hivesys_i386.inf [iso-8859-1] Fri Jan 15 23:17:16 2010 @@ -1198,7 +1198,7 @@ HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","Group",0x00000000,"SpoolerGroup" HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","ImagePath",0x00020000,"%SystemRoot%\system32\spoolsv.exe" HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","ObjectName",0x00000000,"LocalSystem" -HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","Start",0x00010001,0x00000002 +HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","Start",0x00010001,0x00000004 HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","Type",0x00010001,0x00000110 ; WLAN service

15 years, 3 months

[ros-diffs] [sir_richard] 45052: Patch that fixes VMWare boot (and

by Dmitry Gorbachev

Hi, sir_richard wrote: > * We really have to get a good DS/ES first before touching any data. > * > * These two reads will either go in a register (with optimizations ON) or > * a stack variable (which is on SS:ESP, guaranteed to be good/valid). > * > * Because the assembly is marked volatile, the order of instructions is > * as-is, otherwise the optimizer could simply get rid of our DS/ES. Timo Kreuzer wrote: > 2.) Segements should be fixed up before entering C code, as not doing so > may introduce possible compiler dependend breakages. It's also much > cleaner and there's no reason to do the same stuff later in inline assembly > instead of direcly in the asm entry point. Ros Arm wrote: > Regarding #2, I unfortunately do not see the need to add more assembly > when it is not needed. There are no subtle compiler breakages involved, > since it is impossible for the compiler to add a DS/ES access for no reason > at all (can you come up with an example?), this is part of the contract the > compiler has to make (if compilers did this, it would break a whole class of > embedded and real-mode software). Because the stack is safe, I think it's > worth avoiding the extra lines of assembly. The C inlines will produce > exactly the same code anyway. Not as a guide to action, simply to note — there is no guarantee that volatile asm statements (and code around them) will never be reordered. As only two registers are needed to keep Ds and Es, it seems to work there. But in a general case, GCC does not hesitate to rearrange such stuff…

15 years, 3 months

Request for a project

by sudheer kumar

Hi, I am interested to work on reactos developement. I want to take my work on reactos as a credit in my university. I spoke toAleksey Bragin (Fireball) regarding this. He asked me to mail to the developer mailing list. I need some concrete work to work for like five months or more so that I can show to professor to get his acceptance. My skills involve mostly on developing .I am mostly a C++ programmer with some experience in assembly language. I have some prior experience on filesystems and kernel but mostly linux. I have some experience on windows drivers too. By the way I am a masters student in computer science from US. Thanks & Regards, sudhir. .

15 years, 3 months

bug in KiTrap0DHandler

by Timo Kreuzer

@Sir Richard, While fixing trunk breakage, I also fixed another bug in KiTrap0DHandler, which was always only checking one prefix. I attached the patch. Regards, Timo Index: traphdlr.c =================================================================== --- traphdlr.c (Revision 45057) +++ traphdlr.c (Arbeitskopie) @@ -1103,19 +1103,23 @@ /* Skip prefix instructions */ for (j = 0; j < sizeof(KiTrapPrefixTable); j++) { - /* Is this NOT a prefix instruction? */ - if (Instructions[i] != KiTrapPrefixTable[j]) + /* Is this a prefix instruction? */ + if (Instructions[i] == KiTrapPrefixTable[j]) { - /* We can go ahead and handle the fault now */ - Instruction = Instructions[i]; + /* Stop looking */ break; } } - /* Do we need to keep looking? */ - if (Instruction) break; + /* Is this NOT any prefix instruction? */ + if (Instructions[i] != KiTrapPrefixTable[j]) + { + /* We can go ahead and handle the fault now */ + Instruction = Instructions[i]; + break; + } } - + /* If all we found was prefixes, then this instruction is too long */ if (!Instruction) {

15 years, 3 months

Fwd: removing ReactOS (for lulz)

by Aleksey Bragin

:) Begin forwarded message: > From: Max Winter <maxwinter2001(a)yahoo.com> > Date: January 13, 2010 1:26:11 AM GMT+03:00 > To: xxxxxxx(a)reactos.org > Subject: removing ReactOS > > How do I get ReactOS off my computer? I downloaded a third of it > and for various reasons stopped the download. I want to get it off > my computer now but it is not giving me delete or cut options. > This is as bad as malware, or Hotel California, you can check it > in but you can't check out. > > M >

15 years, 3 months

Re: [ros-dev] [ros-diffs] [sir_richard] 45057: [NTOS]: Fix some bugs and cleanup V8086 code in regards to flags usage. [NTOS]: Add VDM debug spew to see why there's now an invalid opcode on Windows builds of VMWare and certain QEmu combinations. (Not

by James Tabor

Go into ntoskrnl and svn up -r 45013 should take care of it....... On Wed, Jan 13, 2010 at 3:31 AM, Ged Murphy <gedmurphy(a)gmail.com> wrote: > sir_richard, > > Trunk is still broken and is causing issues for some of the dev team. > > You can see the problems in our buildbot test machine: > - Go to the following address : http://build.reactos.org:8010 > - under the x86_(Test) machine, click on the stdio for the 'test' stage. > - You'll see stage 1 complete, the stage 2 bugchecks. > > Could you please address this problem before continuing your work as it's ruining the test system. > The problem is that because our test machine can't run we aren't able to monitor other commits in other areas, meaning we're potentially introducing other bugs that we're now missing. > According to our policy, failure to fix this soon (it's normally 24 hours) will result in us having to freeze development on trunk until the bug is fixed. If we're unable to fix it in a reasonable amount of time then the changes need to be reverted until we have a bootable OS again. > > Regards, > Ged Murphy. > > >

15 years, 3 months

by Ged Murphy

sir_richard, Trunk is still broken and is causing issues for some of the dev team. You can see the problems in our buildbot test machine: - Go to the following address : http://build.reactos.org:8010 - under the x86_(Test) machine, click on the stdio for the 'test' stage. - You'll see stage 1 complete, the stage 2 bugchecks. Could you please address this problem before continuing your work as it's ruining the test system. The problem is that because our test machine can't run we aren't able to monitor other commits in other areas, meaning we're potentially introducing other bugs that we're now missing. According to our policy, failure to fix this soon (it's normally 24 hours) will result in us having to freeze development on trunk until the bug is fixed. If we're unable to fix it in a reasonable amount of time then the changes need to be reverted until we have a bootable OS again. Regards, Ged Murphy. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of sir_richard(a)svn.reactos.org Sent: 13 January 2010 03:43 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [sir_richard] 45057: [NTOS]: Fix some bugs and cleanup V8086 code in regards to flags usage. [NTOS]: Add VDM debug spew to see why there's now an invalid opcode on Windows builds of VMWare and certain QEmu combinations. (Note: the double fault Author: sir_richard Date: Wed Jan 13 04:43:03 2010 New Revision: 45057 URL: http://svn.reactos.org/svn/reactos?rev=45057&view=rev Log: [NTOS]: Fix some bugs and cleanup V8086 code in regards to flags usage. [NTOS]: Add VDM debug spew to see why there's now an invalid opcode on Windows builds of VMWare and certain QEmu combinations. (Note: the double fault issue is fixed, this is a new issue). Modified: trunk/reactos/ntoskrnl/ke/i386/v86vdm.c Modified: trunk/reactos/ntoskrnl/ke/i386/v86vdm.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/v86vdm.c?… ============================================================================== --- trunk/reactos/ntoskrnl/ke/i386/v86vdm.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/ke/i386/v86vdm.c [iso-8859-1] Wed Jan 13 04:43:03 2010 @@ -12,6 +12,9 @@ #include <ntoskrnl.h> #define NDEBUG #include <debug.h> + +#define KiVdmGetInstructionSize(x) ((x) & 0xFF) +#define KiVdmGetPrefixFlags(x) ((x) & 0xFFFFFF00) /* GLOBALS ********************************************************************/ @@ -51,6 +54,7 @@ ULONG Esp, V86EFlags, TrapEFlags; /* Get current V8086 flags and mask out interrupt flag */ + DbgPrint("VDM: Handling PUSHF (PREFIX [0x%lx])\n", KiVdmGetPrefixFlags(Flags)); V86EFlags = *KiNtVdmState; V86EFlags &= ~EFLAGS_INTERRUPT_MASK; @@ -67,7 +71,7 @@ Esp -= 2; /* Check for OPER32 */ - if (Flags & PFX_FLAG_OPER32) + if (KiVdmGetPrefixFlags(Flags) & PFX_FLAG_OPER32) { /* Save EFlags */ Esp -= 2; @@ -81,7 +85,7 @@ /* Set new ESP and EIP */ TrapFrame->HardwareEsp = (USHORT)Esp; - TrapFrame->Eip += (Flags & 0xFF); + TrapFrame->Eip += KiVdmGetInstructionSize(Flags); /* We're done */ return TRUE; @@ -95,6 +99,7 @@ ULONG Esp, V86EFlags, EFlags, TrapEFlags; /* Build flat ESP */ + DbgPrint("VDM: Handling POPF (PREFIX [0x%lx])\n", KiVdmGetPrefixFlags(Flags)); Esp = (TrapFrame->HardwareSegSs << 4) + (USHORT)TrapFrame->HardwareEsp; /* Read EFlags */ @@ -102,7 +107,7 @@ Esp += 4; /* Check for OPER32 */ - if (!(Flags & PFX_FLAG_OPER32)) + if (!(KiVdmGetPrefixFlags(Flags) & PFX_FLAG_OPER32)) { /* Read correct flags and use correct stack address */ Esp -= 2; @@ -140,7 +145,7 @@ /* FIXME: Check for VDM interrupts */ /* Update EIP */ - TrapFrame->Eip += (Flags & 0xFF); + TrapFrame->Eip += KiVdmGetInstructionSize(Flags); /* We're done */ return TRUE; @@ -187,7 +192,7 @@ /* Push IP */ Esp -= 2; - *(PUSHORT)(Esp) = (USHORT)TrapFrame->Eip + (Flags & 0xFF) + 1; + *(PUSHORT)(Esp) = (USHORT)TrapFrame->Eip + KiVdmGetInstructionSize(Flags) + 1; /* Update ESP */ TrapFrame->HardwareEsp = (USHORT)Esp; @@ -196,11 +201,12 @@ Eip = (TrapFrame->SegCs << 4) + TrapFrame->Eip; /* Now get the *next* EIP address (current is original + the count - 1) */ - Eip += (Flags & 0xFF); + Eip += KiVdmGetInstructionSize(Flags); /* Now read the interrupt number */ Interrupt = *(PUCHAR)Eip; - + DbgPrint("VDM: Handling INT [0x%lx]\n", Interrupt); + /* Read the EIP from its IVT entry */ Interrupt = *(PULONG)(Interrupt * 4); TrapFrame->Eip = (USHORT)Interrupt; @@ -240,12 +246,13 @@ IN ULONG Flags) { ULONG Esp, V86EFlags, EFlags, TrapEFlags, Eip; - + /* Build flat ESP */ + DbgPrint("VDM: Handling IRET (PREFIX [0x%lx])\n", KiVdmGetPrefixFlags(Flags)); Esp = (TrapFrame->HardwareSegSs << 4) + TrapFrame->HardwareEsp; /* Check for OPER32 */ - if (Flags & PFX_FLAG_OPER32) + if (KiVdmGetPrefixFlags(Flags) & PFX_FLAG_OPER32) { /* Build segmented EIP */ TrapFrame->Eip = *(PULONG)Esp; @@ -292,6 +299,7 @@ /* Build flat EIP and check if this is the BOP instruction */ Eip = (TrapFrame->SegCs << 4) + TrapFrame->Eip; + DbgPrint("VDM: Handling IRET EIP @ 0x%p [OPCODE: %lx]\n", Eip, *(PUSHORT)Eip); if (*(PUSHORT)Eip == 0xC4C4) { /* Dispatch the BOP */ @@ -313,11 +321,12 @@ { /* FIXME: Support VME */ - /* disable interrupts */ + /* Disable interrupts */ + DbgPrint("VDM: Handling CLI\n"); KiVdmClearVdmEFlags(EFLAGS_INTERRUPT_MASK); /* Skip instruction */ - TrapFrame->Eip += (Flags & 0xFF); + TrapFrame->Eip += KiVdmGetInstructionSize(Flags); /* Done */ return TRUE; @@ -331,10 +340,11 @@ /* FIXME: Support VME */ /* Enable interrupts */ + DbgPrint("VDM: Handling STI\n"); KiVdmSetVdmEFlags(EFLAGS_INTERRUPT_MASK); /* Skip instruction */ - TrapFrame->Eip += (Flags & 0xFF); + TrapFrame->Eip += KiVdmGetInstructionSize(Flags); /* Done */ return TRUE; @@ -351,7 +361,8 @@ /* Get flat EIP of the *current* instruction (not the original EIP) */ Eip = (TrapFrame->SegCs << 4) + TrapFrame->Eip; - Eip += (Flags & 0xFF) - 1; + DbgPrint("VDM: Handling Opcode @ 0x%p\n", Eip); + Eip += KiVdmGetInstructionSize(Flags) - 1; /* Read the opcode entry */ switch (*(PUCHAR)Eip) @@ -409,6 +420,7 @@ IN ULONG Flags) { /* Increase instruction size */ + DbgPrint("VDM: Handling PREFIX [%lx] Opcode @ 0x%p\n", KiVdmGetPrefixFlags(Flags), TrapFrame->Eip); Flags++; /* Handle the next opcode */ @@ -623,7 +635,9 @@ Tss->IoMapBase = (USHORT)IOPM_OFFSET; /* Switch stacks and work the magic */ + DbgPrint("VDM: Entering V8086 Mode\n"); Ki386SetupAndExitToV86Mode(VdmTeb); + DbgPrint("VDM: Exiting V8086 Mode\n"); /* Restore IOPM */ RtlCopyMemory(&Tss->IoMaps[0].IoMap, Ki386IopmSaveArea, PAGE_SIZE * 2);

15 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