You are rebrowsing the *whole* list, yet the caller gave you an argument (DriverObjectListSize) that indicated to you how large his array is.
You should browse the minimum of the whole list while making sure that "Index" does not grow larger than DriverObjectListSize / sizeof(pointer).
Right now the function is overwriting memory possibly.
This is because + /* Then, check if given buffer is big enough to contain list */
+ if (ListSize > DriverObjectListSize / sizeof(PDRIVER_OBJECT))
+ {
+ Status = STATUS_BUFFER_TOO_SMALL;
+ }
+ else
is incorrect. The function attempts to write as many entries as possible instead of failing.
As per the docs:
" Note that if the array at DriverObjectList is too small, the number of driver object pointers that are copied into the array will be less than ActualNumberDriverObjects."
--
Best regards,
Alex Ionescu
On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote:
> + /* Rebrowse the whole list */
> + ListEntry = IopFsNotifyChangeQueueHead.Flink;
> + while (ListEntry != &IopFsNotifyChangeQueueHead)
> + {
As per elementary Windows Driver Development basics, resources should ALWAYS be acquired within a critical or guarded region.
--
Best regards,
Alex Ionescu
On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote:
> + /* Acquire the FS lock */
> + ExAcquireResourceExclusiveLite(&IopDatabaseResource, TRUE);
You misunderstand the meaning of the parameter. The last entry is the RAW file system. This parameter influences if RAWFS should be notified or not.
--
Best regards,
Alex Ionescu
On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote:
> + /* Check if we reached end and if we have to skip it */
> + if (ListEntry->Flink == ListHead && SkipLast)
> + {
You need to cast to volatile.
(Same for Increment).
There's also no need to return the old value.
--
Best regards,
Alex Ionescu
On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote:
> + OldValue = (*Ulong)--;
With all my respect to the hard work put into this, I want to express
my concerns:
Why is there a need to develop a half-done fdc, if there is a full,
working, tested by millions driver available even in old DDKs, which
we can use without violating its license?
Why waste time writing that driver from scratch now when we could
just import DDK's one and spend time fixing our PnP manager instead,
and other involved components so that DDK's driver actually works?
Again, with all my respect to Cameron, he does a great job, but when
he disappears next time for a year or two, who is going to finish
FDC? Or any other of his half-finished branches? (each being really a
pearl if it's done).
I would really suggest using all available resources first and only
then spend time developing our own stuff instead of already existing.
Thanks for understanding,
Aleksey.
On Jun 2, 2011, at 10:24 AM, cgutman(a)svn.reactos.org wrote:
> Author: cgutman
> Date: Thu Jun 2 06:24:25 2011
> New Revision: 52055
>
> URL: http://svn.reactos.org/svn/reactos?rev=52055&view=rev
> Log:
> [FDC]
> - Implement fdc.sys (still needs work but fairly complete)
> [TXTSETUP.SIF]
> - Load fdc.sys for floppy controllers
> [FDC.INF]
> - Install fdc.sys for floppy controllers
>
> Added:
> trunk/reactos/drivers/storage/fdc/CMakeLists.txt (with props)
> trunk/reactos/drivers/storage/fdc/directory.rbuild (with props)
> trunk/reactos/drivers/storage/fdc/fdc/CMakeLists.txt (with
> props)
> trunk/reactos/drivers/storage/fdc/fdc/SOURCES (with props)
> trunk/reactos/drivers/storage/fdc/fdc/fdc.c (with props)
> trunk/reactos/drivers/storage/fdc/fdc/fdc.h (with props)
> trunk/reactos/drivers/storage/fdc/fdc/fdc.rbuild (with props)
> trunk/reactos/drivers/storage/fdc/fdc/fdc.rc (with props)
> trunk/reactos/drivers/storage/fdc/fdc/fdo.c (with props)
> trunk/reactos/drivers/storage/fdc/fdc/pdo.c (with props)
> Modified:
> trunk/reactos/boot/bootdata/txtsetup.sif
> trunk/reactos/drivers/storage/CMakeLists.txt
> trunk/reactos/drivers/storage/directory.rbuild
> trunk/reactos/media/inf/fdc.inf
>
Hi, I'm one of the authors of hivex, a program for reading Windows
registry hive files:
http://libguestfs.org/hivex.3.html
The library can't currently read ReactOS hive files. I'm *very*
hestitant to say anyone is "wrong" here since the documentation for
hive files is obviously non-existent, but it appears that ReactOS
doesn't fill in the end_pages field in the header, and instead relies
on the size of the file itself.
For example, a hive downloaded from a fresh ReactOS install:
hivex_open: header fields:
file version 1.3
sequence nos 3 3
(sequences nos should match if hive was synched at shutdown)
original file name
(only 32 chars are stored, name is probably truncated)
root offset 0x70 + 0x1000
** end of last page 0x1000 + 0x1000 (total file size 0x22000)
checksum 0x8dc38fdf (calculated 0x8dc38fdf)
Notice that "end of last page" field is 0x1000, versus a completely
different file size.
hivex currently refuses to read past the end_pages limit, and we are
able to read every Windows hive that has ever been thrown at us.
If I hack hivex so that it ignores end_pages and simply uses the size
of the file as a guide, then hivex can successfully read the whole of
the file.
However I'm a bit unwilling to make this change to hivex just for
ReactOS, since it works fine with real Windows already.
So I wonder if this could just be a mistake in ReactOS or if there's
some deeper reason that I'm missing.
TIA,
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
May Meeting Minutes
2011-05-26
20:05 UTC
Freenode, #reactos-meeting
Participants
=============
- Aleksey Bragin
- Art Yerkes
- Cameron Gutman
- Claudiu Mihail
- Colin Finck
- Gabriel Ilardi
- Ged Murphy
- Giannis Adamopoulos
- James Tabor
- Jan Blomqvist Kinander
- Javier Agustìn Fernàndez Arroyo
- Johannes Anderwald
- Kamil Hornicek
- Maciej Bialas
- Matthias Kupfer
- Neeraj Yadav
- Olaf Siejka
- Pierre Schweitzer
- Rafal Harabien
- Samuel Serapion
- Sylvain Petreolle
- Thomas Faber
- Timo Kreuzer
- Victor Martinez
- Ziliang Guo
Proceedings
============
○ Meeting called to order at 20:05 UTC by Aleksey Bragin.
○ Point 1: Status of our GSoC participation
--------------------------------------------
■ ReactOS' GSoC administrator Ged Murphy gave a quick update about
individual participants:
- Timo Kreuzer is way ahead of the timeline and already has his
font driver working under Windows. He later showed these
screenshots:
* http://imageshack.us/photo/my-images/156/ftfd.png/
* http://imageshack.us/photo/my-images/5/roxxc.png/
* http://imageshack.us/photo/my-images/220/wtfishappening.png/
* http://imageshack.us/photo/my-images/199/ie1d.png/
The major remaining work is implementing the appropriate interface
to make the font driver usable under ReactOS.
- Giannis Adamopoulos is also progressing well and has already
committed a lot of code regarding theming. He later showed these
screenshots:
* http://img846.imageshack.us/img846/8500/theme2.png
* http://img88.imageshack.us/img88/9660/theme3v.png
* http://img691.imageshack.us/img691/7425/theme1c.jpg
- Thomas Faber, who works on the kernel-mode test suite, has been
pretty quiet so far, but is considered a trustworthy person who
knows what he is doing and does not need much help from the
community.
- Claudiu Mihail is considered a great student who is always
available on IRC and often asking questions. His lwIP driver is
progressing well, although he agrees that there is still much
work left.
- Andrew Green has taken the task to complete our new Explorer, but
there were a few issues with what he thought he was doing and what
we wanted from him. He assumed he had to work on the explorer_new
application itself while we actually need work done on related
components like shell32 and browseui. Ged thinks he might have
underestimated the workload a little, so some help from the
community might be required. This is also why Ged has begun to
work on shell32 himself and merge the latest changes with the C++
code by Andrew Hill.
Ged explicitly asks for more developers to join these efforts.
It would be great if these people had experiences with COM,
although this could also be a nice task for developers who want
to learn a bit about COM.
○ Point 2 (added): Neeraj Yadav's participation in GSoC
--------------------------------------------------------
■ Ged Murphy gave a quick background on what happened regarding Neeraj
Yadav, who was meant to work on the Audio Mixer project:
- After Google announced the project, Neeraj Yadav disappeared for
4 weeks and was not reachable by E-Mail or IRC.
- Ged has spoken to Carol Smith from Google afterwards, who
mentioned that some students waited for the first payment and then
fled.
- After a lot of discussion, it was necessary to inform Google that
we had lost a student.
- Ged has written some very apologetic mails to Google afterwards,
and they were pretty understanding.
- He has especially emphasized that this was a very bad time for us
and made the project looking incompetent. Apart from him, Amine
Khaldi and Johannes Anderwald (his mentor) were very angry about
this as well.
- Two days after these mails, Neeraj Yadav reappeared on IRC.
■ Neeraj Yadav said he was really sorry about his mistake, but also
explained his actions:
- He mentioned that his case was actually the opposite of what
Google might assume: While some students keep in contact with the
organisation until they get their first payment, he actually
disappeared during the community bonding period, but was available
again on the first day when coding started.
- His sudden absence occurred, because he needed to move to his
brother who lives in a remote place with no internet connectivity.
■ Ged again emphasized that a wrong decision on this can affect our
further participation in Google's Summer of Code project.
■ After a long discussion, it was decided that this matter requires a
private conversation between Johannes Anderwald and Ged Murphy and a
final decision needs to be taken by them.
Please note that this is a very shortened version of the discussion and
you should not build an opinion about the issue just from this information.
○ Point 3 (added): Changes in the meeting organisation
-------------------------------------------------------
■ Victor Martinez proposed to create a list of E-Mail addresses of
ReactOS Members, who are then informed one week before the meeting takes
place.
- This idea was immediately rejected by Aleksey Bragin and Samuel
Serapion, because we have the ros-dev mailing list for this.
- Victor Martinez then proposed that someone at least sends a mail
to ros-dev one week in advance. Colin Finck, Gabriel Ilardi, Jan
Blomqvist Kinander and Pierre Schweitzer agreed to this.
- Colin Finck proposed that Aleksey Bragin could take this job.
Aleksey Bragin agreed.
■ Jan Blomqvist Kinander asked whether we could already begin at 19:00
UTC. This required a voting between all participants (excluding the
people who only came to us through GSoC). As Colin Finck has not fixed
the IRC server with voting capabilities yet, the voters were publicly
asked about their opinion. Result:
- 17 positive votes
- 1 abstention
- 0 negative votes
The remaining participants were not available and did not vote. Even
without them, this result shows that we have a clear simple majority, so
further meetings will begin at 19:00 UTC.
○ Point 4: Current ReactOS work, Developers reporting their status
-------------------------------------------------------------------
■ Aleksey Bragin had a busy month, which began by giving a technical
lecture about ReactOS at Prague's technical university in the faculty of
informatics. It was received quite well with enough of interesting
questions. Afterwards, he moved to Berlin to join Matthias at our
LinuxTag booth. He describes the event as a very crowded and well
advertised one. On top of this, the ReactOS booth was located quite
close to the entrance, so we received a lot of visitors. Despite
LinuxTag being Europe's biggest Open-Source event, 99% of the incoming
people were German, so Matthias had to handle most of them.
Regarding ReactOS development, Aleksey is still working on his LDR
rewrite and fixed a few of the blocker bugs. There is still one serious
problem left until he can commit the rewrite to Trunk and gradually
improve it there, which should be done much faster. When this is done
and there are no new regressions left, he wants to perform a full Wine sync.
■ Art Yerkes has spent most time working on DWARF symbols. He made slow
progress towards reading the arguments off the stack as described by the
DWARF debug information. After Colin Finck asked, he also reported about
NewCC being in the same state as before, namely still requiring
performance improvements and regression testing until it can be merged
back to Trunk.
■ Cameron Gutman has been doing work on the PnP manager involving hot
swapping devices (like implementing device ejection, surprise removal,
etc.). He is almost done with his implementation of
IoRequestDeviceEject. The code is currently unused, but the USB work
might be a good testcase for it.
■ Colin Finck has returned to Germany two weeks ago and has been busy
with (mostly routine) foundation and server work. He is also relocating
in August, so he might be missing time for ReactOS work afterwards. For
now, his list basically inclues three ReactOS-related points:
- Fixing the bug in the IRC server we used for the March meeting
- Starting work on "RosBE 2.0" (certainly together with dreimer),
which also includes establishing fixed build tool versions for the
big CMake rollout
- Helping with the big website revamp
■ Gabriel Ilardi is quite busy lately, so he is mainly following the
forum and contributed some bitmaps for logonui.
■ Giannis Adamopoulos is exclusively working on the Theming task for GSoC.
■ Ged Murphy as our GSoC administrator has been pretty busy with related
work. However, he has recently started to work on the conversion of
shell32 to C++ and just finished merging back all changes from the C
version. He especially wants to thank Andrew Hill for his first work on
the C++ version and in particular his ATL headers, which give us a true
OO COM implementation. Additionally, he has started work on a logonui
module, but this is just a fun project for now. Finally, he has a
partially working NTFS driver, but this project is currently put on hold.
■ James Tabor is researching bug reports and building a list of related
issues and problems in the server-side window procedures. As we
currently do not have a functional screensaver, he is also trying to fix
this.
■ Jan Blomqvist Kinander is planning a new burglar-proof server bunker
fire cell at his workplace and will move our Fezile server (currently
hosting Doxygen and ISO Storage) there. He is also planning to make room
for a LAN behind the Fezile server, which we could use for automatic
tests on real hardware.
■ Johannes Anderwald is teaming with Michael Martin to develop the USB
stack. The current goal is to bring a working USB mass storage stack to
ReactOS. From this perspective, the goal is already reached for USB 2.0.
Today, he also got OHCI 1.1 mass storage support working and added some
fixes for keyboard/mice support in the USBOHCI driver. This still
requires proper HID support in a higher class driver though. The next
goals probably include UHCI support and synchronizing the work with
Cameron's PnP fixes and Pierre's Mount Manager work.
■ Kamil Hornicek has been arranging Aleksey's speech in Prague, but did
not have time for other ReactOS-related work. If anybody has an
interesting side project, he is willing to find some spare time for it
though.
■ Maciej Bialas hopes to get back to working on our new website in the
next one or two weeks. He has lately been setting up a local Bugzilla
and evaluated its authentication capabilities when combined with Drupal CMS.
■ Matthias Kupfer has been attending our LinuxTag booth for all three
days and is now working on a lot of "end-user-visible" parts in his
spare time. Since LinuxTag, he has started with the internationalization
of registry entries and small changes like adding the progress bar back
to FreeLdr. Besides, he also does routine work for the German ReactOS
foundation.
■ Olaf Siejka has been working on testing and pushing patches (as
reported by Gabriel Ilardi). He also reported that the CMake/MSVC builds
are now compiled from Trunk, but he needs to reinstall his Buildslave
with Windows 7 SP1 and thinks about buying a fast SSD for it. Finally,
he is in the middle of converting Polish resources to UTF-8 and perform
some cleanup and style corrections in the process.
■ Rafal Harabien has been busy with real life issues lately, but plans
to fix our cursors implementation in Win32k soon and clipboards afterwards.
■ Samuel Serapion is writing code for NTLM authentication stuff and will
move to the MSV1_0 and LSA modules afterwards. He referred to
http://msdn.microsoft.com/en-us/library/aa378753%28v=vs.85%29.aspx for
explanations about what these modules are used for.
■ Timo Kreuzer is exclusively working on the FreeType font driver for GSoC.
■ Victor Martinez has been presenting ReactOS at small Spanish
conferences about Open-Source in Seville and Huelva (again) before he
joined Aleksey and Matthias at LinuxTag in Berlin. Lately, he has been
modifying the Testing Central Wiki page, where the GoldenApps now point
to the Compatibility Database. Finally, he plans to establish a real
Testing Team (mainly from Forum users) together with Olaf.
■ Ziliang Guo has been working on several things like building and
verifying the drivers which are going to be signed with the ReactOS
Foundation certificate. He is also testing out a new MSI installer for
RosBE-Windows. His work towards the website overhaul is currently on
hold, because he first needs to install some more modules.
○ Meeting closed at 22:36 UTC by Colin Finck on behalf of Aleksey Bragin.
○ Minutes written by Colin Finck.
Hi,
I am a GSoC student working on Audio Mixer Project.Unfortunately, I was not
able to contact my mentor/administrator during community bonding period.I
have disappointed whole of the community and you have every right to be
angry and I am really sorry for my act.But I request you all to reconsider
the following points :
1. Firstly, Why would one disappear during community bonding period without
any reason ? It is the easiest part of the whole program for a student in
which they have to just talk to the community, which I think they have
already been doing for not less than a month, then what is the problem in
being in contact for another month.
In my opinion a smart student who just wanted his initial payment would have
disappeared after the community bonding period.Instead of coming back at the
time of actual work.
2. Some of you think that I was waiting for initial payment and then
reappeared when i did not get it, I would like to say that I appeared
without even knowing that my project has been discontinued, neither had
anyone got his welcome package upto that time.Nothing regarding my project
discontinuation had been reported in Melange.How could i get even a
slightest idea about my project's termination.
3. Some of you think that it is going to hurt the reputation of organisation
for next year's selection at GSoC, I would like to admit that terminating my
project will straightaway decrease project completion rate of ReactOS
organisation to 80% and it may further reduce if some students actually do
not complete the project which is considered too bad for an organisation.And
believe me next year's sole criterion for organisation selection will be
this success rate.
4.Problems occur to every organisation and Google understands it very well
and it doesn't affect the organisation's reputation that much.All that
matters is the success rate.
5. I talked to Google and they just want an email of consent from my mentor
and its not too late.I have filled all my forms in due time.
6. My project would have automatically been discontinued if I failed for
Mid-term Evaluation.But no one gets benefit if my project is discontinued
earlier.Take a chance guys, If I complete my project it will be good for
both me and community if not terminating my project at both
7. In case above explanations do not satisfy you and if you think this is
only money I am after, I am ready to deposit $500 as security which is equal
to the initial payment.[or whatever amount you say]
This issue can be discussed in today's meeting.I am ready to answer all of
your questions.I hope you will think about it with a cool mind keeping the
anger/ego apart.
--
Regards
Neeraj Yadav
Undergraduate Student
Indian Institute of Technology, Delhi
HI folks,
the German company Thomas Krenn AG (Server Hardware) announced on LinuxTag an
open source support programme for open source projectes, that register during
LinuxTag. So I've use this chance and made the first step and registered
ReactOS. Now we need some arguments what kind of hardware do we need and why
resp. for what purpose. Devs please take a look at thomas-krenn.com and
select a usefull set of hardware and describe what is usefull for. I think we
should define specific tasks, not "upgrade exisiting hardware", but e.g. "New
continuous integration server". Please send the description and the ID of the
basket to me. The prices are:
1st: hardware for 2500 € (excluding VAT)
2nd: hardware for 1500 € (excluding VAT)
3rd: hardware for 1000 € (excluding VAT)
4th: hardware for 800 € (excluding VAT)
5th: hardware for 700 € (excluding VAT)
They told me at the booth the chances increase with the detailed description
of the intended use of the selected hardware (maybe combined with neediness).
Best regards
Matthias
--
Matthias Kupfer phone +49 371 236 46 52
Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54
09122 Chemnitz, Germany
Hi, I will have to take down the Fezile server for a short period of time in about 2 weeks due to a move of the server room to a fireproof, fairly burglarproof security room (brickswork with steeldoor, no windows). However, it is beeing remodelled right now, and then the aircondition, ethernet lines and power is going to be installed, so I guess two weeks.
I have some computers to move so the power down may take some time, but I will try to make the move as fast as possible.
During this time I will try to prepare for a ReactOS LAN behind the Fezile server on the second and third LAN adapter, for example for build testing on real hardware or another build bot.
Yours sincerely,
Jaix Bly (Jan Blomqvist Kinander)