Ros-dev

ros-dev@reactos.org

5788 discussions

Re: [ros-dev] [ros-diffs] [tkreuzer] 37431: forgot this file

by Matthieu Suiche

+ return !!(Flags & EFLAGS_INTERRUPT_MASK); Why do you donnot use something like that instead ? return (Flags & EFLAGS_INTERRUPT_MASK) ? TRUE: FALSE; -- Matthieu Suiche On Tue, Nov 18, 2008 at 3:27 AM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Mon Nov 17 20:27:04 2008 > New Revision: 37431 > > URL: http://svn.reactos.org/svn/reactos?rev=37431&view=rev > Log: > forgot this file > > Added: > branches/ros-amd64-bringup/reactos/ntoskrnl/ke/amd64/interrupt.c (with props) > > Added: branches/ros-amd64-bringup/reactos/ntoskrnl/ke/amd64/interrupt.c > URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/ntosk… > ============================================================================== > --- branches/ros-amd64-bringup/reactos/ntoskrnl/ke/amd64/interrupt.c (added) > +++ branches/ros-amd64-bringup/reactos/ntoskrnl/ke/amd64/interrupt.c [iso-8859-1] Mon Nov 17 20:27:04 2008 > @@ -1,0 +1,62 @@ > +/* > + * PROJECT: ReactOS Kernel > + * LICENSE: GPL - See COPYING in the top level directory > + * FILE: ntoskrnl/ke/i386/irq.c > + * PURPOSE: Manages the Kernel's IRQ support for external drivers, > + * for the purpopses of connecting, disconnecting and setting > + * up ISRs for drivers. The backend behind the Io* Interrupt > + * routines. > + * PROGRAMMERS: Timo Kreuzer (timo.kreuzer(a)web.de) > + */ > + > +/* INCLUDES *****************************************************************/ > + > +#include <ntoskrnl.h> > +#define NDEBUG > +#include <debug.h> > + > +/* FUNCTIONS ****************************************************************/ > + > + > + > +BOOLEAN > +NTAPI > +KeDisableInterrupts(VOID) > +{ > + ULONG64 Flags; > + > + /* Get the flags */ > + Flags = __readeflags(); > + > + /* Disable interrupts */ > + _disable(); > + > + return !!(Flags & EFLAGS_INTERRUPT_MASK); > +} > + > + > +BOOLEAN > +NTAPI > +KeDisconnectInterrupt(IN PKINTERRUPT Interrupt) > +{ > + UNIMPLEMENTED; > + return FALSE; > +} > + > +VOID > +NTAPI > +KeInitializeInterrupt(IN PKINTERRUPT Interrupt, > + IN PKSERVICE_ROUTINE ServiceRoutine, > + IN PVOID ServiceContext, > + IN PKSPIN_LOCK SpinLock, > + IN ULONG Vector, > + IN KIRQL Irql, > + IN KIRQL SynchronizeIrql, > + IN KINTERRUPT_MODE InterruptMode, > + IN BOOLEAN ShareVector, > + IN CHAR ProcessorNumber, > + IN BOOLEAN FloatingSave) > +{ > + UNIMPLEMENTED; > +} > + > > Propchange: branches/ros-amd64-bringup/reactos/ntoskrnl/ke/amd64/interrupt.c > ------------------------------------------------------------------------------ > svn:eol-style = native > >

15 years, 10 months

Another WIDL sync, another build breakage

by Olaf Siejka

This is just getting repetitive: [WIDL] obj-i386\include\reactos\idl\lsa_c.c include\reactos\idl\lsa.idl:17: Error: NTSTATUS: redefinition error; original definition was at ( ť: 21 mingw32-make: *** [obj-i386\include\reactos\idl\lsa_c.c] Error 1 mingw32-make: *** Waiting for unfinished jobs.... [WIDL] obj-i386\include\reactos\idl\eventlogrpc_c.c include\reactos\idl\eventlogrpc.idl:7: Error: NTSTATUS: redefinition error; original definition was at Ş■.:21 mingw32-make: *** [obj-i386\include\reactos\idl\eventlogrpc_c.c] Error 1 With all due respect, Eric, would you be so kind and test your commits on more OS than your PC/buildbot???

15 years, 10 months

Re: [ros-dev] [ros-diffs] [greatlrd] 37343: Bugfix : Do not link to LPDDRAWI_DIRECTDRAW_INT->lpLink when we do not have any LPDDRAWI_DIRECTDRAW_INT->lpLcl

by gedmurphy

Is it not time to start getting rid of IsBadWritePtr and friends? I don't see a good reason for these in our own code, especially when we can just use SEH directly. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of greatlrd(a)svn.reactos.org Sent: 13 November 2008 19:52 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [greatlrd] 37343: Bugfix : Do not link to LPDDRAWI_DIRECTDRAW_INT->lpLink when we do not have any LPDDRAWI_DIRECTDRAW_INT->lpLcl Author: greatlrd Date: Thu Nov 13 13:52:20 2008 New Revision: 37343 URL: http://svn.reactos.org/svn/reactos?rev=37343&view=rev Log: Bugfix : Do not link to LPDDRAWI_DIRECTDRAW_INT->lpLink when we do not have any LPDDRAWI_DIRECTDRAW_INT->lpLcl Modified: branches/reactx/reactos/dll/directx/ddraw/startup.c Modified: branches/reactx/reactos/dll/directx/ddraw/startup.c URL: http://svn.reactos.org/svn/reactos/branches/reactx/reactos/dll/directx/ddra… ============================================================================== --- branches/reactx/reactos/dll/directx/ddraw/startup.c [iso-8859-1] (original) +++ branches/reactx/reactos/dll/directx/ddraw/startup.c [iso-8859-1] Thu Nov 13 13:52:20 2008 @@ -33,8 +33,8 @@ This = (LPDDRAWI_DIRECTDRAW_INT)*pIface; - /* fixme linking too second link when we shall not doing it */ - if (IsBadReadPtr(This,sizeof(LPDIRECTDRAW))) + if ( (IsBadWritePtr(This,sizeof(LPDDRAWI_DIRECTDRAW_INT)) != 0) || + (IsBadWritePtr(This->lpLcl,sizeof(LPDDRAWI_DIRECTDRAW_LCL)) != 0) ) { /* We do not have a DirectDraw interface, we need alloc it*/ LPDDRAWI_DIRECTDRAW_INT memThis;

15 years, 10 months

[WIDL] Problems with latest sync

by Olaf Siejka

Since revisions 37313-37314 i observe repetitive problems with WIDL. Every time WIDL is called by our BE, it throws an exception: Faulting application widl.exe, version 0.0.0.0, time stamp 0x491c610d, faulting module widl.exe, version 0.0.0.0, time stamp 0x491c610d, exception code 0xc0000005, fault offset 0x00005f0a, process id 0x17f8, application start time 0x01c945b3aefa8530. > [WIDL] obj-i386\include\reactos\idl\svcctl_s.c > [WIDL] obj-i386\include\reactos\idl\svcctl_s.h > mingw32-make: *** Waiting for unfinished jobs.... > mingw32-make: *** [obj-i386\include\reactos\idl\svcctl_s.h] Error -1073741819 (0xC0000005) > mingw32-make: *** [obj-i386\include\reactos\idl\svcctl_s.c] Error -1073741819 (0xC0000005) Reverting revisions 37313 and 37314 fixes this problem. Apart from me, this issue been noted by dreimer, encoded and Christoph_vW. Dunno about Christoph, but me, dreimer and encoded are using Vista/2008. I couldnt replicate this issue on XP/2003 though.

15 years, 10 months

1st stage GUI setup and file system managment

by Matthias Kupfer

Hi folks, during the development of the 1st-stage-GUI-setup I experienced some problems with physical drive detection with reactos api (because it's fairly incomplete - it works under windows). To continue the development and to bring more benefits I want to make following suggestion. Sooner or later we need a drive/volume/partition management tool, so i will continue with this basing on the usetup code and replaced later by working reactos api calls. So we can use this tool to determine the current harddisk(s) layout(s), create/delete partitions, format with different file systems and show/install/configure the current boot loader. Later I can use this functions to handle the drives during installation process in a similiar way. What do you think about this plan? Matt -- Matthias Kupfer Telefon +49 (0) 371 236 46 52 Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54 09122 Chemnitz

15 years, 10 months

Add a linkerflag to make sure we get an .eh_frame section

by Dmitry Gorbachev

Hi, > Todo: Get it at the end of the executable, so we can safely remove it. I think it can be safely removed from inside of the executable — just wasting some address space.

15 years, 10 months

Re: [ros-dev] [ros-diffs] [gschneider] 37281: Implement ConvertSecurityDescriptorToStringSecurityDescriptorW based on Wine code.

by Steven Edwards

On Mon, Nov 10, 2008 at 9:25 AM, <gschneider(a)svn.reactos.org> wrote: > Author: gschneider > Date: Mon Nov 10 08:25:24 2008 > New Revision: 37281 > > URL: http://svn.reactos.org/svn/reactos?rev=37281&view=rev > Log: > Implement ConvertSecurityDescriptorToStringSecurityDescriptorW based on Wine code. Please add the appropriate copyright headers to the source file stating the original author when implementing code based on third party sources. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

15 years, 10 months

seh 64

by Timo Kreuzer

Hi, I have recently been working on getting SEH into the x64 port. This covers several parts. One of them is compiler support. On x64 SEH is table based rather than code based, that means it needs tables of unwind data. These can be generated from DWARF unwind info - which gcc generates - and that's what I'm working on. The x64 version of rsym shall parse the DWARF unwind data and convert it into Windows compatible unwind data. Now there is a problem. While older versions of mingw64 used the ".debug_frame" section, the newer versions use the ".eh_frame" section. That is good and bad at the same time. What does that mean? What's the difference? The .eh_frame section isn't part of the DWARF 2 or 3 specification, it's a GNU extension / part of the LSB-Core specification. Documentation was hard to find, but google is your friend and it seems there's only one major difference to the debug_frame section and that is relative addressing rather than absolute. This is actually very good and saves the day for all modules that live in kernel space, because the addresses are only 32 bits. There is still a problem left. While the .debug_frame section is by default put into the output executable as a seperate section, the .eh_frame section isn't. The default linker script puts it into the ".rdata" section. But there it's kinda lost and I don't want to keep it anyway. With ntoskrnl there's no problem as it uses it's own linker script anyway. I can change it, so the .eh_frame section is put at the end of the executable. But how do I do this for the other modules? Do i need to provide a new default linkerscript for all other modules? Can I "fix" this behavior in RosBE64 (the files in lib/ldscripts seem to be unused)? Or does anyone know a command line option to change this default behavior? Regards, Timo

15 years, 10 months

seh 64

by Dmitry Gorbachev

> Or does anyone know a command line option to change this default behavior? --unique=.eh_frame ?

15 years, 10 months

Re: [ros-dev] [ros-diffs] [cgutman] 37248: - Check the status of IPSendDatagram - Validate the protocol - Use the hash value of the NCE address to get the lock - Simplify TCPAbortListenForSocket - Hardcode the length of the array

by Aleksey Bragin

On Nov 7, 2008, at 11:31 PM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Fri Nov 7 14:31:34 2008 > New Revision: 37248 > > URL: http://svn.reactos.org/svn/reactos?rev=37248&view=rev > Log: > - Check the status of IPSendDatagram > - Validate the protocol > - Use the hash value of the NCE address to get the lock > - Simplify TCPAbortListenForSocket > - Hardcode the length of the array > > + HashValue = *(PULONG)(&NCE->Address.Address); > + HashValue ^= HashValue >> 16; > + HashValue ^= HashValue >> 8; > + HashValue ^= HashValue >> 4; > + HashValue &= NB_HASHMASK; It's used at least three times in the source code, I would do an inline hash-calculating function for that.

15 years, 10 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev