Ros-dev

ros-dev@reactos.org

5791 discussions

DIB code generator
by Ge van Geldorp 08 Jul '05

08 Jul '05

One of the things which has bothered me a bit is the code duplication we have in our DIB engine (subsys/win32k/dib). Most of the BitBlt routines in there are very similar. With the recent interest in optimizations a bunch of new (almost identical) routines were added. Don't get me wrong, I'm not saying that adding those optimizations was a bad idea, I'm just pointing out that we have a lot of code duplication. There are 256 possible ROP codes, we support 1bpp, 4bpp, 8bpp, 16bpp, 24bpp and 32bpp, so in theory there could be 1536 routines with basically the same structure. I've been playing around with the idea to write a code generator which would generate the source code for those routines. That would cut down on the duplicated source code and associated maintenance problems (you only need to change the code generator) while still allowing optimized code for each individual ROP code. Just to give you an idea what such a code generator would look like, I've attached my first attempt. Please note that it doesn't really try to optimize the generated code yet, it's just to give an impression. The code generated (16bpp only atm) is rather large, you can get it from ftp://ftp.geldorp.nl/pub/ReactOS/dib16gen.c if you like (or compile the code generator ("gcc -o gendib gendib.c") and run it). A possible problem is that the generated code is quite large. When using the generated 16bpp code, size of win32k.sys increases by about 350kb. Extrapolating this for all bpps, it would mean that win32k.sys would triple in size. So, I'm wondering what you guys are thinking. Should we basically trade memory for speed? Problem is that I can't quantify the speed increase at the moment. Gé van Geldorp.

8 10

Re: [ros-svn] [navaraf] 16445: Put the page tables and hyperspace at the right place in memory (ie. Windows compatible).
by Hartmut Birr 07 Jul '05

07 Jul '05

navaraf(a)svn.reactos.com wrote: >Put the page tables and hyperspace at the right place in memory (ie. Windows compatible). > > >Updated files: >trunk/reactos/boot/freeldr/freeldr/arch/i386/mb.S >trunk/reactos/boot/freeldr/freeldr/multiboot.c >trunk/reactos/ntoskrnl/mm/i386/page.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > > Hi, on windows the hyperspace area is always 4MB. If you change the size you have also to change the mapping and initialisation functions. - Hartmut

1 0

A few bugs
by Rafal Kupiec 07 Jul '05

07 Jul '05

1) Task manager displays closed / killed software too. Maybe it cannot kill software? Runned software window disappears but in task manager it on runned application list. There's no info about this software in process tab. 2) In browse window I cannot enter in folders. System want to change its name when I double click on it. 3) In Task Manager there's 2x Windows posision in menu (sometimes).

6 8

ReactOS Website
by Rick Langschultz 07 Jul '05

07 Jul '05

I was wondering what software was being run on the ReactOS machine. I know that it is a version of linux and I guess php and mysql. Are there any others?

2 1

#16452 Bug
by Rafal Kupiec 07 Jul '05

07 Jul '05

Blue screen INACCESSIBLE_BOOT_DEVICE :) Nice work.

3 2

Branch for the 0.2.7-Release approaching
by Robert Köpferl 06 Jul '05

06 Jul '05

Hi, the date of the branch for the 0.2.7-release is fastly approaching. I dated it for Monday, 11.06. So there's still over one week ahead. I please you to stop implementing new features but and finish bigger reorganizations in the code. Keep the checked in code compileable. If you have issues concerning the date of the branch, post a message. More or less for my own (but also from comments on the ml) I decided to do a just normal release with normal names. So there will be no "network preview release" or such kind.

3 3

Website
by Murphy, Ged (Bolton) 06 Jul '05

06 Jul '05

Whats happening with this? It seems to have died a death again. Can we appoint some more people to the web team as there have been some great ideas put forward, but nobody seems to be acting on them. Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

1 0

Re: [ros-svn] [ekohl] 16437: Add architecture-specific headers and move I386-specific definitions into them.
by Alex Ionescu 05 Jul '05

05 Jul '05

ekohl(a)svn.reactos.com wrote: >Add architecture-specific headers and move I386-specific definitions into them. > > > Thanks a lot Eric. I did some research on another FIXME that is actually related to your PnP work, which you might want to take a look at. You will notice that DEVICE_NODE has 2 non-NT members. I saw that you had some previous patches concerning this structure that removed some of the ROS-Only fields, and I guess you might want to get rid of the two ones remaning. The first is BusTypeGuid. The correct way it should be handled is through a private array of GUIDs, which is indexed according DeviceNode.ChildBusTypeIndex. When querying, you just return the GUID in IopXxxxx[DeviceNode.ChildBusTypeIndex], and when creating a bus type guid, you just write the index there. I hope that's clear enough. The second is "Address". That field is actually already present in the DDK-documented DEVICE_CAPABILITIES structure. Therefore, when queried for it, simply send an IRP_MJ_QUERY_CAPABILITIES (or whatever the name is) to DeviceNode->PhysicalDeviceObject, and return the DeviceCapabilities.Address. That should be less then 20 lines of code to change, but I don't want to break any PnP features since they aren't my speciality.. Best regards, Alex Ionescu

1 0

PING
by Thomas Weidenmueller 05 Jul '05

05 Jul '05

PING

6 5

Re: [ros-svn] [gdalsnes] 16417: fix premature close og reg key
by TwoTailedFox 04 Jul '05

04 Jul '05

Shouldn't that be 'of reg key'? ;) On 7/4/05, gdalsnes(a)svn.reactos.com <gdalsnes(a)svn.reactos.com> wrote: > fix premature close og reg key > > > Updated files: > trunk/reactos/lib/setupapi/devinst.c > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-svn > -- "I had a handle on life, but then it broke"

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev