- Ros-dev - ReactOS.org

Task proposals
by Olaf Siejka 26 Apr '11

26 Apr '11

Below, a brief list of tasks i would propose for review at the next meeting. Please post your proposals as well: - LDR rewrite; - HEAP rewrite regression fixup; - CMake adoption; - MSVC adoption; - WineSync; - LIBSync; - Sysreg fixup (stdio problems, transition to pipe, automatical backtrace); - WineTest-with-HEAP-debugging checkup (basically, running every test from suite with heap debugging enabled); - Video Driver fixup (fixing ReactOS to use real video drivers, bug #2286 and all connected);

2 2

Action list
by Olaf Siejka 26 Apr '11

26 Apr '11

Dear colleagues We need to some short-term planning within our project, as the amount of tasks awaiting will simply turn into chaos. I propose a list to be kept, named "Action list". It should list our goals, things to be done, for example Winesync, fixing some particular bug, etc. Every task should be assigned to particular person, who would choose to be responsible for getting it done. It doesn't need to be the only person working on this, but rather someone making sure its done and not forgotten. Other variable assigned to task would be a deadline - approximate one, susceptible to extension when necessary. Goals are removed from the list when completed. Action list should be reviewed at every meeting, by querying people responsible for every task, being asked for an update. I can keep such list. Awaiting proposals for tasks if you think this makes sense. Regards

5 6

Re: [ros-dev] Ros-dev Digest, Vol 80, Issue 28
by Dimas FranK 25 Apr '11

25 Apr '11

Thanks for attention tone I was thinking of developing for ntfs http://www.reactos.org/wiki/index.php?title=Special%3ASearch&search=NTFS 2011/4/25, ros-dev-request(a)reactos.org <ros-dev-request(a)reactos.org>: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Re: Implementing ScmAssignNewTag (bug 6147) (Eric Kohl) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 24 Apr 2011 21:09:19 +0200 > From: Eric Kohl <eric.kohl(a)t-online.de> > Subject: Re: [ros-dev] Implementing ScmAssignNewTag (bug 6147) > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <4DB4755F.1040003(a)t-online.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello Thomas, > > your plan sounds good to me. Just implement ScmAssingnNewTag and attach > the patch to bug #6147. I will review and and apply your patch if it is OK. > > Regards, > Eric > > > Thomas Faber wrote: >> Hi, >> >> I'm thinking about implementing the ScmAssignNewTag function in >> base\system\services\rpcserver.c because of >> http://www.reactos.org/bugzilla/show_bug.cgi?id=6147 >> >> My current plan would be: loop through all service keys in the >> registry, check the Tag values for all that are in the same group, >> and choose either max+1 or the first unused tag. >> >> Any opinions? Would it be important to observe how Windows calculates >> tags? Perhaps Eric has a good overview and thus an opinion on this >> service stuff? ;) >> >> Thanks. :) >> >> Regards, >> Tom >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > > > > ------------------------------ > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > End of Ros-dev Digest, Vol 80, Issue 28 > *************************************** >

1 0

Implementing ScmAssignNewTag (bug 6147)
by Thomas Faber 24 Apr '11

24 Apr '11

Hi, I'm thinking about implementing the ScmAssignNewTag function in base\system\services\rpcserver.c because of http://www.reactos.org/bugzilla/show_bug.cgi?id=6147 My current plan would be: loop through all service keys in the registry, check the Tag values for all that are in the same group, and choose either max+1 or the first unused tag. Any opinions? Would it be important to observe how Windows calculates tags? Perhaps Eric has a good overview and thus an opinion on this service stuff? ;) Thanks. :) Regards, Tom

2 1

RSS feeds on the fron page
by Gabriel ilardi 22 Apr '11

22 Apr '11

Hi team, I've found an rss service (http://www.rssinclude.com) that lets us add our svn activity in the frontage, result would like like this: http://img15.imageshack.us/i/svni.jpg/ I'd like to publish it in our site for all languages, anyone disagrees ? There are better ways to do it, but this is a fast one and we'll have more "news" (fresh info) in our homepage directly and right now.... Please answer. Thanks. Gabriel.

2 2

1st stage gui installer partition manipulation
by Andrew Green 16 Apr '11

16 Apr '11

I have stumbled across this documentation http://doc.sch130.nsc.ru/www.sysinternals.com/ntw2k/source/fmifs.shtml. What it contains discusses how partitions are created. The very cool thing is that by using FMIFS in the installer means that you can delete,create and resize all the partitions that the disk manager supports. This means it will make it a lot easier to add support to both without duplicating efforts.(windows vista+ has resizing xp doesn't seem to though) The current text installer doesn't use this as this part of reactos code is incomplete. I would like to add this to my gsoc proposal. Though I know I'm probably not going to get a place it may help me if I get a chance to do it in the future or maybe this could give ideas to someone else who tries. Any thoughts or suggestions would be very much appreciated.

3 5

Could opensource GPL USB driver for NT4 be help for implementing USB in ReactOS?
by Minas Abrahamyan 15 Apr '11

15 Apr '11

Hi all, The subj. I'm talking about Woodhead's GPL USB driver: * Original page (and site) is dead ("Woodhead--NT4--USB" http://www.geocities.com/mypublic99/index.html ) * But files are backed up, for example, here: [ftp://piekraste.daba.lv/pub/Service_Pack/NT_4/NT4_USB/HS/] (or look into internet wayback machine) Regards, M.A.

3 4

Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS
by Minas Abrahamyan 14 Apr '11

14 Apr '11

Hi all, I'm going to implement dmesg.exe, a ROS application to read dmesg/kmsg buffer (debug messages in kernel buffer), which is filled in by appropriate patch 6018 (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW, it's not yet reviewed and not applied!). So I'm requesting advice on: What would be the better way for user-mode code to get the contents of kmsg buffer in kernel-space (kdbg)? Shortly: Linux has special system call "syslog" (man 2 syslog) FreeBSD uses its special sysctl interface to kernel along with 'kern.msgbuf' parameter. My questions: Do we need special system call like Linux, or even more, the whole family of them (sysctl('*')) as in BSD? How to implement simple system call for it, now? --- Now detailed info for unices: Linux case: * syslog(2) - read and/or clear kernel message ring buffer; set console_loglevel int syslog(int type, char *bufp, int len); * also /proc/kmsg virtual file, which when being read returns buffer contents ==excerpt from man proc == /proc/kmsg This file can be used instead of the syslog(2) system call to read kernel messages. A process must have superuser privileges to read this file, and only one process should read this file. This file should not be read if a syslog process is running which uses the sys‐ log(2) system call facility to log kernel messages. Information in this file is retrieved with the dmesg(1) program. ==eo exerpt== dmesg in FreeBSD: Parameter 'kern.msgbuf' given to sysctl(3) returns contents of kernel message buffer. There is also 'kern.msgbuf_clear' to clean the buffer. --- WBR, Minas Abrahamyan

4 13

Re: [ros-dev] [ros-diffs] [dreimer] 51296: - Sync all resource files with the English one. - Translate the new Dialog in the German one. - Normally we use BEGIN and END, no {} - DIALOG -> DIALOGEX
by Johannnes Anderwald 09 Apr '11

09 Apr '11

Am 09.04.2011 16:46, schrieb dreimer(a)svn.reactos.org: > Author: dreimer > Date: Sat Apr 9 14:46:37 2011 > New Revision: 51296 > > URL: http://svn.reactos.org/svn/reactos?rev=51296&view=rev > Log: > - Sync all resource files with the English one. > - Translate the new Dialog in the German one. > - Normally we use BEGIN and END, no {} > - DIALOG -> DIALOGEX > Hi, This change breaks sndvol32. Have you run sndvol32 after your changes? The reason is sndvol32 parses the dialog template code in memory, but it uses the DIALOG resource format instead of the DIALOGEX resource format. Please revert that partial change. kind regards, Johannes Anderwald

1 0

Re: [ros-dev] IFS wrapper project proposal draft
by Love Nystrom 09 Apr '11

09 Apr '11

Hi Bryan, Just like Aleksey, I would welcome an effort to simplify IFS implementation. Seen as NTFS is (and always will be?) not well documented, I've been thinking about supporting some alternative, OSS, journaling file system in ReactOS, e.g. ReiserFS, to allow us to provide the (relative) fail-safety of file transaction journaling that NTFS has. Also, hopefully, to enable us to implement NT's access privilege system (Security) on files. So far, it remains just a thought, since I can't allocate the time to adapt e.g ReiserFS to an NT IFS, and if I'm not mistaken, our IFS implementation has shortcomings of it's own which You may need to address as well in implementing Your proposal. In addition to "Windows NT File System Internals" I would also recommend "Windows Internals, 4th Edition" for additional/complementary insight. Especially Ch.12 "File Systems", but Ch.8-12 are all relevant, and the whole book is strongly recommended (by everyone, I think). It will be a BIG job I think (thesis big), and I hope You have the structural "common sense" to make it a success, and not a mess ;). It would be most welcome ! Comment Your code scrupulously :) Best Regards // Love On Sun, Apr 3, 2011 at 1:55 PM, <ros-dev-request(a)reactos.org> wrote: > ---------- Forwarded message ---------- > From: Bryan Donlan <bdonlan(a)gmail.com> > To: ReactOS Development List <ros-dev(a)reactos.org> > Date: Sat, 2 Apr 2011 18:26:23 -0400 > Subject: [ros-dev] [GSoC] IFS wrapper project proposal draft > Hello, > > After reading the ReactOS GSoC ideas page, I became interested in the > IFS wrapper driver project idea[1], and would appreciate any comments > on my project proposal before I formally submit it. > > First, a bit about me. I am a student in a dual-major program, > studying Computer Science and Japanese at the University of > Massachusetts at Amherst. I have had some experience in kernel > development previously; as part of an internship at a research project > at my University, I wrote some network flow analysis code running in > the Linux kernel. While filesystem work will be a first for me, I > think it will be an interesting leaning experience. I am fluent in > English and Japanese, and am in the UTC-0400 timezone (TZ=US/Eastern). > My freenode username is bd_, and my myReactOS username is bdonlan. > > In preparation for writing this proposal, I obtained a copy of the > "Windows NT File System Internals: A Developer's Guide" book from > O'Reilly. Although a bit dated, it has been enourmously helpful in > helping me get an idea of what I'm getting into. > > My goal in this project will be to write a library to significantly > simplify writing a NT File System Driver. Although writing a > kernel-mode filesystem will never be as easy as with, eg, FUSE, it > should be possible to abstract away many of the idiosyncracies of the > NT filesystem API, at least. For example, the wrapper library may > handle: > * Automatically queueing asynchronous filesystem operations on a worker > thread > * Parsing paths and invoking a FS-supplied traversal function for each > directory element > * Interfacing with the NT cache manager, including flushing data from > the cache when a non-cached operation is performed on a cached file, > and establishing cache maps for the underlying device for a disk-based > file system > * Providing a common implementation of byte range locks and oplocks, > and disabling fast I/O when they are in use > * Caching directory entry lookups > * Performing typical input validation/security checks needed by all NT > filesystems > * Helper tools may also be provided to load pseudo-filesystems > (filesystems with neither network nor disk backing) on an ad-hoc basis > > Essentially, the library should make it easy for the filesystem > designer to focus on the actual filesystem, rather than the NT IFS > interfaces - a read call would be able to skip all the preparation and > checks, and directly go to perform the actual I/O. > > Major milestones for the project may include: > - Prepare a sketch of the API and callbacks for the IFS helper library > (subject to change if necessary) > - Implement enough of the wrapper library to implement a simple > pseudo-filesystem demonstrating non-cached reads and writes > - Add support for cached reads/writes (interaction with the cache > manager, caching for on-disk metadata) > - Demonstrate a disk-based filesystem without metadata update support > (MINIX FS or FAT?) > - Demonstrate a disk-based filesystem with full read-write support > - If time allows, add support for ancillary features, such as byte > locks, oplocks, and notify watchers. > > The interfaces exposed by the filesystem library will of course be > clearly documented. Filesystems needing more advanced support will > also be able to override any IFS callbacks they choose. > > I have an existing consulting commitment that will take some of my > time, but I expect to be able to put in 20-30 hours of work per week > into this project. Further, I hereby swear that I have not used nor > seen the source code to any version of the Windows operating system > nor any Microsoft product that may be related to the proposed project > that is under a license incompatible with contribution to ReactOS, > including but not limited to the leaked Windows 2000 source code and > the Windows Research Kernel. > > I would appreciate any comments on my proposal before formally > submitting it to the GSoC site. > > Thanks, > > Bryan Donlan > >

6 15

LinuxTag in Berlin
by Matthias Kupfer 08 Apr '11

08 Apr '11

Hi all, Daniel Reimer wrote recently he is unable to organise due to a bereavement for at least one week. So I will try to organise a little bit, even if i don't know all things. To make it short, we need a list of booth personnel for the period 11th May 2011 to 14th May 2011. We have to distinguish between booth personnel and (even project members as) visitors, because as booth member you can enter the fairground a little bit earlier. We have no hard limit, but we should take care of the amount we request. Looking at the schedule we should do this very soon, the deadline was 6th April. So please tell me/us when and in which role you want to attend the LinuxTag in Berlin (we can get free normal tickets for visitors and members if needed). Maybe we should plan time for set up the booth on 10th May 2011. Do we need any posters to prepare? I already know, we are located in hall 7.2b Suggestions, information remarks are very welcome, because I've lost the overview and try to save the event. Matthias -- Matthias Kupfer phone +49 371 236 46 52 Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54 09122 Chemnitz, Germany -- Matthias Kupfer phone +49 371 236 46 52 Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54 09122 Chemnitz, Germany

3 2

gsoc-application-2011
by Armaan 07 Apr '11

07 Apr '11

Hello friends, suggestions on gsoc application improvement needed: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/armaan/8… Thanks Armaan

1 0

GSoC 2011 proposal - lwIP
by Claudiu Mihail 06 Apr '11

06 Apr '11

Hello all, My name is Claudiu Mihail and I would like to introduce myself to the ReactOS community. I am a computer science student from Bucharest, Romania. I've been hanging around the IRC channel for sometime now under the nick KlausM and I would like to participate in this year's GSoC un behalf of ReactOS. As such I have opted for the "TCP/IP Driver Replacement Using lwIP" idea. The reason why I chose this idea is because, after some discussions on IRC with members of the community, it was setteled that this is something that takes priority for ReactOS. I have basic kernel programming experience on both Linux and Windows and am quite familiar with the Win32 API. I have attached a PDF document with my resume and past projects in the hopes that it will help determine if my skill set is compatible with the ReactOS project demands. Time commitment: I will free to work on the ReactOS project I am applying for from the end of april up until the end of august, the current year. I will have 2 week period of exams from the beginning of July up until the 15th of July. Legal Requirements: I declare the following is *true:* * * I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel. Regarding the milestone part I have some basic sketches and would greatly appreciate some pointers. After some discussions on IRC I have elarned that there is already a branch dedicated to using lwIP. Bringing that branch up to date should be the first task. Thus, during the community bonding period I could do this task (if not earlier) and in so doing get familiarized with the ReactOS codebase. After managing to bring the branch up to date versus a trunk checkout I could further begin improving the replacement driver. Yet I would very much appreciate some pointers as to more precise goals. In the end there should be a fully functional driver and a suite of test cases, that much is clear. I don't have any previous experience with lwIP or protocol drivers but I have some kernel programming experience and am willing to learn. Thank you, Claudiu

1 0

March meeting minutes
by Aleksey Bragin 06 Apr '11

06 Apr '11

March Meeting Minutes 2010-03-31 20:30 UTC Fezile IRC Server (fezile.reactos.org), #meeting Participants Present: Giannis Adamopoulos Johannes Anderwald Javier Agustìn Fernàndez Arroyo Maciej Białas Aleksey Bragin Colin Finck Danny Götte Ziliang Guo Rafał Harabień Kamil Hornicek Amine Khaldi Timo Kreuzer Matthias Kupfer Victor Martinez Ged Murphy Sylvain Petreolle Hervé Poussineau Daniel Reimer Pierre Schweitzer Samuel Serapion Olaf Siejka James Tabor Art Yerkes Proceedings ○ Meeting called to order at 20:30 UTC by Colin Finck ○ Point 1 in the agenda: ReactOS member definition ■ This point wasn’t easy to address, since there is no clear criteria to apply in order to define the team members. As a result, a discussion went on and ended up with an accepted proposal. ■ Colin Finck proposed that we skip a fixed definition of the term "ReactOS Member", but instead maintain a list with names employing the following rule: A person is added to this list if at least two existing ReactOS members propose him and the list maintainer (Colin Finck) or alternatively the backup list maintainer (Aleksey Bragin) agrees with their proposal. ■ The participants accepted Colin’s proposal. (15 yes votes, 2 no votes, 3 abstained) ○ Point 2: Current ReactOS work ■ Aleksey: Currently working on ntdll/ldr and kernel32/ldr loaders, his next goal is undecided yet, he will look at what ReactOS needs more from user perspective. ■ Amine: Currently working on the CMake branch, the website revamp and the ideas around it. ■ Art: Currently working on fixing a few crashes running the regression test CD on the NewCC branch. ■ Colin: He has been busy with preparing the 0.3.13 release, then Chemnitz Linux Days, afterwards this meeting. He will be on a trip abroad starting 9th April and will return 13th May, he’s not yet sure what he will do then. ■ Daniel: He will continue to work on RosBE 1.6/2.0. Playing with the new GCC 4.6 right now. He also regularly works on forum moderation, translations and the rapps database. ■ Giannis: He has been working on fixing several bugs in win32k lately. This included multiple issues in ancient code related to handling desktops and window stations. He looks forward to apply for GSoC and work on theming support. ■ Matthias: He is occasionally working on small bugfixes for the ReactOS source tree. His main ReactOS work lies in leading the German foundation and preparing ReactOS appearances at events in Germany (passed Chemnitz Linux Days and upcoming LinuxTag in Berlin). ■ Maciej: Right now, he is investigating forum modules and extensions for Drupal, which could be handy for our users. This is part of the ongoing website revamp (point 6 in the meeting agenda). ■ Olaf: He has been working on our BuildBot, doing some cleanup work and setting up some builders for the NewCC branch and patches. He will handle the remaining issues like a need to backup the VBox test logs. When the new RosBE is out, he is going to try to make use of it within CMake build scripts. He has also been introducing the WIP (Work In Progress) tag in our Bugzilla and is going to push some more bugs marked with the PATCH tag to developers. ■ Pierre: For the moment, he is mainly cleaning up some parts of kernel32, focusing on the code inside the “file” subdirectory. This requires implementing the Mount Manager, which he is also doing. This may help to bring several improvements elsewhere in ReactOS. His work on FsRtl and especially the FsRtlIs*InExpression functions is also still going on. The current implementation will be superseded by a proper algorithm based on a NFA as soon as he has the time. He is moving to the CERN starting on 4th April, so his involvement in the project might change soon. ■ Samuel: He is already working on secur32, lsalib and schannel to refine his GSoC proposal. ■ Sylvain: He has been busy with various tasks related to the CMake branch, regression tests and bug fixing. ■ Timo: He is working on the GDI handle manager, better performance/ scalability, better tracking of errors that could lead to deadlocks/ leaks and minor interface improvements. Will take some time to get it right. ■ Victor: He is continuing working on PR aspects. He has just returned from another show in Huelva (Spain). Youtube videos will be available soon. He will also work on the website revamp and on improving the users forum experience, trying to create testing coordination. He is open to any suggestion regarding PR and attracting new users and developers. ■ Ziliang: Mostly doing GSoC preparation work at the moment. He is also preparing his own GSoC application concerning performance counters. ○ Point 3: Status of our GSoC participation, in particular students and mentors ■ Amine reported that we have got some student applications, but we still await more. As to mentors, so far we need Hervé and Kamil to register as mentors in the web platform, and we welcome more mentors and at least co-mentors to do the same. So far, we have Aleksey, Art, Ged, Pierre and Kamil as confirmed mentors. As to timeline, for student applications it is 8th April, and to get everything sorted out it is 22nd April. ○ Point 4: Upcoming LinuxTag event on 11th to 14th May ■ Matthias reported that our project has been accepted this week for LinuxTag, so we would like to invite all ReactOS Team members to take part. He stated that he will be there the whole time if necessary, but he recommends that more members take part. ■ Victor expressed that he will be there from 11th to 13th. ■ Matthias thinks that we need at least 2 team members per day, and 3-4 team members overall. He also mentioned that, depending on the count of persons, we cannot pay all expenses for accommodation and transport. ■ Colin stressed out the fact that this is Europe's most-important event regarding Open-Source, and that it would not just be a good chance to present the project internationally, but also to get in touch with other ReactOS members. ○ Point 5: Sum up of previous events, ideas for next ones ■ Colin reported that we recently had the Chemnitz Linux Days event again. We presented ReactOS on 4 laptops there, two native and two in VMs. Compared to last year, ReactOS was now able for two major breakthroughs: One of the laptops running in a VM was capable of streaming internet radio all day long, while on the other hand, ReactOS was also able to run natively on a 4-year old system (with SATA controller!). The only caveat preventing the real usefulness of the native system was the lack of a working network driver for the Intel PRO/1000 PL chip. Having an improved network/driver stack would have made the presentation even better. He I assumes we had 50% interested people who already knew about ReactOS and wanted to hear about the updates in the last year, while the other half was completely new to ReactOS. Colin thinks we still have enough potential to make new people aware of the project and maybe even gain more developers. That was just said to understand why we are so eager about PR lately and have the next event in not much more than a month. ■ Victor reported that he has been holding 2 events lately. The major one is Imaginatica'11. We had a booth there and a showroom, and had a lot of visitors quite interested in ReactOS. Even more, we had 2 important visits from a company and CSIC (Spanish investigators) who asked if a Windows driver would work in ReactOS, because they are doing embedded systems. They also asked Victor if we would work on sponsored specific compatibility aspects, which means "if I pay you a certain amount for having OpenOffice and ContaPlus working, will you work on it ?". Victor suggested as a result that this "Compatibility On demand" concept is a possible market. He also was holding another speech in Huelva: "Jornadas Tecnlogicas". The best thing about this was that it is the first time an Event has contacted us to show ReactOS. As a result of the recent events, he noticed that we have to change our presentations style from the quite technical ones to the quite general ones, for a wider audience. He also reported that he was contacted by a new Spanish designer thanks to Imaginatica. This was a direct result of his emphasis on the fact that we don't just need developers, but also skilled members in the other departments, including designers, bloggers, testers, users, etc. Victor will see if this new designer has web design capabilities, in which case he may join our website revamp efforts. ○ Point 6: Website revamp. Current status, who is working, who is willing to help ■ Colin mentioned that we still want a complete revamp of our website, starting from scratch with the articles and also dropping RosCMS and basing everything around the Drupal CMS. He also mentioned that while the design winner from 2009 is still the target design, it needs to be adapted to Drupal now, not just due to the different technology behind Drupal, but also because our Drupal website should be more based on activity (as outlined in our website revamp google document) ■ A technical discussion has been held to try to analyze the needs and discuss how they will be addressed. ■ Victor is in contact with a Spanish designer, hopefully he can work with him on the design department. ■ Ziliang will be taking care of the content department. ■ Maciej will handle the technical aspects of the website revamp, he set up a testing server where we are going to test the Drupal 7-based website revamp. Moving this server to an officially hosted VM is planned. ■ Danny is handling the VM on the ReactOS server. ■ We agreed on working on these different departments in parallel. ○ Meeting ended at 23:57 UTC. ○ Minutes submitted by Amine Khaldi.

1 0

Re: [ros-dev] Windows Internals 5th Edition
by Love Nystrom 05 Apr '11

05 Apr '11

Hi James, Yes, most interesting, but isn't it a little beside point? I mean, we're still targeting the XP kernel in ReactOS, aren't we? Or have I missed a re-targeting point in my absence? WBR // Love 2011/3/31 <ros-dev-request(a)reactos.org> > ---------- Forwarded message ---------- > From: James Tabor <jimtabor.rosdev(a)gmail.com> > To: ReactOS Development List <ros-dev(a)reactos.org> > Date: Wed, 30 Mar 2011 19:23:40 -0500 > Subject: Re: [ros-dev] [ros-diffs] [gadamopoulos] 51115: [ntoskrnl] - > Implement calling OkayToCloseProcedure callouts to win32k for desktop and > window station objects - Fix a bug that caused ObpCloseHandle to return > success even whe... > Hi everyone, > http://www.alex-ionescu.com/ Main Blog, > http://www.alex-ionescu.com/?p=61 Black Hat 2008 Wrap-up <------- here > http://www.alex-ionescu.com/BH08-AlexIonescu.pdf <------------------ read > > I would like everyone (new Developers) that haven't read this blog to > do so and get up to date! > > I'm not sure if M$ fixed their issues, it may not be Server 2003 but > at least 2008 plus or 7. > > Thanks, > James > > ps I have the right to use M$ since 1983........ > > On Tue, Mar 22, 2011 at 9:19 AM, Alex Ionescu <ionucu(a)videotron.ca> wrote: > > It's hilarious how this new code has the exact same Windows security bug > I gave a talk about at BlackHat 2-3 years ago (which Microsoft fixed in > Vista). > > > > It's sad how this code ignores the exported PsSetProcessWindowStation API > and relevant EPROCESS field. > > > > It's awesome how nothing changes whenever I prop up to see the > "progress". > > > > -- > > Best regards, > > Alex Ionescu >

3 6

Brothers In Arms
by Love Nystrom 05 Apr '11

05 Apr '11

Thank You for understanding, Adam! Here's an off-topic for all of You, my Brothers in Arms .. http://www.youtube.com/watch?v=q2rx3IAEISA <http://www.youtube.com/watch?v=q2rx3IAEISA> Happy listening. Peace // Love On Sun, Apr 3, 2011 at 2:21 PM, Adam <geekdundee(a)gmail.com> wrote: > I know exactly what you mean. I live with autism (although not severe) and > depression and it's not good stuff that these things occur. I have seen your > past mails and they are not too shabby. > > Allocating time is a hard thing because unlike ReactOS I do not have a > priority-driven round-robin scheduler. > > Hope you get better soon mate. > > > On Sun, 03 Apr 2011 16:55:38 +1000, Love Nystrom <love.nystrom(a)gmail.com> > wrote: > > As a side note, my shitty RL situation is largely responsible for my >> occasional tantrums, >> for which I am truly sorry. Taking my RL frustrations out on my Brothers >> In Arms is *unfair*. >> I am trying hard to find a more stable RL solution that will allow me to >> allocate time to ReactOS >> coding, but nothing is yet for certain .. all just a glimmer of hope. >> >

1 0

ReactOS Project at LinuxTag 2011 in Berlin
by Colin Finck 04 Apr '11

04 Apr '11

Hi all, Even though Chemnitzer Linux-Tage has not been that long ago, I can already announce that the ReactOS Project has received a sponsored booth at LinuxTag 2011 in Berlin. LinuxTag is considered to be Europe's most important Open-Source event and it takes place from 11th to 14th May at the Berlin Fairgrounds. As it is much more directed at an international audience compared to the Chemnitz event, it would be nice if we can get many ReactOS team members to attend it. So far, I already got a positive answer from Aleksey for 1-2 days, Matthias for the whole time and Victor for an unspecified time. I myself will still be away from Germany during this time, so I won't be able to come. The German foundation might be able to refund some of the transport and accomodation costs, but this also depends on the number of ReactOS members present. On the other hand, this mail should of course also serve as a call for interested people to visit us in Berlin :-) With best regards, Colin

2 1

[GSoC] IFS wrapper project proposal draft
by Bryan Donlan 03 Apr '11

03 Apr '11

Hello, After reading the ReactOS GSoC ideas page, I became interested in the IFS wrapper driver project idea[1], and would appreciate any comments on my project proposal before I formally submit it. First, a bit about me. I am a student in a dual-major program, studying Computer Science and Japanese at the University of Massachusetts at Amherst. I have had some experience in kernel development previously; as part of an internship at a research project at my University, I wrote some network flow analysis code running in the Linux kernel. While filesystem work will be a first for me, I think it will be an interesting leaning experience. I am fluent in English and Japanese, and am in the UTC-0400 timezone (TZ=US/Eastern). My freenode username is bd_, and my myReactOS username is bdonlan. In preparation for writing this proposal, I obtained a copy of the "Windows NT File System Internals: A Developer's Guide" book from O'Reilly. Although a bit dated, it has been enourmously helpful in helping me get an idea of what I'm getting into. My goal in this project will be to write a library to significantly simplify writing a NT File System Driver. Although writing a kernel-mode filesystem will never be as easy as with, eg, FUSE, it should be possible to abstract away many of the idiosyncracies of the NT filesystem API, at least. For example, the wrapper library may handle: * Automatically queueing asynchronous filesystem operations on a worker thread * Parsing paths and invoking a FS-supplied traversal function for each directory element * Interfacing with the NT cache manager, including flushing data from the cache when a non-cached operation is performed on a cached file, and establishing cache maps for the underlying device for a disk-based file system * Providing a common implementation of byte range locks and oplocks, and disabling fast I/O when they are in use * Caching directory entry lookups * Performing typical input validation/security checks needed by all NT filesystems * Helper tools may also be provided to load pseudo-filesystems (filesystems with neither network nor disk backing) on an ad-hoc basis Essentially, the library should make it easy for the filesystem designer to focus on the actual filesystem, rather than the NT IFS interfaces - a read call would be able to skip all the preparation and checks, and directly go to perform the actual I/O. Major milestones for the project may include: - Prepare a sketch of the API and callbacks for the IFS helper library (subject to change if necessary) - Implement enough of the wrapper library to implement a simple pseudo-filesystem demonstrating non-cached reads and writes - Add support for cached reads/writes (interaction with the cache manager, caching for on-disk metadata) - Demonstrate a disk-based filesystem without metadata update support (MINIX FS or FAT?) - Demonstrate a disk-based filesystem with full read-write support - If time allows, add support for ancillary features, such as byte locks, oplocks, and notify watchers. The interfaces exposed by the filesystem library will of course be clearly documented. Filesystems needing more advanced support will also be able to override any IFS callbacks they choose. I have an existing consulting commitment that will take some of my time, but I expect to be able to put in 20-30 hours of work per week into this project. Further, I hereby swear that I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel. I would appreciate any comments on my proposal before formally submitting it to the GSoC site. Thanks, Bryan Donlan [1] - http://www.reactos.org/wiki/Google_Summer_of_Code_2011_Ideas#IFS_Wrapper_Dr…

3 3

(no subject)
by Karl Wechselberger 03 Apr '11

03 Apr '11

1 0

Re: [ros-dev] Meeting on Thursday
by Love Nystrom 03 Apr '11

03 Apr '11

Hi Colin, Please put me on the list as well, would You? Because of a real shitty RL situation I haven't been able to contribute the way I would like to, but believe me when I say I am committed to the success of the ReactOS project. I guess we all have our own reasons.. Mine is by and large to be free of Microsoft! As a side note, my shitty RL situation is largely responsible for my occasional tantrums, for which I am truly sorry. Taking my RL frustrations out on my Brothers In Arms is *unfair*. I am trying hard to find a more stable RL solution that will allow me to allocate time to ReactOS coding, but nothing is yet for certain .. all just a glimmer of hope. Peace // Love On Tue, Mar 29, 2011 at 5:23 PM, <ros-dev-request(a)reactos.org> wrote: > > > Date: Tue, 29 Mar 2011 00:32:20 +0200 > > From: colin(a)reactos.org > > To: ros-dev(a)reactos.org > > Subject: [ros-dev] Meeting on Thursday > > > > Hi folks, > > > > As proposed in our urgent meeting in February, we are going to have > > regular meetings at 20:00 UTC on the last Thursday of every month. Next > > Thursday will be the first time to hold such a meeting. > > > > While I was preparing the technical side (we're going to have a > > dedicated IRC server with voting capabilities this time), Amine and > > Victor have come up with a meeting agenda. We have agreed on the > > following points in this order: > > > > - ReactOS member definition. Proposal is not to establish a fixed > > definition, but decide upon always keeping a list of people and just > > giving hints on how you can get on this list > > - Current ReactOS work. Developers saying what they are working on > > - Status of our GSoC participation, in particular students and mentors > > - Upcoming LinuxTag event on 11th to 14th May > > - Sum up of previous events, ideas for next ones > > - Website revamp. Current status, who is working, who is willing to help > > > > You see that the list is more about inquiring and getting information > > than doing vital decisions this time. The agenda is also prioritized so > > that people may leave if they don't want to participate in website > > discussions for example. > > If nobody else volunteers, Amine would be in the minute taker position > > again and I would take the meeting leader role. > > > > My current list of ReactOS members is as follows. Only these people will > > be able to participate in the discussions and votings, so please tell me > > if I have forgotten anybody or if you want to be added to this list: > > > > - Giannis Adamopoulos (smiley1_) > > - Johannes Anderwald (janderwald) > > - Javier Agustìn Fernàndez Arroyo (elhoir) > > - Maciej Bialas (niski) > > - Aleksey Bragin (abragin) > > - Colin Finck (Colin_Finck) > > - Danny Götte (dangerground) > > - Cameron Gutman (aicom) > > - Ziliang Guo (ZWabbit) > > - Rafal Harabien (rafalh) > > - Kamil Hornicek (Pigglesworth) > > - Amine Khaldi (AmineKhaldi) > > - Timo Kreuzer (tkreuzer) > > - Matthias Kupfer (Collibri) > > - Michael Martin (mjmartin) > > - Victor Martinez (vicmarcal) > > - Roel Messiant (Mephisto) > > - Andrew Munger (WaxDragon) > > - Ged Murphy (GedMurphy) > > - Sylvain Petreolle (Usurp) > > - Hervé Poussineau (hpoussin) > > - Daniel Reimer (dreimer) > > - Pierre Schweitzer (HeisSpiter) > > - Samuel Serapion (encoded) > > - Olaf Siejka (Caemyr) > > - James Tabor (jimtabor) > > - Art Yerkes (arty) >

2 1

GSoC
by mebik＠email.cz 02 Apr '11

02 Apr '11

Hi, I am student IT technology college, I can programming in C, NASM or C#. I want try make project for GSoC. I have some teoretic knowledge about filesystem from school. Can you help me with choice ideas from project ? Thank you

1 0

Re: [ros-dev] [ros-diffs] [rharabien] 51221: [SYSTEMINFO] Don't translate System Type Don't mix TCHARs and chars Fix Time Zone for not English systems Use proper registry key for Install Date Format dates using system setti...
by Ged Murphy 01 Apr '11

01 Apr '11

On 1 April 2011 19:58, <rharabien(a)svn.reactos.org> wrote: > Don't mix TCHARs and chars That's ironic. The use of TCHAR is quite messy in this patch.

1 0

Meeting on Thursday
by Colin Finck 01 Apr '11

01 Apr '11

Hi folks, As proposed in our urgent meeting in February, we are going to have regular meetings at 20:00 UTC on the last Thursday of every month. Next Thursday will be the first time to hold such a meeting. While I was preparing the technical side (we're going to have a dedicated IRC server with voting capabilities this time), Amine and Victor have come up with a meeting agenda. We have agreed on the following points in this order: - ReactOS member definition. Proposal is not to establish a fixed definition, but decide upon always keeping a list of people and just giving hints on how you can get on this list - Current ReactOS work. Developers saying what they are working on - Status of our GSoC participation, in particular students and mentors - Upcoming LinuxTag event on 11th to 14th May - Sum up of previous events, ideas for next ones - Website revamp. Current status, who is working, who is willing to help You see that the list is more about inquiring and getting information than doing vital decisions this time. The agenda is also prioritized so that people may leave if they don't want to participate in website discussions for example. If nobody else volunteers, Amine would be in the minute taker position again and I would take the meeting leader role. My current list of ReactOS members is as follows. Only these people will be able to participate in the discussions and votings, so please tell me if I have forgotten anybody or if you want to be added to this list: - Giannis Adamopoulos (smiley1_) - Johannes Anderwald (janderwald) - Javier Agustìn Fernàndez Arroyo (elhoir) - Maciej Bialas (niski) - Aleksey Bragin (abragin) - Colin Finck (Colin_Finck) - Danny Götte (dangerground) - Cameron Gutman (aicom) - Ziliang Guo (ZWabbit) - Rafal Harabien (rafalh) - Kamil Hornicek (Pigglesworth) - Amine Khaldi (AmineKhaldi) - Timo Kreuzer (tkreuzer) - Matthias Kupfer (Collibri) - Michael Martin (mjmartin) - Victor Martinez (vicmarcal) - Roel Messiant (Mephisto) - Andrew Munger (WaxDragon) - Ged Murphy (GedMurphy) - Sylvain Petreolle (Usurp) - Hervé Poussineau (hpoussin) - Daniel Reimer (dreimer) - Pierre Schweitzer (HeisSpiter) - Samuel Serapion (encoded) - Olaf Siejka (Caemyr) - James Tabor (jimtabor) - Art Yerkes (arty) Everybody may join the meeting channel as a non-participating observer though. I'll hand you all connection details when we're ready. With best regards, Colin

12 18

Re: [ros-dev] [ros-diffs] [gadamopoulos] 51115: [ntoskrnl] - Implement calling OkayToCloseProcedure callouts to win32k for desktop and window station objects - Fix a bug that caused ObpCloseHandle to return success even whe...
by Alex Ionescu 31 Mar '11

31 Mar '11

It's hilarious how this new code has the exact same Windows security bug I gave a talk about at BlackHat 2-3 years ago (which Microsoft fixed in Vista). It's sad how this code ignores the exported PsSetProcessWindowStation API and relevant EPROCESS field. It's awesome how nothing changes whenever I prop up to see the "progress". -- Best regards, Alex Ionescu On 2011-03-22, at 5:19 AM, gadamopoulos(a)svn.reactos.org wrote: > Author: gadamopoulos > Date: Tue Mar 22 09:19:26 2011 > New Revision: 51115 > > URL: http://svn.reactos.org/svn/reactos?rev=51115&view=rev > Log: > [ntoskrnl] > - Implement calling OkayToCloseProcedure callouts to win32k for desktop and window station objects > - Fix a bug that caused ObpCloseHandle to return success even when OkayToCloseProcedure failed > > [win32k] > - Rewrite SetProcessWindowStation to actually set the current window station and close the previous one > - Implement OkayToCloseProcedure callouts from the kernel to prevent closing the current desktop or window station > > Modified: > trunk/reactos/ntoskrnl/ex/win32k.c > trunk/reactos/ntoskrnl/ob/obhandle.c > trunk/reactos/ntoskrnl/ps/win32.c > trunk/reactos/subsystems/win32/win32k/include/desktop.h > trunk/reactos/subsystems/win32/win32k/include/win32.h > trunk/reactos/subsystems/win32/win32k/include/winsta.h > trunk/reactos/subsystems/win32/win32k/main/dllmain.c > trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c > trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c > > Modified: trunk/reactos/ntoskrnl/ex/win32k.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/win32k.c?rev=5… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/win32k.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/win32k.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -37,9 +37,45 @@ > > PKWIN32_PARSEMETHOD_CALLOUT ExpWindowStationObjectParse = NULL; > PKWIN32_DELETEMETHOD_CALLOUT ExpWindowStationObjectDelete = NULL; > +PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpWindowStationObjectOkToClose = NULL; > +PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpDesktopObjectOkToClose = NULL; > PKWIN32_DELETEMETHOD_CALLOUT ExpDesktopObjectDelete = NULL; > > /* FUNCTIONS ****************************************************************/ > + > +NTSTATUS > +NTAPI > +ExpDesktopOkToClose( IN PEPROCESS Process OPTIONAL, > + IN PVOID Object, > + IN HANDLE Handle, > + IN KPROCESSOR_MODE AccessMode) > +{ > + WIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters; > + > + Parameters.Process = Process; > + Parameters.Object = Object; > + Parameters.Handle = Handle; > + Parameters.PreviousMode = AccessMode; > + > + return ExpDesktopObjectOkToClose(&Parameters); > +} > + > +NTSTATUS > +NTAPI > +ExpWindowStationOkToClose( IN PEPROCESS Process OPTIONAL, > + IN PVOID Object, > + IN HANDLE Handle, > + IN KPROCESSOR_MODE AccessMode) > +{ > + WIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters; > + > + Parameters.Process = Process; > + Parameters.Object = Object; > + Parameters.Handle = Handle; > + Parameters.PreviousMode = AccessMode; > + > + return ExpWindowStationObjectOkToClose(&Parameters); > +} > > VOID > NTAPI > @@ -114,6 +150,7 @@ > ObjectTypeInitializer.PoolType = NonPagedPool; > ObjectTypeInitializer.DeleteProcedure = ExpWinStaObjectDelete; > ObjectTypeInitializer.ParseProcedure = ExpWinStaObjectParse; > + ObjectTypeInitializer.OkayToCloseProcedure = ExpWindowStationOkToClose; > ObCreateObjectType(&Name, > &ObjectTypeInitializer, > NULL, > @@ -124,6 +161,7 @@ > ObjectTypeInitializer.GenericMapping = ExpDesktopMapping; > ObjectTypeInitializer.DeleteProcedure = ExpDesktopDelete; > ObjectTypeInitializer.ParseProcedure = NULL; > + ObjectTypeInitializer.OkayToCloseProcedure = ExpDesktopOkToClose; > ObCreateObjectType(&Name, > &ObjectTypeInitializer, > NULL, > > Modified: trunk/reactos/ntoskrnl/ob/obhandle.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ob/obhandle.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/ob/obhandle.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ob/obhandle.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -1752,7 +1752,6 @@ > > /* Detach and return success */ > if (AttachedToProcess) KeUnstackDetachProcess(&ApcState); > - Status = STATUS_SUCCESS; > } > else > { > > Modified: trunk/reactos/ntoskrnl/ps/win32.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/win32.c?rev=51… > ============================================================================== > --- trunk/reactos/ntoskrnl/ps/win32.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ps/win32.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -20,6 +20,8 @@ > PGDI_BATCHFLUSH_ROUTINE KeGdiFlushUserBatch = NULL; > extern PKWIN32_PARSEMETHOD_CALLOUT ExpWindowStationObjectParse; > extern PKWIN32_DELETEMETHOD_CALLOUT ExpWindowStationObjectDelete; > +extern PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpWindowStationObjectOkToClose; > +extern PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpDesktopObjectOkToClose; > extern PKWIN32_DELETEMETHOD_CALLOUT ExpDesktopObjectDelete; > extern PKWIN32_POWEREVENT_CALLOUT PopEventCallout; > > @@ -116,6 +118,8 @@ > PspW32ThreadCallout = CalloutData->ThreadCallout; > ExpWindowStationObjectParse = CalloutData->WindowStationParseProcedure; > ExpWindowStationObjectDelete = CalloutData->WindowStationDeleteProcedure; > + ExpWindowStationObjectOkToClose = CalloutData->WindowStationOkToCloseProcedure; > + ExpDesktopObjectOkToClose = CalloutData->DesktopOkToCloseProcedure; > ExpDesktopObjectDelete = CalloutData->DesktopDeleteProcedure; > PopEventCallout = CalloutData->PowerEventCallout; > KeGdiFlushUserBatch = CalloutData->BatchFlushRoutine; > > Modified: trunk/reactos/subsystems/win32/win32k/include/desktop.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/include/desktop.h [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/include/desktop.h [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -69,6 +69,9 @@ > VOID APIENTRY > IntDesktopObjectDelete(PWIN32_DELETEMETHOD_PARAMETERS Parameters); > > +NTSTATUS NTAPI > +IntDesktopOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters); > + > LRESULT CALLBACK > IntDesktopWindowProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam); > > > Modified: trunk/reactos/subsystems/win32/win32k/include/win32.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/include/win32.h [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/include/win32.h [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -166,6 +166,7 @@ > PCLS pclsPrivateList; > PCLS pclsPublicList; > INT cThreads; > + HDESK hdeskStartup; > DWORD dwhmodLibLoadedMask; > HANDLE ahmodLibLoaded[CLIBS]; > struct _WINSTATION_OBJECT *prpwinsta; > > Modified: trunk/reactos/subsystems/win32/win32k/include/winsta.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/include/winsta.h [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/include/winsta.h [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -82,6 +82,9 @@ > APIENTRY > IntWinStaObjectParse(PWIN32_PARSEMETHOD_PARAMETERS Parameters); > > +NTSTATUS NTAPI > +IntWinstaOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters); > + > NTSTATUS FASTCALL > IntValidateWindowStationHandle( > HWINSTA WindowStation, > @@ -106,4 +109,7 @@ > > PWINSTATION_OBJECT FASTCALL IntGetWinStaObj(VOID); > > +BOOL FASTCALL > +UserSetProcessWindowStation(HWINSTA hWindowStation); > + > /* EOF */ > > Modified: trunk/reactos/subsystems/win32/win32k/main/dllmain.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ma… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/main/dllmain.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/main/dllmain.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -119,6 +119,7 @@ > { > DPRINT("Destroying W32 process PID:%d at IRQ level: %lu\n", Process->UniqueProcessId, KeGetCurrentIrql()); > Win32Process->W32PF_flags |= W32PF_TERMINATED; > + > if (Win32Process->InputIdleEvent) > { > EngFreeMem((PVOID)Win32Process->InputIdleEvent); > @@ -144,6 +145,9 @@ > { > LogonProcess = NULL; > } > + > + UserSetProcessWindowStation(NULL); > + > } > > RETURN( STATUS_SUCCESS); > @@ -220,25 +224,14 @@ > { > if(hWinSta != NULL) > { > - if(Process != CsrProcess) > + if(!UserSetProcessWindowStation(hWinSta)) > { > - HWINSTA hProcessWinSta = (HWINSTA)InterlockedCompareExchangePointer((PVOID)&Process->Win32WindowStation, (PVOID)hWinSta, NULL); > - if(hProcessWinSta != NULL) > - { > - /* our process is already assigned to a different window station, we don't need the handle anymore */ > - NtClose(hWinSta); > - } > - } > - else > - { > - NtClose(hWinSta); > + DPRINT1("Failed to set process window station\n"); > } > } > > if (hDesk != NULL) > { > - Win32Thread->rpdesk = NULL; > - Win32Thread->hdesk = NULL; > if (!IntSetThreadDesktop(hDesk, FALSE)) > { > DPRINT1("Unable to set thread desktop\n"); > @@ -441,6 +434,8 @@ > CalloutData.ProcessCallout = Win32kProcessCallback; > CalloutData.ThreadCallout = Win32kThreadCallback; > CalloutData.BatchFlushRoutine = NtGdiFlushUserBatch; > + CalloutData.DesktopOkToCloseProcedure = IntDesktopOkToClose; > + CalloutData.WindowStationOkToCloseProcedure = IntWinstaOkToClose; > > /* Register our per-process and per-thread structures. */ > PsEstablishWin32Callouts((PWIN32_CALLOUTS_FPNS)&CalloutData); > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -166,6 +166,29 @@ > RemoveEntryList(&Desktop->ListEntry); > > IntFreeDesktopHeap(Desktop); > +} > + > +NTSTATUS NTAPI > +IntDesktopOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters) > +{ > + PTHREADINFO pti; > + > + pti = PsGetCurrentThreadWin32Thread(); > + > + if( pti == NULL) > + { > + /* This happens when we leak desktop handles */ > + return TRUE; > + } > + > + /* Do not allow the current desktop or the initial desktop to be closed */ > + if( Parameters->Handle == pti->ppi->hdeskStartup || > + Parameters->Handle == pti->hdesk) > + { > + return FALSE; > + } > + > + return TRUE; > } > > /* PRIVATE FUNCTIONS **********************************************************/ > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -187,6 +187,21 @@ > return STATUS_OBJECT_TYPE_MISMATCH; > } > > +NTSTATUS NTAPI > +IntWinstaOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters) > +{ > + PPROCESSINFO ppi; > + > + ppi = PsGetCurrentProcessWin32Process(); > + > + if(Parameters->Handle == ppi->hwinsta) > + { > + return FALSE; > + } > + > + return TRUE; > +} > + > /* PRIVATE FUNCTIONS **********************************************************/ > > /* > @@ -915,6 +930,57 @@ > return WinStaObj; > } > > +BOOL FASTCALL > +UserSetProcessWindowStation(HWINSTA hWindowStation) > +{ > + PPROCESSINFO ppi; > + NTSTATUS Status; > + HWINSTA hwinstaOld; > + PWINSTATION_OBJECT NewWinSta = NULL, OldWinSta; > + > + ppi = PsGetCurrentProcessWin32Process(); > + > + if(hWindowStation !=NULL) > + { > + Status = IntValidateWindowStationHandle( hWindowStation, > + KernelMode, > + 0, > + &NewWinSta); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT("Validation of window station handle (0x%X) failed\n", > + hWindowStation); > + SetLastNtError(Status); > + return FALSE; > + } > + } > + > + OldWinSta = ppi->prpwinsta; > + hwinstaOld = ppi->hwinsta; > + > + /* > + * FIXME - don't allow changing the window station if there are threads that are attached to desktops and own gui objects > + */ > + > + InterlockedExchangePointer(&PsGetCurrentProcess()->Win32WindowStation, hWindowStation); > + > + ppi->prpwinsta = NewWinSta; > + ppi->hwinsta = hWindowStation; > + > + > + if(OldWinSta != NULL) > + { > + ObDereferenceObject(OldWinSta); > + } > + > + if(hwinstaOld != NULL) > + { > + ZwClose(hwinstaOld); > + } > + > + return TRUE; > +} > + > /* > * NtUserSetProcessWindowStation > * > @@ -934,44 +1000,15 @@ > BOOL APIENTRY > NtUserSetProcessWindowStation(HWINSTA hWindowStation) > { > - PWINSTATION_OBJECT NewWinSta; > - NTSTATUS Status; > - > - DPRINT("About to set process window station with handle (0x%X)\n", > - hWindowStation); > - > - if(PsGetCurrentProcess() == CsrProcess) > - { > - DPRINT1("CSRSS is not allowed to change it's window station!!!\n"); > - EngSetLastError(ERROR_ACCESS_DENIED); > - return FALSE; > - } > - > - Status = IntValidateWindowStationHandle( > - hWindowStation, > - KernelMode, > - 0, > - &NewWinSta); > - > - if (!NT_SUCCESS(Status)) > - { > - DPRINT("Validation of window station handle (0x%X) failed\n", > - hWindowStation); > - SetLastNtError(Status); > - return FALSE; > - } > - > - /* > - * FIXME - don't allow changing the window station if there are threads that are attached to desktops and own gui objects > - */ > - > - /* FIXME - dereference the old window station, etc... */ > - InterlockedExchangePointer(&PsGetCurrentProcess()->Win32WindowStation, hWindowStation); > - > - DPRINT("PsGetCurrentProcess()->Win32WindowStation 0x%X\n", > - PsGetCurrentProcess()->Win32WindowStation); > - > - return TRUE; > + BOOL ret; > + > + UserEnterExclusive(); > + > + ret = UserSetProcessWindowStation(hWindowStation); > + > + UserLeave(); > + > + return ret; > } > > /* > >

13 23

GSoC 2011 idea
by Ilie Halip 30 Mar '11

30 Mar '11

Hi! My name is Ilie Halip, and I'm a student at the Faculty of Computer Science, in Iasi, Romania. I'd like to take part in this year's Google Summer of Code, and I was browsing the ideas page earlier. What caught my eye was the Management Console, but after some discussions on IRC, I got very excited about another thing not listed on the wiki page for GSoC. It's about implementing support for Windows Error Reporting. It's listed at http://reactos.org/wiki/Missing_ReactOS_Functionality. I think it's doable in less than 3 months, and might prove to be helpful too (the wiki page sais that :P). I'm not sure if you would accept this kind of proposal, so I'm here to ask about that. Also, I would need a mentor to help me with this project - so... would anyone be willing to mentor me, if this project would be accepted? I was also looking at WMI, but I know it's huge, and I'm not sure how much of it would be required to consider such a project successful. Also, another thing I should mention. I do have a full time job right now. That's a reason I didn't dive into anything bigger listed on the ideas page. Even though I do have some experience writing Windows drivers (I wrote a file system filter driver 2 years back), I don't think I'd be able to write an Intel HDA driver in less than 3 months. But I talked to my superiors, and they are willing to let me work part-time during GSoC, so I should be able to work for my would-be project about 30 hours/week. Do you think that's enough? Regards, Ilie.

4 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev