Ros-dev

ros-dev@reactos.org

5789 discussions

Re: [ros-dev] 52061 [jgardou] [CMAKE], "According to gcc doc, if header.h is precompiled, the output should be named "header.h.gch" and not anything else.", Knowing it was the first step before actually doing it :-/

by Colin Finck

jgardou(a)svn.reactos.org wrote: > - set(_gch_filename "${_target_name}_${_FILE}.gch") > + set(_gch_filename "${_FILE}.gch") Looks like we're going through the same mess of GNU precompiled headers, which we already had in rbuild: 1) Giving the GCH file a custom name. Problem: It is simply ignored in the build process. 2) Just renaming it to the name of the header file. Problem: If two modules use the same header file with different build options (like #defines), the compiler can only choose one precompiled header and we have a corrupted build. The solution now is to give every GCH file an individual directory whose name contains the module name (like ".gch_smlib", this is what we currently have in rbuild). Concluding from what I see in rbuild, please also note that the GCH file needs to be named "header.h.gch", not "header.gch". Your ${basename} variable sounds like this is not done either in the CMake branch. - Colin

14 years, 1 month

Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes global to match Windows names (in case of debug) - renamed IopDereferenceVpb() to IopDereferenceVpbAndFree(), IopReferenceVpbForVerify() to IopR...

by Alex Ionescu

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) > + {

14 years, 1 month

by Alex Ionescu

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);

14 years, 1 month

by Alex Ionescu

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) > + {

14 years, 1 month

by Alex Ionescu

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)--;

14 years, 1 month

Re: [ros-dev] [ros-diffs] [cgutman] 52055: [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

by Aleksey Bragin

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 >

14 years, 1 month

About ReactOS hive files and end_pages in header being possibly wrong

by Richard W.M. Jones

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/

14 years, 1 month

May Meeting Minutes

by Colin Finck

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.

14 years, 1 month

Regarding Meeting

by Neeraj Yadav

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

14 years, 1 month

Thomas Krenn Support

by Matthias Kupfer

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

14 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev