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.
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
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
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
>
>
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
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
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.
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
>
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.
>>
>