Ros-dev April 2011

ros-dev@reactos.org

32 participants
27 discussions

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev April 2011