Ros-dev

ros-dev@reactos.org

5789 discussions

Re: [ros-diffs] [hpoussin] 18442: Don't always return STATUS_BUFFER_TOO_SMALL when an error occurs in ZwQueryValueKey.

by Alex Ionescu

hpoussin(a)svn.reactos.com wrote: >Don't always return STATUS_BUFFER_TOO_SMALL when an error occurs in ZwQueryValueKey. >The "if" was triggered because ValueInformation->DataLength is 0xcdcdcdcd at the return of the function > But that means that the memory was freed during the failure, so now the ExFreePool will run into a double-free! >Modified: trunk/reactos/ntoskrnl/io/pnpmgr.c > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/ntoskrnl/io/pnpmgr.c* > >--- trunk/reactos/ntoskrnl/io/pnpmgr.c 2005-10-14 13:00:18 UTC (rev 18441) >+++ trunk/reactos/ntoskrnl/io/pnpmgr.c 2005-10-14 13:04:11 UTC (rev 18442) >@@ -322,15 +322,18 @@ > > *ResultLength = ValueInformation->DataLength; > ZwClose(KeyHandle); > > > >- if (ValueInformation->DataLength > BufferLength) >- Status = STATUS_BUFFER_TOO_SMALL; >- > > > if (!NT_SUCCESS(Status)) > { > ExFreePool(ValueInformation); > return Status; > } > > > >+ if (ValueInformation->DataLength > BufferLength) >+ { >+ ExFreePool(ValueInformation); >+ return STATUS_BUFFER_TOO_SMALL; >+ } >+ > > > /* FIXME: Verify the value (NULL-terminated, correct format). */ > > RtlCopyMemory(PropertyBuffer, ValueInformation->Data, > > Please check this out in more detail... Best regards, Alex Ionescu

19 years, 6 months

RE: [ros-dev] A call for 0.2.8 (Pic of Mozilla)

by Murphy, Ged (Bolton)

Richard Campbell wrote: > But how WELL does mozilla work with it? Well enough we could include it > with 0.2.8? > No, it's still full of bugs. Mozilla won't be included anyway, it's a 3rd party app. 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

19 years, 6 months

Re: [ros-svn] [gdalsnes] 18427: make classes use session wide atom table. should fix bug 899

by Emanuele Aliberti

Hi Gunnar, gdalsnes(a)svn.reactos.com wrote: >make classes use session wide atom table. should fix bug 899 > > >Added files: >trunk/reactos/subsys/win32k/ntuser/session.c > > What are you plans for managing multiple instances of win32k.sys? -- :Emanuele Aliberti

19 years, 6 months

termination bug

by Hartmut Birr

Hi, the termination bug is in co_DestroyThreadWindows. co_DestroyThreadWindows hangs in an endless loop which calls UserRefObjectCo. UserRefObjectCo allocates some bytes from stack with alloca. After some rounds, the kernel stack is eaten up. - Hartmut

19 years, 6 months

Tenative Blocker list for 0.2.8

by WaxDragon

I've gone though bugzilla and reviewed most of the bugs, here are the ones that are blockers, might become blockers, or caveats we need to keep in mind. I'm sure we will get some real blockers when we release RC1, but this is a start. 805 - Shutdown issues http://www.reactos.org/bugzilla/show_bug.cgi?id=805 This one MUST be fixed, it affects the default install configuration. 493 - excessive repainting in tree-view controls http://www.reactos.org/bugzilla/show_bug.cgi?id=493 I would really like to see some action on this, it renders regedit near useless, and I've seen this bug in other list style controls. Pegs the CPU. 688 - AllocConsole fails on real hardware due to i8042prt http://www.reactos.org/bugzilla/show_bug.cgi?id=688 This is one of the blockers from 0.2.7 that we shipped with. Is there anything that can be done about this? Can we put some debug info into the debug builds so we can gather information? 703 - ReactOS is a fat big. Minimum mem reqs exceeded. http://www.reactos.org/bugzilla/show_bug.cgi?id=703 This one is partially fixed. 32MB installs fail on vmware due to the speed of the file copy operation. 880 - Some dlls stop display output when starting in CLI http://www.reactos.org/bugzilla/show_bug.cgi?id=880 Not a huge bug that many people see, but this is holding up hpoussin's PnP work. Discuss, WD -- <arty> don't question it ... it's clearly an optimization

19 years, 6 months

Re: [ros-dev] Font problem on Japanese version of ReactOS

by tsk

Thank you for telling me that bug. I tried to use outline mplus, which doesn't include bitmap data: http://reactos-j.sourceforge.jp/up/img/083.png and tried to use Mona Font with WaxDragon's freetype.dll: http://reactos-j.sourceforge.jp/up/img/084.png Modified freetype.dll works well! But I think there still exist some bug with font rendering. One of them is a line break. ReactOS automatically insert line feeds at space. But Japanese text doesn't use space basically, so ReactOS can't insert line feeds to proper position. Many screenshots: http://reactos-j.sourceforge.jp/up/img/085.zip > mf suggested one could comment out #define > TT_CONFIG_OPTION_EMBEDDED_BITMAPS in > lib/freetype/include/freetype/config/ftoption.h to DISABLE the SBIT > support. Doing some quick testing, this allows Helmut 12pt to render > "correctly", i.e. readable. This may or may not help with the CJK > font. > > tsk, if you would like to try, I put up a modified freetype.dll at > http://waxdragon.homeip.net/~ford/freetype.dll. Give that one a try > and see if it helps with your fonts. > > WD

19 years, 6 months

Firefox progress

by Ge van Geldorp

For a long time we've had problems with firefox hanging during startup. Well, I have some good news, as of r18418 it at least shows its main window, see http://www.reactos.nl/pics/ff1.png There are still lots of other problems, but I'm pretty sure we can fix those too in the next month or so. Gé van Geldorp.

19 years, 6 months

A call for 0.2.8

by WaxDragon

I know how most of the devs feel about releases, but I think it's time to branch 0.2.8. After a period of instability, trunk is now showing stability. GvG and Ged reported surprising stability from the LinuxWorld demo builds, I personally had favorable results from my September State of the Repo tests. Last night I was able to build a ReactOS bootcd under r18404, and then take that bootcd and install it under qemu, under ROS! Gunnar's win32k changes have had some time to bake in and seem ok*. There have been approximately 1800 commits since 0.2.7, and I want those changes to get some general use.. I don't want to *release* now, but I want to tag the branch now, and maybe release in two weeks (which would make three months sine 0.2.7). Putting out an RC1 would give the codebase exposure to the general public, who may find problems we as devs overlook. This will also give devs and testers a change to focus on some of the big issues I see at the moment, *like this mysterious hang we see on shutdown. Also, those who wish to move forward can do so, even breaking / destabilising the tree. Giving us two or three weeks for testing release canidates will also allow for the PnP/USB and ws2_32 work to be merged in before the release. WD -- <arty> don't question it ... it's clearly an optimization

19 years, 6 months

RE: [ros-dev] ReactOS UI Team - Concept, Plan, and: help wanted

by Murphy, Ged (Bolton)

Rick Langschultz wrote: > I am however writing ports for OpenLDAP, Jabber, Apache 2.0, > Tomcat, MaxDB, Postgresql, and MySQL for reactos, But there are already Win32 ports for most of, if not all of these. > but without > networking and service support my efforts are restricted to windows > 2000. That's not really a restriction. IMO, it's better to develop on Windows, get your program working perfectly and then look at testing it in ReactOS. 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

19 years, 6 months

ReactOS UI Team - Concept, Plan, and: help wanted

by Aleksey Bragin

Hi, our UI Team Coordinator - mf - asked me to sent this email on his behalf, because unfortunately mails from his address doesn't reach any mailing-list. Here is the original message: From: mf <mf(a)mufunyo.net> Date: October 6, 2005 1:20:56 AM GMT+04:00 Subject: ReactOS UI Team - Concept, Plan, and: help wanted Greetings ReactOS developers and interested parties! For the unintroduced, I am your humble UI coordinator. In addition, I also made some graphics for the project. -Concept- I am here to remind you of a post that was made in the ReactOS user forum, written by crappish (Mikko Tikkanen). In it the author wrote of the need of a consistent user interface, the need of people that actually have knowledge of such things, and how these people would have to be in charge of enforcing such an interface. They should be familiar with Windows, know how to make things accessible and newbie- friendly, and have enough creativity to improve on existing concepts. In addition to that, there should be someone who represents this team and can interface it with the rest of the project, and make sure everything is the way everyone wants it to be. Now, this representative has been chosen. But there is no team to back him up! -Recruiting- So getting down to business. The UI team is recruiting two kinds of people. Primarily: Programmers who have sufficient knowledge to hack other people's code, even if said code is rooted deeply in system libraries. Skill in writing user interfaces and piecing together dialog resources. No advanced skills beyond that required. This is most important, since developers in this category can get straight to business and get started on improving ReactOS. Secondarily: Interface concept designers who have advanced knowledge of human interfacing, easy access, logical positioning, and the creativity to improve and expand on existing ideas. This is a secondary category because a) right now there is little to do in this respect, b) there are already two (counting Mikko?) of these people in ReactOS, and c) for every 1 concept designer, there can be up to 10 implementing developers. Even more appreciated, would be someone who fits both gloves and can write code AND design interfaces. Sadly, experience proves that these two traits don't usually come together in one person. And! Just as important, though not actively recruited, I welcome icon designers, graphic designers, font designers (that includes you, wierd_w!), sound effect samplers, and programmers willing to implement missing UI features (think of things such as extended cursor/icon support, alpha blitting, runtime freetype configuration, recycle bin functionality, control panel, autorun support, etc), on individual application (mail me at mf(a)mufunyo.net). -Plan- The plan(tm) to kickstart the UI team is as follows: Our first goal will be to make the surface experience of ReactOS familiar. Surface in this context means the things a user will see during and after bootup. This mainly involves modifying explorer; to display a consistent and familiar start menu, and to show a friendly explorer when My Computer or the Explore link is opened. This means making all the surface icons consistent (my task), modifying explorer's interface (the 'programmer' category), and figuring out the best layout for the start menu (the 'designer' category). There is no plan past this first task, because I cannot predict how small or big the team is going to be, what feedback we are going to get, and how fast things will move. And that's it for my first big announcement. I hope this will get some discussion going, and some balls rolling. I would also like to take this opportunity to request a mailing list for the UI team, this should have been set up right after the coordinator vote was over, but it wasn't-- so to whoever's in charge of that, I count on you. Thanks. Please reply to this mail only on the general list or to me in person (if you're not on the list and only get digests), it is only crossposted in ros-dev to get a wider range of attention. Thanks for reading, mf.

19 years, 6 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