Ros-dev

ros-dev@reactos.org

5790 discussions

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev